想定環境
- AWSリソースの作成・管理はTerraform
- ECSサービスの作成・管理はecspresso
- ECSのデプロイをCodeDeployで管理
何が起こる?
- 普通にECSリソースを作ろうとすると、エラーになる
- CodeDeployのデプロイメントグループでECSサービスを指定しているけど、ECSサービスはecspressoで管理しているので、Terraformでapplyするときはまだ存在しない
リソース作成順序
以下の順序でリソースを作成すると依存関係的にエラーなく作成できる(はず)
- CodeDeployのDeploymentGroup以外のリソース(ALBとかターゲットグループとかVPCとかサブネットとか)を作る
- GithubActions上とかでecspressoでECSのサービスの作成とタスク定義を登録する
- CodeDeployのDeploymentGroupとを作る
ECSサービスを作るときにCodeDeployのDeploymentGroupがないとエラーになるのでは?
ECSサービス定義では、デプロイメントコントローラーを指定でき、そこでCodeDeploy
を指定することになる
その時に、CodeDeployがまだそのECSサービスに紐づいていないとエラーになるのでは?という懸念がある
ecspressで最初のサービスの作成とタスク定義の登録はecspresso deploy
コマンドで行う
ecspresso v1ではecspresso create
コマンドがあったが、v2からecspresso deploy
コマンドでサービスの作成も行うことになった
ecspressoのデプロイの挙動を見てみると、ecspresso deploy
で指定したECSサービスが初回で存在しないと、ECSサービスを作成する挙動になる(2回目からはデプロイをしようとするので、CodeDeployが作成されていないとエラーになる)
https://github.com/kayac/ecspresso/blob/v2/deploy.go#L89
つまり、
- ECSサービスの作成とタスク定義の登録だけでは、CodeDeployは必要ない
- 実際にECSサービスをCodeDeployでデプロイしようとする時に必要になる
なので、上記の順序で作成すればエラーは起きない(はず)
細かく分けずに、一回でリソースを作成する方法もある
https://techblog.kayac.com/ecspresso-tf-nullresource
ただ、この方法だと、ECSのサービス定義やタスク定義を一緒にTerraformと同じ場所で管理しないいけないことになりそう ライフサイクル?が違うので、同じ場所で管理するのはしんどい ECSサービスやタスクはデプロイごとに更新がかかる(新しいイメージの指定など)
なので、ECSサービス定義とタスク定義はアプリケーションのリポジトリと同じ場所で管理した方が良さそう