想定環境
- 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サービス定義とタスク定義はアプリケーションのリポジトリと同じ場所で管理した方が良さそう
