先に要点
Dockerは、開発環境をそろえたり、アプリをコンテナとして配布したりするうえでかなり便利です。
ただし、本番運用で使うときは「コンテナだから安全」「作り直せるから安心」と考えると、足元をすくわれます。
実際に怖いのは、Dockerそのものの難しさより、運用の思い込みです。
データは残っていると思っていた。latest のまま再起動した。ログがコンテナごと消えた。DBを外へ公開していた。バックアップはあるが戻したことがない。こういう事故は、小規模運用でも普通に起こります。
この記事では、Dockerを本番で使うときによくある事故と、公開前・運用中に確認したいチェックリストを整理します。
Docker Composeを本番で使う判断は、Docker Composeは本番で使っていい？小規模運用の判断基準と注意点 もあわせて読むとつながりやすいです。
この記事では、2026年4月21日時点で Docker Docs のセキュリティ、Dockerfile best practices、volume、backup/restore関連の情報を確認しながら整理しています。
事故1：latestタグで本番が変わる
本番で latest タグを使うと、再pullや再デプロイのタイミングで、意図しないバージョンが動くことがあります。
開発や検証なら便利でも、本番では「昨日と同じものを動かしている」と説明しづらくなります。
services:
app:
image: example/app:latest
この形だと、いつのイメージなのか、どのコミットに対応しているのか、ロールバック先は何かが曖昧です。
本番では、少なくとも次を決めます。
v1.4.2や20260421-1326のようにタグを固定する- GitコミットSHAとイメージタグを対応させる
- どのタグを本番で動かしているか記録する
- 戻すタグを残す
- ベースイメージも不用意に
latestにしない
Docker公式のDockerfileベストプラクティスでも、イメージは再作成しやすく一時的なものとして扱い、プロダクション向けにはより小さく目的に合ったベースイメージを検討する考え方が示されています。
本番では「動けばよい」より「同じものを再現できる」ことが大切です。
事故2：volumeを消してデータを失う
Docker運用で一番分かりやすく痛い事故は、データ消失です。
特に Docker Compose で docker compose down -v を実行すると、ボリュームも削除対象になります。
開発環境を初期化するなら便利なこともあります。
しかし、本番や検証環境でデータベースのデータをnamed volumeに置いている場合、意味を理解せずに実行すると大事故になります。
確認するポイントは次の通りです。
- データベースの保存先がvolumeになっているか
- どのvolumeがどのサービスに対応するか分かるか
down -vを本番手順に入れていないか- volume削除前にバックアップがあるか
- 復元手順を試したことがあるか
volumeの基本は、Dockerのvolumeとは？DBデータを消さないための永続化の基本 で詳しく整理しています。
事故3：バックアップはあるが戻せない
バックアップファイルがあるだけでは、復旧できるとは限りません。
パスワードが分からない、DBバージョンが違う、ファイル権限が崩れる、アップロードファイルだけ漏れている、復元コマンドが古い、といったことが起きます。
本番でDockerを使うなら、バックアップは次の単位で分けて考えます。
| 対象 | 見ること |
|---|---|
| データベース | SQLダンプ、物理バックアップ、復元テスト、世代管理 |
| アップロードファイル | volume、bind mount、S3など外部ストレージへの保管 |
| Composeファイル | compose.yaml、override、本番用環境変数の管理 |
| シークレット | DBパスワード、APIキー、証明書、復元時に必要な値 |
| イメージ | 再pullできるレジストリ、タグ、ロールバック先 |
Docker公式のバックアップ関連ドキュメントでも、volumesやbind mountsにデータを保存している場合、コンテナ自体のバックアップではなく、再作成に必要な設定やデータの扱いを意識する考え方が示されています。
データベースについては、volumeディレクトリを雑にコピーするだけではなく、DBの推奨するバックアップ手順も確認します。
事故4：ログが消える、追えない
コンテナが落ちたとき、ログが見られないと原因調査がかなり難しくなります。
docker logs で見られる範囲だけに頼っていると、コンテナ再作成やログローテーションで追えなくなることがあります。
本番では、少なくとも次を決めます。
- アプリログを標準出力へ出すか、ファイルへ出すか
- ログローテーションをどうするか
- Dockerのlogging driverをどう使うか
- エラー通知をどこへ飛ばすか
- コンテナ再起動前後のログを追えるか
- ホスト側のsyslog、journald、監視サービスとどうつなぐか
ログは「障害が起きたあとに見るもの」ではなく、障害時に自分を助けるための事前準備です。
小規模でも、最低限はアプリエラー、コンテナ再起動、ディスク不足、メモリ不足を見られるようにしておきます。
事故5：不要なポートを公開する
Dockerでは、ポート公開の指定を間違えると、想定外に外から接続できることがあります。
特に危険なのは、MySQL、PostgreSQL、Redis、管理用UIなどをインターネットへ直接公開してしまうことです。
services:
db:
image: mysql:8.4
ports:
- "3306:3306"
ローカル開発では便利でも、本番では危険なことが多いです。
同じComposeファイルを開発と本番で使い回すと、この種の設定が残りやすくなります。
確認するポイントは次の通りです。
- 本当に外部公開が必要なポートだけ開いているか
- データベースやRedisを外部公開していないか
- 管理画面はIP制限や認証で守っているか
- ホストのファイアウォールも確認したか
- クラウド側のセキュリティグループも確認したか
アプリコンテナ同士の通信は、Dockerネットワーク内だけで足りることが多いです。
外部に開くのは、通常はリバースプロキシやWeb入口だけに絞ります。
事故6：root実行と強すぎる権限
Dockerコンテナ内でrootとして動かすこと自体が、常に即アウトというわけではありません。
ただし、本番では不要なroot実行、過剰なLinux capabilities、Dockerソケットのマウント、privileged実行はかなり慎重に扱うべきです。
Docker公式のセキュリティドキュメントでも、コンテナは非特権ユーザーでプロセスを実行する方が望ましく、必要なcapabilityだけに絞る考え方が示されています。
危険になりやすい例です。
--privilegedを理由なく使う/var/run/docker.sockをコンテナへマウントする- rootで動かす必要がないアプリをrootで動かす
- ホストの広いディレクトリをbind mountする
- 書き込み不要な場所まで書き込み可能にする
本番では、アプリユーザーを分ける、read-onlyにできる場所はread-onlyにする、必要なcapabilityだけにする、ホストへのマウントを最小化する、という地味な対策が効きます。
事故7：ホストOSとDocker Engineを放置する
コンテナを使っていても、ホストOSは消えません。
Docker Engine、Linuxカーネル、ファイアウォール、SSH、ディスク、メモリ、証明書、時刻同期などは、普通に本番運用の対象です。
よくある失敗は、アプリコンテナだけ更新して、ホスト側を何年も放置することです。
この状態だと、OSの脆弱性、Docker Engineの古さ、ディスク枯渇、ログ肥大化、証明書期限切れが事故になります。
最低限、次を見ます。
Dockerはアプリを包む道具ですが、サーバー運用を消してくれる道具ではありません。
事故8：デプロイ手順が人によって違う
本番デプロイが「担当者の手元メモ」だけだと、事故が起きやすくなります。
特に、SSHして手作業、サーバー上でgit pull、サーバー上でbuild、環境変数を手で編集、という流れは、最初は速いですが再現性が落ちます。
本番デプロイでは、最低限次を決めます。
- どのブランチ、どのコミットを出すか
- どこでDockerイメージをbuildするか
- どのタグをpushするか
- 本番サーバーでどのタグをpullするか
docker compose configで設定を確認するか- 反映後にどのURL、ログ、ヘルスチェックを見るか
- 失敗時にどのタグへ戻すか
小さなサービスでも、デプロイ手順とロールバック手順は文章で残した方がよいです。
「たぶんこのコマンド」で本番を触る回数を減らすだけでも、事故はかなり減ります。
本番前チェックリスト
Docker本番運用前に、最低限次を確認します。
| カテゴリ | チェック項目 |
|---|---|
| イメージ | タグ固定、レジストリ、ロールバック先、不要なlatest利用がない |
| データ | volume、bind mount、外部ストレージの役割が分かる |
| バックアップ | DB、アップロード、設定、シークレットを復元できる |
| ネットワーク | 不要なポートを公開していない。DBやRedisを外へ出していない |
| ログ | エラー、再起動、アクセス、ホスト状態を追える |
| 監視 | 死活監視、ディスク、メモリ、証明書、バックアップ失敗を検知できる |
| 権限 | root実行、privileged、Dockerソケット、広すぎるマウントを見直した |
| デプロイ | 手順、確認項目、ロールバック先、担当者が決まっている |
このチェックリストを見て不安が多いなら、Dockerをやめるべきというより、本番運用の前提を整える段階です。
まずはデータ、バックアップ、ログ、監視、デプロイ手順を固めると、Docker運用はかなり安定します。
小規模運用での現実的な構成
小規模サービスなら、いきなりKubernetesまで行かなくても構いません。
現実的には、次のような構成から始めることが多いです。
- アプリはDockerイメージ化する
- 単一サーバーならDocker Composeで起動する
- データベースはvolumeか、重要ならマネージドDBへ逃がす
- アップロードファイルはS3など外部ストレージも検討する
- NginxやCaddyを前段に置く
- バックアップと復元手順を作る
- 死活監視とログ確認を入れる
Kubernetesが必要かは、Kubernetesは小規模サービスに必要？やりすぎになる判断基準 で整理しています。
Docker Compose本番運用の判断は、Docker Composeは本番で使っていい？小規模運用の判断基準と注意点 が近いです。
まとめ
Docker本番運用でよくある事故は、コンテナ技術そのものより、運用の抜け漏れから起きます。
latestタグ、volume削除、バックアップ未確認、ログ消失、不要なポート公開、強すぎる権限、ホストOS放置、手作業デプロイは、どれも小規模運用で起こりやすい事故です。
本番でDockerを使うなら、アプリをコンテナ化するだけでなく、データをどこに置くか、どう戻すか、どのログを見るか、どのポートを開くか、どのタグを動かすかを決めます。
派手な構成にする必要はありません。むしろ小規模では、分かる範囲を狭くして、確実に戻せる状態を作る方が強いです。
参考情報
- Docker Docs: Security
- Docker Docs: Dockerfile best practices
- Docker Docs: Volumes
- Docker Docs: Backup and restore data