AWSでの動的に制御可能なマルチアカウントCI/CDソリューション

(この記事はConfiguration driven dynamic multi-account CI/CD solution on AWSを翻訳したものです。)

多くの組織は、アプリケーションに堅牢で自動化されたコードのデリバリーを必要としています。マルチアカウントの継続的インテグレーション/継続的デプロイ (CI/CD) パイプラインを活用してコードをデプロイし、本番環境にデプロイする前に複数の環境で自動テストを実行します。テスト戦略がリリース固有の場合は、リリースのたびにパイプラインを更新する必要があります。従来のパイプラインのステージは事前定義されていて本質的に静的であり、それらが一度定義されると更新するのは困難です。この投稿では、リポジトリごとの動的に制御可能な CI/CD ソリューションを紹介します。パイプラインの状態は Amazon DynamoDB に保存されている設定によって維持および管理されます。これによりテスト要件に基づいてリリースごとにパイプラインを自動的にカスタマイズできるようになります。

この記事をフォローすることで、動的なマルチアカウント CI/CD ソリューションをセットアップできます。パイプラインはサンプルのペットショップ API アプリケーションをデプロイしてテストします。このアプリケーションの詳細についてはAWS CodeBuild、AWS CodePipeline、および Postman による API テストの自動化を参照してください。新しいコードのデプロイメントは、作成したパイプライン設定に基づいてカスタムパイプラインステージで提供されます。このソリューションでは、AWS Cloud Development Kit (AWS CDK) , AWS CloudFormation , Amazon DynamoDB , AWS Lambda , AWS Step Functions.などのサービスを使用しています。

ソリューションの概要

次の図はソリューションのアーキテクチャーを示しています。

図1 : アーキテクチャーダイアグラム

ユーザーはDynamoDBテーブルのエントリーを挿入、更新、削除します。
Step FunctionsのトリガーであるLambdaは全ての変更に対して呼び出されます。
Step FunctionsのトリガーであるLambdaは受信したイベントを評価し次の処理を行います。
1. 挿入、更新時に Step Functions を呼び出します。
2. 削除時には適切な CloudFormation スタックを見つけて削除します。
Step Functionsのステップは以下の通りです。
1. 情報収集 (Passステート) – リポジトリ名や参照名などのイベント情報から関連情報をフィルタリングします。
2. マッピング情報を取得 ( CodeCommit イベントをフィルターする Lambda による ) – DynamoDB に保存されているパイプライン設定からマッピング情報を取得します。
3. デプロイ設定があるかどうか？( Choice ステート) – もし StatusCode が200だった場合、DynamoDB のエントリーが見つかり、CloudFormation スタックのステップが開始され、それ以外の場合 StepFunctions は成功で終了します。
4. CloudFormation スタックの開始 (スタックで作成されたLambda) – CloudFormation パラメーターを構築し、CloudFormation 経由で DynamoDB に保存されている設定に基づいて動的パイプラインを作成、更新します。

コードの成果物

AWS CDK app – AWS CDK appは Lambda , Step Functions , CloudFormation テンプレートのコードを含みます。
sample-application-repo – このディレクトリにはデプロイに使用されるサンプルアプリケーションのリポジトリが含まれています。
automated-tests-repo – このディレクトリにはサンプルアプリケーションリポジトリをテストするための自動テストのリポジトリが含まれています。

CI/CD ソリューションのデプロイ

このリポジトリをローカルマシンにクローンします。
READMEに従って、このソリューションをメインの CI/CD アカウントにデプロイしてください。デプロイに成功した後、下記のリソースが CI /CDアカウントに作成されるはずです。
1. １つの DynamoDB テーブル
2. Step Functions
3. Lambda ファンクション
メインの CI/CD アカウントの Amazon Simple Storage Service (Amazon S3) コンソールに移動し、 cloudformation-template-bucket-<AWS_ACCOUNT_ID> という名前のバケットを検索します。二つの CloudForamtion テンプレート(templates/codepipeline.yaml と templates/childaccount.yaml)がアップロードされているはずです。
CloudFormation コンソールに移動して、すべてのターゲット CI/CD アカウント (Alpha, Beta, Gamma, Prod) で childaccount.yaml を実行します。メインの CI/CD アカウント番号を「CentralAWSAccountId」パラメータとして指定し、実行します。
Stack が正常に作成されると、子アカウントに次の 2 つのロールが作成されます。
1. ChildAccountFormationRole
2. ChildAccountDeployerRole

パイプラインの設定

リポジトリ名とブランチの組み合わせについては、devops-pipeline-table-info にエントリを作成します。サンプルエントリは sample-entry.json にあります。
パイプラインは高度に設定可能で、全ての設定を DynamoDB のエントリで設定できます。
最上位のキーは以下になります :
RepoName : AWS CodePipeline が設定されているリポジトリの名前
RepoTag : コードパイプラインで使用されるブランチの名前
BuildImage : アプリケーションの AWS CodeBuild プロジェクトで利用されるビルドイメージ
BuildSpecFile : アプリケーションの CodeBuild プロジェクトで使用されるビルドスペックファイル
DeploymentConfigurations : このキーにはパイプラインの設定が格納されます。このキーの配下には環境固有の設定があります。私たちのケースでは環境に Alpha , Beta , Gamma , Prod という名前をつけました。好きな名前に設定できますが、json のエントリが CloudFormation テンプレートの codepipeline.yaml のエントリと同じであることを確認してください。これは、両者が 1 : 1 でマッピングされているためです。DeploymentConfigurationsのサブレベルのキーは次のとおりです。

環境名 : これは環境固有の設定の最上位位のキーです。私たちの場合は、Alpha , Beta , Gamma , Prodです。この配下のサブレベルのキーは
- <Env>AwsAccountId : ターゲット環境の AWS アカウント ID
- Deploy<Env> : アーティファクトをこの環境にデプロイするかどうかを指定するキーです。その値に基づいて、CodePipeline はこの環境に対してデプロイメントステージを持ちます。
- ManualApproval<Env> : デプロイ前に手動での承認が必要かどうかを指定するキーです。メールアドレスを入力するか、false に設定します。
- Tests : 最後に、このキーはネストされたデータで構成されています。このキーには特定の環境で実行されるテスト関連情報が格納されます。各テストはテストを実行するかに応じて、CodePipeline に追加のステップを追加します。テストの関連情報も設定可能でCodeBuild プロジェクトをテストするためのテストリポジトリ、ブランチ名、buildspec ファイル、ビルドイメージを指定できます。

実行

メインの CI/CD アカウントの devops-pipeline-table-info DynamoDB テーブルにエントリを作成します。サンプルエントリは sample-entry.json にあります。設定値は必ずご使用の環境に適した値に置き換えてください。値の説明は、上記の「パイプラインの設定」セクションにあります。
DynamoDB テーブルにエントリを作成すると、CloudFormation スタックが作成されていることがわかります。この CloudFormation スタックは DynamoDB テーブルのエントリを読み取って使用することにより、メインの CI/CD アカウントに CodePipeline をデプロイします。

devops-pipeline-table-info DynamoDB テーブルに保存されているパイプライン設定を更新して、ある環境にデプロイして他の環境にはデプロイしないなど、さまざまな組み合わせに合わせてソリューションをカスタマイズします。
以下は、サンプルアプリケーションリポジトリのメインブランチに設定されたパイプラインです。

図 2 : 動的マルチアカウント CI/CD パイプライン

動的なマルチアカウント CI/CD ソリューションと関連リソースのクリーンアップ

この記事に従って作ったリソースに課金されることを避けるために、以下のリソースを削除してください。

DynamoDB に保存されているパイプライン設定
ターゲット CI/CD アカウントにデプロイされた CloudFormation スタック
メインの CI/CD アカウントにデプロイされた AWS CDK アプリケーション
保持されている S3 バケットを空にして削除します

まとめ

この設定駆動の CI/CD ソリューションはDynamoDBを使って動的にパイプラインの作成 / 設定ができます。アイデンティティテクノロジーの世界的リーダーであるIDEMIAは、マイクロサービスベースのアプリケーションをさまざまな環境に展開するためにこのアプローチを採用しました。AWS Professional Services が作成したこのソリューションによりリリース、リポジトリごとにパイプラインを動的に作成して設定できるようになりました。IDEMIA のテクニカルリードである Kunal Bajaj 氏は次のように語っています。「私たちは、AWS のプロフェッショナルサービスチームと協力して、Lambda 、Step Functions 、SQS 、その他の AWS のネイティブサービスを使用して動的な CI/CD ソリューションを作成しました。これにより、さまざまな環境へのクロスアカウントデプロイが可能になり、ビジネスの必要に応じてテストや承認を柔軟に追加できるようになりました。」

翻訳は、ソリューションアーキテクト紙谷が担当しました。原文はこちらです。

この記事の著者について

Amazon Web Services ブログ