CodePipeline の更新 – CloudFormation スタックの継続的配信ワークフローの構築

2 つの AWS サービスを一緒に使用して生産性を高めるための新しい方法について記事を書き始めたときに、1980 年代の Reese ピーナッツバターカップの TV コマーシャルを思い出しました。2 つの有益なサービス (2 つのおいしい味) を組み合わせることで、さらにうまみのある新しいものが生まれます。

今日のチョコレート / ピーナッツバターの組み合わせは、AWS CodePipeline と AWS CloudFormation が出会って生まれます。CodePipeline を使って、CloudFormation スタックの継続的配信パイプラインを構築できるようになりました。継続的配信を実行すると、コードの変更が毎回自動的にビルド、テストされ、本稼働環境へのリリースのために準備されます。ほとんどの場合、継続的配信のリリースプロセスには、手動と自動の承認ステップの組み合わせが含まれます。たとえば、自動化された一連のテストに合格したコードは、最終的な確認と承認のために開発マネージャーまたはプロダクトマネージャーにルーティングしてから、本稼働環境にプッシュできます。

この機能の重要な組み合わせにより、継続的配信の利点をすべて活用しながら、コードとしてのインフラストラクチャモデルを使用できるようになります。CloudFormation テンプレートを変更するたびに、CodePipeline はテストスタックを構築し、変更をテストして手動の承認を待ってから本稼働環境にプッシュするワークフローを開始できます。このワークフローでは多くの異なる方法でスタックを作成し、操作できます。

すぐ後で説明するように、ワークフローでは変更セットを生成して運用可能なスタックに適用する機能 (詳細については、「新機能 – AWS CloudFormation 用の変更セット」を参照) など、CloudFormation の高度な機能を活用できます。

セットアップ
私はこの機能の詳細について参照するため、CloudFormation テンプレートを使って継続的配信パイプラインをセットアップしました (これはコードとしてのインフラストラクチャの別の例です)。このテンプレート (こちらから入手可能で、詳細は こちらで参照可能) により、フル機能のパイプラインをセットアップできます。このテンプレートを使ってパイプラインを作成するときは、S3 バケットの名前とソースファイルの名前を指定します。

SourceS3Key は、S3 のバージョニングが有効な ZIP ファイルを指します。このファイルには、これから作成するパイプラインを介してデプロイされる CloudFormation テンプレート (WordPress のシングルインスタンスの例を使用) が含まれています。また、設定ファイルやパラメーターファイルなど、他のデプロイアーティファクトも含まれています。その例を次に示します。

[Create Stack] をクリックすると、わずか数秒で継続的配信ライン全体を準備できます。これを次に示します。

アクション
この時点で、CloudFormation を使ってパイプラインをセットアップしました。これで準備が整ったので、このパイプラインで新しい CloudFormation アクションを使用する方法をご覧いただくことができます。

2 番目のステージである、TestStage に注目しましょう。このステージは最初のステージによってトリガーされ、CloudFormation を使ってテストスタックを作成します。

このスタックは ZIP の test-stack-configuration.json ファイルのパラメーター値を使って作成されます。CloudFormation アクションごとに異なる設定ファイルを使用できるので、同じテンプレートをテストと本稼働に使用できます。

スタックが起動して実行されると、ApproveTestStack ステップを使って手動の承認を待ちます (“Waiting for approval above.” と表示されます)。私は開発マネージャーの役割を果たし、テストスタックが予期どおり動作、実行されることを確認したら、それを承認します。

承認後は、DeleteTestStack ステップによりテストスタックが削除されます。

これで、本稼働環境へのデプロイの準備がほぼ整いました。ProdStage は CloudFormation 変更セットを作成し、それを手動の承認用に送信します。このステージでは ZIP の prod-stack-configuration.json ファイルからのパラメーター値を使用します。これらのパラメーターを使って、小さい EC2 インスタンスで適切なサイズのテスト環境を起動し、同じテンプレートから大規模な実稼働環境を起動できます。

ここで私は上役の役割を果たし、実稼働サイトの起動と運用を維持する責任を負います。実稼働環境へのデプロイで何が起こるかを確実に理解するため、変更セットを確認します。パイプラインを実行するのはこれが初めてであるため、変更セットは EC2 インスタンスとセキュリティグループが作成されることを示します。

次に、私はこれを承認します。

変更セットが承認されると、ExecuteChangeSet ステップの既存の実稼働スタックに適用されます。既存のスタックに変更を適用すると、既存のリソースは可能な場合は継続して機能し、アプリケーションの完全な再起動を回避します。通常、これはスタック全体を置き換えるよりも効率的で、破壊的ではありません。インメモリキャッシュのウォームアップ状態が維持され、コールドスタートアクティビティで発生する可能性のあるバーストが回避されます。

変更の実装
HTTPS のサポートを決定するとします。これを行うには、アプリケーションのセキュリティグループにポート 443 を追加する必要があります。CloudFormation テンプレートを編集し、新しい ZIP にこれを配置して、S3 にアップロードします。テンプレートに追加したコードは次のとおりです。

      - CidrIp: 0.0.0.0/0
        FromPort: '443'
        IpProtocol: tcp
        ToPort: '443'

次にコンソールに戻り、CodePipeline がすでに変更を検出してパイプラインが動作するよう設定したことを確認します。

パイプラインはもう一度実行されます。テストスタックを承認し、変更セットを点検して、既存のセキュリティグループを変更することを確認します。

次に進む前に、1 つ注意事項があります。パイプラインの CloudFormation テンプレートによって IAM ロールが作成され、これを使ってテストおよびデプロイスタックを作成します (これは新機能です。詳細については、「AWS CloudFormation サービスロール」を参照してください)。最適な結果を得るには、パイプラインを削除する前にスタックを削除します。これを行わない場合は、スタックを削除するためにロールを再作成する必要があります。

その他の情報
スペースと時間が足りなくなってきましたが、この新機能のその他の側面のついて、いくつか簡単に説明します。

パラメーターの上書き – CloudFormation アクションを定義する際に、テンプレートに対して定義されるパラメーター値の追加の制御が必要になる場合があります。これを行うには、[Advanced] ペインを開き、必要なパラメーター値の上書きを入力します。

アーティファクトのリファレンス – 状況によっては、以前のステージのパイプラインで作成されたアーティファクトの属性を参照する必要が生じます。たとえば、パイプラインの早い段階で Lambda 関数を S3 バケットにコピーし、結果として生じるアーティファクト LambdaFunctionSource を呼び出すとします。パラメーターの上書きを使って属性からバケット名とオブジェクトキーを取得する方法を次に示します。

{
  "BucketName" : { "Fn::GetArtifactAtt" : ["LambdaFunctionSource", "BucketName"]},
  "ObjectKey" : { "Fn::GetArtifactAtt" : ["LambdaFunctionSource", "ObjectKey"]}
}

JSON パラメーターへのアクセス – 新しい Fn::GetParam 関数を使って、アーティファクトに含まれる JSON 形式ファイルから値を取得できます。

Fn:GetArtifactAtt と Fn::GetParam は、パラメーターの上書き内で使用されるよう設計されています。

S3 バケットのバージョニング – 私のパイプライン (Source アクション) の最初のステップでは、S3 バケットのオブジェクトを参照します。オブジェクトの S3 バージョニングを有効にして、変更ごとにテンプレートの新しいバージョンをアップロードします。

ソースとして S3 を使用する場合は、バージョニングを使用する必要があります (既存のオブジェクトに対する新しいオブジェクトのアップロードはサポートされません)。AWS CodeCommit または GitHub レポジトリをソースとして使用することもできます。

パイプラインウィザードの作成
私は、CloudFormation テンプレートを使ってパイプラインを作成することで、このブログ投稿を開始しました。コンソールで [Create pipeline] をクリックし、ウィザードを使って最初のパイプラインを構築することもできます (ソース、ビルド、およびベータデプロイステージを使用)。このウィザードでは、デプロイプロバイダーとして CloudFormation を選択することもできます。ベータデプロイステージでスタックや変更セットを作成または更新できます。

今すぐご利用可能
この新機能は今すぐご利用可能で、すぐに使用を開始することができます。詳細については、CodePipeline ドキュメントの「AWS CodePipeline を使用した継続的配信」を参照してください。

— Jeff;