PipeCDで稼働中のECS/LambdaのApplicationを別Projectに移行する方法を説明します。
ケースとしては、以下のような場合が考えられます。
- 組織構造の変更等により、いくつかのApplicationの管理者/チームが変更された
- 管理をシンプルにするために、複数のProjectではなく単一のProjectに集約させたい
まとめ
- ECS,LambdaのApplicationは、別Projectへの移行が簡単に可能
- 👍ダウンタイムなし
- 👍移行前後でAWS上のリソース自体は同一
- 👍Applicationの設定ファイルは変更不要
- ⚠️移行直後の初回デプロイ失敗時は注意
- Kubernetes, CloudRun, Terraformは未検証
移行概要
移行の全体像は下図のようになります。
移行前:
移行後:
移行の特徴
移行の特徴は以下のようになります。
- 稼働中のApplicationを、ダウンタイムなしで移行できる
- app-A-newの登録後、QuickSyncが一度行われる
- デプロイの
pipelineを定義していたとしても、QuickSyncになる
- デプロイの
- 移行前後で、AWS上のリソース自体は同一
- すなわち、別のECSサービスやLambda関数が作成されるわけではない
- ただし、ECSタスク定義のリビジョンやLambda関数のバージョンはインクリメントされる
- app.pipecd.yamlやリソースの定義ファイルに変更は不要
移行の前提条件
- 移行元・移行先のProjectが作成済である
- 移行先のPipedはすでに稼働中である
- 移行させたいApplicationは、移行元のProjectですでにデプロイ済である
移行手順
以下、下記のように表記します。
- 移行元のProject: project-old / 移行元のPiped: piped-old / 移行元のApplication: app-old
- 移行先のProject: project-new / 移行先のPiped: piped-new / 移行先のApplication: app-new
1. project-oldでapp-oldをDisableにする
2. project-newでapp-newを登録する
3. app-newの初回デプロイ(QuickSync)が自動でトリガーされるので、完了まで待機
- ECS/Lambdaリソースの
pipecd-dev-piped(PipedのID)とpipecd-dev-application(ApplicationのID)のタグが新しい値になります。
4. app-newのステータスがSyncedになるまで待つ
- LiveStateのUIとDriftDetectionも、app-new側で正常に利用可能です。
5. 移行したい全てのApplicationに対して、1~4を行う
6. (Optional) 後片付け
- project-old上で、移行済のApplicationを削除する
- 不要な場合、piped-oldを停止・削除する
おわりに
Kubernetes, CloudRun, Terraformは未検証なので、どなたか検証いただけるとありがたいです。
Discussion