はじめに
この記事はDevOps on AWS大全 実践編の一部です。
DevOps on AWS大全 実践編の一覧はこちら。
この記事では別のアカウントにあるCodeCommitを起点にCodePipelineを動かすアーキテクチャを決める流れを解説しています。
具体的には以下流れで説明します。
- 解決したい課題の整理
- 今回使うAWSサービスの整理
- アーキテクチャの策定
- 策定したアーキテクチャで達成できたこと
AWSの区分でいう「Level 400 : 複数のサービス、アーキテクチャによる実装でテクノロジーがどのように機能するかを解説するレベル」の内容です。
この記事を読んでほしい人
- DevOpsエンジニアがアーキテクチャを決めるときにどのような思考フローを踏んでいるか知りたい人
- CodeCommitをクロスアカウントで利用するアーキテクチャを知りたい人
- AWS Certified DevOps Engineer Professionalを目指している人
前回までの流れ
こちらの記事で以下のアーキテクチャを策定しました。
解決したい課題の整理
現在、解決したいと思っている課題は以下になります。
- 管理用アカウントにあるCodeCommitを起点にして、開発用アカウントのGitOpsを実現したい
- チャットの通知先は前回同様、開発アカウントにしたい
ということで、これをどうやって解決するか考えていきましょう。
今回使うAWSサービスの整理
今回使う代表的なAWSサービスの概要とベストプラクティスは前回同様です。
アーキテクチャの策定
ここからはやりたいことを順番に考えながらアーキテクチャを策定していきます。
管理用アカウントと別にある開発用アカウントに管理用アカウントと同じCICDパイプラインが欲しい
とりあえず何も考えずに既存のパイプラインをそっくりそのままコピーすると以下のようなアーキテクチャになります。
上が管理用アカウントですでに作ってあるもの、したが開発用アカウントで新しく作るものです。
とりあえず、これでも管理用アカウントと同じCICDパイプラインを開発用アカウントにも作れましたが実現したいことは違います。
GitLabからミラーリングされるCodeCommitは1つでCICDパイプラインは環境ごとにソースが異なる、というのが実現したいアーキテクチャです。
また、チャットツールであるMattermostは二か所に構築するとコストがかかるのでここも改善したいところです。
管理用アカウントと開発用アカウントで重複するリソースは削除したい
先ほどは何も考えずに管理用アカウントと開発用アカウントで同じパイプラインを構築しましたが、CodeCommitとMattermostは管理用アカウントに統合したいのでそれを消し込んでいきましょう。
また、Mattermostへの通知に使っているEventBridgeとLambdaも1つにしたいので統合する前提で消してしまいます。
これらをまとめると以下のようなアーキテクチャになります。
管理用アカウントのCodeCommitを起点に開発用アカウントのCICDパイプラインを動かしたい
だいぶすっきりしたので、あとは管理用アカウントにあるCodeCommit起点で開発用アカウントのCICDパイプラインを動かし、管理用アカウントのMattermostに通知を飛ばすだけです。
これを実現するためには、開発用アカウントから管理用アカウントへのスイッチロールが必要になります。
そこで、AssumeRole用IAMロールを管理用アカウントに準備しましょう。
AssumeRole用IAMロールが管理用アカウントにあれば、開発用アカウント側のIAMロールが管理用アカウント側にスイッチし、管理用アカウントの権限で管理用アカウントのAWSリソースを触れるようになります。
これらをまとめると以下のようなアーキテクチャになります。
これを全体像とまとめると以下のようなアーキテクチャになります。
まとめ
本記事では別のアカウントにあるCodeCommitを起点にCodePipelineを動かす方法をまとめました。
今回策定したアーキテクチャで実現できたのは以下の項目です。
- 管理用アカウントのCodeCommitから開発用アカウントのS3にアーティファクトを格納
- 開発用アカウントのS3に格納されたアーティファクトをもとに開発用アカウントでCloudFromation Stackを作成
- マネジメントコンソールを確認する必要があるタイミングで開発用アカウントから管理用アカウントに構築したチャットに通知を飛ばすChatOps
次回はコンテナのCICDを考えてみたいと思います。