Ubuntu Server 26.04 LTSにDocker Engineを安全にインストールする方法【Compose対応】

Dockerを導入すると、Webアプリやデータベースを「コンテナ」という単位に分け、同じUbuntu Server上で整理して動かせるようになります。Docker Composeを使えば、複数のコンテナ設定も1つのYAMLファイルで管理できます。

この記事では、Ubuntu Server 26.04 LTSへDocker公式aptリポジトリからDocker Engine、CLI、containerd、Buildx、Composeプラグインを導入します。検証ではネットワークポートを公開せず、サービス状態、hello-world、最小のcompose.yamlまで確認します。

SSH接続がまだなら、先にUbuntu ServerへSSHで安全に接続する方法を進めてください。

この記事で行うこと・行わないこと

今回のゴール

• OS・アーキテクチャ・空き容量を確認する
• 既存の競合パッケージと稼働中コンテナの有無を確認する
• Docker公式の署名鍵とaptリポジトリを登録する
• Docker EngineとComposeプラグインを導入する
• sudo運用のまま、ポートを開けずに動作確認する
• 更新方法、停止条件、アンインストール時のデータ保持を理解する

今回は行わないこと

• インターネット公開やルーターのポート開放
• Webアプリの常時起動やホスト側ポートの公開
• Portainer、rootless mode、Swarm、Kubernetes、GPU設定
• ログローテーション、監視、バックアップの本設定
• Dockerデータ領域の削除

Docker公式リポジトリを使う理由

UbuntuにもDocker関連パッケージはありますが、この記事ではDocker公式ドキュメントと同じパッケージ構成・更新経路にそろえるため、Docker公式aptリポジトリを使います。Ubuntu側のパッケージが危険という意味ではありません。導入元を混在させず、どちらで管理するかを決めることが大切です。

公式リポジトリ方式では、docker-ce、docker-ce-cli、containerd.io、docker-buildx-plugin、docker-compose-pluginをまとめて導入できます。従来のハイフン付きdocker-composeではなく、現行のdocker composeコマンドを使います。

Docker公式の簡易インストールスクリプトはテスト・開発用途向けです。今回はインターネットから取得したスクリプトをrootシェルへ直接渡さず、内容と更新元が見えるaptリポジトリ方式で進めます。

1. OS・アーキテクチャ・空き容量を確認する

grep '^PRETTY_NAME=' /etc/os-release
dpkg --print-architecture
df -h /

OSがUbuntu Server 26.04 LTSであること、Docker公式が対応する64bitアーキテクチャであること、ルートファイルシステムに余裕があることを確認します。イメージやログは運用とともに増えるため、空き容量がほとんどない場合はここで中止します。

2. 既存環境と競合パッケージを確認する

command -v docker || true
command -v podman || true
dpkg -l | grep -E 'docker|containerd|runc|podman' || true
sudo ls -ld /var/lib/docker /var/lib/containerd 2>/dev/null || true

既にdocker psやpodman psでコンテナが動いている、用途が分からないパッケージがある、または過去のDockerデータが必要な場合は削除へ進みません。先に現在の導入元、Composeファイル、ボリューム、バックアップを確認してください。

新規環境であり、既存データが不要だと確認できた場合だけ、Docker公式が競合対象として挙げているパッケージを取り除きます。対象が未導入ならaptからその旨が表示されます。

sudo apt remove $(dpkg --get-selections docker.io docker-compose docker-compose-v2 docker-doc docker-buildx podman-docker containerd runc | cut -f1)

この操作だけで/var/lib/docker内のイメージやコンテナが自動削除されるわけではありません。ただし、既存サービスがある状態でパッケージを外せば停止につながるため、事前確認が必須です。

作業前のUFWと待ち受けポートを記録する

sudo ufw status verbose
sudo ss -lntup

今回はUFWを有効化・無効化しません。作業前の状態を控え、Compose検証後に意図しない待ち受けポートが増えていないことを確認します。

3. Docker公式の署名鍵とaptリポジトリを登録する

まずパッケージ一覧を更新し、HTTPS通信とダウンロードに必要なパッケージを入れます。

sudo apt update
sudo apt install ca-certificates curl

署名鍵を保存するディレクトリを作り、Docker公式サイトから鍵を保存します。

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

curlがエラーを返した場合や、保存先のファイルが空の場合は先へ進みません。URL、DNS、時刻、インターネット接続を確認します。

続けて、Docker公式のaptソースを登録します。

sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<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

sudo apt update

apt updateで署名エラー、Release fileエラー、404が出た場合はインストールへ進みません。docker.sourcesの内容、OSコードネーム、システム時刻を確認します。

インストール前に、Docker公式リポジトリから候補を取得できているか確認します。

apt-cache policy docker-ce

Candidate:が(none)ではなく、候補の取得元にdownload.docker.comが表示されることを確認します。候補がない場合は先へ進みません。

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

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

確認を求められたら、インストール・更新・削除されるパッケージ一覧を読み、想定外の大量削除がないことを確認してから続行します。

5. サービス状態と自動起動を確認する

sudo systemctl status docker.service --no-pager --full
systemctl is-active docker.service
systemctl is-active containerd.service
systemctl is-enabled docker.service
systemctl is-enabled containerd.service

Dockerとcontainerdのis-activeがactive、is-enabledがenabledなら、現在起動しており再起動後も自動起動する設定です。Ubuntuでは通常インストール時に有効になります。inactiveやfailedなら、テストコンテナを動かす前にログを確認します。

sudo journalctl -u docker.service -n 100 --no-pager

6. バージョンとEngine情報を確認する

sudo docker version
sudo docker buildx version
sudo docker compose version
sudo docker info

docker versionでClientとServerの両方、Buildx、Compose、Engine情報が表示されることを確認します。Composeは公開時期によってv2またはv5などの表示になり得ます。特定番号との一致ではなく、docker composeコマンドがエラーなく応答することを成功条件にします。

dockerグループへ追加しない理由

DockerのUnixソケットは初期状態ではrootが所有し、一般ユーザーはsudo dockerで操作します。ユーザーをdockerグループへ追加すればsudoを省略できますが、Docker公式もdockerグループはrootレベルの権限を与えると警告しています。

初心者向けのこの記事では利便性より権限境界を優先し、dockerグループへ追加しません。コマンドが長くてもsudo dockerを使います。rootless modeは別の設計と制約があるため、今回は扱いません。

7. hello-worldをポート公開なしで実行する

sudo docker run --rm --name ouchi-lab-hello hello-world

初回はDocker Hubからテストイメージを取得します。成功メッセージを表示してコンテナが終了すれば、イメージ取得、コンテナ作成、実行まで確認できています。--rmにより停止したテストコンテナは自動削除されます。

現在の状態も確認します。

sudo docker ps
sudo docker ps -a
sudo docker image ls

実行中コンテナはなく、hello-worldイメージだけが残るのが基本です。

8. 最小のcompose.yamlを検証する

テスト用ディレクトリを作ります。

mkdir -p ~/docker-compose-check
cd ~/docker-compose-check
nano compose.yaml

次の内容を保存します。ports:は書かないため、ホスト側のネットワークポートは公開されません。

services:
  check:
    image: alpine:latest
    command:
      - sh
      - -c
      - echo 'Docker Compose is working' && sleep 3600

まずComposeファイルの解釈結果を確認し、その後に起動・終了・後片付けを行います。

sudo docker compose config
sudo docker compose up -d
sudo docker compose ps
sudo docker compose logs
sudo docker ps --format 'table {{.Names}}	{{.Status}}	{{.Ports}}'
sudo ss -lntup
sudo docker compose down

configで構文エラーがなく、checkサービスがUp、ログにDocker Compose is workingが表示されることを確認します。PORTS欄が空で、作業前と比べてWeb用の待ち受けポートが増えていなければ、ホスト側へポートを公開していません。最後にdownでテスト用コンテナとネットワークを削除します。

Dockerの公開ポートとUFWに注意する

そのため今回は-pもports:も使いません。今後LAN内向けサービスを公開するときは、バインド先アドレス、ルーター設定、IPv4・IPv6、Dockerのファイアウォール連携をサービスごとに確認します。Dockerが作るiptables設定を安易に無効化するとコンテナ通信を壊すため、iptables=falseのような変更も行いません。

なお、ホストへポートを公開していなくても、コンテナから外部へ通信できる場合があります。「ポートを公開していない」と「コンテナのネットワークを無効化した」は同じ意味ではありません。

9. 再起動後もDockerが起動するか確認する

sudo docker psでテストコンテナが残っていないことを確認してから再起動します。

sudo docker ps
sudo reboot

SSHで再接続後、次を確認します。

systemctl is-enabled docker.service
systemctl is-active docker.service
systemctl is-active containerd.service
sudo docker version
sudo docker ps -a
sudo docker image ls

ここで確認しているのはDockerサービスの自動起動です。今後作るアプリコンテナが自動再開するかは、各Composeファイルのrestart:設定などで個別に決まります。

10. 普段の更新方法

sudo apt update
apt list --upgradable
sudo apt upgrade

Docker公式リポジトリから導入したパッケージもaptの更新対象になります。apt upgradeの前に変更内容を読み、重要なコンテナを動かすようになった後は停止時間と復旧方法を決めてから更新します。イメージの更新はOSパッケージ更新とは別です。

アンインストールとデータ保持

Engine関連パッケージだけを外す場合は、Docker公式のアンインストール手順に従います。

sudo apt purge docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin docker-ce-rootless-extras

この操作だけでは、イメージ、コンテナ、ボリューム、独自設定は自動削除されません。通常は/var/lib/dockerと/var/lib/containerdにデータが残ります。

リポジトリ登録だけを戻す場合も、先にパッケージとデータをどう扱うか決めてから、Docker公式手順の対象ファイルを確認して削除します。設定ファイルを編集している場合は自動では消えません。

トラブルシューティング

apt updateで署名エラーになる

• /etc/apt/keyrings/docker.ascが存在し、空でないか確認する
• docker.sourcesのSigned-Byと実際の保存先が一致しているか確認する
• OSコードネーム、システム時刻、DNS、HTTPS通信を確認する
• エラーを無視するtrusted=yesは使わない

Cannot connect to the Docker daemonと表示される

sudo systemctl is-active docker
sudo journalctl -u docker.service -n 100 --no-pager

サービスが停止している原因をログで確認します。権限エラーならsudo dockerで実行しているかも確認し、安易にソケットの権限を広げません。

イメージを取得できない

DNS、サーバー時刻、インターネット接続、プロキシの有無、Docker Hub側のエラーを確認します。原因が分からないまま再インストールやデータ削除へ進みません。

完了チェックリスト

• Ubuntu Server 26.04 LTSとアーキテクチャを確認した
• 既存コンテナと競合パッケージの有無を確認した
• Docker公式の署名鍵とaptリポジトリを登録した
• Engine、CLI、containerd、Buildx、Composeプラグインを導入した
• Dockerサービスがactiveかつenabledと確認した
• containerdがactiveかつenabledと確認した
• Client・Server・Buildx・Composeのバージョンを確認した
• sudo docker run --rm ... hello-worldが成功した
• 最小のcompose.yamlを検証・実行・終了した
• ComposeのPORTS欄が空で、意図しない待ち受けが増えていない
• 再起動後もDockerとcontainerdが起動した
• dockerグループへ一般ユーザーを追加していない
• -pとports:を使っていない
• Dockerデータディレクトリを削除していない

まとめ：導入元と権限と公開ポートを意識する

Dockerの導入で大切なのは、コマンドを実行して終わりにしないことです。導入元を公式aptリポジトリへ統一し、競合を確認し、サービスとComposeを順番に検証します。日常操作はsudo dockerのまま始め、公開ポートとUFWの関係を理解するまでは-pやports:を追加しません。

対応OS、導入コマンド、アンインストールはDocker公式のUbuntu向け導入手順、dockerグループの権限はLinux向け導入後手順、UFWとの関係はDockerのファイアウォール解説で確認できます。公式情報の確認日は2026年7月31日です。

次の記事ではComposeで実用サービスを1つ起動し、家庭内LANだけへ公開するためのバインド先、ボリューム、再起動設定を安全に組み立てます。