2026年8月4日

VPSへのDocker環境の構築方法：公式リポジトリからのインストールとファイアウォール・ログ・ディスクの初期設定

VPS・クラウド

VPSにDockerを入れるには、Docker公式のaptリポジトリを登録して Docker Engine と Compose プラグインをインストールし、動作確認のあとに「公開ポートとファイアウォール」「ログの肥大化」「ディスクの使用量」の3点を設定しておくのが基本です。特に、Dockerで公開したポートはUFWの設定をすり抜けることがあり、VPSでは見落とすと危険です。この記事では、Ubuntuを例に、インストールから本番運用前に済ませておきたい初期設定までを説明します。

インストール前に確認すること

OSと既存のパッケージ

Docker公式のリポジトリは、対応するOSの版が決まっています。Ubuntuの場合は、サポート期間内の版（LTS版を使うのが一般的です）であることを確認してください。対応状況は更新されるため、公式ドキュメントのインストール手順のページで確かめます（2026年10月現在）。

cat /etc/os-release

Ubuntuの標準リポジトリにある docker.io など、別系統のパッケージが入っているとぶつかることがあります。公式手順では、先に次のパッケージを取り除くよう案内されています。

for pkg in docker.io docker-doc docker-compose docker-compose-v2 podman-docker containerd runc; do
  sudo apt-get remove -y "$pkg"
done

入っていないパッケージについては「インストールされていません」と表示されるだけなので、問題ありません。既存のコンテナやイメージを使っている環境では、作業前に必要なデータを退避してください。

メモリとディスクの余裕

Docker自体は軽いものの、コンテナを複数動かすとメモリとディスクを使います。メモリが少ないVPSでは、データベースのコンテナがメモリ不足で強制終了されることがあるため、スワップの設定も検討します。イメージやコンテナのデータは既定で /var/lib/docker に置かれるので、ルートのファイルシステムに十分な空きがあるかを df -h / で確認しておきます。

手順1：公式リポジトリからインストールする

公式ドキュメントに沿った手順の例です。リポジトリの登録方法（ファイルの書式など）は変わることがあるので、実際の作業では公式ページのコマンドを優先してください。

sudo apt-get update
sudo apt-get install -y 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

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

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

get.docker.com の便利スクリプトを使う方法もありますが、公式ドキュメントでも本番環境向けではないとされています。VPSで長く運用するなら、リポジトリを登録する方法が更新の管理をしやすくなります。

手順2：動作を確認する

sudo docker version
docker compose version
sudo docker run --rm hello-world
systemctl is-enabled docker

hello-world のメッセージが表示されれば、イメージの取得とコンテナの実行ができています。systemctl is-enabled docker が enabled なら、VPSの再起動後もDockerが自動で起動します。

Composeは docker compose（空白区切り）のプラグイン版を使います。ハイフン付きの docker-compose は旧版のコマンドで、すでに更新が終了しています。古い手順書を参考にするときは読み替えてください。

手順3：docker グループの扱いを決める

毎回 sudo を付けるのが面倒なため、作業用ユーザーを docker グループに加える手順がよく紹介されます。

sudo usermod -aG docker "$USER"
# 反映にはログインし直しが必要

ただし、docker グループに属するユーザーは、コンテナ経由でホストのファイルを自由に読み書きできるため、実質的に root と同じ権限を持ちます。SSHの鍵が漏れたときの影響も root と同じになると考えてください。共用のユーザーには付けない、sudo のままで運用する、Rootless モードを検討する、といった判断が必要です。

手順4：公開ポートとファイアウォールを設定する

VPSでもっとも注意が必要なのがここです。Dockerは -p や Compose の ports: でポートを公開するとき、iptables に独自のルールを追加します。このルールはUFWの許可・拒否より先に処理されるため、UFWで閉じているつもりのポートが外部に開いてしまうことがあります。

確認のため、テスト用のコンテナを起動してみます。

# 悪い例：すべてのアドレスで公開される（UFWで閉じていても外から届く場合がある）
sudo docker run -d --name web-test -p 8080:80 nginx

# よい例：ホスト自身からだけ届くように公開する
sudo docker rm -f web-test
sudo docker run -d --name web-test -p 127.0.0.1:8080:80 nginx
curl -I http://127.0.0.1:8080/

外部に見せるのはホストのNginxなどのリバースプロキシだけにして、コンテナは 127.0.0.1 に限定して公開するのが、VPSでの扱いやすい構成です。Composeでは次のように書きます。

services:
  web:
    image: nginx
    ports:
      - "127.0.0.1:8080:80"
    restart: unless-stopped

ホスト側のNginxからは、次のように転送します。

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

外部に直接公開したいポートがある場合は、Dockerが用意している DOCKER-USER チェーンにルールを書く方法がありますが、iptables の知識が必要です。設定したら、手元のPCなど外部から nmap や curl で、意図しないポートが開いていないかを確かめてください。確認が終わったら sudo docker rm -f web-test でテスト用のコンテナを削除します。

手順5：ログの肥大化を防ぐ

Dockerの既定のログ方式（json-file）は、設定しないとログファイルが際限なく大きくなります。長く動かしているうちにディスクがいっぱいになり、データベースが書き込めなくなる、という障害につながります。/etc/docker/daemon.json で上限を決めておきます。

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

sudo systemctl restart docker

この設定が効くのは、変更後に新しく作られたコンテナだけです。既存のコンテナは作り直す必要があります。また、Dockerの再起動で動いているコンテナも一度止まるため、サービスを始める前に設定を済ませておくのが理想です。

手順6：ディスクの使用量を管理する

イメージの更新を繰り返すと、使われなくなった古いイメージやビルドのキャッシュがたまります。使用量は次のコマンドで確認できます。

sudo docker system df
sudo docker image prune      # タグのない不要なイメージを削除
sudo docker builder prune    # ビルドキャッシュを削除

削除の系統のコマンドのうち、ボリュームを対象にするもの（docker volume prune や docker system prune --volumes）には注意が必要です。データベースのデータをボリュームに置いている場合、コンテナを止めているだけの状態でも削除の対象になることがあります。実行前に docker volume ls で対象を確認し、データベースは別途ダンプでバックアップを取っておきます。

手順7：再起動後に戻ることを確認する

最後に、VPSを再起動してもコンテナが戻ってくるかを確認します。Composeで restart: unless-stopped などの再起動ポリシーを指定しておけば、Dockerの起動とともにコンテナも起動します。

sudo reboot
# 再接続後
sudo docker ps

本番のサービスを載せる前に一度試しておくと、メンテナンスでの再起動のたびに慌てずに済みます。WordPressなどのアプリケーションをコンテナで動かすのは、ここまでの土台ができてからにすると、トラブルの切り分けが楽になります。

まとめ

Docker Engine は公式のaptリポジトリから入れ、Compose は docker compose のプラグイン版を使う
docker グループは実質的に root 権限。付けるユーザーを絞る
公開したポートはUFWをすり抜けることがある。コンテナは 127.0.0.1 に限定して公開し、外部にはリバースプロキシだけを見せる
daemon.json でログの上限を決め、docker system df でディスクの使用量を定期的に確認する
ボリュームを消すコマンドは対象を確認してから使い、再起動後にコンテナが戻ることを確かめておく