はじめに

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

この記事では別のアカウントにあるCodeCommitを起点にCodePipelineを動かすアーキテクチャを決める流れを解説しています。

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

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

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

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

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

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

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

とりあえず何も考えずに既存のパイプラインをそっくりそのままコピーすると以下のようなアーキテクチャになります。

上が管理用アカウントですでに作ってあるもの、したが開発用アカウントで新しく作るものです。
とりあえず、これでも管理用アカウントと同じCICDパイプラインを開発用アカウントにも作れましたが実現したいことは違います。

GitLabからミラーリングされるCodeCommitは1つでCICDパイプラインは環境ごとにソースが異なる、というのが実現したいアーキテクチャです。

また、チャットツールであるMattermostは二か所に構築するとコストがかかるのでここも改善したいところです。

先ほどは何も考えずに管理用アカウントと開発用アカウントで同じパイプラインを構築しましたが、CodeCommitとMattermostは管理用アカウントに統合したいのでそれを消し込んでいきましょう。

また、Mattermostへの通知に使っているEventBridgeとLambdaも1つにしたいので統合する前提で消してしまいます。

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

だいぶすっきりしたので、あとは管理用アカウントにあるCodeCommit起点で開発用アカウントのCICDパイプラインを動かし、管理用アカウントのMattermostに通知を飛ばすだけです。

これを実現するためには、開発用アカウントから管理用アカウントへのスイッチロールが必要になります。

そこで、AssumeRole用IAMロールを管理用アカウントに準備しましょう。
AssumeRole用IAMロールが管理用アカウントにあれば、開発用アカウント側のIAMロールが管理用アカウント側にスイッチし、管理用アカウントの権限で管理用アカウントのAWSリソースを触れるようになります。

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

本記事では別のアカウントにあるCodeCommitを起点にCodePipelineを動かす方法をまとめました。

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

次回はコンテナのCICDを考えてみたいと思います。