コンテナを安全に更新・公開する方法：ステージングから切り戻しまで

コンテナ更新で守りたいのは「新しい版を起動できたこと」ではなく、失敗したときに同じデータを壊さず前の版へ戻れることです。この記事は9事例の全文を並べず、更新前の7点チェックから、公開中の個別検証へ案内します。独立記事がない事例は、当時確認できた核だけを残しています。

更新前の7点チェック

症状から個別検証へ進む

自動更新が開始前に止まる

Watchtowerの隔離検証では、古いDocker APIバージョンの指定により更新そのものへ到達しませんでした。更新失敗を「ロールバックできた」と読み替えず、API互換を先に確認して再検証が必要だと結論づけています。詳細は個別記事を正本にします。

telemetryが流れない

OpenTelemetry Collectorでは、壊した設定を元へ戻し、起動ログのEverything is ready、HTTP応答200、新しいspanの追記までを復旧条件にしました。単なるプロセス再起動ではなく、出口の新規データまで読む流れは個別記事にあります。

独立記事がない事例の検証核

latest更新：先に旧digestとデータ退避を残す

更新前に稼働中imageのdigest、volume名、バックアップ先を記録し、更新後に同じHTTP確認を行う構成でした。要点はlatestを禁止することではなく、戻る対象を更新前に一意にしておくことです。

Proxmox上の同型ステージング：本番データは持ち込まない

検証用VMとDockerへ合成データだけを入れ、構築と撤去を確認しました。本番の投稿データや秘密を複製しないため、同型とはサービス境界と手順が同じという意味です。

正本のずれ：ファイル名ではなくSHA-256を比べる

ステージングで直ったのに本番が古いままだった事例では、配布元・配布先・実行中コンテナのファイルをSHA-256で照合しました。「同じ名前のファイルがある」では同一性の根拠になりません。

Ansible：2回目の変更件数を見る

1回目の成功だけで冪等とせず、同じ入力でもう一度実行し、2回目に意図しない変更が残らないかを確認しました。対象サービスのvalidateがある場合は、適用前の検査に組み込みます。

Caddy：期待した502を観測できなかった

壊したupstreamより手前で自動HTTPSの条件に止められ、狙った502 Bad Gatewayへ到達しませんでした。この断面は502の再現成功ではなく、「観測したい故障より前段の条件が勝った」記録として扱います。

Rootless Podman：安全性の一般論よりportとvolume権限を先に見る

rootful Docker、Rootless Podman、一般ユーザーのsystemdを同じ観点で比べました。低位port、volume所有者、ユーザーサービスの残存条件が違うため、起動可否だけで置換可能とは判断していません。

Gitea Actions：構築と撤去は通ったがジョブ結果の観測が未達

Docker/Composeによる構築、待受、撤去は確認できました。一方、ジョブ結果を読む導線は完了していません。CIが動いたという結論には広げず、検証できた境界をここで止めます。

SOPSとage：暗号化された差分と復号の両方を確認する

Git差分に平文が残らないこと、SOPSメタデータがあること、別工程で復号できることを一組にしました。鍵や実際の秘密は記事へ載せません。

depends_on：起動順ではなくhealthcheckの差分を読む

壊したCompose定義では依存先がunhealthyになり、修正版ではhealthyになりました。depends_onの存在だけでアプリの利用可能性を保証せず、依存先の意味のあるhealthcheckとアプリ側のreadbackを分けます。

切り戻しを先に書く

1. 更新前のimage digestと設定ハッシュを保存する。
2. volumeを別の復元先へ戻せることを確認する。
3. 新旧で同じ意味検証を実行する。
4. 失敗時は旧digestへ戻し、公開URLの新しい応答を読む。
5. 不要になった検証環境を撤去する。

この5行を更新前に埋められないサービスは、自動更新へ進めません。