deploy.sh は変更のあったサービスを再作成します。バージョンを切り替える前にデータとキーをバックアップしてください。スキーマの変更に自動的なロールバックはありません。バージョンごとの手順はバックアップリファレンスと で確認してください。
コードを変更する前に
1
実行中のバージョンを記録する
エンジンのチェックアウトで、現在のコミットを記録し、サービスが応答することを確認します。health レスポンスには
version フィールドがあります。復元が必要になったときにどこへ戻るべきか分かるよう、両方の値を変更記録と一緒に残してください。2
データとキーをバックアップする
リポジトリのバックアップスクリプトを実行し、出力をこのホストの外の保存先に移してください。このスクリプトは、存在する場合 Postgres とローカルのアップロードファイルをバックアップします。一時データベースでの演習と復旧手順はバックアップの確認と復元に従ってください。
.env、使用中の config.prod.yaml などの有効な上書きファイル、.key.yaml ファイル、compose.override.yaml も保護された場所に保管してください。スクリプトはこれらのファイルを含みません。外部オブジェクトストレージのバケットも別途バックアップしておいてください。3
対象リリースを確認する
とそのリリースページで、対象バージョンの説明を読んでください。上書きファイルのキーと provider の設定がまだ有効かを確認してください。正確なリリースタグまたはコミットを選び、確認したその値を続行前に
TARGET_REF としてシェルに設定してください。アップグレードと検証
1
確認済みのリリースに切り替える
同じチェックアウトで、選んだ ref を取得して内容を確認してから切り替えます。追跡対象のファイルにローカルの変更が残っている場合は、先に
git status --short で確認してください。競合があると Git は切り替えを拒否します。2
新しいスタックを起動する
compose.yaml が指定するリリースイメージを取得し（取得できない場合は Docker Hub のミラー mirror.gcr.io または docker.1ms.run を使い、どちらも失敗したときだけこのチェックアウトからローカルビルドします）、Postgres・サーバー・worker、さらにアップロードボリュームの所有者を直すワンショットコンテナを起動して、healthy になるまで待ちます。起動時に Python の依存関係がインストールされることはなく、それはローカルビルドの中でだけ起こります。ローカルモデルを動かしているスタックはそのまま使えます。.env の COMPOSE_PROFILES が llama サービスを再び起動し、そのモデル用ボリュームは再利用されるため、二度目のダウンロードは発生しません。別のターミナルで docker compose logs -f mirobody を使い、起動やスキーマのエラーを確認してください。3
結果を確認する
別のターミナルで次を実行します。
mirobody が healthy になり、レスポンスの version が選んだリリースと一致するはずです。公開 HTTPS アドレスからログインし、既存の記録を開いて、ファイルのアップロードやエージェントの回答など利用者が頼っている機能を1つ確認してください。healthy にならない場合は、トラブルシューティングを使い、docker compose logs --tail 80 mirobody を確認してください。