メニュー
AWS CloudFormation
ユーザーガイド (API Version 2010-05-15)

ウォークスルー: テストおよび本稼働スタック用のパイプラインを構築する

AWS CloudFormation テンプレートを送信すると、AWS CloudFormation でそれを使用して自動的にテストスタックが構築されるリリースプロセスを考えてみてください。テストスタックを確認してから、変更によって本稼働スタックがどのように変更されるかをプレビューして、実装するかどうかを選択できます。このワークフローは、AWS CloudFormation を使用してテストスタックの構築、テストスタックの削除、変更設定の作成、そして変更設定の実行を行うことで実現できます。ただし、各アクションで、手動で AWS CloudFormation を操作する必要があります。このウォークスルーでは、このようなアクションの多くを自動化する AWS CodePipeline アクションを構築し、AWS CloudFormation スタックを使用した継続的な配信ワークフローを実現します。

前提条件

このワークフローでは、お客様に AWS CodePipeline および AWS CloudFormation を使用した経験があり、パイプラインおよび AWS CloudFormation テンプレート、およびスタックがどのように動作するか理解していることを前提としています。AWS CodePipeline の詳細については、AWS CodePipeline ユーザーガイドを参照してください。また、パイプラインを作成するのと同じ AWS リージョンに Amazon S3 バケット がある必要があります。

重要

サンプルの Word Press テンプレートは、インターネットへの接続を必要とする EC2 インスタンスを作成します。インターネットへのトラフィックを許可しているデフォルト VPC とサブネットがあることを確認してください。

チュートリアルの概要

このウォークスルーでは、スタックにある WordPress サンプルサイト用のパイプラインを構築します。パイプラインは、3 つのステージに分かれています。各ステージに少なくとも 1 つのアクションが含まれている必要があります。このアクションは、お客様のアーティファクト (入力) に対してパイプラインが実行するタスクです。ステージはパイプライン内のアクションを整理します。ステージが次のアーティファクトに進む前に (たとえば、パイプラインを再実行する新しい入力を送信した場合)、AWS CodePipeline で 1 つのステージのすべてのアクションが完了される必要があります。

このウォークスルーを完了すると、次のワークフローを実行するパイプラインができあがります。

  1. パイプラインの最初のステージで、リポジトリからソースアーティファクト (AWS CloudFormation テンプレートおよび設定ファイル) を取得します。

    WordPress のサンプルテンプレートを含むアーティファクトを準備して、S3 バケットにアップロードします。

  2. 2 番目のステージで、パイプラインはテストスタックを作成し、承認を待ちます。

    テストスタックを確認した後、元のパイプラインを使用して続行するか、別のアーティファクトを作成して送信することで変更を加えるかを選択できます。承認すると、このステージはテストスタックを削除し、パイプラインは次のステージに進みます。

  3. 3 番目のステージで、パイプラインは本稼働スタックに対する変更セットを作成し、承認を待ちます。

    初めて実行する場合は、本稼働スタックはありません。変更設定には、AWS CloudFormation によって作成されるリソースがすべて表示されます。承認すると、このステージは変更セットを実行し、本番用スタックを構築します。

注記

AWS CloudFormation は無料サービスです。ただし、スタックに含める EC2 インスタンスなどの AWS リソースには、それぞれの現在の料金が課金されます。AWS の料金に関する詳細は、http://aws.amazon.com/ で各製品の詳細ページを参照してください。

ステップ 1: アーティファクトを編集し、S3 バケットにアップロードする

パイプラインを構築する前に、ソースリポジトリとファイルを設定する必要があります。AWS CodePipeline によってこれらのソースファイルがパイプラインのアーティファクトストアにコピーされ、AWS CloudFormation の作成などパイプラインでのアクションの実行に使用されます。

ソースリポジトリとして Amazon Simple Storage Service (Amazon S3) を使用する場合、AWS CodePipeline ではソースファイルを zip にしてから S3 バケットにアップロードする必要があります。zip ファイルは、AWS CloudFormation テンプレート、テンプレート設定ファイル、またはその両方を含む AWS CodePipeline アーティファクトです。WordPress サンプルテンプレートと 2 つのテンプレート設定ファイルを含むアーティファクトが用意されています。2 つの設定ファイルは、WordPress テンプレートのパラメーター値を指定します。AWS CodePipeline は WordPress スタックを作成する際にこれらを使用します。ファイルの 1 つにはテストスタック用のパラメーター値、もう 1 つには本稼働スタック用のパラメーター値が含まれます。たとえばお客様が所有する既存の EC2 キーペア名を指定するために、設定ファイルを編集する必要があります。アーティファクトの詳細については、「AWS CloudFormation アーティファクト」を参照してください。

アーティファクトを構築したら、S3 バケットにアップロードします。

アーティファクトを編集してアップロードするには

  1. サンプルアーティファクトをダウンロードして開きます (https://s3.amazonaws.com/cloudformation-examples/user-guide/continuous-deployment/wordpress-single-instance.zip)。

    アーティファクトには 3 つのファイルが含まれています。

    • WordPress サンプルテンプレート: wordpress-single-instance.yaml

    • テストスタック用テンプレート設定ファイル: test-stack-configuration.json

    • 本稼働スタック用テンプレート設定ファイル: prod-stack-configuration.json

  2. ファイルをすべて展開し、任意のテキストエディタを使用してテンプレート設定ファイルを変更します。

    設定ファイルを開いて、WordPress テンプレートのパラメーターにマッピングするキーと値のペアが含まれていることを確認します。設定ファイルは、パイプラインがテストスタックおよび本稼働スタックを作成するときに使用するパラメーター値を指定します。

    テストスタック用のパラメーター値を指定するには test-stack-configuration.json ファイルを編集します。本稼働スタック用には prod-stack-configuration.json ファイルです。

    • DBPassword キーおよび DBRootPassword キーの値の値を、WordPress データベースへのログインに使用するパスワードに変更します。WordPress テンプレートで定義されたとおり、このパラメーターの値は英文字のみを使用する必要があります。

    • KeyName キーの値を、パイプラインを作成するリージョンにある既存の EC2 キーペア名に変更します。

  3. 変更した設定ファイルを元のアーティファクト (.zip) ファイルに追加して、重複したファイルを置き換えます。

    これで、S3 バケットにアップロードできるカスタマイズされたアーティファクトができました。

  4. お客様が所有する S3 バケットにアーティファクトをアップロードします。

    ファイルの場所をメモしておきます。パイプラインを構築するときに、このファイルの場所を指定します。

    アーティファクトおよび S3 バケットに関する注意事項:

    • パイプラインを作成する AWS リージョンと同じリージョンに存在するバケットを使用してください。

    • AWS CodePipeline では、バケットはバージョニングが有効になっている必要があります。

    • ソースリポジトリには、GitHub や AWS CodeCommit など、ファイルをアップロードする前に zip 化する必要がないサービスも使用できます。

    • アーティファクトには、パスワードなどの機密情報が含まれることがあります。アクセスを制限して、許可されたユーザーのみがファイルを表示できるようにしてください。これを行う際、AWS CodePipeline がファイルにアクセスできるようにしてください。

これで、AWS CodePipeline がパイプラインに引き込むことができるアーティファクトができました。次のステップでは、アーティファクトの位置を指定して、WordPress のパイプラインを構築します。

ステップ 2: パイプラインスタックを作成する

WordPress パイプラインを作成するには、サンプルの AWS CloudFormation テンプレートを使用します。テンプレートは、パイプラインの構築に加えて、AWS CodePipeline および AWS CloudFormation 用の AWS Identity and Access Management (IAM) サービスロール、AWS CodePipeline アーティファクトストア用の S3 バケット、パイプラインが通知 (確認に関する通知など) を送信する Amazon Simple Notification Service (Amazon SNS) トピックもセットアップします。サンプルテンプレートを使用すると、単一の AWS CloudFormation スタック内のこのようなリソースを簡単にプロビジョンし設定できます。

パイプラインの設定の詳細については、「パイプラインの仕組み」を参照してください。

重要

サンプルの WordPress テンプレートは、インターネットへの接続を必要とする EC2 インスタンスを作成します。ご使用のデフォルト VPC とサブネットがインターネットへのトラフィックを許可していることを確認してください。

パイプラインスタックを作成するには

  1. https://s3.amazonaws.com/cloudformation-examples/user-guide/continuous-deployment/basic-pipeline.yml で、サンプルテンプレートをダウンロードします。ご使用のコンピューターに保存します。

  2. AWS CloudFormation コンソール (https://console.aws.amazon.com/cloudformation/) を開きます。

  3. AWS CodePipeline および AWS CloudFormation をサポートする AWS リージョンを選択します。

    詳細については、AWS General ReferenceAWS のリージョンとエンドポイントを参照してください。

  4. [Create Stack] を選択します。

  5. [Template] セクションで、[Upload a template to Amazon S3] を選択し、先ほどダウンロードしたテンプレート basic-pipeline.yml を選択します。

  6. [Next] を選択します。

  7. [Stack name] に sample-WordPress-pipeline を入力します。

  8. [Parameters] セクションで、次のパラメーター値を指定し、[Next] を選択します。WordPress テンプレートとその設定ファイルの名前を同じにしている場合は、スタックのパラメーターを設定する際にデフォルト値を使用できます。そうでない場合は、使用するファイル名を指定します。

    PipelineName

    パイプラインの名前 (たとえば WordPress-test-pipeline)。

    S3 バケット

    アーティファクト (.zip ファイル) を保存した S3 バケットの名前。

    SourceS3Key

    アーティファクトのファイル名。アーティファクトをフォルダに保存した場合は、folder/subfolder/wordpress-single-instance.zip のようにファイル名の一部に含めます。

    E メール

    AWS CodePipeline からのパイプラインの通知を受信するメールアドレス (myemail@example.com など)。

  9. このチュートリアルでは、タグの追加も詳細設定の指定も不要です。[Next] を選択します。

  10. スタック名とテンプレート URL が正しいことを確認し、[Create] を選択します。

  11. AWS CloudFormation が IAM リソースを作成する可能性があることを認識していることを確認するには、チェックボックスをオンにします。

AWS CloudFormation によってスタックが作成されるまでに数分かかることもあります。進捗状況を監視するには、スタックイベントを確認します。詳細については、「スタックのデータとリソースの表示」を参照してください。

スタックが作成されると、AWS CodePipeline は新しいパイプラインを開始します。ステータスを表示するには、AWS CodePipeline コンソールを参照してください。パイプラインのリストから、[WordPress-test-pipeline] を選択します。

パイプラインの仕組み

このセクションでは、WordPress パイプラインテンプレートの例のスニペットを使用して、パイプラインの 3 つのステージについて説明します。

ステージ 1: Source

パイプラインの最初のステージはソースステージです。ここでソースコードの位置を指定します。この場所にリビジョンをプッシュするたびに、AWS CodePipeline はパイプラインを再実行します。

ソースコードは S3 バケットにあり、ファイル名で識別されます。パイプラインのスタックを作成するときに、これらの値を入力パラメーター値として指定しました。その後のステージでソースアーティファクトを使用できるように、スニペットでは OutputArtifacts プロパティを TemplateSource という名前で指定しています。この後のステージでこのアーティファクトを使用するには、入力アーティファクトに TemplateSource を指定します。

Copy
- Name: S3Source Actions: - Name: TemplateSource ActionTypeId: Category: Source Owner: AWS Provider: S3 Version: '1' Configuration: S3Bucket: !Ref 'S3Bucket' S3ObjectKey: !Ref 'SourceS3Key' OutputArtifacts: - Name: TemplateSource

ステージ 2: TestStage

TestStage ステージでは、パイプラインはテストスタックを作成し、承認を待ってから、テストスタックを削除します。

CreateStack アクションでは、パイプラインはテスト設定ファイルおよび WordPress テンプレートを使用してテストスタックを作成します。ファイルはどちらもソースステージで持ち込まれた TemplateSource 入力アーティファクトに含まれています。このスニペットでは、REPLACE_ON_FAILURE アクションモードを使用します。スタックの作成が失敗すると、パイプラインはこれを置き換えます。パイプラインを再実行する前にスタックを消去したりトラブルシューティングする必要はありません。アクションモードは、テストスタックですばやく反復処理する場合に便利です。RoleArn プロパティの値は、テンプレートの他の場所で指定されている AWS CloudFormation サービスロールです。

ApproveTestStack アクションはパイプラインを一時停止し、パイプラインスタックの作成時に指定された E メールアドレスに通知を送信します。パイプラインが一時停止している間に、WordPress テストスタックとそのリソースを確認できます。AWS CodePipeline を使用してこのアクションを承認または却下します。CustomData プロパティには、承認するアクションの説明が含まれています。これはパイプラインによって通知 E メールに追加されています。

このアクションを承認すると、AWS CodePipeline は DeleteTestStack アクションに移行し、テスト WordPress スタックおよびそのリソースを削除します。

Copy
- Name: TestStage Actions: - Name: CreateStack ActionTypeId: Category: Deploy Owner: AWS Provider: CloudFormation Version: '1' InputArtifacts: - Name: TemplateSource Configuration: ActionMode: REPLACE_ON_FAILURE RoleArn: !GetAtt [CFNRole, Arn] StackName: !Ref TestStackName TemplateConfiguration: !Sub "TemplateSource::${TestStackConfig}" TemplatePath: !Sub "TemplateSource::${TemplateFileName}" RunOrder: '1' - Name: ApproveTestStack ActionTypeId: Category: Approval Owner: AWS Provider: Manual Version: '1' Configuration: NotificationArn: !Ref CodePipelineSNSTopic CustomData: !Sub 'Do you want to create a change set against the production stack and delete the ${TestStackName} stack?' RunOrder: '2' - Name: DeleteTestStack ActionTypeId: Category: Deploy Owner: AWS Provider: CloudFormation Version: '1' Configuration: ActionMode: DELETE_ONLY RoleArn: !GetAtt [CFNRole, Arn] StackName: !Ref TestStackName RunOrder: '3'

ステージ 3: ProdStage

パイプラインの ProdStage ステージでは、既存の本稼働スタックに対する変更セットを作成し、承認を待ってから、変更セットを実行します。

AWS CloudFormation が本稼働スタックに対して行うすべての変更を、実装前に変更セットで確認できます。初めてパイプラインを実行する場合は、実行中の本稼働スタックはありません。変更セットには、テストスタック作成時に AWS CloudFormation が実行したアクションが表示されます。CreateChangeSet アクションは、変更セットの作成に、TemplateSource 入力アーティファクトからの WordPress サンプルテンプレートおよび本稼働テンプレート設定を使用します。

前のステージと同様に、ApproveChangeSet アクションでパイプラインが一時停止し、E メール通知が送信されます。パイプラインが一時停止している間に、変更セットを確認して、本稼働 WordPress スタックに対する変更案をすべて確認できます。AWS CodePipeline を使用して、このアクションを承認または却下し、それに合わせてパイプラインを続行または停止します。

アクションを承認した場合、ExecuteChangeSet アクションが変更セットを実行し、変更セットに記述されたアクションがすべて AWS CloudFormation によって実行されます。初めて実行する場合は、AWS CloudFormation によって WordPress 本稼働スタックが作成されます。それ以降の実行では、AWS CloudFormation はそのスタックを更新します。

Copy
- Name: ProdStage Actions: - Name: CreateChangeSet ActionTypeId: Category: Deploy Owner: AWS Provider: CloudFormation Version: '1' InputArtifacts: - Name: TemplateSource Configuration: ActionMode: CHANGE_SET_REPLACE RoleArn: !GetAtt [CFNRole, Arn] StackName: !Ref ProdStackName ChangeSetName: !Ref ChangeSetName TemplateConfiguration: !Sub "TemplateSource::${ProdStackConfig}" TemplatePath: !Sub "TemplateSource::${TemplateFileName}" RunOrder: '1' - Name: ApproveChangeSet ActionTypeId: Category: Approval Owner: AWS Provider: Manual Version: '1' Configuration: NotificationArn: !Ref CodePipelineSNSTopic CustomData: !Sub 'A new change set was created for the ${ProdStackName} stack. Do you want to implement the changes?' RunOrder: '2' - Name: ExecuteChangeSet ActionTypeId: Category: Deploy Owner: AWS Provider: CloudFormation Version: '1' Configuration: ActionMode: CHANGE_SET_EXECUTE ChangeSetName: !Ref ChangeSetName RoleArn: !GetAtt [CFNRole, Arn] StackName: !Ref ProdStackName RunOrder: '3'

ステップ 3: WordPress スタックの表示

AWS CodePipeline は、パイプラインを実行する際に、AWS CloudFormation を使用してテストスタックおよび本稼働スタックを作成します。これらのスタックのステータスとその出力を表示するには、AWS CloudFormation コンソールを使用します。

スタックを表示するには

  1. AWS CloudFormation コンソール (https://console.aws.amazon.com/cloudformation/) を開きます。

  2. パイプラインがテストステージにあるか本稼働ステージにあるかによって、Test-MyWordPressSite または Prod-MyWordPressSite スタックを選択します。

  3. スタックのステータスを確認するには、スタックイベントを表示します。

スタックが失敗状態の場合は、ステータスの理由を参照してスタックのエラーを見つけください。エラーを修正してから、パイプラインを再実行します。スタックが CREATE_COMPLETE 状態にある場合は、その出力を表示して WordPress サイトの URL を取得します。

これで、AWS CodePipeline を使用してサンプルの WordPress サイト用の継続的な配信フローを正常に構築できました。S3 バケットに変更を送信すると、AWS CodePipeline は自動的に新しいバージョンを検出し、パイプラインを再実行します。このワークフローによって、本稼働サイトに変更を加える前に、簡単に変更を送信してテストできます。

ステップ 4: リソースをクリーンアップする

不要なサービスに対して課金されないように、リソースを削除します。

重要

パイプラインのスタックを削除する前に、テストおよび本稼働の WordPress スタックを削除します。パイプラインのスタックには、WordPress スタックを削除するために必要なサービスロールが含まれています。先にパイプラインのスタックを削除する場合は、WordPress スタックに別のサービスロールの Amazon リソースネーム (ARN) を関連付けてから、それらを削除できます。

アーティファクトストアのオブジェクトを削除するには

  1. https://console.aws.amazon.com/s3/ にある Amazon S3 コンソールを開きます。

  2. パイプラインのアーティファクトストアとして AWS CodePipeline が使用した S3 バケットを選択します。

    バケット名の形式は次の通りです。stackname-artifactstorebucket-idこのウォークスルーに従った場合は、バケット名は次の例に似たものになります。sample-WordPress-pipeline-artifactstorebucket-12345abcd12345

  3. アーティファクトストア S3 バケットのすべてのオブジェクトを削除します。

    次のステップでパイプラインのスタックを削除する際、このバケットは空である必要があります。そうしないと、AWS CloudFormation がバケットを削除できません。

スタックを削除するには

  1. AWS CloudFormation コンソールから、削除するスタックを選択します。

    パイプラインによって作成された WordPress スタックがまだ実行中であれば、それらを最初に選択します。デフォルトでは、スタック名は Test-MyWordPressSite および Prod-MyWordPressSite です。

    既に WordPress スタックを削除してある場合は、sample-WordPress-pipeline スタックを選択します。

  2. [Actions] を選択してから、[Delete Stack] を選択します。

  3. 確認メッセージで、[Yes, Delete] を選択します。

AWS CloudFormation がスタックおよび EC2 インスタンス、通知トピック、サービスロール、パイプラインなどのスタックのリソースをすべて削除します。

これで、AWS CodePipeline を使用した基本的な AWS CloudFormation ワークフローの構築方法を理解できたため、サンプルのテンプレートとアーティファクトを開始点として使用して、独自に構築できます。