はじめに
この記事は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の活用を考えてみたいと思います。