先に結論：自動更新は可能。ただし「無停止」と「毎回1秒以内」は約束できない

提案するのは、ホスト側のsystemdタイマーで更新を確認し、イメージをダイジェストで固定してデプロイ、失敗時にはローカルに保管した旧イメージへ戻す方法です。更新専用コンテナは使いません。

ただし、これは無条件に安全という意味ではありません。インターネット越しのレジストリ確認が毎回1秒以内に終わる保証はなく、単一インスタンスのゲートウェイを作り直す以上、無停止や処理中リクエストの完全な維持も保証できません。ホストの電源断やDocker障害、旧イメージ自体が起動しないケースでは、自動復旧ではなく失敗通知が必要です。

また、今回提示できるのは設計草案と実装契約までです。スクリプトやsystemdユニットは未作成で、テストも2台のVPSへの接続確認も行われていません。

なぜタグではなくダイジェストで配備するのか

latestのようなタグは、どの版を確認するかを決める目印には使えます。しかし実際に動かすイメージまでタグ任せにすると、同じ指定でも後から指す内容が変わる可能性があります。そこで、タグから最新候補を見つけたあと、そのイメージをダイジェストで指定して配備します。Docker Composeはタグだけでなくダイジェスト指定のイメージも扱えます。1

設計上は、マルチアーキテクチャのインデックスダイジェスト、各プラットフォームのマニフェストダイジェスト、Docker上のローカルイメージIDを別々に記録します。異なる種類の値をそのまま比較して「同じイメージ」と判断しないためです。

更新前には稼働中コンテナのイメージIDを取得し、専用のローカルタグで旧版を保全。ロールバック時にレジストリへ接続できなくても戻せるようにします。更新処理の途中でホストが再起動した場合に備え、新旧の参照先や処理段階を記録したトランザクション状態もディスクへ保存します。状態ファイルは一時ファイルからの置換だけでなく、ファイルとディレクトリの永続化まで考慮する必要があります。

更新対象をゲートウェイだけに絞る

今回の構成では、ゲートウェイはソースからビルドされ、本機の8080番ポートを使い、読み取り専用の設定ディレクトリを参照します。一方、メールボックスはメモリ上にデータを持つ構成です。そのため、更新時にメールボックスまで再作成しないことが重要です（docker-compose.yml）。

Composeでは、ビルドを行わず、依存サービスを起動せず、追加のイメージ取得もしない指定を使い、対象サービスをゲートウェイだけに限定します。--no-deps、--no-build、--pull neverなどのオプションは、対象サービスの起動や更新方法を絞るために利用できます。2

APP_IMAGE="$NEW_REF" timeout --kill-after=5s 60s \
  docker compose --project-name "$PROJECT" \
  --project-directory "$DEPLOY_DIR" -f "$COMPOSE_FILE" \
  up -d --no-deps --no-build --pull never app

実際に呼び出す前に、Composeプロジェクト名、ゲートウェイが一意であること、設定の指紋、メールボックスコンテナの識別情報を確認します。人手で構成が変更されていた場合は、自動で引き継がず停止する設計です。ローカル開発用のComposeファイルも変更せず、異地配置用の設定だけでイメージ指定を差し替えます。

更新スクリプトの処理順

更新・復旧・初期化・イメージ清掃は、すべて同じファイルロックを使います。すでに別処理が動いていれば、新しい処理は静かに終了。未完了の更新記録がある場合は、遠隔レジストリの確認より先に復旧を試みます。

1. 稼働中のゲートウェイとメールボックス、Composeプロジェクト名、設定が想定どおりか確認する。
2. レジストリからイメージマニフェストだけを取得し、ダイジェストを確認する。通信・認証・解析に失敗したら現行サービスを維持する。
3. ダイジェストに変化がなければ、イメージ取得も再作成も行わず、更新ログも残さない。失敗済みとして隔離したダイジェストも、新しい版が現れるか管理者が解除するまで再試行しない。
4. 新しいダイジェストを取得し、対象プラットフォームのイメージとディスク空き容量を確認する。この間、旧ゲートウェイは動かしたままにする。
5. 旧イメージを保全し、切り替え前の状態をディスクへ記録してから、ゲートウェイだけを再作成する。
6. 新コンテナのイメージ、稼働状態、アプリケーションの応答を確認する。合格した場合に限り、新版を「受け入れ済み」として確定する。
7. 再作成に失敗するか、ヘルスチェックの時間枠内に合格しなければ、保全済みの旧イメージと元の設定でゲートウェイだけを戻す。

コマンドがタイムアウトしたからといって、Docker側の処理まで終了したとは限りません。実際のコンテナ状態を調べてから復旧を進め、切り替え処理を重ねないことが必要です。また、強制終了や電源断では終了時の後処理に頼れません。次回起動時に、保存済みの未完了トランザクションを優先して処理する設計にします。

ヘルスチェックは「起動した」だけで合格にしない

初期案では、チェック全体の時間枠を60秒、1回の接続タイムアウトを1秒、リクエスト上限を3秒、確認間隔を2秒とし、3回連続で成功したら切り替えを確定します。これらは候補値であり、実測で確認された性能ではありません。

確認対象は、ローカルのモデル一覧エンドポイントがHTTP 200を返すことと、応答が期待するJSON形式であることです。リダイレクト先のログイン画面やプロキシのエラーページを成功扱いにしません。さらに、応答したコンテナが候補イメージであることや、再起動回数が増え続けていないことも確認します。

一方、このモデル一覧処理はレジストリのスナップショットを読むもので、実際のチャットリクエストを送るものではありません。ヘルスエンドポイントも静的な生存応答です（internal/api/models.go、internal/api/chat.go）。したがって、これらのチェックだけで上流アカウントの準備や実際のチャット利用可能性まで証明できるわけではありません。実利用テストを加える場合も、利用枠を消費するリクエストを自動で送らないよう、別途設計が必要です。

また、アプリケーションは終了シグナルを受けるとサービスを停止し、HTTPサーバーの終了猶予は5秒です（main.go）。コンテナの停止猶予だけを延ばしても、長時間のストリーミング接続を最後まで維持できる保証にはなりません。無損失の切り替えが必須なら、2インスタンス化や入口の切り替え、接続の排出を含む別設計が必要です。

2台のVPSでは同時に切り替えない

定期確認にはsystemdのoneshotサービスとタイマーを使い、前回の処理が終わってから次回の間隔を数える案です。起動時に1分後、以降は5分間隔を基本とし、最大30秒のランダムな遅延を加える例を想定しています。2台の確認・更新をずらすことで、同時に負荷がかかったり、同じ更新障害を同時に受けたりするリスクを抑えます。

ただし、これは2台が同時に更新される仕組みではありません。目指すのは最終的なバージョン同期であり、1台がロールバックした場合は、問題のあるイメージに追随させず旧版のままにするのが安全です。更新器の優先度を下げても、Dockerデーモンがイメージを展開する際のCPU負荷まで抑えられるとは限りません。低スペック機での実測が必要です。

更新器にはBash、Docker Engine、Composeプラグイン、curl、jq、flockに加え、イメージマニフェストを読むためのSkopeoを想定しています。ホストのディストリビューションや各ツールのバージョンは、実装前に確認します。Docker操作権限を持つホスト側アカウントで動かし、Dockerソケットやレジストリ認証情報をコンテナに渡さない方針です。ただし、実行アカウントがDockerを管理できる以上、ホスト管理者権限に関わるリスクがなくなるわけではありません。

認証情報とイメージ清掃にもルールが必要

GHCRの非公開イメージ取得には、パッケージ読み取り権限を持つPersonal Access Token（classic）を使い、対象パッケージへアクセスできるアカウントであることを確認します。組織の設定によってはSSO認可も必要です。9 CI用の書き込みトークンをVPSへ配布したり、読み取りに不要な書き込み・削除権限を与えたりしません。

各VPSには別々の読み取り専用認証情報を用意し、標準入力経由でログインします。トークンをコマンド引数や監査ログへ残さず、更新器専用の管理者のみ読み取れる場所で保管。認証失敗時は旧サービスを維持して更新を止めます。

イメージの清掃も全体に対する一括削除は避けます。更新器が管理する履歴だけを対象にし、現行版、前回の正常版、未完了トランザクションに関係するイメージは保護します。ほかのコンテナが参照しているイメージや、手動の復旧用タグが付いたものも削除しません。候補として14日を超えた履歴を整理する場合も、強制削除はせず、削除できなければ記録して残します。容量不足を解消するために唯一のロールバック用イメージを消すことはしません。

まずは1台で検証してから

実装に進む前に、両VPSの実際の環境、プロジェクト名、設定マウント、認証情報の権限、現在の正常イメージを確認し、復旧可能な初期状態を作ります。その後、隔離環境で更新とロールバックを演習。問題がなければ1台目で更新・復旧を検証してから、2台目へ進みます。

最低限、次の項目を確認したいところです。

• ダイジェストが変わらない場合、イメージ取得・再作成・更新ログが発生しないこと。ネットワーク越しの確認とローカル比較にかかる時間は別々に測る。
• 更新やロールバックの前後で、メールボックスコンテナのID、起動時刻、保存済みメールが維持されること。
• 不正なイメージ、HTTP 200以外の応答、ヘルスチェックのタイムアウト、再作成失敗から旧版へ戻れること。GHCRに接続できない状態でもローカルの旧イメージで戻れること。
• トランザクションの各段階で更新器を終了させても、次回の起動時に復旧が優先され、隔離した不良ダイジェストを繰り返し配備しないこと。
• 同時実行の防止、認証情報の非露出、保護対象イメージを削除しないこと。

結論として、短いゲートウェイ切り替え時間を許容し、1秒以内の遠隔確認を保証ではなく性能目標とし、各VPSの実環境を確認できるなら、このホスト側更新方式は現実的な候補です。 ただし、現段階で互換性や性能、ロールバック一連の動作が検証済みとは言えません。

先に結論：自動更新は可能。ただし「無停止」と「毎回1秒以内」は約束できない

提案するのは、ホスト側のsystemdタイマーで更新を確認し、イメージをダイジェストで固定してデプロイ、失敗時にはローカルに保管した旧イメージへ戻す方法です。更新専用コンテナは使いません。

ただし、これは無条件に安全という意味ではありません。インターネット越しのレジストリ確認が毎回1秒以内に終わる保証はなく、単一インスタンスのゲートウェイを作り直す以上、無停止や処理中リクエストの完全な維持も保証できません。ホストの電源断やDocker障害、旧イメージ自体が起動しないケースでは、自動復旧ではなく失敗通知が必要です。

また、今回提示できるのは設計草案と実装契約までです。スクリプトやsystemdユニットは未作成で、テストも2台のVPSへの接続確認も行われていません。

なぜタグではなくダイジェストで配備するのか

latestのようなタグは、どの版を確認するかを決める目印には使えます。しかし実際に動かすイメージまでタグ任せにすると、同じ指定でも後から指す内容が変わる可能性があります。そこで、タグから最新候補を見つけたあと、そのイメージをダイジェストで指定して配備します。Docker Composeはタグだけでなくダイジェスト指定のイメージも扱えます。1

設計上は、マルチアーキテクチャのインデックスダイジェスト、各プラットフォームのマニフェストダイジェスト、Docker上のローカルイメージIDを別々に記録します。異なる種類の値をそのまま比較して「同じイメージ」と判断しないためです。

更新前には稼働中コンテナのイメージIDを取得し、専用のローカルタグで旧版を保全。ロールバック時にレジストリへ接続できなくても戻せるようにします。更新処理の途中でホストが再起動した場合に備え、新旧の参照先や処理段階を記録したトランザクション状態もディスクへ保存します。状態ファイルは一時ファイルからの置換だけでなく、ファイルとディレクトリの永続化まで考慮する必要があります。

更新対象をゲートウェイだけに絞る

今回の構成では、ゲートウェイはソースからビルドされ、本機の8080番ポートを使い、読み取り専用の設定ディレクトリを参照します。一方、メールボックスはメモリ上にデータを持つ構成です。そのため、更新時にメールボックスまで再作成しないことが重要です（docker-compose.yml）。

Composeでは、ビルドを行わず、依存サービスを起動せず、追加のイメージ取得もしない指定を使い、対象サービスをゲートウェイだけに限定します。--no-deps、--no-build、--pull neverなどのオプションは、対象サービスの起動や更新方法を絞るために利用できます。2

APP_IMAGE="$NEW_REF" timeout --kill-after=5s 60s \
  docker compose --project-name "$PROJECT" \
  --project-directory "$DEPLOY_DIR" -f "$COMPOSE_FILE" \
  up -d --no-deps --no-build --pull never app

実際に呼び出す前に、Composeプロジェクト名、ゲートウェイが一意であること、設定の指紋、メールボックスコンテナの識別情報を確認します。人手で構成が変更されていた場合は、自動で引き継がず停止する設計です。ローカル開発用のComposeファイルも変更せず、異地配置用の設定だけでイメージ指定を差し替えます。

更新スクリプトの処理順

更新・復旧・初期化・イメージ清掃は、すべて同じファイルロックを使います。すでに別処理が動いていれば、新しい処理は静かに終了。未完了の更新記録がある場合は、遠隔レジストリの確認より先に復旧を試みます。

1. 稼働中のゲートウェイとメールボックス、Composeプロジェクト名、設定が想定どおりか確認する。
2. レジストリからイメージマニフェストだけを取得し、ダイジェストを確認する。通信・認証・解析に失敗したら現行サービスを維持する。
3. ダイジェストに変化がなければ、イメージ取得も再作成も行わず、更新ログも残さない。失敗済みとして隔離したダイジェストも、新しい版が現れるか管理者が解除するまで再試行しない。
4. 新しいダイジェストを取得し、対象プラットフォームのイメージとディスク空き容量を確認する。この間、旧ゲートウェイは動かしたままにする。
5. 旧イメージを保全し、切り替え前の状態をディスクへ記録してから、ゲートウェイだけを再作成する。
6. 新コンテナのイメージ、稼働状態、アプリケーションの応答を確認する。合格した場合に限り、新版を「受け入れ済み」として確定する。
7. 再作成に失敗するか、ヘルスチェックの時間枠内に合格しなければ、保全済みの旧イメージと元の設定でゲートウェイだけを戻す。

コマンドがタイムアウトしたからといって、Docker側の処理まで終了したとは限りません。実際のコンテナ状態を調べてから復旧を進め、切り替え処理を重ねないことが必要です。また、強制終了や電源断では終了時の後処理に頼れません。次回起動時に、保存済みの未完了トランザクションを優先して処理する設計にします。

ヘルスチェックは「起動した」だけで合格にしない

初期案では、チェック全体の時間枠を60秒、1回の接続タイムアウトを1秒、リクエスト上限を3秒、確認間隔を2秒とし、3回連続で成功したら切り替えを確定します。これらは候補値であり、実測で確認された性能ではありません。

確認対象は、ローカルのモデル一覧エンドポイントがHTTP 200を返すことと、応答が期待するJSON形式であることです。リダイレクト先のログイン画面やプロキシのエラーページを成功扱いにしません。さらに、応答したコンテナが候補イメージであることや、再起動回数が増え続けていないことも確認します。

一方、このモデル一覧処理はレジストリのスナップショットを読むもので、実際のチャットリクエストを送るものではありません。ヘルスエンドポイントも静的な生存応答です（internal/api/models.go、internal/api/chat.go）。したがって、これらのチェックだけで上流アカウントの準備や実際のチャット利用可能性まで証明できるわけではありません。実利用テストを加える場合も、利用枠を消費するリクエストを自動で送らないよう、別途設計が必要です。

また、アプリケーションは終了シグナルを受けるとサービスを停止し、HTTPサーバーの終了猶予は5秒です（main.go）。コンテナの停止猶予だけを延ばしても、長時間のストリーミング接続を最後まで維持できる保証にはなりません。無損失の切り替えが必須なら、2インスタンス化や入口の切り替え、接続の排出を含む別設計が必要です。

2台のVPSでは同時に切り替えない

定期確認にはsystemdのoneshotサービスとタイマーを使い、前回の処理が終わってから次回の間隔を数える案です。起動時に1分後、以降は5分間隔を基本とし、最大30秒のランダムな遅延を加える例を想定しています。2台の確認・更新をずらすことで、同時に負荷がかかったり、同じ更新障害を同時に受けたりするリスクを抑えます。

ただし、これは2台が同時に更新される仕組みではありません。目指すのは最終的なバージョン同期であり、1台がロールバックした場合は、問題のあるイメージに追随させず旧版のままにするのが安全です。更新器の優先度を下げても、Dockerデーモンがイメージを展開する際のCPU負荷まで抑えられるとは限りません。低スペック機での実測が必要です。

更新器にはBash、Docker Engine、Composeプラグイン、curl、jq、flockに加え、イメージマニフェストを読むためのSkopeoを想定しています。ホストのディストリビューションや各ツールのバージョンは、実装前に確認します。Docker操作権限を持つホスト側アカウントで動かし、Dockerソケットやレジストリ認証情報をコンテナに渡さない方針です。ただし、実行アカウントがDockerを管理できる以上、ホスト管理者権限に関わるリスクがなくなるわけではありません。

認証情報とイメージ清掃にもルールが必要

GHCRの非公開イメージ取得には、パッケージ読み取り権限を持つPersonal Access Token（classic）を使い、対象パッケージへアクセスできるアカウントであることを確認します。組織の設定によってはSSO認可も必要です。9 CI用の書き込みトークンをVPSへ配布したり、読み取りに不要な書き込み・削除権限を与えたりしません。

各VPSには別々の読み取り専用認証情報を用意し、標準入力経由でログインします。トークンをコマンド引数や監査ログへ残さず、更新器専用の管理者のみ読み取れる場所で保管。認証失敗時は旧サービスを維持して更新を止めます。

イメージの清掃も全体に対する一括削除は避けます。更新器が管理する履歴だけを対象にし、現行版、前回の正常版、未完了トランザクションに関係するイメージは保護します。ほかのコンテナが参照しているイメージや、手動の復旧用タグが付いたものも削除しません。候補として14日を超えた履歴を整理する場合も、強制削除はせず、削除できなければ記録して残します。容量不足を解消するために唯一のロールバック用イメージを消すことはしません。

まずは1台で検証してから

実装に進む前に、両VPSの実際の環境、プロジェクト名、設定マウント、認証情報の権限、現在の正常イメージを確認し、復旧可能な初期状態を作ります。その後、隔離環境で更新とロールバックを演習。問題がなければ1台目で更新・復旧を検証してから、2台目へ進みます。

最低限、次の項目を確認したいところです。

• ダイジェストが変わらない場合、イメージ取得・再作成・更新ログが発生しないこと。ネットワーク越しの確認とローカル比較にかかる時間は別々に測る。
• 更新やロールバックの前後で、メールボックスコンテナのID、起動時刻、保存済みメールが維持されること。
• 不正なイメージ、HTTP 200以外の応答、ヘルスチェックのタイムアウト、再作成失敗から旧版へ戻れること。GHCRに接続できない状態でもローカルの旧イメージで戻れること。
• トランザクションの各段階で更新器を終了させても、次回の起動時に復旧が優先され、隔離した不良ダイジェストを繰り返し配備しないこと。
• 同時実行の防止、認証情報の非露出、保護対象イメージを削除しないこと。

結論として、短いゲートウェイ切り替え時間を許容し、1秒以内の遠隔確認を保証ではなく性能目標とし、各VPSの実環境を確認できるなら、このホスト側更新方式は現実的な候補です。 ただし、現段階で互換性や性能、ロールバック一連の動作が検証済みとは言えません。