ECS の構成と Terraform コード化する際の構造化について
こんにちは。@jedipunkz です。 今回は AWS ECS についてです。直近の仕事で ECS の Terraform コード開発をしていたのですがコードの構造化について考えていました。一枚岩のコードを書いても運用に耐えられるとは考えられません。また ECS を構成するにあたって ECS のネットワークモードとコンテナのロギングについて考えているうちに、どの構成が一番適しているのか?について時間を掛けて考えました。ここではそれらについてまとめたいと思います。 Terraform コードの構造化 運用の精神的な負担を軽減するという観点で Terraform のコード開発をする上で一番重要なのはコードの構造化だと思います。前回のブログ記事に書いたのですがコードの構造化をする上で下記に留意して考えると良いと思います。 影響範囲 ステートレスかステートフルか 安定度 ライフサイクル 結果、具体的に Terraform のコードはどのような構造になるでしょうか。自分は下記のようにコンポーネント化して Terraform の実行単位を別けました。ここは人それぞれだと思いますが、ECS 本体と ECS の周辺 AWS サービスの一般的な物を考慮しつつ、いかにシンプルに構造化するかを考えると自然と下記の区分けになる気がします。 コンポーネント 具体的なリソース ネットワーク vpc, route table, igw, endpoint, subnet ECS 本体 ecs, alb, autoscaling, cloudwatch, iam CI/CD codebuild, codepipeline, ecr, iam パラメータ ssm, kms データストア s3, rds, elasticache … vpc や subnet に関して頻繁に更新を掛ける人は少ないのではないでしょうか。よってネットワークは “影響範囲” を考慮しつつコンポーネントを別けました。また、同じ理由でパラメータ・CI/CD も ECS 本体とは実行単位を別けた方が好ましいと思います。また “ステートフルかステートレスか” という観点でデータベースやストレージは頻繁に更新する ECS 本体とは別けるべきでしょう。 ...