Category: AWS CodeDeploy*


AWS CodePipelineを利用したネストされたAWS CloudFormationスタックの継続的デリバリー

CodePipeline の更新 – CloudFormation スタックの継続的デリバリーワークフローの構築で、 Jeff BarrはInfrastructure as Codeについてと、AWS CodePipelineを継続的デリバリーに使用する方法について説明しています。 本ブログ記事では、ソースリポジトリとしてAWS CodeCommitを、ビルドおよびテストツールとしてAWS CodeBuildを使用した、AWS CodePipelineを使ったネストされたCloudFormationスタックの継続的デリバリーについて説明します。手動承認プロセスに従ってCloudFormationチェンジセットを使用してスタックをデプロイします。

AWS CodePipelineでは、次の4つのステージでパイプラインを作成します。

  • Source (AWS CodeCommit)
  • Build and Test (AWS CodeBuild および AWS CloudFormation)
  • Staging (AWS CloudFormation および 手動承認)
  • Production (AWS CloudFormation および 手動承認)

次の図に、パイプラインのステージと、各ステージのアクション、およびステージ間の遷移を示します。

CloudFormationテンプレート、テストスクリプト、およびビルドスペックファイルは、AWS CodeCommitリポジトリに格納されています。これらのファイルは、AWS CodePipelineのパイプラインのSourceステージで使用されます。

AWS::CloudFormation::Stackリソースタイプは、親スタックから子スタックを作成するために使用されます。 CloudFormationスタックリソースでは、S3バケットに格納される子スタックのテンプレートを必要とします。テンプレートファイルの場所は、リソース定義のPropertiesセクションにURLとして指定されます。

次のテンプレートは、3つの子スタックを作成します。

  • Security (IAM, セキュリティグループ)
  • Database (RDSインスタンス)
  • Web stacks (Auto ScalingグループのEC2インスタンス, ELB)

Description: Master stack which creates all required nested stacks

Parameters:
  TemplatePath:
    Type: String
    Description: S3Bucket Path where the templates are stored
  VPCID:
    Type: "AWS::EC2::VPC::Id"
    Description: Enter a valid VPC Id
  PrivateSubnet1:
    Type: "AWS::EC2::Subnet::Id"
    Description: Enter a valid SubnetId of private subnet in AZ1
  PrivateSubnet2:
    Type: "AWS::EC2::Subnet::Id"
    Description: Enter a valid SubnetId of private subnet in AZ2
  PublicSubnet1:
    Type: "AWS::EC2::Subnet::Id"
    Description: Enter a valid SubnetId of public subnet in AZ1
  PublicSubnet2:
    Type: "AWS::EC2::Subnet::Id"
    Description: Enter a valid SubnetId of public subnet in AZ2
  S3BucketName:
    Type: String
    Description: Name of the S3 bucket to allow access to the Web Server IAM Role.
  KeyPair:
    Type: "AWS::EC2::KeyPair::KeyName"
    Description: Enter a valid KeyPair Name
  AMIId:
    Type: "AWS::EC2::Image::Id"
    Description: Enter a valid AMI ID to launch the instance
  WebInstanceType:
    Type: String
    Description: Enter one of the possible instance type for web server
    AllowedValues:
      - t2.large
      - m4.large
      - m4.xlarge
      - c4.large
  WebMinSize:
    Type: String
    Description: Minimum number of instances in auto scaling group
  WebMaxSize:
    Type: String
    Description: Maximum number of instances in auto scaling group
  DBSubnetGroup:
    Type: String
    Description: Enter a valid DB Subnet Group
  DBUsername:
    Type: String
    Description: Enter a valid Database master username
    MinLength: 1
    MaxLength: 16
    AllowedPattern: "[a-zA-Z][a-zA-Z0-9]*"
  DBPassword:
    Type: String
    Description: Enter a valid Database master password
    NoEcho: true
    MinLength: 1
    MaxLength: 41
    AllowedPattern: "[a-zA-Z0-9]*"
  DBInstanceType:
    Type: String
    Description: Enter one of the possible instance type for database
    AllowedValues:
      - db.t2.micro
      - db.t2.small
      - db.t2.medium
      - db.t2.large
  Environment:
    Type: String
    Description: Select the appropriate environment
    AllowedValues:
      - dev
      - test
      - uat
      - prod

Resources:
  SecurityStack:
    Type: "AWS::CloudFormation::Stack"
    Properties:
      TemplateURL:
        Fn::Sub: "https://s3.amazonaws.com/${TemplatePath}/security-stack.yml"
      Parameters:
        S3BucketName:
          Ref: S3BucketName
        VPCID:
          Ref: VPCID
        Environment:
          Ref: Environment
      Tags:
        - Key: Name
          Value: SecurityStack

  DatabaseStack:
    Type: "AWS::CloudFormation::Stack"
    Properties:
      TemplateURL:
        Fn::Sub: "https://s3.amazonaws.com/${TemplatePath}/database-stack.yml"
      Parameters:
        DBSubnetGroup:
          Ref: DBSubnetGroup
        DBUsername:
          Ref: DBUsername
        DBPassword:
          Ref: DBPassword
        DBServerSecurityGroup:
          Fn::GetAtt: SecurityStack.Outputs.DBServerSG
        DBInstanceType:
          Ref: DBInstanceType
        Environment:
          Ref: Environment
      Tags:
        - Key: Name
          Value:   DatabaseStack

  ServerStack:
    Type: "AWS::CloudFormation::Stack"
    Properties:
      TemplateURL:
        Fn::Sub: "https://s3.amazonaws.com/${TemplatePath}/server-stack.yml"
      Parameters:
        VPCID:
          Ref: VPCID
        PrivateSubnet1:
          Ref: PrivateSubnet1
        PrivateSubnet2:
          Ref: PrivateSubnet2
        PublicSubnet1:
          Ref: PublicSubnet1
        PublicSubnet2:
          Ref: PublicSubnet2
        KeyPair:
          Ref: KeyPair
        AMIId:
          Ref: AMIId
        WebSG:
          Fn::GetAtt: SecurityStack.Outputs.WebSG
        ELBSG:
          Fn::GetAtt: SecurityStack.Outputs.ELBSG
        DBClientSG:
          Fn::GetAtt: SecurityStack.Outputs.DBClientSG
        WebIAMProfile:
          Fn::GetAtt: SecurityStack.Outputs.WebIAMProfile
        WebInstanceType:
          Ref: WebInstanceType
        WebMinSize:
          Ref: WebMinSize
        WebMaxSize:
          Ref: WebMaxSize
        Environment:
          Ref: Environment
      Tags:
        - Key: Name
          Value: ServerStack

Outputs:
  WebELBURL:
    Description: "URL endpoint of web ELB"
    Value:
      Fn::GetAtt: ServerStack.Outputs.WebELBURL

Validateステージでは、AWS CodeBuildはAWS CodeCommitソースリポジトリの変更をチェックします。 ValidateTemplate APIを使用してCloudFormationテンプレートを検証し、子テンプレートと設定ファイルをS3バケットの適切な場所にコピーします。

次のAWS CodeBuildビルドスペックでは、TEMPLATE_FILES環境変数にリストされているCloudFormationテンプレートが検証され、AWS CodeBuildプロジェクトの環境変数TEMPLATE_BUCKETに指定されたS3バケットにコピーされます。 オプションとして、TEMPLATE_PREFIX環境変数を使用して、バケット内のパスを指定することもできます。これにより、構成ファイルの子テンプレートファイルの場所が更新されます。テンプレートファイルの場所は、親スタックのパラメータとして渡されます。

version: 0.1

environment_variables:
  plaintext:
    CHILD_TEMPLATES: |
      security-stack.yml
      server-stack.yml
      database-stack.yml
    TEMPLATE_FILES: |
      master-stack.yml
      security-stack.yml
      server-stack.yml
      database-stack.yml
    CONFIG_FILES: |
      config-prod.json
      config-test.json
      config-uat.json

phases:
  install:
    commands:
      npm install jsonlint -g
  pre_build:
    commands:
      - echo "Validating CFN templates"
      - |
        for cfn_template in $TEMPLATE_FILES; do
          echo "Validating CloudFormation template file $cfn_template"
          aws cloudformation validate-template --template-body file://$cfn_template
        done
      - |
        for conf in $CONFIG_FILES; do
          echo "Validating CFN parameters config file $conf"
          jsonlint -q $conf
        done
  build:
    commands:
      - echo "Copying child stack templates to S3"
      - |
        for child_template in $CHILD_TEMPLATES; do
          if [ "X$TEMPLATE_PREFIX" = "X" ]; then
            aws s3 cp "$child_template" "s3://$TEMPLATE_BUCKET/$child_template"
          else
            aws s3 cp "$child_template" "s3://$TEMPLATE_BUCKET/$TEMPLATE_PREFIX/$child_template"
          fi
        done
      - echo "Updating template configurtion files to use the appropriate values"
      - |
        for conf in $CONFIG_FILES; do
          if [ "X$TEMPLATE_PREFIX" = "X" ]; then
            echo "Replacing \"TEMPLATE_PATH_PLACEHOLDER\" for \"$TEMPLATE_BUCKET\" in $conf"
            sed -i -e "s/TEMPLATE_PATH_PLACEHOLDER/$TEMPLATE_BUCKET/" $conf
          else
            echo "Replacing \"TEMPLATE_PATH_PLACEHOLDER\" for \"$TEMPLATE_BUCKET/$TEMPLATE_PREFIX\" in $conf"
            sed -i -e "s/TEMPLATE_PATH_PLACEHOLDER/$TEMPLATE_BUCKET\/$TEMPLATE_PREFIX/" $conf
          fi
        done

artifacts:
  files:
    - master-stack.yml
    - config-*.json

テンプレートファイルがS3にコピーされると、CloudFormationはテストスタックを作成し、テストアクションとしてAWS CodeBuildをトリガーします。

AWS CodeBuildのビルドスペックでは、ネストされたCloudFormationスタックを使用して作成されたリソースが、CONFIG_FILEで指定された仕様に準拠しているかどうかをチェックするためのPythonスクリプト、validate-env.pyが実行されます。

version: 0.1

environment_variables:
  plaintext:
    CONFIG_FILE: env-details.yml

phases:
  install:
    commands:
      - pip install --upgrade pip
      - pip install boto3 --upgrade
      - pip install pyyaml --upgrade
      - pip install yamllint --upgrade
  pre_build:
    commands:
      - echo "Validating config file $CONFIG_FILE"
      - yamllint $CONFIG_FILE
  build:
    commands:
      - echo "Validating resources..."
      - python validate-env.py
      - exit $?

テストアクションが正常に完了すると、CloudFormationはテストスタックを削除し、パイプラインのUAT(訳者注:User Acceptance Test/ユーザ受け入れテスト)ステージに進みます。

このステージでは、CloudFormationはUATスタックに対して変更セットを作成し、変更セットを実行します。これにより、UAT環境が更新され、受け入れテストが可能になります。プロセスは手動承認アクションに進みます。 QAチームがUAT環境を検証して承認をおこなった後、プロセスはパイプラインのProductionステージに移行します。

このステージでは、CloudFormationはネストされた本番スタックの変更セットを作成し、プロセスは手動承認ステップに進みます。(通常は指定されたエグゼクティブによって)承認されると、変更セットが実行され、Productionデプロイメントが完了します。
 

継続的デリバリーパイプラインの設定

 
CloudFormationテンプレートを使用して、継続的デリバリーパイプラインを設定します。 GitHubから入手できるcodepipeline-cfn-codebuild.ymlテンプレートは、フル機能のパイプラインを設定します。

このテンプレートを使用してパイプラインを作成するときは、次の項目を指定します。

  • AWS CodeCommitリポジトリ
  • 承認通知を送信するSNSトピック
  • アーティファクトが格納されるS3バケット名

CFNTemplateRepoNameには、CloudFormationテンプレート、設定ファイル、およびビルドスペックファイルが格納されているAWS CodeCommitリポジトリを指定します。

私のリポジトリには以下のファイルが含まれています:

継続的デリバリーパイプラインは、Create Stackをクリックするとすぐに配備されます。作成後、パイプラインは各ステージを実行します。 UATおよびProductionステージの手動承認により、パイプラインは継続的デリバリーを可能にします。


 

ネストされたスタックの変更の実装

 
ネストしたスタック内の子スタックを変更するには(たとえば、パラメータ値を更新する、またはリソースを追加または変更するなど)、親スタックを更新します。変更は適切なテンプレートファイルまたは設定ファイルで行い、AWS CodeCommitリポジトリにチェックインする必要があります。これにより、次のデプロイプロセスがトリガーされます:

 

まとめ

 
この記事では、AWS CodePipeline、AWS CloudFormation、AWS CodeBuild、および手動承認プロセスを使用して、Infrastructure as Codeとアプリケーションデプロイメントの両方で継続的デリバリーパイプラインを作成する方法を示しました。

AWS CodePipelineの詳細については、AWS CodePipelineのドキュメントを参照してください。数回のクリックで始めることができます。 すべてのCloudFormationテンプレート、AWS CodeBuildビルドスペックファイル、および検証を実行するPythonスクリプトは、codepipeline-nested-cfn GitHubリポジトリに公開しています。


著者紹介

 
Prakash PalanisamyはAmazon Web ServicesのSolutions Architectです。 Serverless、DevOps、Alexaを担当する他、Project Eulerでの問題解決をおこなっています。彼はまた、教育ドキュメンタリーを見て楽しんでいます。

(翻訳はSA千葉が担当しました。原文はこちら)

ASP.NET CoreとAWS CodeStarのDeep Dive

AWS CodeStar チームは最近、2つのASP.NET Coreプロジェクト テンプレートの追加を発表しました。ご存知かもしれませんが、AWS CodeStarは継続的インテグレーションと継続的デプロイメント(CI/CD)パイプラインを開発者に代わって作成し、それによって開発者は貴重な時間をインフラの構築の代わりにアプリケーションの構築に費やすことができます。新しいASP.NET Coreプロジェクトテンプレートを使用することで、.NET開発者は初日からAWSアプリケーションを構築し、展開することができます。Tara Walkerの優れたブログ記事では、AWS CodeStarでASP.NET Core アプリケーションを作成する方法について説明しています。このブログ記事では、AWS CodeStarのASP.NET Coreプロジェクトにテストを追加する方法を学ぶ中で、背後で何が起こっているのかを詳しく見ていきます。

 

Unit Test プロジェクトの追加

私たちの目標は、HelloControllerの機能を実行するシンプルなテストケースを追加することです。私はあなたが全く新しいASP.Net Core Web Service プロジェクトを持っていると仮定しています。もし、まだプロジェクトを持っていない場合は、Taraのブログ記事(上記)をたどってプロジェクトを作成することができます。ASP.NET Core Web Service テンプレートを選択していることを確認してください。ASP.NET Core for AWS CodeStarプロジェクトを作成後、Team Explorer でプロジェクト リポジトリをクローンし、AspNetCoreWebServiceソリューションをロードしたら、残りのブログ記事に沿って後を追えるようになります。Team Explorer でリポジトリをセットアップするためのガイドが必要な場合は、5月のSteve RobertのVisual StudioとCodeCommitのインテグレーションについての発表をご覧ください。

最初に、AspNetCoreWebServiceTestという名前の新しいxUnitプロジェクトをAspNetCoreWebServiceソリューションに追加します。私たちの新しいテストプロジェクトはHelloControllerクラスとJsonResultを参照するので、AspNetCoreWebServiceをプロジェクト参照として追加し、Microsoft.AspNetCore.MvcをNuGet参照として追加する必要があります。それらをテストプロジェクトに追加すると、AspNetCoreWebServiceTest.csprojに次の追加情報が表示されます。

 

<ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.3" />
    ...
</ItemGroup>
...
<ItemGroup>
    <ProjectReference Include="..\AspNetCoreWebService\AspNetCoreWebService.csproj" />
</ItemGroup>

 

これにより、HelloControllerクラスを直接参照し、JsonResultを展開することができます。次のように簡単なテストケースを追加しましょう。

using System;
using Xunit;
using Microsoft.AspNetCore.Mvc;
using AspNetCoreWebService.Controllers;

namespace AspNetCoreWebServiceTest
{
    public class HelloControllerTest
    {
        [Fact]
        public void SimpleTest()
        {
            HelloController controller = new HelloController();
            var response = controller.Get("AWS").Value as Response;
            Assert.Equal(response.output, "Hello AWS!");
        }
    }
}

 

ファイル名、名前空間、クラス名、およびメソッド名を変更したことに注意してください。テストを実行し、テストが合格することを確認します。ソリューション エクスプローラで次のように表示されます。

動作するテストプロジェクトを手に入れたので、アプリケーションをデプロイする前にテストをビルドして実行するようにパイプラインを更新します。

 

AWS CodeBuildジョブの更新

最初にプロジェクトの構築方法を見てみましょう。あなた、もしくはチームのメンバーがリポジトリに変更をプッシュすると、パイプラインは自動的に最新の変更に対してビルドプロセスを開始します。このステップでは、AWS CodeBuildはビルドプロセスを実行するためにリポジトリのルートにあるbuildspec.ymlファイルを使用します。

version: 0.2
phases:
  pre_build:
    commands:
      - echo Restore started on `date`
      - dotnet restore AspNetCoreWebService/AspNetCoreWebService.csproj
  build:
    commands:
      - echo Build started on `date`
      - dotnet publish -c release -o ./build_output AspNetCoreWebService/AspNetCoreWebService.csproj
artifacts:
  files:
    - AspNetCoreWebService/build_output/**/*
    - scripts/**/*
    - appspec.yml

 

AWS CodeBuildジョブは、AWS CodeBuildに.NET Coreイメージを使用します。これには buildspec.ymlで呼び出す.NET Core SDKとCLIが含まれています。このプロジェクトは1つのWebサービスで構成されているため、1つのbuildspec.ymlファイルで十分です。プロジェクトが拡大しビルドプロセスの複雑さが増すにつれて、いずれはシェルスクリプトまたはMSBuildの.projファイルを使用してシンプルにbuildspec.ymlでscript / buildファイルを呼び出すように、ビルドプロセスを外部で駆動したいと思うかもしれません。

 

ここでは dotnet publishコマンドに注目したいと思います。この発行のステップは、すべての依存関係をパッケージ化してホストマシン上ですぐに利用できるようにするために重要です。上記のbuildspec.ymlファイルのartifactsセクションで定義されているように、AWS CodeDeployがホストにアプリケーションを配置するために使用するファイル群が、Amazon S3バケットに格納されます。scripts/**/* には、appsec.ymlが依存するすべてのスクリプトが含まれています。appsec.ymlに慣れていない方や詳細を知りたい方のために次のセクションで説明します。

前のセクションでは、AWS CodeCommitリポジトリにテストプロジェクトを追加しました。今度は、新しいテストプロジェクトをビルドするためにbuildspec.ymlを更新する必要があります。ビルド ステージの一部として、単にdotnet vstestを実行することができますが、このエクササイズではベストプラクティスに従ってビルドとテストのステージを分けて構築します。 buildspec.ymlを修正してテスト バイナリをビルドし、その成果物をAspNetCoreWebServiceTest/test_outputディレクトリに発行しましょう。

pre_build:
    commands:
        ...
        - dotnet restore AspNetCoreWebServiceTest/AspNetCoreWebServiceTest.csproj
post_build:
    commands:
        ...
        - dotnet publish -c release -o ./test_output AspNetCoreWebServiceTest/AspNetCoreWebServiceTest.csproj  
artifacts:
    files:
        ...
        - AspNetCoreWebServiceTest/test_output/**/*

 

アーティファクトとしてAspNetCoreWebServiceTest/test_output/**/* を追加したことに注意してください。実際には、これは発行されたテストバイナリをAmazon S3にアップロードするようにAWS CodeBuildサービスに指示することになります。これにより、次に作成するテスト ジョブでそれらを参照できるようになります。

 

AWS CodePipelineの更新

前のセクションでは、テストを実行するために必要なバイナリをビルドして保存するために、新しいテストプロジェクトを追加し、buildspec.ymlを修正しました。次にテストステージをパイプラインに追加する方法について説明します。まずTestステージとUnitTestアクションをコンソールからパイプラインに追加しましょう。

残りのUIも以下のパラメータで埋めます:

  • Action category: Test
  • Action name: UnitTest
  • Test provider: AWS CodeBuild
  • Create a new build project を選択
  • Project name: <プロジェクト名>-test
  • Operating system: Ubuntu
  • Runtime: .NET Core
  • Version: aws/codebuild/dot-net:core-1
  • Build specificationInsert build Commands を選択
  • Build command: dotnet vstest AspNetCoreWebServiceTest/test_output/AspNetCoreWebServiceTest.dll
  • Role nameCodeStarWorker-<プロジェクト名>-CodeBuild をリストから選択
  • Input artifacts #1 は, <プロジェクト名>-BuildArtifact をリストから選択

 

ここでの重要な情報は、ビルドコマンドです。私たちのテストジョブは前のステージでビルドされたtest.dllに対してdotnet vstestを実行します。あなたのパイプラインはこのようになります。

これでほぼ完成です!「Release Change」を押してこのパイプラインを実行すると、パイプラインのテストステージで Error Code: AccessDeniedException  のメッセージを伴って実行が失敗します。これは、AWS CodeStarサービスに新しいテストステージを実行する権限がないためです。ここではAWS CodeStarプロジェクトへの適切なアクセスを許可する方法を確認しましょう。

 

Role ポリシーの更新

AWS CodeStarプロジェクトでは、さまざまなサービスやワーカーがアプリケーションを同期、ビルド、およびデプロイするための最小限のアクセス許可のポリシーを作成します。新しいAWS CodeBuildジョブを追加したので、新しいリソースへのアクセスをCodeStarWorkerCodePipelinePolicyで許可する必要があります。この変更を行うためにIAMコンソールに移動します。 [Role]タブで、 “codebuild”キーワードを使用して検索します。ロールはCodeStarWorker- <プロジェクト名> -CodePipelineの形式である必要があります。次に、ロールにアタッチされているポリシーを編集します。以下に示します。

変更したい内容は、ポリシー内にAWS CodeBuildアクションに関連付けられている新しいcodebuildリソースである arn:aws:codebuild:us-east-1:532345249509:project/<プロジェクト名>-test を追加することです。

{
    "Action": [
        "codebuild:StartBuild",
        "codebuild:BatchGetBuilds",
        "codebuild:StopBuild"
    ],
    "Resource": [
        "arn:aws:codebuild:us-east-1:532345249509:project/<your project name>"
        "arn:aws:codebuild:us-east-1:532345249509:project/<your project name>-test"
    ],
    "Effect": "Allow"
}

 

以上です。AWS CodeStarプロジェクトは新しいジョブを構築するための適切な権限を持ちました。[Release Change] を押して試してみてください。

 

ASP.NET Core アプリケーションのデプロイメント

ここまでAWS CodeStarがプロジェクトをビルドしテストする方法を見てきました。このセクションでは、デプロイメントプロセスを詳しく見ていきます。AWS CodeStarプロジェクトの作成の一部として、AWS CodeStarサービスはアプリケーションをホストするAmazon EC2インスタンスを作成します。またappspec.ymlの指示に従って、そのインスタンスにデプロイメントプロセスを実行するcode-deploy-agentもインストールされます。appspec.ymlを見てみましょう。

version: 0.0
os: linux
files:
  - source: AspNetCoreWebService/build_output
    destination: /home/ubuntu/aspnetcoreservice
  - source: scripts/virtualhost.conf
    destination: /home/ubuntu/aspnetcoreservice 
hooks:
  ApplicationStop:
    - location: scripts/stop_service
      timeout: 300
      runas: root

  BeforeInstall:
    - location: scripts/remove_application
      timeout: 300
      runas: root

  AfterInstall:
    - location: scripts/install_dotnetcore
      timeout: 500
      runas: root

    - location: scripts/install_httpd
      timeout: 300
      runas: root

  ApplicationStart:
    - location: scripts/start_service
      timeout: 300
      runas: root

 

各スクリプトは、デプロイメントプロセスのさまざまなステージで実行されます:

  • install_dotnetcore – もしまだインストールされていなければ .NET Core をインストールし、最初の実行時にパッケージ キャッシュをアップデートします。これはMicrosoftのUbuntuへの.NET Coreインストールの推奨方法です。
  • install_httpd – HTTPDデーモンとmodsをインストールし、HTTPD設定ファイルを上書きしてリバースプロキシを有効化します。
  • start_service – HTTPDサービスを再起動し、既存のASP.NETアプリケーション/サービス プロセスを再起動します。
  • scripts/stop_service – HTTPDサービスを停止し、既に実行している場合、ASP.NETアプリケーション/サービスを停止します。
  • remove_application – インスタンスからデプロイされているアプリケーションを削除します。

 

インスタンス上のcode-deploy-agentは、アプリケーションのデプロイ時にこれらのフックを実行して、サービスをインストールして開始します。イベントのアクティビティはAWS CodeDeployコンソールで監視でき、EC2インスタンスから詳細なログを取得できます。インスタンスへのSSH接続を開いたら、デプロイメントログを見るために /var/log/aws/codedeploy-agentに移動してください。

 

結論

このブログ記事では、アプリケーションのパイプラインにテストステージを追加する例を使用して、AWS CodeStarのASP.NET Core プロジェクトの構築とデプロイメントを学びました。この記事がAWS CodeStarの下で完全なCI / CDシステムを提供するために、さまざまなコンポーネントとAWSサービスがどのように相互作用するかを理解する助けになることを願っています。詳細については、AWS CodeStarユーザーガイドをご覧ください。AWS CodeStarに固有の問題が発生した場合は、AWS CodeStarのトラブルシューティング ガイドを参照してください。

 

(翻訳はSA 福井が担当しました。原文はこちらです。)

 

New – AWS CodeStarの紹介 – AWS上のアプリケーションをすばやく開発、構築、デプロイする

それほど遠く無い昔、今日多くのソフトウェア チームがアプリケーション開発で直面している、リリース期限までにソフトウェア プロジェクトを完成させ変化に対応するというような開発チームに私は所属していました。そこには新しいプロジェクト環境のセットアップ、チームメンバーのコラボレーション、各開発ビルドのコード変更、構成、ライブラリの継続的な追跡を行う日常的なタスクなどの課題がありました。 今日、企業がイノベーションと市場投入をより迅速に行うためには、開発チームがソフトウェアの作成、構築、展開をより簡単かつ効率的に行うことが不可欠になっています。

 

残念なことに、多くの組織は、より機敏で動的なソフトウェア開発プロセスを追求する上で、いくつかの重要な課題に直面しています。 ほとんどの新しいソフトウェア プロジェクトが直面する最初の課題は、開発者がコーディングを開始する前に完了しなければならない長いセットアップ プロセスです。 このプロセスには、IDEのセットアップ、適切なコード リポジトリへのアクセスの取得、および/またはビルド、テスト、および運用に必要なインフラストラクチャの識別が含まれます。

 

コラボレーションは、ほとんどの開発チームが直面しうる別の課題です。 プロジェクトのすべてのメンバーに安全な環境を提供するために、チームはさまざまなチームの役割とニーズに応じて別々のプロジェクトとツールを頻繁に設定する必要があります。 さらに、すべてのステークホルダーに、課題の更新、開発の進展、およびソフトウェアの問題の報告に関する情報を提供することは、時間がかかる可能性があります。

 

最後に、ほとんどの企業では、継続的インテグレーションと継続的デリバリに関するベストプラクティスを採用することで、ソフトウェア開発のスピードを高め、市場投入までの時間を短縮したいと考えています。 これらのアジャイル開発戦略を適用するには、企業が方法論についてチームを教育し、これらの新しいプロセスのためのリソースを設定するための時間を費やす必要があります。

 

AWS CodeStar:プレゼンテーション

 

開発チームがソフトウェアを構築する上での課題を緩和し、アプリケーションやソリューションをリリースするペースを向上させるために、AWS CodeStarを紹介します。

 

AWS CodeStarは、開発プロジェクト全体の設定を簡素化することにより、AWS上でアプリケーションの開発、構築、および展開を容易にするために設計されたクラウドサービスです。 AWS CodeStarには、ソフトウェア プロジェクトのコーディング、ビルド、テスト、デプロイ、および実行のためのプロジェクトとリソースのプロビジョニングを可能にする一般的な開発プラットフォーム用のプロジェクト テンプレートが含まれています。

 

AWS CodeStarサービスの主な利点は次の通りです:

  • Amazon EC2AWS Elastic Beanstalk、またはAWS Lambda用のテンプレートを使用して、5つの異なるプログラミング言語を使用して新しいプロジェクトを簡単に作成できます。 JavaScript、Java、Python、Ruby、およびPHPをサポートします。 テンプレートを選択すると、サービスはプロジェクトとアプリケーションに必要な基盤となるAWSサービスをプロビジョニングします。
  • ソフトウェアチーム全体に対するアクセスおよびセキュリティ ポリシー管理の統一されたエクスペリエンスを提供します。プロジェクトは、適切なIAMコントロール ポリシーで自動的に構成され、安全なアプリケーション環境を確保します。
  • コードのコミット、ビルドの結果、デプロイメント アクティビティなど、さまざまなアクティビティを追跡するための事前設定されたプロジェクト管理ダッシュボード。
    素早い立ち上げと実行に役立つ実行可能なサンプルコードは、Visual Studio、Eclipse、またはGitをサポートする任意のコード エディタなどのお好きなIDEで使用できます。
  • AWS CodeCommitAWS CodeBuildAWS CodePipeline、およびAWS CodeDeployを使用して、自動的に構成された各プロジェクトの継続的なデリバリ パイプライン。
  • CodeStarコンソールから課題管理とトラッキングを直接行えるAtlassian JIRA Softwareとの統合

 

AWS CodeStarによって、開発チームはソフトウェアのデプロイとバグ修正のスピードアップだけでなく、開発者が顧客の要望やニーズに一層合ったソフトウェアを構築できるようにするためのアジャイル ソフトウェア開発ワークフローを構築することができます。

 

AWS CodeStarを使用したレスポンシブな開発ワークフローの例を以下に示します:

CodeStarへの旅

 

AWS CodeStarサービスについて少し理解できたので、このサービスを使ってWebアプリケーションプロジェクトを設定しましょう。 まず、AWS CodeStar Consoleに行き、[Start a project]ボタンをクリックします。

適切なIAM権限を設定していない場合、AWS CodeStarはあなたのためにAWSリソースを管理する権限を要求するダイアログボックスを表示します。 [Yes、grant permissions]ボタンをクリックして、AWS CodeStarに他のAWSリソースへの適切な権限を与えます。

ところが、IAMユーザーに正しいポリシーを適用していないため、AWS CodeStarに対する管理者権限がないという警告が表示されました。 AWS CodeStarでプロジェクトを作成する場合は、IMSユーザーにAWSCodeStarFullAccess管理ポリシーを適用するか、すべてのAWSサービスに対して完全な権限を持つIAM管理ユーザーを持っている必要があります。

IAMで前述の権限を追加したので、このサービスを使ってプロジェクトを作成することができます。 単に [Create a new project]ボタンをクリックするだけで、AWS CodeStarサービスのハブに移動します。

この時点でソフトウェア開発のニーズに応じて、さまざまな環境を提供するために、20種類以上のAWS CodeStarプロジェクトテンプレートが用意されています。 各プロジェクトテンプレートは、プロジェクトの展開に使用されるAWSサービス、サポートされているプログラミング言語、実装されている開発ソリューションの種類の説明が記述されています。 AWS CodeStarは現在、Amazon EC2、AWS Lambda、AWS Elastic BeanstalkのAWSサービスをサポートしています。 これらのプロジェクト テンプレートは、あらかじめ設定されたAWS CloudFormationテンプレートを使用して、ボタンをクリックするだけで、マイクロサービス、Alexaスキル、Webアプリケーションなどのソフトウェア開発プロジェクトを作成できます。

私の最初のAWS CodeStarプロジェクトでは、Node.js / AWS Lambdaプロジェクトテンプレートを使用して、Node.jsとAWS Lambdaを使用してサーバーレスWebアプリケーションを構築しましょう。

このテンプレートによってAWS CodeStarがAWS CodeBuild、AWS CloudFormation、Amazon CloudWatchなどのサービスと連携するAWS CodePipelineを含む、開発プロジェクトに必要なすべてのツールとサービスを設定することに気づくでしょう。 新しいAWS CodeStarプロジェクトの名前をTaraWebProjectにして、Create Projectをクリックします。

ここではAWS CodeStarを初めて作成したので、AWS CodeStarのユーザー設定について質問するダイアログが表示されます。 表示名のテキストボックスにTaraと入力し、メールテキストボックスに自分のメールアドレスを追加します。 この情報は、プロジェクトの他のメンバーにどのように表示されるかを示しています。

次に、プロジェクトコードの編集方法を選択します。 Visual Studio IDEを使用してTaraWebProjectプロジェクトコードを編集することに決めました。 Visual Studioでは、プロジェクトコードの編集中にAWS Toolkit for Visual Studio 2015を使用してAWSリソースにアクセスするように設定することがポイントです。 この画面では、AWS CodeStarがプロジェクト用に設定したAWS CodeCommit Gitリポジトリへのリンクも表示されます。

ソフトウェア開発プロジェクトのプロビジョニングとツールのセットアップが完了しました。 私のソフトウェアプロジェクトであるTaraWebProjectのAWS CodeStarダッシュボードを提示されているので、プロジェクトのリソースを管理することができます。 これには、コードのコミット、チームメンバーシップとwiki、継続的なデリバリ パイプライン、Jiraの課題トラッキング、プロジェクトステータス、およびその他の適用可能なプロジェクトリソースなどのリソース管理が含まれます。

AWS CodeStarが本当にすばらしいのは、サーバレスWebアプリケーションの開発を開始できる実用的なサンプルプロジェクトを提供することです。 私の新しいWebアプリケーションのサンプルを見るには、ダッシュボードのApplication endpointsセクションに行き、提供されたリンクをクリックします。

新しいブラウザウィンドウが開き、開発を開始するためにAWS CodeStarが生成したサンプルWebアプリケーションが表示されます。サンプルアプリケーションのクールな機能は、サンプルアプリのバックグラウンドが時刻に基づいて色が変わることです。

サンプルWebサイトの構築に使用したコードを見てみましょう。 コードを表示するには、AWS CodeStarコンソールのTaraWebProjectダッシュボードに戻り、サイドバーメニューからCodeオプションを選択します。

AWS CodeCommitコンソールのtarawebproject Gitリポジトリに移動します。 ここから自分のWebアプリケーションのコード、リポジトリで行われたコミット、コミットやブランチの比較、リポジトリのイベントに応じたトリガーの作成を手動で行うことができます。

これによりAWSでホストされているWebアプリケーションの開発を開始することができます。 AWS CodeStarをVisual Studioに統合したので、コードを変更するためにIDEを使用してWebアプリケーションを更新することができます。これによってプロビジョニングされたコード リポジトリにコミットするたびにTaraWebProjectに含まれるコードを毎回自動的更新できます。

AWS CodeStarのTaraWebProjectダッシュボードには、コードを操作するためにツールをプロジェクト リポジトリに接続していますというメッセージがあります。 Visual StudioをIDEとして既に選択していますが、Connect ToolsボタンをクリックしてこのIDEに接続する手順を確認してみましょう。

再度、どのIDEを選択するかを選択できる画面を参照します。 Visual Studio、Eclipse、またはコマンドライン ツールがプロジェクト コードの編集に使用できます。 開発プロジェクトの作業中はいつでもIDEの選択肢を変更するオプションがあることが重要です。 さらに、HTTPSとSSH経由のGitでAWS CodeCommitリポジトリに接続できます。 各プロトコルの適切なリポジトリURLを取得するには、Code repository URLドロップダウンを選択してHTTPSまたはSSHを選択し、結果のURLをテキストフィールドから単にコピーするだけです。

Visual Studioを選択した後、CodeStarはVisual Studioとの統合に必要な手順に進みます。 これには、Visual Studio用のAWS Toolkitのダウンロード、Team ExplorerをAWS CodeCommitを介してAWS CodeStarに接続すること、および変更をリポジトリにプッシュする方法が含まれます。

Visual StudioをAWS CodeStarプロジェクトに正しく接続したら、AWS CodeStar TaraWebProject CodeStarダッシュボードに戻り、Webアプリケーションで作業しているチームメンバーの管理を開始します。 Setup your teamを選択して、プロジェクトチームページに行くことができます。

私のTaraWebProjectプロジェクトチームページでは、Add team member ボタンを選択し Select userドロップダウンをクリックして、チームメンバーのJeffを追加します。 チームメンバーは自分のアカウントのIAMユーザーでなければならないので、JeffのIAMアカウントを作成するには、Create new IAM userリンクをクリックします。

Create IAM user ダイアログボックスが表示されたら、チームメンバー(この場合はJeff Barr)のIAMユーザー名、表示名、電子メールアドレスを入力します。 Jeffに付与できるプロジェクトロールには、所有者、コントリビュータ、ビューアの3種類があります。 TaraWebProjectアプリケーションでは、Contributor プロジェクト ロールを付与し、Remote accessチェックボックスをオンにしてリモートアクセスできるようにします。 ここでは、[Create]ボタンをクリックしてJeffのIAMユーザーアカウントを作成します。

これにより、新しいIAMユーザーの作成を確認するIAMコンソールが表示されます。 IAMユーザー情報と許可されたアクセス許可を確認した後、[Create user]ボタンをクリックして、TaraWebProject用のJeffのIAMユーザーアカウントの作成を完了します。

Jeffのアカウントを正常に作成したら、Jeffのログイン資格情報を電子メールで送信するか、credentials.csvファイルをダウンロードすることが重要です。これらの資格情報を再度取得することはできません。 現在のログイン資格情報を取得せずにこのページを終了すると、Jeffの新しい資格情報を生成する必要があります。 [Close]ボタンをクリックすると、AWS CodeStarコンソールに戻ります。

JeffBarr-WebDev IAMロールを選択し、[Add]ボタンをクリックすることで、TaraWebProjectのチームメンバーとしてJeffを追加することができます。


私はジェフをAWS CodeStarプロジェクトのチームメンバーとして追加し、Webアプリケーションを構築する際にTaraWebProjectのチームコラボレーションを可能にしました。

私がAWS CodeStarサービスを本当に気に入っているのは、TaraWebProjectダッシュボードから自分のプロジェクトのすべてのアクティビティを監視できるからです。 アプリケーションのアクティビティや最近のコードのコミットを見ることができ、ビルドの結果、コードの変更、展開などのプロジェクトアクションの状態を1つの包括的なダッシュボードで追跡できます。 AWS CodeStarはダッシュボードのApplication activityセクションでAmazon CloudWatchと結びつけ、AWS CodePipelineに連携したContinious Deploymentセクションでビルドとデプロイメントのステータスに関するデータを提供し、Commit HistoryセクションでAWS CodeCommitのの最新のGit コードのコミットを表示します。


まとめ

AWS CodeStarサービスの旅で、AWSサービスを使用してTaraWebProjectソフトウェアプロジェクトのコーディング、ビルド、テスト、デプロイメント用に開発ツールチェーン全体をプロビジョニングしたサーバーレスWebアプリケーションを作成しました。 驚くべきことに、私はアプリケーションをリリースする日々のソフトウェア開発活動を管理するためのAWS CodeStarを使用するメリットについて、まださらっと表面をなめただけです。

AWS CodeStarを使用すると、AWS上でアプリケーションを迅速に開発、構築、および展開できます。 AWS CodeStarは、統一されたユーザーインターフェースを提供し、ソフトウェア開発活動を1か所で簡単に管理できるようにします。 AWS CodeStarでは、さまざまなテンプレートからAWS LambdaAmazon EC2AWS Elastic Beanstalkを使用してプロジェクトを設定することができます。 AWS CodeCommitAWS CodeBuildAWS CodePipeline、およびAWS CodeDeployを使用して、プロジェクト管理ダッシュボード、自動化された継続的デリバリ パイプライン、およびGitコードリポジトリが事前設定されており、開発者は最新のアジャイル ソフトウェア開発のベストプラクティスを実装できます。各AWS CodeStarプロジェクトは、Gitをサポートする一般的なIDEで使用できる実用的なコードサンプルを提供することにより、開発者に開発の最前線を提供します。加えてAWS CodeStarのAtlassian JIRA Softwareとの組み込みの統合機能によって、AWS CodeStarコンソールからダイレクトに連携するプロジェクト管理と課題追跡システムをソフトウェアチームに提供します。

AWS CodeStarサービスを使用して、AWSで新しいソフトウェア プロジェクトを開発することができます。 詳細については、AWS CodeStarの製品ページとAWS CodeStarのユーザーガイドのドキュメントを参照してください。
Tara

 

原文 New- Introducing AWS CodeStar – Quickly Develop, Build, and Deploy Applications on AWS (翻訳;SA 福井 厚)

AWS CodePipeline, AWS CodeBuild, Amazon ECR, AWS CloudFormationを利用したAmazon ECSへの継続的デプロイメント

同僚のJohn PignataがAmazon ECSに対する継続的デプロイメントパイプライン作成方法について素晴らしいブログを書いてくれました。

今日のビジネス環境では、新しいソフトウェアの反復を高速で提供することは競合に対するアドバンテージになります。企業がイノベーションを顧客に提供するスピード、変化する市場に適応するスピードは、ますます成功と失敗の違いを生む重要な要素になっています。

AWSは、企業がアプリケーションやサービスを高速に提供する組織の能力を向上させるDevOpsと呼ばれる文化哲学、実践、ツールの組み合わせを企業が採用できるように設計された一連の柔軟なサービスを提供します。

このポストでは、継続的デプロイメントと呼ばれるデプロイの実行方法について説明し、AWS CodePipeline、 AWS CodeBuild、および AWS CloudFormationを使用してAmazon ECS上のDockerコンテナとして提供されるアプリケーションの自動デプロイメントパイプラインを実装するためのリファレンスアーキテクチャの概要を説明します。

継続的デプロイメントとは?

俊敏性は、ITリソースのトラディショナルな提供方法に比べてクラウドコンピューティングが持つ重要な利点としてよく引用されています。他の部門が新しいサーバーをプロビジョニングするのに数週間か数ヶ月待つ代わりに、開発者はシングルクリックやAPIコールで新しいインスタンスを作成することができ、数分で使用開始することができます。この新たな速度と自律性は、開発者が新しい製品や機能を試し、できるだけ早く顧客に提供するこを可能にします。

製品の市場投入期間を短縮し、コードの品質を向上させ、より信頼性の高い製品やサービスのリリースを実現するために、開発チームはクラウド上でDevOpsの実践を採用しています。 継続的デプロイは、新しいソフトウェアリビジョンが自動的にビルドされ、テストされ、パッケージ化され、本番環境にリリースされる、DevOpsの実践です。

継続的デプロイにより、開発者は完全に自動化されたソフトウェアリリースプロセスを通じて機能や修正を出荷できます。開発者は、数週間や数ヶ月にわたる大規模なリリースをバッチ処理し、手動で展開する代わりに、新しいソフトウェアリビジョンが準備され次第、自動化されたプロセスを使用してアプリケーションのバージョンを1日に何回も配信することができます。クラウドコンピューティングがリソースの調達期間を短縮するのと同様に、継続的デプロイは新しいソフトウェアのリリースサイクルを数週間~数ヶ月から数分間に短縮します。

このスピードと敏捷性を活用することには、次のような多くの利点があります。

  • 新機能やバグ修正を迅速にすることができる :  ソースコードリポジトリに置いてあるコードは、ビジネス価値をもたらしたり、顧客に利益をもたらすものではありません。新しいソフトウェアリビジョンをできるだけ早くリリースすることで、顧客はより迅速に利益を享受できるようになり、チームはより集中的なフィードバックを得ることができます。
  • 変更セットが小さくなる : 大きな変更セットは、問題、バグ、およびその他の退化の根本原因を突き止める際に問題を引き起こします。より小さな変更セットを頻繁にリリースすることで、チームは発生した問題をより簡単に特定して修正することができます。
  • 自働デプロイによりベストプラクティが促進される : ソースコードリポジトリにコミットされた変更は即座に自動プロセスによってデプロイすることができるため、チームはその変更が十分にテストされ、運用環境が厳重に監視されていることを確実にする必要があります。

継続的デプロイはどのように動くのか?

継続的デプロイは、ソフトウェアのリリースに関連する活動を調整する自動化されたパイプラインによって実行され、プロセスの可視性を提供します。プロセスの最中に、リリース可能な成果物が構築され、テストされ、パッケージ化され、本番環境にデプロイされます。リリース可能な成果物には、実行可能ファイル、スクリプトファイルのパッケージ、コンテナ、または最終的にプロダクションに配信されなければならないその他のコンポーネントが含まれます。

AWS CodePipelineは、新しいソフトウェアリビジョンができるたびにコードのビルド、テスト、およびデプロイを実行する継続的デプロイおよび継続的デリバリーのサービスです。 CodePipelineは、コード変更の統合、可視化を行い、ワークフローを介して最終的にユーザーの提供します。このパイプラインは、ソースコードリポジトリからのコード取得、ソースコードのビルド、テスト、および本番環境へのデプロイといったステージを定義し、これらのステージが順番に実行されること、障害が発生した場合には停止することを保証します。

CodePipelineはデリバリパイプラインを強化し、プロセスを統合しますが、ソフトウェア自体をビルドまたはテストする機能はありません。このステージでは、CodePipelineは、フルマネージドのビルドサービスであるAWS CodeBuildなど、いくつかのツールと統合されます。 CodeBuildはソースコードをコンパイルし、テストを実行し、デプロイする準備が整ったソフトウェアパッケージを生成します。このサービスは継続的なデプロイパイプラインの構築とテストに最適です。CodeBuildはDockerコンテナのビルドを含む多くの異なる種類のビルド環境をネイティブサポートしています。

コンテナは、予測可能で再現可能な環境を実現し、ある環境でテストされた変更が正常に展開できるという高いレベルの信頼性を提供するため、ソフトウェア提供の強力なメカニズムです。 AWSは、Dockerコンテナイメージを実行・管理するためのいくつかのサービスを提供しています。 Amazon ECSは、非常に高い拡張性とパフォーマンスを持つコンテナ管理サービスで、Amazon EC2インスタンスのクラスタ上でアプリケーションの実行環境を提供します。  Amazon ECRは、フルマネージドのDockerコンテナレジストリで、開発者は簡単にDockerコンテナイメージの格納、管理、およびデプロイが可能です。

最後に、CodePipelineはデプロイメントを容易にするために、AWS Elastic Beanstalk、AWS CodeDeploy、AWS OpsWorksや、AWS LambdaまたはAWS CloudFormationを使用した独自のカスタムデプロイメントコードやデプロイプロセスなど、いくつかのサービスと統合されます。これらのデプロイアクションを使用してパイプラインの最後に新しく構築された変更を本番環境にプッシュすることができます。

Amazon ECSへの継続的デプロイ

これらのコンポーネントを組み合わせて、Dockerアプリケーションの継続的なデプロイパイプラインをECSに提供するためのリファレンスアーキテクチャを次に示します。

このアーキテクチャーは、CodePipelineを使用してECSおよびECRにコンテナをデプロイし、AWS上でフルマネージドの継続的デプロイパイプラインを構築する方法を示しています。この継続的デプロイのアプローチは、完全にサーバーレスであり、ソフトウェアの統合、ビルド、およびデプロイにマネージドサービスを使用します。

リファレンスアーキテクチャで作成されたパイプラインは、次のようになります。

このポストでは、このリファレンスアーキテクチャの各ステージについて説明します。開発者がランディングページの原稿を変更し、その変更をソースコードリポジトリにプッシュするとどうなるでしょう?

まず、Source ステージでは、ソースコードリポジトリシステムにアクセスするための詳細がパイプラインに設定されます。リファレンスアーキテクチャでは、GitHubリポジトリにホストされているサンプルアプリケーションがあります。 CodePipelineはこのリポジトリをポーリングし、新しいコミットごとに新しいパイプラインを実行開始します。 GitHubに加えて、CodePipelineは、AWS CodeCommitのGitリポジトリやAmazon S3に格納されたバージョン管理されたオブジェクトなどのソースロケーションもサポートしています。新しいビルドはそれぞれソースコードリポジトリから取得され、zipファイルとしてパッケージ化され、S3に格納され、パイプラインの次のステージに送られます。

Sourceステージでは、Amazon S3に格納されているテンプレートも定義されます。これは、アプリケーションのビルドが成功した後に、デプロイメントステージで使用されるデプロイメント環境を定義するテンプレートです。

Build ステージではCodeBuildを使用して、最新のソースコードに基づいて新しいDockerコンテナイメージを作成し、ECRリポジトリにプッシュします。 CodePipelineは、Jenkins、CloudBees、Solano CI、TeamCityなどのサードパーティのビルドシステムとも統合されています。

最後に、DeployステージではCloudFormationを使用して、新しく作成されたDockerコンテナイメージを指す新しいタスク定義リビジョンを作成し、新しいタスク定義リビジョンを使用するためにECSサービスを更新しています。こうすることで、ECSは新しいDockerコンテナをECRから取得し、サービスを再起動することによってデプロイを開始します。

パイプラインのステージがすべてグリーンになったら、Webブラウザでアプリケーションをリロードして、開発者の原稿の変更を本番環境で確認することができます。これは人手での作業は何もしなくても自動的に実行されます。

このパイプラインはすでにプロダクション状態であり、ソースコードリポジトリから新しいコードを取得し、チームがプロダクションにプッシュする将来の変更を出荷する用意ができています。また、拡張可能なので、新しいステップを追加して追加のステージを含めることもできます。たとえば、新しいコードリビジョンが本番環境に安全にデプロイされることを確認するために、テストステージを組み込んでユニットテストと受入テストを実行することができます。デプロイ後、新しいバージョンが稼動したことおよび、本番環境にデプロイされた変更セットの詳細について、電子メールまたはSlackチャンネルでチームにアラートを送るための通知ステップも追加することができます。

最後に

私たちはこのアプローチを使用してあなた方がどのような種類のアプリケーションをユーザーに提供できるのか、またそれが製品開発プロセスにどのような影響を及ぼすのかを見せていただけることを楽しみにしています。クラウドは俊敏性において大きなメリットを発揮し、継続的デプロイなどの技術を実装する能力は、競争上の大きな利点を生み出します。

GitHub上のAWS Labs EC2 Container Service – Reference Architecture: Continuous Deploymentリポジトリには、独自の継続的デプロイパイプラインを起動するために必要なすべてのものを含むAWS CloudFormationテンプレートがあります。

ご質問、ご意見、ご提案がありましたら是非お知らせください!

(翻訳はSA千葉が担当しました。原文はこちら)

AWS 開発者用ツールのまとめ – CodeCommit、CodePipeline、CodeDeploy に追加した最近の機能強化

AWS 開発者用ツールは現代の DevOps を実施する上で役立ちます。概要については次をご覧ください (詳しくは「ソースコード管理やデプロイに使用できる新しい AWS ツール」を参照)。

AWS CodeCommit は完全マネージド型のソースコード管理サービスです。既存の Git ツールやワークフローを引き続き使用しながら、安全でスケーラビリティに優れたプライベート Git リポジトリをホストするために同サービスを使用できます (詳細は「Introduction to AWS CodeCommit」のビデオをご覧ください)。

AWS CodeDeployAmazon Elastic Compute Cloud (EC2) インスタンスやオンプレミスサーバーでコードのデプロイを自動化します。デプロイの間にダウンタイムを回避しながら、すばやくアプリケーションを更新することができます (詳細は「Introduction to AWS CodeDeploy」のビデオをご覧ください)。

AWS CodePipeline はリリースプロセスの効率化や自動化に使用することができる継続的配信サービスです。リポジトリ (CodeCommit または Git) でチェックインを行うと、ビルド、テスト、デプロイなどの操作が開始します (概要については「Introducing AWS CodePipeline」をご覧ください)。このビルドは CodeDeploy、AWS Elastic BeanstalkAWS OpsWorks のいずれかを使用して EC2 インスタンスまたはオンプレミスサーバーでデプロイすることができます。

こうしたサービスと既存のビルドやテストツールを組み合わせて使用することで、CodePipeline がまとめるエンドツーエンドソフトウェアのリリースパイプラインを作成することができます。

AWS は今年 Code* 製品に多数の機能強化を追加しました。今回は時期的にもそうした機能の概要をご説明するのにちょうど良い時期だろうと思い、このブログを公開することにしました。こうした機能強化の多くは開発者用ツールと AWS の他の部分を連携できるようにするので、今後もデプロイのプロセスを調整していくことが可能になります。

CodeCommit の機能強化
[codecommit_u] の新機能:

  • リポジトリトリガー
  • コードブラウジング
  • コミット履歴
  • コミットの可視化
  • Elastic Beanstalk の統合

リポジトリトリガー – リポジトリで変更があるたびに通知を送信したりコードを実行するリポジトリトリガーを作成することができます (これは場合によって webhooks と呼ばれることもあります — ユーザー定義の HTTP コールバック)。こうしたフックは開発のワークフローをカスタマイズしたり自動化することを可能にします。トピックまたは Lambda 関数を呼び出して Amazon Simple Notification Service (SNS) に通知を配信することもできます。

コードブラウジングコンソールでコードをブラウズすることができます。これにはソースコードのツリーとコードでのナビゲーションも含まれています。

コミット履歴 – リポジトリのコミット履歴を表示できます (私の場合はあまり動きがなかったため 2015 年の履歴が表示されています)。

コミットの可視化 – リポジトリのコミット履歴をグラフィカル表示にすることができます。

Elastic Beanstalk の統合Elastic Beanstalk を使用する CodeCommit リポジトリで、Elastic Beanstalk 環境で実施するデプロイ用のプロジェクトコードを保存できます。

CodeDeploy の機能強化
CodeDeploy の新機能:

  • CloudWatch イベントの統合
  • CloudWatch アラームと自動デプロイメントロールバック
  • プッシュ通知
  • 新しいパートナーの統合

CloudWatch イベントの統合 – インスタンスの状態または AWS Lambda 関数、Amazon Kinesis ストリーム、Amazon Simple Queue Service (SQS) キュー、SNS トピックのデプロイで起きた変更をストリームするように CloudWatch イベントを設定すると、デプロイで起きた変更を Amazon CloudWatch イベントで監視したり対応することができます。変更によりトリガーするワークフローやプロセスを構築することができます。デプロイに失敗した場合に EC2 インスタンスを自動的に終了させたり、Slack チャネルにメッセージをポストする Lambda 関数を呼び出すことができます。

CloudWatch アラームと自動デプロイメントロールバック – CloudWatch アラームは別の方法でデプロイ監視を可能にします。CodeDeploy で管理しているインスタンスまたは Auto Scaling グループのメトリックスを監視できるほか、決められた期間にしきい値を超えた場合は再起動、終了または復元することでデプロイを停止したり、インスタンスの状態を変更することができます。デプロイに失敗した場合や CloudWatch アラームへの対応として自動的にデプロイをロールバックすることもできます。

プッシュ通知 – デプロイに関するイベントについて Amazon SNS からプッシュ通知を受信し、デプロイの状態やプログレスを確認することができます。

新しいパートナーの統合 – AWS の CodeDeploy パートナーは AWS 製品と自社製品を連結できるように努めています。最近のリリース:

CodePipeline の機能強化
[codepipeline_u] の新機能:

  • AWS OpsWorks 統合
  • Lambda 関数のトリガー
  • 手動の承認アクション
  • コミット済み変更の情報
  • 新しいパートナーの統合

AWS OpsWorks 統合 – CodePipeline でモデルしたソフトウェアリリースパイプラインで AWS OpsWorks をデプロイプロバイダとして選択することができます。

[codepipeline_u] で [opsworks_u] を使用するように設定して、カスタム Chef cookbooks のレシピでコードをデプロイすることもできます。

Lambda 関数のトリガー – ソフトウェアリリースパイプラインの操作のひとつとして Lambda 関数をトリガーできるようになりました。Lambda では、ほぼすべてのタスク実行を可能にする関数を記述できるので、パイプラインを好きなようにカスタマイズすることができます。

手動承認アクション – ソフトウェアリリースパイプラインで手動承認アクションを追加できるようになりました。必要な IAM アクセス権限を持つ人物がコード変更を承認または拒否するまで実行が一時停止します。

コミット済み変更の情報 – ソフトウェアリリースパイプラインを経由するコードに対するコミット済み変更の情報を表示できるようになりました。

 

新しいパートナー統合 – AWS の CodePipeline パートナーは AWS 製品と自社製品を連結できるように努めています。最近のリリース:

新しいオンラインコンテンツ
最新の開発手法について皆さんにご理解いただけるように、いくつかの新しい入門用資料をご提供しています。

ご覧いただきありがとうございました。
今回は AWS の開発用ツールに新しく追加された機能概要をご紹介しました。いかがでしたか?

皆さんが継続的配信を実際に体験できるように、私の同僚が新たに Pipeline スターターキットを作成しました。このキットには、EC2 インスタンスを内部に含む VPC 作成のテンプレート、アプリケーションペア (各インスタンス用、CodeDeploy でデプロイ)、サンプルアプリケーションを構築してデプロイするパイプライン、その他必要な IAM サービスとインスタンスロールが含まれています。

Jeff;