Zenn
💬

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

2022/03/01に公開
AWS
GitHub
ECS
CodePipeline
tech

概要

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などの準備や連携先環境の準備などがあると思いますが）環境及びデプロイパイプラインを簡単に増やせます。

Discussion