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

はじめに

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

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

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

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

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

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

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

前回までの流れ

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

解決したい課題の整理

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

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

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

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

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

アーキテクチャの策定

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

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

まずはCI部分としてアーティファクトの作成を実現します。
Fargate上のGitLabからCodeCommitにミラーリングしてCodepipelineの起点として利用します。

そのうえで、アーティファクトを作成するためにCodeBuildを起動し、S3にアーティファクトを格納します。

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

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

続いて、CD部分です。
まずは、作成されたアーティファクトをもとに変更内容を誰かに承認してほしいので、承認ステージを追加します。

そして、承認後にLambdaのデプロイを実行しますがここではCodeDeployを利用します。

CodeDeployを利用するメリットはLambdaのバージョン変更をエイリアンの切り替えで実現できる点です。

なお、SAMを利用したエイリアスの切り替えも裏側ではCodeDeployが動いているという点と、GitLabがミラーリングされているCodeCommit起点でCodepipelineを動かすほかの形式にそろえたほうが運用管理が楽な点を考慮しSAMは利用しません。

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

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

これまでと変わらずCodePipelineをずっと見ていたくはないのでチャットへの通知を実装します。

これに加えてCodeCommitを保持していないアカウントのCodePipelineの起点にもしたいのでこれを実装します。

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

まとめ

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

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

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

次回はEC2 ImageBuilderの活用を考えてみたいと思います。