Fargate上のGitLab起点でECSを更新するGitOpsを実現したい

はじめに

この記事はDevOps on AWS大全 実践編の一部です。
DevOps on AWS大全 実践編の一覧はこちら。

この記事ではGitLab起点でECSを更新するCICDパイプラインのアーキテクチャを決める流れを解説しています。

具体的には以下流れで説明します。

• 解決したい課題の整理
• 今回使うAWSサービスの整理
• アーキテクチャの策定
• 策定したアーキテクチャで達成できたこと

AWSの区分でいう「Level 400 : 複数のサービス、アーキテクチャによる実装でテクノロジーがどのように機能するかを解説するレベル」の内容です。

この記事を読んでほしい人

• DevOpsエンジニアがアーキテクチャを決めるときにどのような思考フローを踏んでいるか知りたい人
• ECSを更新するCICDパイプラインのアーキテクチャを知りたい人
• AWS Certified DevOps Engineer Professionalを目指している人

前回までの流れ

こちらの記事で以下のアーキテクチャを策定しました。

解決したい課題の整理

現在、解決したいと思っている課題は以下になります。

• GitLabにコミットしたECSの定義を使ってGitOpsを実現したい
• CICDパイプラインを実行した後、実行完了までの間はマネジメントコンソールを見たくない

ということで、これをどうやって解決するか考えていきましょう。

今回使うAWSサービスの整理

今回使う代表的なAWSサービスの概要とベストプラクティスは前回同様です。

アーキテクチャの策定

ここからはやりたいことを順番に考えながらアーキテクチャを策定していきます。

GitLabにコミットしたECSの定義を起点にCIを実現したい

ECSはコンテナサービスになるのでイメージのビルドが必要になります。
そこでコンテナのCICDのCIはコンテナイメージのビルド、と定義してここからはアーキテクチャ検討をしていきます。

まず、Fargate上のGitLabに必要な定義はすべてコミットしてある前提です。
今回のアーキテクチャではGitLabからCodeCommitにミラーリングされるので、ここを起点にCIが動作します。

CIではイメージのビルドと後段のパイプラインで必要なるアーティファクトの作成を実行します。
アーティファクトにはタスクの定義であるtaskdef.json、作成したイメージの詳細を記載するimageDetail.json、動作を定義するappspec.ymlが含まれます。

これらをまとめると以下のようなアーキテクチャになります。

GitLabにコミットしたECSの定義を起点にCDを実現したい

続いてCD部分です。
CIで作成したイメージとアーティファクトをもとにECSを更新していきます。

まずは、作成されたイメージとアーティファクトを見てデプロイしてよいかの承認フェーズが欲しくなるのでそれを追加してみます。

承認した後は実際にデプロイをしていきますがこれにはCodeDeployを利用します。
CodeDeployを利用するメリットは一時的に新旧二つのコンテナが併存しトラフィックシフトによるデプロイが実現できることです。
これにより、サービスのダウンタイムを大幅に減らすことができます。

これらをまとめると以下のようなアーキテクチャになります。

GitLabにコミットしたECSの定義を起点にChatOpsを実現したい

そして、例によってパイプラインが動作している間ずっとマネジメントコンソールをみているのは嫌なのでチャットに通知を行います。今回だと、イメージのビルドが終わった時とデプロイのトラフィックシフトが完了したときに通知を飛ばすとよさそうです。

さらに、管理用のアカウントと開発用のアカウントでクロスアカウントの動作をさせる必要があります。
具体的にはCodeCommitと別のアカウントでパイプラインを動作させたいということです。

これらをまとめると以下のようなアーキテクチャになります。

まとめ

本記事ではGitLab起点でECSを更新するGitOpsを実現する方法をまとめました。

今回策定したアーキテクチャで実現できたのは以下の項目です。

• GitLabにコミットしたECSの定義を起点にイメージのビルドを実行するCI
• GitLabにコミットしたECSの定義を起点にECS関連の資材を作成するCD
• マネジメントコンソールを確認する必要があるタイミングでチャットに通知を飛ばすChatOps

次回はLambdaのCICDを考えてみたいと思います。