1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@honda-dev-jp

古いLIFEBOOKをUbuntu開発機にする【4. Docker Engine構築編】

1
Last updated at Posted at 2026-09-10

目次

はじめに

メインPCのDELLでフリーズやWSL切断などの不調が発生し、修理・切り分け中もLaravel開発を止めないため、以前使っていた古いLIFEBOOKをUbuntu開発機として再利用しています。

これまでにLIFEBOOKへ Ubuntu 24.04.4 LTS Desktop をインストールし、OpenSSH Server、公開鍵認証、UFW、Git、GitHub CLI、VS Code Remote - SSHなどの開発基盤を整えてきました。

今回の第4回では、LIFEBOOKへ Docker DesktopではなくDocker Engineを直接インストールします。

目的は、UbuntuホストへPHP・MySQL・Apacheなどを大量に直接インストールするのではなく、今後Laravel / SailをDocker上で動かせるようにすることです。

最終的には次の構成を目指します。

メインPC
  │
  │ 家庭内LAN
  │ SSH / VS Code Remote - SSH
  ▼
LIFEBOOK
Ubuntu 24.04.4 LTS Desktop
  ├─ OpenSSH Server
  ├─ Git / GitHub CLI
  ├─ Docker Engine
  ├─ Docker Compose Plugin
  └─ Laravel / Sail

今回はDocker公式ドキュメントの Ubuntu向けAPTリポジトリ方式を使用しました。

Ubuntuの docker.io パッケージや古い apt-key を使う手順ではなく、Docker公式のGPGキーと docker.sources を登録して導入しています。

この記事のバージョン番号や実行結果は、今回のLIFEBOOKで実際に確認したものです。

Docker EngineやDocker Composeの最新版は今後変わるため、別の時点で構築する場合はDocker公式ドキュメントと実際のAPT候補バージョンを確認してください。

今回の導入環境

項目 内容
PC 富士通 LIFEBOOK AH52/C
型名 FMVA52CBJ
CPU Intel Pentium P6200 2.13GHz
メモリ 8GB
ストレージ 256GB SSD
OS Ubuntu 24.04.4 LTS Desktop
Ubuntuコードネーム noble
アーキテクチャ x86_64 / APTでは amd64
Ubuntuユーザー honta
LIFEBOOK側IPv4 192.168.11.9/24
家庭内LAN 192.168.11.0/24
UFW 有効
Docker Engine 未導入から開始
初回導入時 Docker Engine 29.7.2
初回導入時 Docker Compose v5.5.0
初回導入時 containerd 2.3.4
初回導入時 Buildx Plugin 0.36.1

192.168.11.9/24 と 192.168.11.0/24 は今回の家庭内LANで確認した値です。

別環境ではIPアドレスやサブネットが異なります。そのままコピーせず、自分の環境で確認してください。

今回作る構成

DockerはUbuntu実機へ直接導入し、その上で将来的にLaravel Sailを動かします。

Ubuntu 24.04.4 LTS
  │
  ├─ systemd
  │    └─ docker.service
  │
  ├─ Docker Engine
  │    ├─ docker-ce
  │    ├─ docker-ce-cli
  │    ├─ containerd.io
  │    ├─ docker-buildx-plugin
  │    └─ docker-compose-plugin
  │
  └─ UFW
       └─ SSH: 192.168.11.0/24 → TCP/22のみ許可

今回はLaravel / Sailを起動する前に、DockerとUFWの関係も確認します。

Dockerではコンテナのポートを -p やComposeの ports: で公開すると、Docker自身がFirewallルールを作成します。

そのため、「UFWが有効だからDockerで公開したポートも自動的に守られる」とは判断しないことを今回の重要な前提にしました。

1. Docker導入前の状態を確認する

いきなりDockerをインストールせず、まずLIFEBOOK実機の状態を確認しました。

hostname
whoami
lsb_release -a
uname -m

ip -4 -br address
systemctl --failed --no-pager

docker --version 2>/dev/null || true
docker compose version 2>/dev/null || true
command -v docker || true
command -v containerd || true

dpkg -l | grep -E 'docker|containerd|runc|podman' || true

今回の主な結果です。

hostname:
lifebook-ubuntu

user:
honta

Description: Ubuntu 24.04.4 LTS
Release:     24.04
Codename:    noble

architecture:
x86_64

IPv4:
wlp16s0 UP 192.168.11.9/24

failed service:
0 loaded units listed.

Docker関連コマンドとパッケージは何も表示されませんでした。

つまり今回のLIFEBOOKでは、

Docker Engine      → 未導入
Docker Compose     → 未導入
containerd         → 未導入
Docker関連deb      → 確認できず

という状態から開始しています。

APTアーキテクチャも確認する

Docker公式APTリポジトリを登録する前に、APT側のアーキテクチャも確認しました。

dpkg --print-architecture

結果：

amd64

uname -m の x86_64 と、Debian / UbuntuのAPTで使われる amd64 は表記が異なりますが、今回の環境ではDocker公式のamd64パッケージを使用します。

過去のDocker公式リポジトリ設定が残っていないか確認する

ls -l /etc/apt/keyrings/docker.asc 2>/dev/null || true
ls -l /etc/apt/sources.list.d/docker.sources 2>/dev/null || true

今回はどちらも何も表示されませんでした。

/etc/apt/keyrings/docker.asc             → なし
/etc/apt/sources.list.d/docker.sources   → なし

過去のDocker公式リポジトリ設定が残っている形跡はありませんでした。

2. Docker公式の対応OSと競合パッケージを確認する

Docker公式のUbuntu向けインストール手順を確認しました。

判断元URL：

公式ページでは対応Ubuntuとして次の記載があります。

Ubuntu Noble 24.04 (LTS)

今回のLIFEBOOKは、

Ubuntu 24.04.4 LTS
Codename: noble
Architecture: amd64

なので、Docker公式のサポート対象と一致します。

またDocker公式では、公式Dockerパッケージと競合する可能性があるパッケージを事前に削除するよう案内しています。

今回確認対象にした主なものは、

docker.io
docker-compose
docker-compose-v2
docker-doc
podman-docker
containerd
runc

です。

ただし、今回の実機確認ではDocker関連パッケージは見つかりませんでした。

そのため、存在しない競合パッケージを機械的に削除する操作は行いませんでした。

「公式手順に削除コマンドがあるから実行する」のではなく、先に実機状態を確認し、今回の環境に存在するものだけを対象にする方針にしました。

今回は削除対象そのものがなかったため、削除操作は不要でした。

3. Docker公式APTリポジトリを登録する

Docker公式の現在のUbuntu向け手順では、GPGキーを /etc/apt/keyrings/docker.asc に配置し、APT sourceを /etc/apt/sources.list.d/docker.sources に登録します。

判断元URL：

3.1 パッケージ情報を更新する

sudo apt update

今回の結果ではエラーはなく、

パッケージはすべて最新です。

となりました。

3.2 ca-certificates と curl を準備する

sudo apt install ca-certificates curl

今回、

ca-certificates → すでに最新
curl            → 新規インストール

となりました。

また、

libfwupd2

が apt autoremove の候補として表示されましたが、Docker導入とは直接関係しないため、この作業では削除しませんでした。

3.3 Docker公式GPGキーを配置する

sudo install -m 0755 -d /etc/apt/keyrings

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  -o /etc/apt/keyrings/docker.asc

sudo chmod a+r /etc/apt/keyrings/docker.asc

作成後に確認します。

ls -l /etc/apt/keyrings/docker.asc
head -n 2 /etc/apt/keyrings/docker.asc

今回の結果です。

-rw-r--r-- 1 root root 3817 ... /etc/apt/keyrings/docker.asc

先頭も、

-----BEGIN PGP PUBLIC KEY BLOCK-----

となっていました。

3.4 docker.sources を作成する

Docker公式のAPTリポジトリを登録します。

sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

作成後に中身を確認しました。

cat /etc/apt/sources.list.d/docker.sources

今回の結果です。

Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: noble
Components: stable
Architectures: amd64
Signed-By: /etc/apt/keyrings/docker.asc

実機の、

Ubuntu codename → noble
APT architecture → amd64

と一致しています。

今回は古い apt-key を使う方法ではなく、Docker公式の現行手順に合わせて /etc/apt/keyrings/docker.asc と docker.sources を使用しました。

4. Docker公式リポジトリから取得できることを確認する

リポジトリ登録後、すぐDocker本体をインストールせず、APTがDocker公式リポジトリを正常に読めるか確認しました。

sudo apt update

今回の出力には、

https://download.docker.com/linux/ubuntu noble InRelease
https://download.docker.com/linux/ubuntu noble/stable amd64 Packages

が表示され、エラーなく取得できました。

次に docker-ce の候補バージョンと取得元を確認します。

apt-cache policy docker-ce

今回の候補は、

候補:
5:29.7.2-1~ubuntu.24.04~noble

取得元は、

https://download.docker.com/linux/ubuntu noble/stable amd64 Packages

でした。

これで、Ubuntu標準の別パッケージではなく、Docker公式stableリポジトリからDocker CEを取得する状態になっていることを確認してからインストールへ進みました。

29.7.2 は今回構築した時点の候補バージョンです。

将来この記事を見ながらインストールする場合、最新版が異なることは正常です。記事中の番号へ無理に合わせず、公式リポジトリと実機の apt-cache policy を確認してください。

5. Docker EngineとDocker Compose Pluginをインストールする

Docker公式のUbuntu向け手順に従い、次のパッケージをインストールしました。

sudo apt install \
  docker-ce \
  docker-ce-cli \
  containerd.io \
  docker-buildx-plugin \
  docker-compose-plugin

今回、追加で次のパッケージも導入されました。

containerd.io                  2.3.4
docker-ce-cli                  29.7.2
docker-ce                      29.7.2
docker-buildx-plugin           0.36.1
docker-ce-rootless-extras      29.7.2
docker-compose-plugin          5.5.0
pigz                           2.8

ダウンロード量は約102MB、追加ディスク使用量は約395MBでした。

インストール中にはsystemdのsymlinkも作成されました。

containerd.service
docker.service
docker.socket

docker-ce-rootless-extras は依存関係として今回インストールされましたが、今回はRootless Dockerへ切り替えていません。

後述する docker グループ方式を採用しています。

6. Docker Engineの起動とhello-worldを確認する

6.1 バージョン確認

インストール後、Docker EngineとCompose Pluginのバージョンを確認しました。

docker --version
docker compose version

結果：

Docker version 29.7.2, build a7dcaa6
Docker Compose version v5.5.0

ここで使っているのは旧来の、

docker-compose

ではなく、

docker compose

というDocker CLI Plugin形式です。

6.2 systemdの状態を確認する

systemctl is-active docker
systemctl is-enabled docker

今回の結果です。

active
enabled

つまり、

Docker daemon → 起動中
自動起動      → 有効

でした。

Docker公式のLinux post-installation documentationでも、Debian / UbuntuではDocker serviceが起動時に開始される構成が案内されています。

判断元URL：

6.3 公式の hello-world で動作確認する

Docker公式のUbuntuインストール手順では、インストール確認として hello-world imageの実行が案内されています。

判断元URL：

今回は、まず sudo 付きで確認しました。

sudo docker run hello-world

初回なのでDocker Hubからimageが取得され、

Unable to find image 'hello-world:latest' locally
...
Status: Downloaded newer image for hello-world:latest

その後、

Hello from Docker!
This message shows that your installation appears to be working correctly.

と表示されました。

これで、

Docker CLI
  ↓
Docker daemon
  ↓
Docker Hubからimage pull
  ↓
container作成
  ↓
container実行
  ↓
結果をterminalへ返す

という一連の動作が成功したことを確認できました。

7. sudoなしでDockerを使えるようにする

Laravel Sailを日常的に使う予定なので、毎回 sudo docker ... とするのではなく、一般ユーザー honta からDockerを操作できる構成を検討しました。

7.1 docker グループの状態を確認する

まず変更せずに現在状態を確認します。

getent group docker
id -nG

今回の結果です。

docker:x:984:

docker グループはDockerインストール時に作成されていましたが、まだメンバーはいません。

honta の所属グループにも、

docker

はありませんでした。

7.2 docker.sock の所有者を確認する

ls -l /var/run/docker.sock

今回の結果です。

srw-rw---- 1 root docker ... /var/run/docker.sock

つまりDocker socketは、

owner → root
group → docker

でした。

7.3 ~/.docker がroot所有になっていないか確認する

先に sudo docker run hello-world を実行しているため、Docker公式が注意している ~/.docker の所有権問題が起きていないか確認しました。

ls -ld ~/.docker 2>/dev/null || echo "~/.docker はまだありません"

今回の結果：

~/.docker はまだありません

この時点ではroot所有の ~/.docker は作成されていませんでした。

7.4 docker グループのセキュリティ上の意味

Docker公式は docker グループについて明確に警告しています。

判断元URL：

公式の警告：

The docker group grants root-level privileges to the user.

つまり、単に「sudoを書かなくてよくなる便利なグループ」と考えるのは危険です。

Docker daemonはrootで動いており、docker グループのメンバーはDockerを通してroot相当の操作が可能になります。

今回は、

  • 家庭内LANの個人用開発機
  • 利用ユーザーは自分自身
  • Laravel Sailを日常的に使用予定
  • SSHは公開鍵認証
  • UFWで家庭内LANからのSSHだけ許可

という用途を踏まえ、利便性とのバランスから honta を docker グループへ追加しました。

docker グループは強い権限を持ちます。

複数ユーザーで共有するサーバーや、信頼できないユーザーがログインできる環境では、この記事と同じ判断をそのまま適用しないでください。

必要に応じてDocker公式のRootless modeも検討してください。

7.5 honta を docker グループへ追加する

sudo usermod -aG docker honta

確認：

getent group docker

結果：

docker:x:984:honta

7.6 現在のログインセッションへ反映する

通常は一度ログアウトして再ログインすればグループ所属が再評価されます。

しかし、この作業時はメインPCのDELLを修復中で、LIFEBOOKを直接操作していました。

そのため今回はDocker公式でも案内されている、

newgrp docker

を使用しました。

確認します。

id -nG

結果：

docker adm cdrom sudo dip plugdev users lpadmin honta

docker が含まれています。

7.7 sudoなしで hello-world を実行する

docker run hello-world

結果：

Hello from Docker!

今度は sudo なしで成功しました。

これで一般ユーザー honta からDockerを操作できるところまで確認できました。

newgrp docker は今回、現在のセッションへグループ変更を反映するために使いました。

ユーザー自体は usermod -aG docker honta で登録済みなので、次回通常ログインした際に毎回 newgrp docker を実行する前提ではありません。

8. UFWとDockerのFirewallルールを確認する

ここは今回、特に重要視した部分です。

Docker公式のUbuntuインストールページには、UFW利用時の注意が記載されています。

判断元URL：

公式の記載：

these ports bypass your firewall rules.

さらにDockerのFirewall documentationでは、DockerがLinux上でnetwork isolationやport publishingのためにFirewallルールを作成することが説明されています。

判断元URL：

8.1 UFWが引き続き有効か確認する

Dockerインストール後に、

sudo ufw status verbose

を確認しました。

今回の結果です。

状態: アクティブ
ロギング: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    192.168.11.0/24

Docker導入前から設定していた、

家庭内LAN 192.168.11.0/24
          ↓
TCP/22のみ許可

というSSHルールは残っています。

8.2 iptablesのbackendを確認する

sudo iptables --version

今回の結果：

iptables v1.8.10 (nf_tables)

Docker公式のUbuntuインストールページでは、Dockerは iptables-nft と iptables-legacy に対応すると案内されています。

判断元URL：

今回の iptables は nf_tables backendを使用していました。

iptables v1.8.10 (nf_tables) と表示されたことだけを根拠に、「Docker daemonがDocker Engine 29の実験的なnftables firewall backendを使用している」とは判断しません。

Docker公式のFirewall documentationでは、Docker Engineの標準Firewall backendはiptablesであり、nftables backendは別の設定として説明されています。

8.3 DOCKER-USER を確認する

sudo iptables -S DOCKER-USER

結果：

-N DOCKER-USER

DOCKER-USER chain自体は作成されていますが、この時点では独自ルールを追加していません。

8.4 FORWARD chainを確認する

sudo iptables -S FORWARD

今回の結果です。

-P FORWARD DROP
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-FORWARD
-A FORWARD -j ufw-before-logging-forward
-A FORWARD -j ufw-before-forward
-A FORWARD -j ufw-after-forward
-A FORWARD -j ufw-after-logging-forward
-A FORWARD -j ufw-reject-forward
-A FORWARD -j ufw-track-forward

Docker関連chainとUFWのforward chainが同じFORWARD chain上に存在していることが確認できました。

8.5 DockerのNAT chainを確認する

sudo iptables -t nat -S DOCKER

今回の結果：

-N DOCKER

この時点では hello-world しか実行しておらず、-p でホストポートをpublishしていません。

そのため、今回の確認時点ではDockerのpublish portに対応するNATルールはありませんでした。

今回の記事では、UFWを回避できるかを実際に外部端末から再現するための公開ポートテストは行っていません。

「DockerでpublishしたポートはUFWの想定どおりに制御されない場合がある」という判断は、Docker公式ドキュメントを根拠にしています。

実機では、Docker/UFW/iptablesの現在状態と、まだ公開ポートが存在しないことまで確認しました。

8.6 Laravel / Sailでは ports: を必ず確認する

Docker公式のport publishing documentationでは、host IPを指定しないpublishは全host addressへbindされることが説明されています。

判断元URL：

公式の注意：

Publishing container ports is insecure by default.

例えば、

docker run -p 8080:80 ...

はhostの全addressへ公開される可能性があります。

一方、

docker run -p 127.0.0.1:8080:80 ...

のようにlocalhostへ限定できます。

Laravel Sailへ進むと、

  • Laravel Web
  • Vite
  • MySQL
  • phpMyAdmin
  • Mailpit

など複数のportを扱う可能性があります。

そのため今回は、Sailを起動する前にComposeの ports: を監査する方針にしました。

UFWが active であっても、Dockerでpublishしたportまで自動的に同じUFWルールで保護されるとは考えないようにします。

特にMySQLや管理画面系サービスを不要に 0.0.0.0 へ公開しないよう、Compose設定を確認してから起動します。

9. Docker daemonの独自設定有無を確認する

Dockerを入れた直後なので、daemonへ独自設定が作られていないか確認しました。

Docker公式では通常のLinux構成でdaemon設定ファイルの既定位置を、

/etc/docker/daemon.json

としています。

判断元URL：

確認：

sudo cat /etc/docker/daemon.json 2>/dev/null \
  || echo "/etc/docker/daemon.json はありません"

今回の結果：

/etc/docker/daemon.json はありません

今回の構築作業では独自の daemon.json を作成していません。

続いてDocker Root Dirを確認しました。

docker info --format 'Docker Root Dir: {{.DockerRootDir}}'

結果：

Docker Root Dir: /var/lib/docker

Docker公式では、Docker Engine 29.0以降の新規インストールではcontainerd image storeが標準になり、image contentsやcontainer snapshotsは /var/lib/containerd に保存されると説明されています。

今回の記事では Docker Root Dir: /var/lib/docker まで実機確認していますが、image store backendを判定する追加コマンドまでは実行していないため、実機の保存内訳についてそれ以上は断定しません。

判断元URL：

https://docs.docker.com/engine/daemon/

10. 最終確認

今回のDocker Engine構築後の状態を整理します。

Docker / Compose

docker --version
docker compose version

Docker version 29.7.2, build a7dcaa6
Docker Compose version v5.5.0

systemd

systemctl is-active docker
systemctl is-enabled docker

active
enabled

一般ユーザーからDockerを実行

id -nG
docker run hello-world

docker ... honta

Hello from Docker!

UFW

sudo ufw status verbose

状態: アクティブ
Default: deny (incoming), allow (outgoing), deny (routed)

22/tcp ALLOW IN 192.168.11.0/24

Docker独自daemon設定

/etc/docker/daemon.json はありません

ここまでで、

Docker Engine導入
  ↓
Docker Compose Plugin導入
  ↓
Docker daemon起動確認
  ↓
hello-world成功
  ↓
sudoなしDocker実行成功
  ↓
UFW / iptables状態確認
  ↓
公開ポートなしを確認

まで完了しました。

今回躓いたポイント

docker グループへ追加しても、現在のセッションにはすぐ反映されない

sudo usermod -aG docker honta

でユーザーを追加しても、既存ログインセッションの補助グループ情報が自動で書き換わるわけではありません。

Docker公式ではログアウト・再ログインによる再評価、または、

newgrp docker

による反映方法が案内されています。

今回はDELL修復中でLIFEBOOKを直接操作していたため、

newgrp docker

を使いました。

その後、

id -nG

で docker が含まれることを確認し、sudoなしの docker run hello-world が成功しました。

UFWが有効でもDockerの公開ポートは別途考える必要があった

Docker導入後も、

UFW: active
22/tcp: 192.168.11.0/24からのみ許可

というSSH設定は維持されていました。

しかしDocker公式は、Dockerでpublishしたcontainer portがUFWのFirewallルールを回避し得ることを明記しています。

そのため、

UFWがactive
  ↓
Dockerの公開portも安全

とは判断できません。

今回はLaravel Sailを起動する前に、

sudo iptables -S DOCKER-USER
sudo iptables -S FORWARD
sudo iptables -t nat -S DOCKER

まで確認し、まだDockerの公開portがない状態を確認してから作業を区切りました。

docker グループは利便性だけで追加しない

Laravel Sailの操作ではsudoなしDockerが便利ですが、Docker公式は docker グループがroot-level privilegesを与えると警告しています。

そこで今回は、

個人用の家庭内LAN開発機
        ↓
Laravel Sailを日常利用
        ↓
dockerグループを採用

という用途を明確にした上で追加しました。

「Dockerを使うならとりあえず全ユーザーを docker グループへ追加」という判断にはしませんでした。

切り分けの時系列

Ubuntu 24.04.4 LTS / nobleを確認
  ↓
x86_64 / amd64を確認
  ↓
failed service 0を確認
  ↓
Docker / containerd未導入を確認
  ↓
過去のdocker.asc / docker.sourcesがないことを確認
  ↓
Docker公式Ubuntuドキュメントを確認
  ↓
競合パッケージが存在しないことを確認
  ↓
ca-certificates / curlを準備
  ↓
Docker公式GPGキーを配置
  ↓
docker.sourcesを作成
  ↓
Suites: noble / Architectures: amd64を確認
  ↓
apt updateでDocker公式stable repositoryを取得
  ↓
apt-cache policy docker-ce
  ↓
Docker CE 29.7.2候補とDocker公式取得元を確認
  ↓
docker-ce / CLI / containerd / Buildx / Compose Pluginをインストール
  ↓
docker --version / docker compose version
  ↓
docker.service active / enabled
  ↓
sudo docker run hello-world
  ↓
Docker Hub pull + container実行成功
  ↓
dockerグループの状態を確認
  ↓
/var/run/docker.sockがroot:dockerであることを確認
  ↓
~/.dockerがまだないことを確認
  ↓
hontaをdockerグループへ追加
  ↓
newgrp docker
  ↓
id -nGでdocker所属を確認
  ↓
docker run hello-worldをsudoなしで実行
  ↓
UFWがactiveのままか確認
  ↓
iptables / DOCKER-USER / FORWARD / NAT chainを確認
  ↓
Docker publish portがまだないことを確認
  ↓
daemon.json未作成を確認
  ↓
Docker Root Dirを確認
  ↓
Docker Engine基盤構築完了

まとめ

今回は、Ubuntu 24.04.4 LTSをインストールした古いLIFEBOOKへ Docker Engineを直接導入しました。

単に apt install docker で終わらせず、

  • Docker導入前の実機状態確認
  • Ubuntu Noble 24.04 / amd64がDocker公式対応環境であることを確認
  • 競合パッケージの有無を実機確認
  • Docker公式GPGキーの登録
  • docker.sources による公式APTリポジトリ登録
  • apt-cache policy で取得元と候補バージョンを確認
  • Docker Engine 29.7.2をインストール
  • Docker Compose Plugin v5.5.0をインストール
  • systemdで active / enabled を確認
  • hello-world でDocker Hubからのpullとcontainer実行を確認
  • docker グループの権限リスクを確認
  • honta からsudoなしでDockerを実行
  • UFWとDockerのiptables chainを確認
  • Dockerでまだportをpublishしていないことを確認
  • /etc/docker/daemon.json が未作成であることを確認

まで行いました。

今回特に重要だったのは、DockerとUFWを別々の仕組みとして考え、UFWがactiveであることだけを根拠にDockerの公開portまで安全だと判断しなかったことです。

Laravel SailではWeb、Vite、MySQL、Mailpit、phpMyAdminなど複数のportを扱う可能性があります。

次の段階では、既存LaravelプロジェクトのCompose設定を確認し、必要なportだけを適切なhost addressへbindする構成を検討してからSailを起動します。

古いPentium搭載のLIFEBOOKですが、少なくとも今回のDocker Engine導入と hello-world までは問題なく完了しました。

参考資料

Docker公式：Install Docker Engine on Ubuntu

確認内容:

  • Ubuntu Noble 24.04 LTSがサポート対象であること
  • amd64 / x86_64が対応architectureであること
  • 競合パッケージの扱い
  • Docker公式GPGキーの登録方法
  • docker.sources を使ったAPT repository設定
  • docker-ce / docker-ce-cli / containerd.io / Buildx / Compose Pluginのインストール
  • hello-world による動作確認
  • UFW利用時のFirewall上の注意点

公式記載例:

Ubuntu Noble 24.04 (LTS)

these ports bypass your firewall rules.

Docker公式：Linux post-installation steps for Docker Engine

確認内容:

  • sudoなしでDockerを使う場合の docker group
  • usermod -aG docker
  • ログアウト / 再ログインによるgroup membership再評価
  • newgrp docker
  • sudoなしでの docker run hello-world
  • ~/.docker ownership問題
  • Debian / UbuntuでDocker serviceがboot時に起動すること
  • docker groupの権限上の警告

公式警告:

The docker group grants root-level privileges to the user.

Docker公式：Packet filtering and firewalls

確認内容:

  • DockerがLinux hostへFirewall ruleを作成すること
  • bridge networkでのnetwork isolation
  • port publishing
  • DOCKER-USER
  • DockerとUFWの関係
  • 標準Firewall backendとしてiptablesが使われること

Docker公式：Port publishing and mapping

確認内容:

  • -p / --publish
  • host IPを指定しない場合のbind範囲
  • 127.0.0.1 へ限定するpublish
  • bridge networkのportはpublishしない限りhost外部へ公開されないこと

公式注意:

Publishing container ports is insecure by default.

Docker公式：Docker daemon configuration overview

確認内容:

  • Linux通常構成の daemon.json の既定位置
  • /var/lib/docker
  • Docker Engine 29以降のcontainerd image store
  • /var/lib/containerd と /var/lib/docker の役割

関連記事

このシリーズ

あわせて読みたい

1
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?