ダウンタイムなしのコンテナ更新

サービスを稼働させたままロールバックも可能なイメージ更新の方法です。バージョンの固定、ヘルスチェック、手順の順序、自動化を説明します。

更新日 2026年8月23日

コンテナの更新は「新しいイメージをpullする」ことではなく、「実行中のバージョンを新しいものに置き換え、ロールバックできるようにする」ことです。この違いがはっきりと現れるのは、新しいバージョンが起動に失敗したときの一度だけです。

機能する手順

cd /opt/myapp
docker compose pull
docker compose up -d
docker compose ps
docker compose logs -f --tail 100

Composeはイメージが変更されたサービスだけを再作成し、それ以外には手を付けません。ダウンタイムはコンテナの再起動にかかる数秒だけです。

ただし、これを実行する前に2つの条件を満たしてください。

1つ目：バージョンが固定されていること。 ファイルには postgres:latest ではなく postgres:17.2 を指定する必要があります。そうでなければ、ある日 pull がデータ形式を書き換えるメジャーバージョンを持ち込んでしまい、ロールバックが不可能になります。

2つ目：バックアップが新しいこと。 データベースを壊す更新は、それを不可逆的に壊します。メジャーバージョン変更の前にはダンプを取得してください。詳しくはバックアップすべきものを参照してください。

ギャップなく置き換える

リバースプロキシの背後にあるWebサービスでは、コンテナにヘルスチェックがあればダウンタイムはほぼゼロになります。プロキシは準備が整ったインスタンスにのみリクエストを送信し始めるからです。

services:
  app:
    image: ghcr.io/example/app:1.5.0
    healthcheck:
      test: ["CMD", "curl", "-fsS", "http://localhost:8080/health"]
      interval: 5s
      timeout: 3s
      retries: 6
      start_period: 20s

docker inspect -f '{{.State.Health.Status}}' <container>

ヘルスチェックがない場合、Composeはプロセスが起動した時点でコンテナを準備完了と見なします。その間、アプリケーションはまだ設定を読み込み、マイグレーションを適用しています。

新しいバージョンが少なくとも1時間稼働するまで、古いイメージを削除しないでください。ロールバックとは image: ...:1.4.2 を復元して docker compose up -d を実行することですが、それは古いイメージがまだディスク上にある場合に限られます。更新直後の docker image prune -a は、その選択肢をあなたから奪います。

ロールバック

sed -i 's|app:1.5.0|app:1.4.2|' compose.yaml
docker compose up -d app
docker compose logs -f --tail 50 app

新しいバージョンがすでにデータベーススキーマを変更している場合、イメージだけをロールバックしても十分ではありません。バックアップからの復元が必要になります。だからこそ、メジャーアップデートは静かな時間帯に、検証済みのバックアップを用意して行います。詳しくはリストア演習を参照してください。

自動化：注意が必要

Watchtowerはコンテナを自動で更新できます。家庭用サービスでは便利ですが、本番環境ではリスクです。夜中に更新が届き、データベースが壊れ、誰も気づきません。妥当な妥協点は通知のみです。

services:
  watchtower:
    image: containrrr/watchtower
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    command: --monitor-only --schedule "0 0 6 * * *"

新しいバージョンがリリースされたことを知り、都合の良い時間に手動で更新します。

マシンの再起動

システムパッケージはコンテナとは別に更新されます。カーネル更新後には再起動が必要で、restart: unless-stopped を設定したコンテナは自動的に復帰します。これは事前にテストしてください。インシデントの最中ではなく、静かな時間帯に sudo reboot で行います。コントロールパネルからのソフトリブートは、システムに qemu-guest-agent がインストールされていれば機能します。

よくある間違い

up -d を伴わない pull。 新しいイメージはダウンロードされますが、古いコンテナはまだ稼働しています。
ディスクが古いイメージで詰まっている。 月に一度 docker image prune を実行してください。ただし更新直後は避けてください。詳しくはディスク容量を参照してください。
一度にすべてを更新した。 何かが壊れても、どれが原因か分かりません。サービスは1つずつ更新してください。
リリースノートを読んでいない。 互換性のない設定ファイルは、メジャーバージョン変更後の障害で最もよくある原因です。詳しい内訳はDockerのよくある問題を参照してください。