> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mirobody.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# デプロイのアップグレード

> 復元できるバックアップを取り、リリース内容を確認してから、セルフホストの Docker スタックをアップグレードして動作を検証します。

対象 mirobody
[`1.5.10`](https://github.com/thetahealth/mirobody/tree/b37cd7b24af5251a4364aab30905a7497fc69dcb)

短いメンテナンス時間帯を予定してください。`deploy.sh` は変更のあったサービスを再作成します。バージョンを切り替える前にデータとキーをバックアップしてください。スキーマの変更に自動的なロールバックはありません。バージョンごとの手順は[バックアップリファレンス](https://docs.mirobody.ai/ja/deployment/backup.md)と `CHANGELOG.md` で確認してください。

## コードを変更する前に

**1. 実行中のバージョンを記録する**

エンジンのチェックアウトで、現在のコミットを記録し、サービスが応答することを確認します。

```bash theme={null}
git rev-parse HEAD
curl -fsS http://127.0.0.1:18060/api/health
```

health レスポンスには `version` フィールドがあります。復元が必要になったときにどこへ戻るべきか分かるよう、両方の値を変更記録と一緒に残してください。

**2. データとキーをバックアップする**

リポジトリのバックアップスクリプトを実行し、出力をこのホストの外の保存先に移してください。

```bash theme={null}
shell/backup.sh
```

このスクリプトは、存在する場合 Postgres とローカルのアップロードファイルをバックアップします。一時データベースでの演習と復旧手順は[バックアップの確認と復元](https://docs.mirobody.ai/ja/deployment/restore.md)に従ってください。`.env`、使用中の `config.prod.yaml` などの有効な上書きファイル、`.key.yaml` ファイル、`compose.override.yaml` も保護された場所に保管してください。スクリプトはこれらのファイルを含みません。外部オブジェクトストレージのバケットも別途バックアップしておいてください。

**3. 対象リリースを確認する**

`CHANGELOG.md` とそのリリースページで、対象バージョンの説明を読んでください。上書きファイルのキーと provider の設定がまだ有効かを確認してください。正確なリリースタグまたはコミットを選び、確認したその値を続行前に `TARGET_REF` としてシェルに設定してください。

## アップグレードと検証

**1. 確認済みのリリースに切り替える**

同じチェックアウトで、選んだ ref を取得して内容を確認してから切り替えます。

```bash theme={null}
git fetch --tags origin
git show --no-patch "$TARGET_REF"
git checkout "$TARGET_REF"
```

追跡対象のファイルにローカルの変更が残っている場合は、先に `git status --short` で確認してください。競合があると Git は切り替えを拒否します。

**2. 新しいスタックを起動する**

```bash theme={null}
./deploy.sh
```

このスクリプトは `compose.yaml` が指定するリリースイメージを取得し（取得できない場合は Docker Hub のミラー `mirror.gcr.io` または `docker.1ms.run` を使い、どちらも失敗したときだけこのチェックアウトからローカルビルドします）、Postgres・サーバー・worker、さらにアップロードボリュームの所有者を直すワンショットコンテナを起動して、healthy になるまで待ちます。起動時に Python の依存関係がインストールされることはなく、それはローカルビルドの中でだけ起こります。ローカルモデルを動かしているスタックはそのまま使えます。`.env` の `COMPOSE_PROFILES` が `llama` サービスを再び起動し、そのモデル用ボリュームは再利用されるため、二度目のダウンロードは発生しません。別のターミナルで `docker compose logs -f mirobody` を使い、起動やスキーマのエラーを確認してください。

**3. 結果を確認する**

別のターミナルで次を実行します。

```bash theme={null}
docker compose ps
curl -fsS http://127.0.0.1:18060/api/health
```

`mirobody` が healthy になり、レスポンスの `version` が選んだリリースと一致するはずです。公開 HTTPS アドレスからログインし、既存の記録を開いて、ファイルのアップロードやエージェントの回答など利用者が頼っている機能を1つ確認してください。healthy にならない場合は、[トラブルシューティング](https://docs.mirobody.ai/ja/troubleshooting.md)を使い、`docker compose logs --tail 80 mirobody` を確認してください。

## ロールバック

アプリと worker を停止し、アップグレード前のバックアップからデータベースとローカルのアップロードファイルを復元し、**対応する**キーと設定も復元してから、チェックアウトを記録済みのコミットに戻して起動してください。復元コマンドは[デプロイを復旧する](https://docs.mirobody.ai/ja/deployment/restore.md#recover-a-deployment)に従ってください。バックアップは1つのまとまりとして扱ってください。スキーマ変更の後にコードだけを戻すと、古いリリースが新しいデータベースを読んでしまうことがあります。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.