Category: AWS .NET Development*


AWS Tools for Visual Studio Team Servicesのご紹介

本日、Amazon Web Servicesは、AWS Tools for Microsoft Visual Studio Team Services(VSTS)を発表しました(訳注:原文のBlog記事は2017/8/15にポストされました)。 ツールは無料で使用することができ、Visual Studio Marketplaceで配布されます。 VSTS内とTeam Foundation Serverでホストされたビルドとリリースのパイプラインで、AWSサービスと対話するためにこれらのタスクを使用することができます。 例えばタスクを利用してAmazon S3バケットとの間でコンテンツをコピーしたり、パイプラインにタスクを追加してAWS Elastic BeanstalkAWS CodeDeploy、またはAWS Lambdaにビルド出力をデプロイしたりすることができます。 ツールはオープンソースとして提供されGitHubで公開されています。

この記事では、ツールのインストール方法、中に含まれるタスクの概要、セットアップを検証するための簡単なシナリオを実行し、いかに簡単に使使えるかを見ていきます。 後続の記事では、タスクの詳細とVSTSパイプラインでの使用方法について詳しく説明する予定です。

 

インストール

AWS Tools for Microsoft Visual Studio Team Servicesのインストールは素早くて簡単です! 最初にVisual Studio Marketplaceにアクセスしてください。 以下に示すように、ツールをインストールするには2つのオプションがあります。 オンラインのVSTSアカウントにインストールするか、ツールをダウンロードしてオンプレミスのTeam Foundation Serverインスタンスにインストールすることができます。

やることはこれだけです! これでこの拡張機能のタスクは、アカウントまたはオンプレミスのインスタンスで使用できるようになりました。この最初のリリースで提供されているタスクを簡単に確認してみましょう。 先に述べたように、続く記事ではこれらのタスクのいくつかをより深く見ていくことになります。

  • AWS CloudFormation Create/Update Stack: このタスクでは、テンプレートファイルとオプションのパラメータファイルを使用して、AWS CloudFormationでスタックを作成または更新できます。 タスクはスタックがすでに存在するかどうかによって、既存のスタックを更新するか、新しいスタックを作成するかを自動的に切り替えます。 どちらの「モード」かを選択する必要はないため、パイプラインでの使用が便利です。 テンプレートとパラメータファイルを選択するだけでなく、変更セットを使用してスタックを作成または更新することも、変更セットを自動的に実行するオプションを追加することもできます(正常に検証された場合)。 また「Execute Change Set」タスクを使用して、後から有効な変更セットを実行することもできます。
  • AWS CloudFormation Delete Stack: このタスクは名前またはIDで識別されるスタックを削除します。 新規のデプロイメントに伴う破壊と再構築のシナリオで、開発環境やテスト環境のスタックをクリーンアップするのに使用することができます。
  • AWS CloudFormation Execute Change Set:前述のように、「Create/Update Stack」タスクでは、変更セットを使用して変更を実行するオプションが提供され、セットが有効であればすぐに実行するか、またはこのタスクを後で使用して変更を実行できます。 変更セットと関連するスタックの名前を提供するとタスクが残りの処理を行いスタックが作成または更新の完了ステータスに達するのを待ちます。
  • AWS Elastic Beanstalk Deployment:このタスクを使用してWebDeployアーカイブを使用して従来のASP.NETアプリケーションをデプロイしたり、ASP.NET Coreアプリケーションをデプロイしたりすることができます。
  • AWS Lambda .NET Core Deployment:このタスクでは、スタンドアロンの関数またはサーバレスアプリケーションをAWS Lambdaにデプロイすることができます。 このタスクはAWS Visual Studio Toolkitと同じdotnet CLI拡張を使用するため、タスク内で使用可能なコマンドラインツールスイッチの完全なカスタマイズ機能が利用できます。
  • AWS Lambda Invoke Function:AWS Lambdaにデプロイすることに加えて、このタスクを使用してパイプライン内からLambda関数を実行するようにします。 関数の結果はパイプライン内の次のタスクが利用する変数に出力することができます。
  • AWS S3 Download:バケット名とオプションのキープレフィックスの組み合わせを使用して、このタスクは1つ以上のglobパターンのセットを使用して、Amazon S3バケットからパイプラインの作業フォルダにコンテンツをダウンロードできるようにします。 たとえばこれを使用してカスタムな静的コン テンツをビルドに挿入することができます。
  • AWS S3 Upload:AWS S3 Downloadタスクと同様に、このタスクではパイプラインの作業フォルダからバケットにコンテンツをアップロードするために、ソースフォルダ内で実行されるバケット名とglobパターンの組み合わせを取ります。
  • AWS Tools for Windows PowerShell Script:このタスクでは、Tools for Windows PowerShell(AWSPowerShell)モジュールのコマンドレットを使用するスクリプトを実行し、必要に応じてスクリプトを実行する前にモジュールをインストールします。
  • AWS CLI:このタスクでは、個々のAWS CLIコマンドを実行できます。 ただし、ビルドホストにAWS CLIをすでにインストールしている必要があります。

 

タスクの設定と利用

リリースに含まれるタスクについて少し理解できたので、パイプラインでAWS S3 Uploadタスクを使用する方法を簡単に見ていきましょう。 これはまたツールの設定の検証と、タスクに対する資格情報がどのように扱われるかを理解することにも繋がります。

このチュートリアルでは、ビルドおよび/またはデプロイするアーティファクトをフェッチする既存のビルドまたはリリース定義があると仮定しています。 ここでは単純に新しいタスクをパイプラインの最後に追加し、S3バケットにビルド済みまたはデプロイ可能な成果物をアップロードするように設定します。 先に進み使用するビルド定義を選択するか新しいビルド定義を作成します。 定義を選択したり作成したりしたら定義を編集するオプションを選択します。

次のスクリーンショットの例では、ASP.NET Coreプロジェクトの新しいビルド定義を作成することを選択しました。 リストされているタスクにはデフォルト値が割り当てられています。

1.  パイプラインにS3 Uploadタスクを追加
このチュートリアルでは、Publishタスクによって生成されたビルド出力を取得し、Amazon S3にアップロードします。 したがって既存のPublishとPublich Artifactsタスクの間に新しいタスクを挿入します。 これを行うには、[Add Task]を選択します。 右側のパネルで使用可能なタスクを利用可能なAWSタスクが現れるまでスクロールし、AWS S3 Uploadを指定します。そして「Add」を選択してビルド定義に追加します。

Publishタスクの直後に新しいタスクが追加されていない場合はそのタスクを所定の位置にドラッグします。 それから設定を開始します。

 

2. タスクの資格情報を設定

Amazon S3などのAWSサービスのリクエストを行うタスクでは認証情報を設定する必要があります。 Team Systemsの用語では、これらをサービスエンドポイントと呼びます。 AWSタスクは資格情報を提供できるようにAWSという名前のサービスエンドポイントタイプを提供します。 このタスクの資格情報をすばやく追加するには、AWS Credential ボックスの右側にある[+]アイコンをクリックします。

歯車のアイコンをクリックすると新しいブラウザページが開き、すべてのサービスエンドポイント(新しいAWSタイプを含む)を管理できます。 タスクで使用するために複数のAWS資格情報セットを設定する場合はこれを行います。

「+」アイコンをクリックすると、AWSキーを入力できるポップアップウィンドウが表示されます。

AWS CLIやAWS modules for PowerShellのようなAWS SDKやツールを使用するのに慣れているなら、ここでのオプションに慣れているかもしれません。それらのSDKやツールと同じように基本的にはAWSの認証情報を構築します。プロファイルには名前(この場合はConnection nameに入力された値)があり、これをタスク設定でこの資格情報のセットを参照するために使用します。 次に使用する認証情報のアクセスキーとシークレットキーを入力し後で利用するための名前を割り当て[OK]をクリックして保存します。 ポップアップが閉じ新しい資格情報が事前に選択されたS3 Uploadタスク設定に戻ります。

他のタスクで入力した資格情報を再利用することができます。 設定しているタスクの[AWS Credentials]リストで、資格情報を識別するために使用した名前を選択するだけです。

 

注意:

アカウントのルート資格情報を使用することはお勧めしません。 代わりに、1つ以上のIAMユーザーを作成し、それらの資格情報を使用します。 詳細については、「AWSアクセスキーを管理するためのベストプラクティス」を参照してください。

 

3. タスクオプションの設定

資格情報を設定して選択することで、タスク設定を完了できます。

  • us-east-1、us-west-2などバケットが存在する(または作成する)リージョンを設定します。
  • バケットの名前を入力します(バケット名はグローバルに一意でなければなりません)。
  • Source Folderは、アップロードするコンテンツを含むビルドエリア内のフォルダを指します。 Team Servicesにはハードコードされたパスを避けるために使用できるいくつかの変数が用意されています。このチュートリアルでは、Build.ArtifactStagingDirectoryという変数を使用することを選択します。これは、デプロイ先にプッシュされる前にアーティファクトがコピーされるエージェント上のローカルパスです。 完璧ですね!
  • Filename Patternsには、アップロードのためにソースフォルダの下のファイルを選択するために使用される1つ以上のglobパターンを含めることができます。 ここに示すデフォルトの値は、すべてのファイルを再帰的に選択します。複数のパターンを1行ごとに指定できます。 このチュートリアルでは、前のタスク(パブリッシュ)がビルドした結果を含むzipファイルを出力します。 これがアップロードされるファイルになります。
  • Target Folderは、アップロードされたすべてのファイルに適用されるバケットのキープレフィックスです。 これはフォルダパスのように考えることができます。 値を指定しないと、ファイルはバケットのルートにアップロードされます。 デフォルトでは、相対的なフォルダ階層は保持されます。
  • 最後に、設定できる追加オプションがあります:
    • Create S3 Bucket if it does not exist:バケットを作成できない場合、タスクは失敗します。
    • Overwirte(アドバンスドセクション内): これはデフォルトで選択されています。
    • Flatten folders(アドバンスドセクション内):これにより、ソースフォルダを基準にした各ファイルのパスが削除され、すべてのファイルがターゲットフォルダに直接配置されます。

 

4. ビルドの実行

設定された新しいタスクで、ビルドを実行する準備が整いました。 Save & Queueを選択します。

ビルド中、タスクはメッセージをログに出力します。

まとめ

ご覧のとおり、新しいタスクの使用は簡単です。 今後の記事では、いくつかのデプロイメントタスクとその使用方法の詳細について説明します。 私たちは、新しいツールの登場によってあなたが私たちと同じようにワクワクしていることを願っています。そして、VSTS環境でツールが役立つことがわかるでしょう。 GitHubリポジトリにフィードバックを提供して、今後の開発を支援してください!

 

謝辞

これらの新しいツールをVisual Studio Marketplaceに導入する際に、Visual Studio ALM Rangersの支援を頂きました。Visual Studio ALM Rangersのサポートに感謝します。

 

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

AWSと.NET Core 2.0

昨日、.NET Core 2.0がリリースされ(訳注:このブログ記事の原文は2017/8/15に発行されています)、AWSでは .NET Coreプラットフォームに追加された新機能と完成度にとても興奮しています。今後数か月以内に、AWSサービスをアップデートして、.NET Core 2.0のファーストクラスのサポートを提供します。 2つの簡単な方法ですぐにAWS上で.NET Core 2.0を使い始めることができます。

 

AWS Elastic Beanstalkの利用

Elastic Beanstalkを使用すると、Webアプリケーションを簡単に展開できます。現在、.NET Frameworkおよび.NET Core 1.1がサポートされています。 Elastic Beanstalkプラットフォームは、すぐに.NET Core 2.0をサポートするように更新されるでしょう。 それまではデプロイメントパッケージをカスタマイズして、デプロイ中のインスタンスに.NET Core 2.0をインストールするようにBeanstalkに指示することができます。

ASP.NET CoreアプリケーションがBeanstalkにデプロイされると、AWS-windows-deployment-manifest.jsonというJSONマニフェストがツールキットによって作成され、Beanstalkにアプリケーションのデプロイ方法を指示します。 以前のブログ記事では、このマニフェストのカスタマイズ方法について説明しました。 この機能を使用して、デプロイ前にPowerShellスクリプトを実行して.NET Core 2.0をインストールすることができます。

最初のステップとして、ASP.NET Core 2.0プロジェクトにaws-windows-deployment-manifest.jsonというファイルを追加します。 aws-windows-deployment-manifest.jsonのプロパティウィンドウで、[Copy to Output Directory]フィールドを必ず[Copy Always]に設定してください。 このファイルは、通常、ツールキットによって生成されますが、ツールキットがファイルがすでに存在することが判明した場合は、代わりにデプロイメントウィザードで指定された設定で既存のファイルを変更します。

 

次に、下の内容をコピーしてaws-windows-deployment-manifest.jsonに貼り付けます。 これはASP.NET Coreアプリケーションをデプロイし、デプロイの前に./Scripts/installnetcore20.ps1 PowerShellスクリプトを実行することを示しています。

 

{
  "manifestVersion": 1,
  "deployments": {

    "aspNetCoreWeb": [
      {
        "name": "app",
        "parameters": {
          "appBundle": ".",
          "iisPath": "/",
          "iisWebSite": "Default Web Site"
        },
        "scripts": {
          "preInstall": {
            "file": "./Scripts/installnetcore20.ps1"
          }
        }
      }
    ]
  }
}

PowerShellスクリプトを追加するためのマニフェストを追加しました。 ASP.NET Coreプロジェクトに./Scripts/installnetcore20.ps1ファイルを追加します。 再度、[Copy to Output Directory]フィールドを[Copy Always]に設定して、デプロイメントパッケージに追加されていることを確認してください。 以下のスクリプトは、.NET Core 2.0インストーラをダウンロードし、インストーラを実行します。

 

$localPath = 'C:\dotnet-sdk-2.0.0-win-x64.exe'

if(!(Test-Path $localPath))
{
    Invoke-WebRequest -Uri 'https://download.microsoft.com/download/0/F/D/0FD852A4-7EA1-4E2A-983A-0484AC19B92C/dotnet-sdk-2.0.0-win-x64.exe' -OutFile $localPath
    & $localPath /quiet /log c:\InstallNetCore20.log
}

 

このスクリプトでは、Microsoftの公式リンクから.NET Core 2.0をダウンロードしています。 デプロイ中のダウンロードを高速化し、リンクの変更の影響を受けないようにするために、.NET Core 2.0インストレーションをElastic Beanstalk環境と同じリージョンにあるAmazon S3バケットにコピーすることをお勧めします。

デプロイメントマニフェストのカスタマイズにより、ASP .NET Core 2.0アプリケーションをElastic Beanstalkに簡単にデプロイできます。

 

Dockerベース サービスの利用

Amazon EC2 Container ServiceやAWS CodeBuildなどのDockerコンテナを実行するDockerベースのサービスについては、Docker Hubに発行されたDockerイメージを使用してすぐに開始できます。 たとえばコンソールでAWS CodeBuildプロジェクトを設定するときに、Docker HubからカスタムのDockerイメージを指定することができます。

 


.NET Core Dockerイメージの詳細については、GitHubリポジトリを参照してください。 AWSでDockerコンテナを実行する方法の詳細については、「Amazon ECS入門」を参照してください。

 

AWS SDK for .NET

.NET Core 2.0は.NET Standard 2.0をサポートしています。つまり、.NET Standard 2.0とそれ以下を対象とするNuGetパッケージは.NET Core 2.0でサポートされています。 AWS SDK for .NETは.NET Standard 1.3をターゲットとしています。このことはつまり、.NET Core 1.xまたは.NET Core 2.0の両方で利用できることを意味しています。

 

結論

.NET Core 2.0とAWSについて最新の情報を入手するには、AWS .NET開発ブログをフォローし、Twitterで私たちのツイートを見つけてください

 
(日本語翻訳は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 福井が担当しました。原文はこちらです。)