先に要点
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、ディスク、メモリ、証明書、時刻同期などは、普通に本番運用の対象です。
時刻同期を軽く見るとログ調査や認証で詰まりやすいので、NTPとは？サーバーの時刻同期がずれると何が起きるのか もあわせて確認しておくと安全です。
アプリコンテナだけ更新して、ホスト側を何年も放置すると、OSの脆弱性、Docker Engineの古さ、ディスク枯渇、ログ肥大化、証明書期限切れが事故になります。
最低限、次を見ます。
Dockerはアプリを包む道具ですが、サーバー運用を消してくれる道具ではありません。
事故8：デプロイ手順が人によって違う
本番デプロイが「担当者の手元メモ」だけだと、事故が起きやすくなります。
特に、SSHして手作業、サーバー上でgit pull、サーバー上でbuild、環境変数を手で編集、という流れは、最初は速いですが再現性が落ちます。
本番デプロイでは、最低限次を決めます。
本番デプロイで決めておくこと
- 1出すもの
どのブランチ、どのコミットを出すか
- 2build する場所
どこでDockerイメージをbuildするか
- 3push するタグ
どのタグをpushするか
- 4pull するタグ
本番サーバーでどのタグをpullするか
- 5設定の確認
docker compose config で設定を確認するか
- 6反映後の確認
反映後にどのURL、ログ、ヘルスチェックを見るか
- 7戻し先
失敗時にどのタグへ戻すか
小さなサービスでも、デプロイ手順とロールバック手順は文章で残した方がよいです。
「たぶんこのコマンド」で本番を触る回数を減らすだけでも、事故はかなり減ります。
本番前チェックリスト
Docker本番運用前に、最低限次を確認します。
| カテゴリ | チェック項目 |
|---|---|
| イメージ | タグ固定、レジストリ、ロールバック先、不要なlatest利用がない |
| データ | volume、bind mount、外部ストレージの役割が分かる |
| バックアップ | DB、アップロード、設定、シークレットを復元できる |
| ネットワーク | 不要なポートを公開していない。DBやRedisを外へ出していない |
| ログ | エラー、再起動、アクセス、ホスト状態を追える |
| 監視 | 死活監視、ディスク、メモリ、証明書、バックアップ失敗を検知できる |
| 権限 | root実行、privileged、Dockerソケット、広すぎるマウントを見直した |
| デプロイ | 手順、確認項目、ロールバック先、担当者が決まっている |
このチェックリストを見て不安が多いなら、Dockerをやめるべきというより、本番運用の前提を整える段階です。まずはデータ、バックアップ、ログ、監視、デプロイ手順を固めると、Docker運用はかなり安定します。
小規模運用での現実的な構成
小規模サービスなら、いきなりKubernetesまで行かなくても構いません。
現実的には、次のような構成から始めることが多いです。
アプリ
イメージ化してComposeで起動
アプリはDockerイメージ化し、単一サーバーならDocker Composeで起動します。前段にはNginxやCaddyを置きます。
データ
DBとファイルの置き場所
データベースはvolumeか、重要ならマネージドDBへ逃がします。アップロードファイルはS3など外部ストレージも検討します。
運用
戻せる・気づける状態
Kubernetesが必要かは、Kubernetesは小規模サービスに必要？やりすぎになる判断基準 で整理しています。 Docker Compose本番運用の判断は、Docker Composeは本番で使っていい？小規模運用の判断基準と注意点 が近いです。
Docker本番運用の事故に関するよくある質問
Q. コンテナ再起動でデータが消えるのを防ぐには？
A. データを volume にマウントするのが基本です。/var/lib/mysql などの永続データディレクトリを named volume または bind mount に出します。docker compose down でデータが消えないかもテストします。
Q. ホスト OS のディスク不足はどう監視しますか？
A. Docker は古いイメージ、未使用コンテナ、ログ、ビルドキャッシュでディスクを食います。docker system prune、docker image prune の定期実行、du -sh /var/lib/docker の監視、で対策します。
Q. ログが肥大化したらどうしますか？
A. デフォルトの json-file ドライバではログが無限に増えます。max-size: 10m、max-file: 3 を /etc/docker/daemon.json で設定するか、Compose ファイルで logging セクションで指定します。
Q. コンテナが落ちて自動復旧しません。
A. restart: unless-stopped または restart: always を Compose で設定すると、エラー時に自動再起動します。ただし healthcheck は状態を unhealthy と表示するだけで、Docker Engine や Compose 単体では unhealthy になったコンテナを自動では再起動しません（再起動は Swarm やオーケストレーター、外部の監視の役割です）。depends_on の condition: service_healthy で起動順をそろえる用途にも使えます。
Q. デプロイ中に一瞬ダウンするのを避けるには？
A. docker compose up -d --no-deps app で1サービスずつ再起動、ロードバランサーの裏に複数インスタンス、Blue/Green デプロイ、などで対策します。完全無停止は ECS や Kubernetes に近づきます。
Q. メモリ不足で OOM Killer が動きます。
A. mem_limit でコンテナごとのメモリ上限を設定、swappiness 調整、ホスト OS の swap 増加、で対策します。docker stats で各コンテナのメモリ消費を常時把握しておくのが大事です。
Q. セキュリティで気を付けることは？
A. 公式または信頼できるイメージを使う、USER 命令で非 root ユーザーで動かす、不要なポートを公開しない、secrets でパスワードを安全に渡す、定期的にイメージ更新、の5点が基本です。
まとめ
Docker本番運用でよくある事故は、コンテナ技術そのものより、運用の抜け漏れから起きます。
latestタグ、volume削除、バックアップ未確認、ログ消失、不要なポート公開、強すぎる権限、ホストOS放置、手作業デプロイは、どれも小規模運用で起こりやすい事故です。
本番でDockerを使うなら、アプリをコンテナ化するだけでなく、データをどこに置くか、どう戻すか、どのログを見るか、どのポートを開くか、どのタグを動かすかを決めます。
派手な構成にする必要はありません。むしろ小規模では、分かる範囲を狭くして、確実に戻せる状態を作る方が強いです。
参考情報
- Docker Docs: Security
- Docker Docs: Dockerfile best practices
- Docker Docs: Volumes
- Docker Docs: Backup and restore data