コンテナの安全な自動更新 ― Watchtowerと運用設計で「古いイメージ」を放置しない

デプロイした当初は最新だったイメージも，時間が経てば古くなり，脆弱性を抱える．「動いているから」と更新を放置したコンテナは，気づかぬうちにセキュリティリスクの温床になる．

かといって，すべてを手動で更新し続けるのは現実的でない．そこでコンテナの更新を仕組み化する── 自動更新ツールと，それを安全に運用する設計が必要になる．

この記事は，VPSでコンテナを運用する個人開発者，イメージ更新を放置しがちなエンジニアに向けている．Watchtowerによる自動更新の仕組みから，その利点とリスク，安全な運用設計までを解説する．

読み終えたとき，あなたはコンテナを最新・安全に保ちつつ，自動更新の暴走で本番を壊さない更新運用ができるようになっている．

なぜコンテナの更新を放置してはいけないか

コンテナイメージには，OSのパッケージ・言語ランタイム・ライブラリが含まれる．時間が経つと，これらに脆弱性が発見される．更新しないコンテナは，既知の穴を抱えたまま動き続ける．

「動いているから触らない」は，セキュリティの観点では「既知の脆弱性を放置している」のと同じだ．特に公開サービスでは，古いイメージは攻撃の標的になりうる．

一方で，無計画な更新は別のリスクを生む．自動更新が破壊的変更を含むイメージを引いてきて，本番が動かなくなる事故もある．「更新する」と「壊さない」の両立が課題だ．

解決は，更新を仕組み化しつつ，バックアップとロールバックで守ること．自動と手動を適切に使い分けることが鍵になる．

更新戦略の全体像 ― 何を自動化し、何を手動にするか

すべてを自動更新するのも，すべてを手動にするのも極端だ．リスクと重要度で使い分けるのが現実的だ．

対象	推奨	理由
DB・ステートフルなもの	手動・慎重に	破壊的変更やデータ移行のリスク
自作アプリ(自分でビルド)	CI/CD経由で管理	テストを通してから更新
補助的なツール・軽量サービス	自動更新も可	壊れても影響が小さい

原則は，影響が大きく破壊的変更のリスクがあるもの(特にDB)は手動，影響が小さく更新の安全なものは自動だ．自作アプリはCI/CDで「テスト→ビルド→デプロイ」を管理するのが理想で，無条件の自動更新とは分けて考える．

Watchtower ― 自動更新の仕組み

Watchtowerは，実行中のコンテナのイメージに更新があるかを定期的にチェックし，新しいイメージがあれば自動でpullして再作成するツールだ．コンテナとして手軽に導入できる．

Watchtowerの基本設定(compose)

services:
  watchtower:
    image: containrrr/watchtower
    restart: always
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      WATCHTOWER_SCHEDULE: "0 0 4 * * *"   # 毎日4時にチェック
      WATCHTOWER_CLEANUP: "true"           # 古いイメージを掃除
      WATCHTOWER_NOTIFICATIONS: shoutrrr   # 通知(任意)

/var/run/docker.sockをマウントすることで，WatchtowerはDockerを操作できる(これは強い権限なので扱いに注意)．WATCHTOWER_SCHEDULEでチェック時刻を指定し，WATCHTOWER_CLEANUPで更新後に古いイメージを掃除する．通知を設定すれば，更新が起きたことを把握できる．

対象を絞る ― ラベルで自動更新するものを限定

全コンテナを無条件に自動更新するのは危険だ．ラベルで「自動更新してよいコンテナ」だけを対象にするのが安全な運用だ．

ラベルで対象を限定

# Watchtower側: ラベルが付いたものだけ監視
environment:
  WATCHTOWER_LABEL_ENABLE: "true"

# 各サービス側: 自動更新を許可するものにラベル
services:
  tool:
    image: some/tool
    labels:
      com.centurylinklabs.watchtower.enable: "true"
  # DBにはラベルを付けない=自動更新されない

WATCHTOWER_LABEL_ENABLEを有効にすると，ラベルを付けたコンテナだけが自動更新の対象になる．DBや重要なステートフルサービスにはラベルを付けず，自動更新から除外する．これで「DBが勝手に更新されてデータ移行が必要になった」といった事故を防げる．

自動更新のリスクと、その緩和

自動更新には固有のリスクがある．(1)破壊的変更を含むイメージで動かなくなる (2)更新タイミングが読めない (3)問題に気づくのが遅れる．これらを緩和する設計が要る．

タグ戦略：latestを追うと破壊的変更を引きやすい．メジャー固定タグ(例: 1)を使うとリスクを減らせる．
更新時刻の固定：深夜など影響の少ない時間にスケジュールし，万一の影響を抑える．
通知：更新が起きたら通知を受け，問題があればすぐ気づけるようにする．
バックアップ前提：更新前にスナップショットがあれば，壊れても戻せる．

バックアップとロールバック ― 壊れても戻せる

自動・手動を問わず，更新には「壊れたら戻す」手段が不可欠だ．イメージ更新で問題が出たとき，速やかに前のバージョンに戻せる体制を作る．

特定バージョンへのロールバック

# タグでバージョンを管理していれば,前のタグに戻すだけ
docker compose pull   # or 特定タグを指定
# compose.ymlのイメージタグを前バージョンに変更して
docker compose up -d

# サーバー全体ならスナップショットから復元が最速

イメージにバージョンタグを付けて管理していれば，compose.ymlのタグを前のバージョンに書き換えてup -dするだけでロールバックできる(イメージ最適化・レジストリの記事参照)．より確実なのは更新前のスナップショットで，サーバー全体を更新前に戻せる．自動更新を使うなら，この戻せる体制とセットにする．

自動と手動の使い分け ― 現実的な落とし所

結局のところ，個人開発の現実的な落とし所はこうだ．自作アプリはCI/CDで管理(テスト経由)，DBは手動で慎重に，補助ツールはWatchtowerで自動，そして全体をスナップショットで守る．

「最新を保ちたい」気持ちと「壊したくない」気持ちのバランスを，対象ごとに変えるのが賢い．何でも自動，何でも手動ではなく，リスクに応じて選ぶ．

そして忘れてはいけないのがホストOS自体の更新だ．コンテナを最新にしても，ホストのOSパッケージ(特にカーネルやDockerエンジン)が古ければ穴が残る．無人セキュリティ更新(初期設定の記事参照)と併せて，OSとコンテナの両方を最新に保つ意識が重要だ．

補論：安全な自動更新は「スナップショットで戻せるVPS」が前提

コンテナの自動更新は，セキュリティ維持に有効な反面，「壊れても戻せる」体制がなければ怖くて使えない．更新が破壊的変更を引いてきたとき，即座に戻せるかどうかが運用の安心を左右する．

高速NVMe・50種類以上のOSテンプレートに対応した国内VPS─シン・VPS─ はスナップショットを備え，NVMe SSDでイメージのpullや再作成も高速だ．「更新前にスナップショット→自動更新→問題があれば即復元」という安全な更新サイクルを組めるため，Watchtowerによる自動更新も安心して導入できる．OSの自動更新と合わせ，常に最新・安全な状態を保てる．

更新を続けるサービスは独自ドメインで安定公開しよう．取り扱い400種類以上のドメイン取得サービス─ムームードメイン─ でドメインを取得し，最新に保たれた安全なコンテナでサービスを運用するのが理想だ．

よくある質問(FAQ)

Q1．コンテナの更新を放置するとどうなる？

イメージに含まれるOS・ランタイム・ライブラリの既知の脆弱性を抱えたまま動き続ける．公開サービスでは攻撃の標的になりうる．「動いているから触らない」はセキュリティ上は危険だ．

Q2．全部Watchtowerで自動更新してよい？

非推奨だ．DBや重要なステートフルサービスは破壊的変更のリスクがあるため手動・慎重に．ラベルで自動更新対象を限定し，影響の小さいものだけ自動化するのが安全だ．

Q3．latestタグを追うのは危険？

破壊的変更を引きやすい．メジャーバージョン固定タグ(例: postgres:16)を使うと，互換性を保ちつつセキュリティ更新を受けられる．latestの無条件自動更新は事故の元だ．

Q4．自作アプリも自動更新すべき？

CI/CDで管理するのが理想だ．テストを通してからビルド・デプロイする．Watchtowerのような無条件自動更新ではなく，「テスト経由の更新」と分けて考える．

Q5．更新で壊れたらどうする？

バージョンタグで前に戻すか，更新前のスナップショットから復元する．自動更新を使うなら，この戻せる体制を必ずセットにする．

Q6．ホストOSの更新も要る？

必須だ．コンテナを最新にしてもホストOSやDockerエンジンが古ければ穴が残る．無人セキュリティ更新を有効にし，OSとコンテナの両方を最新に保つ．

まとめ ― 「最新に保つ」と「壊さない」を両立する

コンテナの更新運用は，放置せず最新に保ちつつ，自動更新の暴走で本番を壊さないことが要点だ．対象ごとに自動・手動を使い分け，タグ戦略・通知・バックアップで守る．

今日やるべきことは，自分のコンテナのイメージが古くないか確認し，更新戦略(何を自動・何を手動)を決めること．そして更新前にスナップショットを取る習慣をつける．

セキュリティは「最新に保つ」ことから始まる．スナップショットで戻せるVPSがあれば，自動更新も恐れず取り入れ，常に安全な状態を保てる．