アップグレードする
配備を新しい版に上げ、メンバーのワークスペースを新しいイメージへ移します。 コマンドは形態ごとの手順書にあります。ここでは、何が起きて何に気をつけるかをまとめます。
| あなたがやること | 起きること |
|---|---|
先に backup.sh でバックアップを取る |
戻る道ができる。ダウングレードはできないので、戻すときは復元します |
| 版を変えてイメージを取り、Control Plane を上げ直す | スキーマの移行は Control Plane が起動のときに自動で行う |
| ワークスペースの入れ替えをメンバーに任せる | 動いているワークスペースは古いイメージのまま。Console に「要再起動」が出る |
| 形態 | 手順書 |
|---|---|
| Docker Compose | compose の手順書の「Upgrade」 |
ECS(ecs / ecs-ec2) |
ECS の手順書の「Upgrade (runbook)」 |
| Kubernetes | Kubernetes の手順書の「Upgrading the CP」 |
- 必ずバックアップを取ってください。 新しい版で移行したスキーマは、古い Control Plane には読めません。うまくいかなかったときは、古いイメージに戻すのではなく、バックアップから復元します(バックアップして復元する)
- 互換性のない変更がないか、リリースノートで確かめます
- スキーマの移行は Control Plane に組み込まれていて、起動のときに自動で行われます。手で実行するものはありません
Docker Compose で上げる
Section titled “Docker Compose で上げる”.env の VERSION を新しいタグに変え、イメージを取得(またはビルド)して docker compose up -d します。
- イメージは GHCR(
ghcr.io/k-k1/agent-fleet/*)から取ります。REGISTRYとVERSIONで決まり、レジストリへのログインはいりません - ワークスペースのイメージは compose のサービスではありません。
docker compose pullでは取れないので、別にdocker pullするか、ビルドし直します。WS_IMAGEはVERSIONから作られない別の変数なので、合う版を指すように変えます docker compose up -dは動いているワークスペースに触りません。Docker を再起動しても、作ったときの環境のままです
ECS で上げる
Section titled “ECS で上げる”deploy/aws/ecs/update.sh が 1 回で行います。イメージを ECR に push し、ingress スタックの ImageTag だけを変えてデプロイし、Control Plane のサービスが入れ替わるのを待ちます。
| 気をつけること | 起きること |
|---|---|
| 版によって、あるスタックを先に更新する必要がある | update.sh が最初に確かめ、何にも触れずに止まります。単独で実行する aws cloudformation deploy のコマンドを表示するので、実行してから update.sh をもう一度実行します |
データスタックは update.sh では更新されない |
Persistence=retain で日次の EFS バックアップがない配備を、update.sh が読み取りだけで見つけて警告し、変更セットのコマンドを表示します。手順は手順書の手順 1a です |
ネットワークスタック(00-network)も update.sh では更新されない |
手で更新します。新しいテンプレートを既定値のまま入れると、その S3 エンドポイントが、まだ再起動していないワークスペースの S3 リクエストをすべて拒否します(AccessDenied)。動いているワークスペースをすべて再起動するメンテナンスの時間を取ってください。手順は手順書の「Upgrading from v0.34.x」です |
ecs-ec2 で、リリースがスロットの起動テンプレートを変えた |
今あるスロットには、入れ替えたときにしか届きません(スロットを入れ替える・止める) |
EFS バックアップがないという通知
Section titled “EFS バックアップがないという通知”データスタックに日次の EFS バックアップがないと、Console の管理画面のすべてのセクションに、配備管理者向けの通知が出ます。 「この配備はメンバーのデータを EFS に保持(Persistence=retain)していますが、データスタックに日次の EFS バックアップがありません。」で始まるものです。
update.shが結果を ingress スタックのパラメータEfsBackupに記録し、データスタックにバックアップが入ったことを確かめた時点で消えますupdate.shがデータスタックを読めなかったときは前の判定を残すので、直したことを確かめられた実行まで通知は残ります- 一度も記録していない配備には出ません
- 同じ確認は
deploy/aws/ecs/efs-backup-check.shだけでも実行できます。バックアップがあるか、配備にバックアップがいらない(Persistence=delete)ときだけ、終了コード 0 で終わります
ワークスペースを新しいイメージに移す
Section titled “ワークスペースを新しいイメージに移す”動いているワークスペースは、自動では新しくなりません。次に作られたときから新しいイメージになります。
| 方法 | 起きること |
|---|---|
| メンバーが Console で停止して起動する | 新しいイメージと環境でコンテナが作り直されます。古いワークスペースのメンバーには「要再起動」のバッジが出るので、止めるタイミングは本人に任せます |
| メンバーが「イメージの自動更新」をオンにしておく | 使われていないときに、新しいイメージへ自動で再起動します(新しいイメージへ自動で再起動する) |
自動更新について、配備管理者が知っておくこと:
- 静かだったとみなす時間は、テナントの上限です。配備の既定は
AF_IMAGE_REFRESH_QUIETで、15 分です。0を指定すると行いません - アイドル停止の活動のシグナルは、別の Control Plane のレプリカが持つものも含めてすべて尊重します
- 再作成はせず、再起動だけです。同じイメージで試すのは、ワークスペースごとに 1 回だけです。起動に失敗したら停止したままです
- 毎回、監査ログに
workspace.image_refreshが残り、メンバーに通知が 1 回届きます
- バックアップして復元する
- 閉じたネットワークに入れる:レジストリに届かないホストでイメージを用意する
エージェント向け
この指示をエージェントに送ると、このページを読ませられます。
https://agent-fleet.org/docs/ja/operate/run/upgrade/index.md を読んで