チュートリアル: テストおよび本稼働スタック用のパイプラインを構築する - AWS CloudFormation
前提条件チュートリアルの概要ステップ 1: アーティファクトを編集し、S3 バケットにアップロードするステップ 2: パイプラインスタックを作成するステップ 3: WordPress スタックの表示ステップ 4: リソースをクリーンアップする以下も参照してください。

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

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

前提条件

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

重要

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

チュートリアルの概要

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

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

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

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

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

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

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

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

注記

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

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

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

ソースリポジトリとして Amazon Simple Storage Service (Amazon S3) を使用する場合、CodePipeline ではソースファイルを zip にしてから S3 バケットにアップロードする必要があります。zip ファイルは、AWS CloudFormation テンプレート、テンプレート構成ファイル、またはその両方を含む CodePipeline アーティファクトです。WordPress サンプルテンプレートと 2 つのテンプレート構成ファイルを含むアーティファクトが用意されています。2 つの構成ファイルは、WordPress テンプレートのパラメータ値を指定します。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 リージョンと同じリージョンに存在するバケットを使用します。

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

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

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

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

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

WordPress パイプラインを作成するには、サンプルの AWS CloudFormation テンプレートを使用します。パイプラインの構築に加えて、テンプレートは CodePipeline と AWS CloudFormation 用に AWS Identity and Access Management (IAM) サービスロール、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. https://console.aws.amazon.com/cloudformation/ で AWS CloudFormation コンソール を開きます。

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

    詳細については、「AWS 全般のリファレンス」の「AWS のリージョンとエンドポイント」を参照してください。

  4. [スタックの作成] を選択します。

  5. [Specify template (テンプレートの指定)] で [Upload a template file (テンプレートファイルのアップロード)] を選択し、先ほどダウンロードしたテンプレート basic-pipeline.yml を選択します。

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

  7. [スタックの名前] に sample-WordPress-pipeline を入力します。

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

    PipelineName

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

    S3 バケット

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

    SourceS3Key

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

    Email(メール)

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

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

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

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

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

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

パイプラインの仕組み

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

ステージ 1: Source

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

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

- 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 テストスタックとそのリソースを確認できます。CodePipeline を使用してこのアクションを承認または却下します。CustomData プロパティには、承認するアクションの説明が含まれています。これはパイプラインによって通知 E メールに追加されています。

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

- 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 スタックに対する変更案をすべて確認できます。CodePipeline を使用して、このアクションを承認または却下し、それに合わせてパイプラインを続行または停止します。

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

- 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 スタックの表示

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

スタックを表示するには

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

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

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

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

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

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

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

重要

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

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

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

  2. パイプラインのアーティファクトストアとして 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. [アクション] を選択してから、[スタックの削除] を選択します。

  3. 確認メッセージで、[はい、削除する] を選択します。

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

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

以下も参照してください。

これらのパラメータを利用する際に役立つ関連リソースは以下の通りです。

  • CodePipeline の AWS CloudFormation アクションパラメータの詳細については、「AWS CodePipeline ユーザーガイド」の「AWS CloudFormation アクション構成リファレンス」を参照してください。

  • アクションプロバイダーごとのテンプレート値における例の場合 (Owner フィールドまたは configuration フィールドなど)、「AWS CodePipeline ユーザーガイド」の「アクション構造のリファレンス」を参照してください。

  • YAML または JSON 形式のパイプラインスタックテンプレートの例をダウンロードするには、「AWS CodePipeline ユーザーガイド」の「AWS CloudFormation でパイプラインの作成」のチュートリアルを参照してください。

  • 構成ファイルのテンプレートの例については、「AWS CloudFormation アーティファクト」を参照してください。