GitHub＋AWS ECS環境での基本的なデプロイパイプラインの構築

概要

GitHub と AWS の ECS を用いた、基本的なデプロイパイプライン環境について説明します。

やりたいこととしては、GitHub でソースコードを管理して開発を行いながら、随時 AWS 環境の ECS に対して自動デプロイを行い検証を行って、最終的に Pull Request をマージすることで、本番環境にデプロイできるようにすることです。

構成のイメージ

構成のポイントとしては、CodePipeline 側の設定および環境変数で、使用するリポジトリを切り替えて、検証環境（面）を増やす場合などに、簡単に増やせるようにしています。

環境を増やす場合、以下のような手順（設定のみ）で、環境（検証面）が増やせるようになります。

1. GitHub で環境に対応したブランチを作る。
2. コンテナリポジトリ（ECR）を追加する。
3. ECS クラスターにサービスを追加する。
4. CodePipeline の追加を行う。

構築の流れ

1.ECS 環境を構築する

まず、ECS 環境を構築します。
ECS には EC2 タイプと Fargate がありますので、以下を参照していただければと思います。

EC2

https://zenn.dev/ttani/articles/aws-ecs-setup

Fargate

https://zenn.dev/ttani/articles/aws-fargate-setup

2.ホストベースでのルーティングを構築する

ECS 上のサービスに対してホストベースルーティングをできるようにしておくと、環境展開が容易になります。ECS に対するホストベースルーティングは以下を参考にしてください。

https://zenn.dev/ttani/articles/aws-ecs-hostbase-routing

例えば、下記のような形でドメインを構成します。

• 本番環境：www.example.com
• 検証環境：test.example.com
• 開発環境：dev.example.com

3.CodePipeline を用いた自動デプロイを構成する

続いて、CodePipeline を用いて、GitHub からソースコードを取得してビルドを行い、対象のサービスに対してデプロイを行う設定を行っていきます。自動デプロイの設定は以下を参考にしてください。

https://zenn.dev/ttani/articles/aws-ecs-autodeploy
https://zenn.dev/ttani/articles/aws-ecs-next-autodeploy

4.リポジトリ URI の参照を環境変数で渡すようにして、CodePileline を追加する

CodeBuild 用の設定buildspec.ymlを構成する際に、REPOSITORY_URIの値と、imagedefinitions.jsonに引き渡すコンテナ名についてを直接記載せずに、CodePipeline 側の環境変数を使用するよう構成していきます。

環境変数設定例

• REPOSITORY_URI：ECR のリポジトリ URI を設定する。
• CONTAINER_NAME：タスク定義で設定したコンテナ名を設定する。

buildspec.yaml 上の記載

- printf '[{"name":"%s","imageUri":"%s"}]' $CONTAINER_NAME $REPOSITORY_URI:$IMAGE_TAG > imagedefinitions.json

※buildspec.yaml 上部のデフォルトの REPOSITORY_URI 定義は削除します。

CodePipeline のビルド時の環境変数の設定は、CodePipeline 初期設定時にビルドステージを追加するで設定を行うか、作成後に追加する場合は、AWS コンソールからCodePipeline-パイプラインに進み、対象のパイプラインを選択して、編集を押下して、Buildのステージを編集する-編集アイコン押下で環境変数などの変更が行えます。
※設定後、子画面の完了ボタン →Build ステージの完了ボタン → パイプラインの保存ボタンまで押下しないと反映されませんので注意してください。

例えば、3 環境ある場合、3 つの ECR と、3 つのパイプラインを作成します。
その際に、GitHub リポジトリと以下のように紐づけておきます。

• 本番環境：www.example.com　 → 　 main ブランチ　 → 　本番用 ECR
• 検証環境：test.example.com 　 → 　 test ブランチ　 → 　検証用 ECR
• 開発環境：dev.example.com 　 → 　 develop ブランチ　 → 　開発用 ECR

以上で構成は完了です。GitHub で対象のブランチに PUSH やマージをすると自動デプロイが行われます。
環境を増やしたい場合は、同じような手順で、ブランチ、ECR リポジトリ、サービス、Pipeline を追加設定します。

構成上の考慮事項

本番環境向けのトラフィックと、検証環境向けのトラフィックをクラスターや ALB などで混ぜたくない場合、本番用の ECS クラスター/ALB と、検証や開発系の ECS クラスター/ALB を分ける、あるいは、AWS アカウントごと分けるなどを行うとよいかと思います。

まとめ

実際に開発プロジェクトを進めていくと、検証用の環境（面）が追加で必要になったりしますが、そういった際に（実際には DB などの準備や連携先環境の準備などがあると思いますが）環境及びデプロイパイプラインを簡単に増やせます。