UbuntuにDockerをインストールする方法：APT、Snap、Rootless — 2026年版完全ガイド

Ubuntuで適切なDockerのインストールパスを選択してください。

目次

Ubuntu に Docker をインストールするのは本来シンプルであるはずですが、実際には複数の「Docker 関連」の選択肢が同じコマンド名を巡って競合しており、それぞれ異なるパッケージ構成、アップグレード動作、セキュリティへの影響を持っています。

このガイドでは、お使いの環境に最適なインストール方法を選べるよう、主要なインストールパスをすべて比較します。

遭遇する可能性のある選択肢は以下の通りです。

  • Ubuntu リポジトリからの docker.io
  • Docker 公式 APT リポジトリからの docker-ce
  • Snap からの Docker
  • Docker Desktop
  • 手動ダウンロードした .deb パッケージ
  • Docker 簡易インストールスクリプト
  • ルートレス Docker（Rootless Docker）

docker workplace

これらはすべてコンテナツールを提供しますが、互換性のあるパッケージではありません。最適な選択は、そのマシンが開者ワークステーションなのか、CI ランナーなのか、小さなサーバーなのか、セルフホスティング用ボックスなのか、あるいは本番ホストなのかによって異なります。私のデフォルトの推奨は穏やかですが明確です。通常の Ubuntu マシンを使用する技術ユーザーのほとんどにとって、Docker 公式 APT リポジトリから Docker Engine をインストールするのが最善です。Ubuntu の docker.io は、ディストリビューション統合が Docker 上流パッケージよりも優先される場合にのみ使用してください。Snap パッケージは、Snap 独自の動作を意図的に望み、その制限を理解している場合以外は避けてください。ルートレス Docker は知っておく価値がありますが、すべてのマシンにおいて自動的に最善のデフォルトとは限りません。

このガイドではトレードオフを説明し、インストール後のセキュリティをカバーし、各方法に対するクリーンなインストールパスを提供します。Docker Engine が起動したら、Docker チートシート が毎日のコマンドリファレンスとなり、Docker Compose チートシート がマルチコンテナセットアップをカバーします。これらは、開発ツール：モダンな開発ワークフローの完全ガイド において、Git、VS Code、CI/CD ガイドと並んで提供されています。

クイック推奨事項

以下の表は、一般的なシナリオに合うインストールパスを要約しています。

ユースケース 推奨されるインストール
開発者ワークステーション Docker 公式 APT リポジトリ
CI ランナー Docker 公式 APT リポジトリ（必要に応じてバージョン固定）
小型セルフホストサーバー Docker 公式 APT リポジトリ
本番サーバー Docker 公式 APT リポジトリ（アップグレードを制御）
Ubuntu 固有の保守的なシステム Ubuntu docker.io パッケージ
クイックなデスクトップ実験 Docker Desktop または公式 APT リポジトリ
Snap で管理された Ubuntu セットアップ Docker Snap（注意して）
強力な非ルートデーモン要件 ルートレス Docker
エアギャップホスト 手動 .deb パッケージまたは内部ミラー

特に理由がない限り、Docker 公式 APT リポジトリがデフォルトとなります。

インストールされるコンポーネント

通常の Docker Engine セットアップには、いくつかの移動する部品が含まれます。

  • Docker デーモン: dockerd
  • Docker CLI: docker
  • コンテナランタイム: containerd
  • ローレベルランタイム: runc
  • Buildx プラグイン: docker buildx
  • Compose プラグイン: docker compose

モダンな Docker Compose は通常、Docker CLI プラグインとしてインストールされます。つまり、コマンドは以下になります。

docker compose version

以下ではありません。

docker-compose version

古い docker-compose コマンドは古いガイドや古いシステムではまだ存在しますが、新しい Ubuntu セットアップでは一般的に Compose プラグインを使用すべきです。

オプション 1: Docker 公式 APT リポジトリから Docker をインストール

これは、ほとんどの開発者および DevOps ユーザーにとって最高のデフォルトです。Docker の上流パッケージ、最新の Docker Engine リリース、Buildx、Compose プラグイン、および通常の APT アップグレードパスが得られます。

競合するパッケージをまず削除する

Docker CE をインストールする前に、公式 Docker パッケージと競合する可能性のあるパッケージを削除します。

sudo apt remove docker.io docker-compose docker-compose-v2 docker-doc podman-docker containerd runc

APT がこれらのパッケージの一部がインストールされていないと表示されても問題ありません。

このコマンドは /var/lib/docker 以下に保存されている Docker イメージ、コンテナ、ボリューム、ネットワークを削除しません。クリーンなリセットを行いたい場合は、それは別のステップであり、意図的に行う必要があります。

Docker 公式 APT リポジトリを追加

前提条件をインストールします。

sudo apt update
sudo apt install ca-certificates curl

キーリングディレクトリを作成します。

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

Docker のリポジトリキーをダウンロードします。

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

APT がキーを読み取れるようにします。

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

deb822 .sources 形式を使用して Docker リポジトリを追加します。

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

APT メタデータを更新します。

sudo apt update

Docker Engine、Buildx、および Compose をインストール

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

サービスを確認します。

sudo systemctl status docker

実行されていない場合は、以下のコマンドを実行します。

sudo systemctl start docker

インストールを確認します。

sudo docker run hello-world

バージョンを確認します。

docker --version
docker buildx version
docker compose version

この時点で Docker は動作しますが、以下のインストール後のセクションで非ルートアクセスを構成しない限り、ほとんどのコマンドには sudo が必要です。

オプション 2: Ubuntu リポジトリから Docker をインストール

Ubuntu は docker.io パッケージを提供しており、以下でインストールできます。

sudo apt update
sudo apt install docker.io docker-compose-v2

Docker を起動し、有効にします。

sudo systemctl enable --now docker

確認します。

sudo docker run hello-world

Ubuntu docker.io が理にかなっている場合

Ubuntu のパッケージは、以下の場合に良い選択肢になります。

  • Ubuntu が管理するパッケージを好む場合。
  • Ubuntu のリリースプロセスに準拠したバージョンを希望する場合。
  • 標準リポジトリで多数の Ubuntu ホストを管理している場合。
  • 最新の上流 Docker リリースを必要としない場合。
  • サードパーティの APT ソースを少なくしたい場合。

これは理にかなった選択です。「間違い」ではありません。

Ubuntu docker.io が最適でない場合

代わりに Docker 公式リポジトリを使用するのは、以下の場合です。

  • 現在の上流 Docker Engine を希望する場合。
  • Docker 独自のドキュメントに従う場合。
  • 最新の Buildx および Compose の動作に依存する場合。
  • Docker CE パッケージ名を希望する場合。
  • 上流 Docker ドキュメントに対して問題のデバッグを行う場合。
  • ディストリビューション間で予測可能な Docker バージョンの整合性が必要な場合。

私のバイアス：開発者マシンおよびコンテナ中心のホストには、Docker 公式 APT リポジトリを使用します。保守的な Ubuntu 管理マシンには、docker.io が許容されます。

オプション 3: Snap で Docker をインストール

Docker snap は1つのコマンドでインストールされますが、シンプルさがサーバーや開発マシンでの予測可能な動作を常に意味するわけではありません。

sudo snap install docker

Snap パッケージには独自のモデル、更新動作、閉じ込め（confinement）の前提、およびファイルシステムレイアウトがあります。これは多くのデスクトップアプリには問題ありませんが、Docker Engine はすでにシステムレベルのコンテナランタイムであるため、追加の Snap レイヤーがユーザーを驚かせる可能性があります。他のソフトウェアを Snap で管理している場合、Snap パッケージマネージャー チートシート でチャネル、閉じ込め、および更新動作について詳しく説明されています。

Docker Snap が理にかなっている場合

Docker Snap は、以下の場合に理にかなっている可能性があります。

  • 意図的にソフトウェアを Snap で管理している場合。
  • Ubuntu Core または Snap 中心の環境を使用している場合。
  • snap スタイルの自動更新を希望する場合。
  • 実験しており、Docker の上流 APT 指示と一致させる必要がない場合。

なぜ私は通常 Docker Snap を避けるのか

私は通常、開発およびサーバー用途のために Docker snap を避けます。その理由は以下の通りです。

  • ほとんどの Docker ドキュメントは、標準的な Docker Engine レイアウトを前提としています。
  • トラブルシューティングパスが APT インストールとは異なる可能性があります。
  • サービス管理が不透明に感じられる可能性があります。
  • Snap の自動更新は、インフラソフトウェアにとって不便になる可能性があります。
  • 一部のバインドマウント、ソケット、およびホスト統合の詳細が驚くべきことがあります。

Docker がワークフローの中心であれば、カジュアルなデスクトップアプリのようにインストールするのではなく、インフラとしてインストールしてください。たとえ Snap インストールが表面では魅力的に見えたとしてもです。

オプション 4: 手動 .deb パッケージから Docker をインストール

手動 .deb インストールは、以下の場合に役立ちます。

  • マシンが外部 APT リポジトリを使用できない場合。
  • オフラインインストールプロセスを構築している場合。
  • 内部でパッケージをミラーリングしている場合。
  • 厳格な変更管理が必要な場合。

トレードオフはメンテナンスです。アップグレードするたびに、新しいパッケージを手動でダウンロードしてインストールする必要があります。

手動インストールには、通常以下のパッケージが必要です。

  • containerd.io
  • docker-ce
  • docker-ce-cli
  • docker-buildx-plugin
  • docker-compose-plugin

以下でインストールします。

sudo dpkg -i ./containerd.io_*.deb \
  ./docker-ce_*.deb \
  ./docker-ce-cli_*.deb \
  ./docker-buildx-plugin_*.deb \
  ./docker-compose-plugin_*.deb

次に、必要に応じて欠落している依存関係を修正します。

sudo apt --fix-broken install

確認します。

sudo systemctl status docker
sudo docker run hello-world

手動 .deb インストールは私の第一選択ではありませんが、明示的なパッケージ承認が利便性よりも重要である制御されたまたはエアギャップ環境では依然として有効です。

オプション 5: Docker の簡易スクリプトを使用

Docker は簡易スクリプトを提供しています。

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

それが何を行うかプレビューできます。

sudo sh get-docker.sh --dry-run

簡易スクリプトは、使い捨てのテストマシン、デモ、ラボ、および捨てられる環境に役立ちますが、本番システムの主要なインストール方法としては使用しません。リポジトリを構成し、パッケージを非対話的にインストールするスクリプトは便利ですが、長寿のインフラは明示的でレビュー可能なステップに値します。したがって、本番ホストには APT リポジトリ手法を直接使用してください。

Ubuntu 上の Docker Desktop と Docker Engine

Linux 用 Docker Desktop は Docker Engine とは異なる製品です。Docker Engine は、ほとんどの Linux サーバーユーザーが期待するサーバー側ランタイムおよび CLI ワークフローですが、Docker Desktop は GUI、デスクトップ統合、および macOS および Windows の Docker 使用に近い製品体験を追加します。

以下の場合に Docker Desktop を使用します。

  • グラフィカルな Docker 体験を希望する場合。
  • デスクトップ機能を希望する場合。
  • Docker Desktop を標準化しているチームと連携している場合。
  • 追加のレイヤーを気にしない場合。

以下の場合に Docker Engine を使用します。

  • サーバーを実行している場合。
  • シンプルな Linux ネイティブランタイムを希望する場合。
  • systemd で管理されるサービスを好む場合。
  • CI、DevOps、またはセルフホストインフラを構築している場合。
  • GUI を必要としない場合。

高度な技術ブログの読者にとって、Docker Engine は通常、Linux サーバーおよび CI ホストにおいてより興味深いデフォルトです。

インストール後：Sudo なしで Docker を実行

インストール後、以下は動作します。

sudo docker ps

しかし、以下は失敗する可能性があります。

docker ps

これは、Docker デーモンが root 所有の Unix ソケットをリッスンしているためです。一般的な修正は、ユーザーを docker グループに追加することです。

必要に応じてグループを作成します。

sudo groupadd docker

ユーザーを追加します。

sudo usermod -aG docker $USER

新しいグループ所属を適用します。

newgrp docker

またはログアウトして再ログインします。

テストします。

docker run hello-world

Docker グループに関する重要なセキュリティノート

docker グループは害のない利便性グループではありません。Docker デーモンを制御できるユーザーは、通常、ホストの root 同等の制御を取得できるため、個人の開発者マシンではこれが許容されることが多いですが、共有サーバーでは深刻なアクセス制御の決定事項です。docker グループの所属を管理者アクセスのように扱い、それが広すぎると感じるのであれば、代わりにルートレス Docker を検討してください。

Ubuntu 上のルートレス Docker

ルートレス Docker は、Docker デーモンおよびコンテナを非ルートユーザーとして実行します。これは、ユーザーを docker グループに追加することとは異なります。docker グループでは、デーモンは依然として root として実行されますが、ルートレスモードでは、デーモン自体がユーザーとして実行されます。

ルートレス Docker が理にかなっている場合

ルートレス Docker は、以下の場合に役立ちます。

  • デーモンレベルの root リスクを低減したい場合。
  • 共有開発マシンにいる場合。
  • ユーザー所有のコンテナを実行する場合。
  • すべての高度なネットワークおよびストレージ機能が必要ない場合。
  • 実験的なワークロードにとってより安全なデフォルトを希望する場合。

ルートレス Docker が面倒である可能性がある場合

ルートレス Docker は、以下の場合により不便になる可能性があります。

  • 特権コンテナが必要な場合。
  • 追加のセットアップなしで低ポートバインディングに依存している場合。
  • 一部のホストネットワークパターンが必要な場合。
  • ルートフル Docker と完全に同一の動作を期待している場合。
  • 通常の Docker Engine インストールのために書かれたガイドに従っている場合。

ルートレスモードはセキュリティの態勢を改善しますが、標準的なルートフルインストールと比較して摩擦ゼロではありません。

ルートレス Docker をインストール

前提条件をインストールします。

sudo apt update
sudo apt install uidmap

DEB または APT パッケージから Docker をインストールした場合、ルートレスセットアップツールが利用可能になります。

dockerd-rootless-setuptool.sh install

ルートフル Docker がすでに実行されており、ルートレス Docker のみを希望する場合、システムデーモンを無効にします。

sudo systemctl disable --now docker.service docker.socket

ルートフルソケットを削除する必要がある場合もあります。

sudo rm -f /var/run/docker.sock

ルートレス Docker をインストールした後、セットアップツールは通常、シェルのプロファイルに追加する環境変数を出力します。それらは通常以下のように見えます。

export PATH=/usr/bin:$PATH
export DOCKER_HOST=unix:///run/user/1000/docker.sock

UID が異なる場合があります。セットアップツールからの正確な出力を確認してください。

ログアウト後もユーザーサービスを実行したい場合は、リンゲリング（lingering）を有効にします。

sudo loginctl enable-linger $USER

ユーザーサービスを確認します。

systemctl --user status docker

テストコンテナを実行します。

docker run hello-world

ルートフル Docker と ルートレス Docker

項目 ルートフル Docker ルートレス Docker
デーモンユーザー root 通常のユーザー
コマンドの利便性 高 中程度
互換性 最高 良好だが完全ではない
セキュリティの態勢 デフォルトで弱い デフォルトで良い
特権コンテナ サポート済み 制限あり
低ポート シンプル 追加のセットアップが必要
サーバーでの使用 一般的 可能だが、慎重に計画する
開発者ワークステーション 一般的 セキュリティ意識の高いユーザー向けに良い

私の実用的な推奨事項：

  • 個人の開発マシンまたは単純なサーバーには、通常のルートフル Docker を使用します。
  • docker グループには信頼できるユーザーのみを追加します。
  • ユーザー分離が重要である場合は、ルートレス Docker を使用します。
  • docker グループをセキュリティの境界であると誤解しないでください。

起動時に Docker を有効にする

Ubuntu では、通常のパッケージからインストールされた Docker は通常自動的に起動しますが、新規インストールまたは移行後に確認する価値があります。

確認します。

systemctl is-enabled docker
systemctl is-enabled containerd

必要に応じて手動で有効にします。

sudo systemctl enable docker.service
sudo systemctl enable containerd.service

今すぐ起動します。

sudo systemctl start docker

自動起動を無効にします。

sudo systemctl disable docker.service
sudo systemctl disable containerd.service

ルートレス Docker の場合、ユーザーサービスを使用します。

systemctl --user enable docker
systemctl --user start docker

必要に応じてリンゲリングを有効にします。

sudo loginctl enable-linger $USER

Docker Compose のインストールまたは確認

Docker 公式 APT リポジトリを使用する場合、Compose をプラグインとしてインストールします。

sudo apt update
sudo apt install docker-compose-plugin

確認します。

docker compose version

Ubuntu のパッケージをインストールした場合、以下を使用できる場合があります。

sudo apt install docker-compose-v2

以下を優先します。

docker compose up -d

以下の古いスタイルではなく。

docker-compose up -d

ハイフン付きの docker-compose コマンドは、古いスタンドアロン Compose エポックに属します。多くのシステムではまだ存在しますが、新しいドキュメントでは docker compose を使用するべきです。

インストールされている Docker を確認

マスを継承したり、壊れたセットアップをデバッグしたりする際に、どの Docker パッケージが実際に使用されているかを特定するために、これらのコマンドが役立ちます。

Docker バイナリを確認します。

which docker

パッケージの所有権を確認します。

dpkg -S "$(which docker)"

Docker 関連パッケージをリストします。

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

APT ポリシーを確認します。

apt-cache policy docker-ce docker.io containerd.io docker-compose-plugin docker-compose-v2

Snap を確認します。

snap list | grep docker

サービスステータスを確認します。

systemctl status docker
systemctl status containerd

Docker サーバー詳細を確認します。

docker info

docker info が sudo なしで失敗する場合、グループ所属を確認します。

groups

Ubuntu docker.io から Docker CE へ移行

Docker を停止します。

sudo systemctl stop docker

Ubuntu パッケージを削除します。

sudo apt remove docker.io docker-compose docker-compose-v2 docker-doc containerd runc

上記の手順を使用して Docker 公式 APT リポジトリを追加します。

Docker CE をインストールします。

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

Docker を起動します。

sudo systemctl start docker

既存のコンテナを確認します。

docker ps -a
docker images
docker volume ls

通常、パッケージの削除は /var/lib/docker を削除しないため、イメージ、コンテナ、およびボリュームは依然として存在する場合があります。それでも、重要なデータをまずバックアップしてください。

Docker Snap から Docker CE へ移行

まず、何が存在するかを確認します。

snap list | grep docker
docker info

ワークロードを停止し、重要なボリュームまたはバインドマウントされたデータをバックアップします。

snap を削除します。

sudo snap remove docker

次に、公式 APT リポジトリから Docker CE をインストールします。

データロケーションに注意してください。Snap パッケージはしばしば異なるパスおよび閉じ込めルールを使用します。移行後、Docker Snap データが標準の /var/lib/docker パス以下に自動的に表示されると想定しないでください。

重要なサービスの場合、パッケージソースを切り替える前にデータを明示的にエクスポートまたはバックアップしてください。

APT で Docker バージョンを固定する

本番ライクなシステムの場合、制御されたアップグレードを希望する場合があります。

利用可能なバージョンをリストします。

apt list --all-versions docker-ce

特定のバージョンをインストールします。

VERSION_STRING="5:29.0.0-1~ubuntu.24.04~noble"

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

Docker パッケージを保持します。

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

後で保持を解除します。

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

予測可能な変更ウィンドウが必要な場合にこれを行ってください。個人のラップトップでは不要かもしれません。

ファイアウォールおよびネットワークに関するノート

Docker はコンテナネットワークを機能させるためにパケットフィルタリングルールを変更するため、UFW、firewalld、nftables、またはカスタムファイアウォールルールを使用している場合は重要になります。

重要な点：

  • 公開された Docker ポートは、単純な UFW の期待を回避する可能性があります。
  • Docker は iptables 統合を使用します。
  • カスタムルールは、Docker が作成したチェーンを考慮すべきです。
  • サーバーのハードニングは、実際のコンテナポートマッピングでテストされるべきです。
  • ufw deny が Docker によって公開されたポートを保護すると想定しないでください。

公開されたポートは、localhost だけでなく、他のマシンからテストしてください。

例：

docker run --rm -p 8080:80 nginx

次に、他のホストから：

curl http://server-ip:8080

サーバーでは、Docker ネットワークはセキュリティモデルの一部であり、インストール後に無視できる実装の詳細ではありません。

一般的なエラーと修正

Docker ソケットでの Permission Denied

エラー：

permission denied while trying to connect to the Docker daemon socket

修正オプション：

sudo を使用：

sudo docker ps

または、ユーザーを docker グループに追加：

sudo usermod -aG docker $USER
newgrp docker

docker グループは実質的に root 同等であるため、グループ所属を特権アクセスの決定として扱ってください。

Docker デーモンが実行されていない

ステータスを確認：

sudo systemctl status docker

起動：

sudo systemctl start docker

ログを確認：

journalctl -u docker --no-pager -n 100

競合する Docker パッケージ

競合のために Docker CE のインストールが失敗する場合、古いパッケージを削除します。Docker リポジトリを追加した後、APT 自体の状態が悪い場合、再試行する前に Ubuntu APT のトラブルシューティング：壊れたパッケージおよび GPG エラー を通じて作業します。

sudo apt remove docker.io docker-compose docker-compose-v2 docker-doc podman-docker containerd runc

次に再試行：

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

Compose コマンドが見つからない

モダンな Compose を確認：

docker compose version

プラグインをインストール：

sudo apt install docker-compose-plugin

古いコマンドを期待していた場合：

docker-compose version

古いドキュメントに従っている可能性があります。コマンドを docker compose に更新することを優先してください。

古い root 所有の Docker 設定

グループアクセスをセットアップする前に sudo で Docker を実行した場合、ユーザー設定が root 所有になっている可能性があります。

所有権を修正：

sudo chown "$USER":"$USER" "$HOME/.docker" -R
sudo chmod g+rwx "$HOME/.docker" -R

または、必要ない場合は設定を削除：

sudo rm -rf "$HOME/.docker"

再作成されます。

ルートレス Docker に接続できない

環境を確認：

echo "$DOCKER_HOST"

ユーザーサービスを確認：

systemctl --user status docker

必要に応じてソケットパスを設定：

export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock

それが正しいことを確認した後、シェルのプロファイルに追加してください。

Docker Engine のアンインストール

Docker CE パッケージを削除：

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

イメージ、コンテナ、およびボリュームを本当に削除したい場合にのみ Docker データを削除：

sudo rm -rf /var/lib/docker
sudo rm -rf /var/lib/containerd

Docker リポジトリファイルを削除：

sudo rm -f /etc/apt/sources.list.d/docker.sources
sudo rm -f /etc/apt/keyrings/docker.asc

APT をリフレッシュ：

sudo apt update

Docker Snap の場合：

sudo snap remove docker

Ubuntu docker.io の場合：

sudo apt purge docker.io docker-compose-v2

ほとんどの Ubuntu ユーザー向けの推奨インストールパス

ほとんどの技術的な Ubuntu ユーザーにとって、これがクリーンなパスです。

sudo apt remove docker.io docker-compose docker-compose-v2 docker-doc podman-docker containerd runc

sudo apt update
sudo apt install ca-certificates curl

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

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

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

sudo docker run hello-world

次に、利便性のためにグループアクセスを希望するか、より厳密な分離のためにルートレス Docker を希望するかを決定します。

sudo usermod -aG docker $USER
newgrp docker
docker run hello-world

最終的な意見のあるガイダンス

Ubuntu 上の Docker インストールは、パッケージの選択だけでなく、運用上の選択です。選択した方法は、アップグレード、セキュリティの境界、およびホストが上流 Docker ドキュメントにどの程度一致するかに影響します。

私の実用的なルールは以下の通りです。

  • ほとんどの開発者および DevOps マシンには、Docker 公式 APT リポジトリを使用します。
  • 上流の新鮮さよりも Ubuntu リポジトリの一貫性が重要である場合は、Ubuntu docker.io を使用します。
  • 意図的に Snap 動作を望まない限り、本格的なコンテナワークフローには Docker Snap を避けます。
  • 本番ホストには簡易スクリプトを避けます。
  • 古い docker-compose ではなく、モダンな docker compose を使用します。
  • docker グループを特権アクセスとして扱います。
  • ユーザー分離が重要である場合は、ルートレス Docker を検討します。
  • 本番ライクなシステムではバージョンを固定します。
  • サーバーでポートを公開する場合は、ファイアウォールの動作をテストします。

最も退屈な Docker インストールが通常最善です：公式 APT リポジトリ、明示的なキーリング、Compose プラグイン、systemd サービス、理解されたパーミッション、および中間に謎のパッケージレイヤーなし。エンジンが配置されると、マルチサービスワークロード（セルフホスト LLM スタックを含む）が自然な次のステップになります。例えば、Docker Compose での Ollama を参照して、コンテナ内でローカルモデルを実行する方法をご覧ください。1つのサーバーで再起動後も Compose スタックを実行し続けるには、systemd で Docker Compose を Linux サービスとして実行する でユニットファイルおよび運用習慣を解説しています。

さらに読む

購読する

システム、インフラ、AIエンジニアリングの新記事をお届けします。