Category: デベロッパーツール


LumberyardがGitHubで公開されました!

本日とてもエキサイティングなご報告をさせていただきます。LumberyardのソースがGitHubで公開されました。コミュニティーの皆様からの特に多いご要望の1つでしたが、ようやく実現でき大変嬉しいです。こちらのURL(www.github.com/aws/Lumberyard)をご確認ください。

ゲームを制作する事はチャレンジングですが、GitHubを活用することで2つの手法が容易になります。

 

LumberyardをGitHubから取得できます。

これまでは、Lumberyardを標準インストーラーからインストールする事がLumberyardを入手いただく唯一の方法で、ソースを含めたすべてのLumberyardが新たに別のディレクトリに保存されました。ですので継続的にLumberyardをアップグレードすることはうんざりする作業だったかもしれませんが、GitHubを活用することで劇的に変わります。

 

本日よりLumberyardソースコードをGitHubリポジトリから容易に直接取得して管理する事が可能となります。新たなバージョンのLumberyardをインテグレートすることも今までよりとてもシンプルな操作で可能です。そして、今後の新たなLumberyardのリリースは別々のブランチで提供されますので、任意のバージョンのインテグレートも可能となります。さらに!あなた自身のGitHubアカウントを作成してGitHubであなたのプロジェクトを管理したり、リモートリポジトリであなたのチームとの共同作業も容易にできるようになります。

Lumberyardの改良やバグ修正を送っていただく事も可能です。

これまでは、Lumberyardの開発者は最大50行までのLumberyardのコードをフォーラムを通して送っていただく事が可能でしたが、簡易な修正にしか適用できませんでした。(このような状況にもかかわらず、これまで修正を送っていただいた皆様に御礼を申し上げます!)本日より、GitHubを活用することで、どのようなサイズの改良やバグ修正でも容易にLumberyardチームに送っていただく事が可能となります。プルリクエストにより、必要となるコードを複数のファイルにまたがるような場合でも、正確な方法で管理できます。皆様からのフィードバックとサポートは我々を突き動かす大きな要因で、皆様とともにこのエンジンを創り上げていける事はとてもエキサイティングです。

メインブランチで安定したLumberyardを提供し続けていく事は我々にとってとても重要ですので、プルリクエストがすぐにはマージされるわけではなく、承認された変更は将来のリリースに反映される可能性があるということにご留意ください。継続的にプルリクエストは確認させていただきます。プルリクエストが採用されました皆様はリリースノートにクレジットさせていただきます!

もう一点、我々のリポジトリからフォークする事も可能です(詳しくはリポジトリ中のReadme.mdファイルをご参照ください)がLumberyardは引き続き「AWS Customer Agreement」と「Lumberyard Service Terms」の元にライセンスされております。この点にご留意いただければ公開リポジトリとすることも可能ですので、ログインせずに取得する事も可能となります。

いつでもお気軽にご意見をお聞かせください。今後の数ヶ月でScript Canvasや新たなアニメーションツール等さらにいくつかのエキサイティングな要素の提供も予定していますのでお見逃しなく!Lumberyardに関します様々な情報はチュートリアルやコミュニティフォーラム、さらにドキュメントからも得られます。

LumberyardのGitHub公開に関します詳細はこちら(www.github.com/aws/Lumberyard)をご参照ください。

本記事の作者について

Todd Gilbertsenは1980年台からゲームエンジンの制作、ビデオゲームだけでなく、様々なソフトウエア開発のプロフェッショナルとして活動を続けており、ゲーム開発者がクリエイティブに開発を進めるためのツールやテクノロジーの開発をする事に情熱を注いでおります。ToddはLumberyradのシニア・テクニカルプロダクトマネージャーです。

(翻訳は下田が担当しました。原文はこちら)

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

 

新機能 – AWS リソースのタグ付け API

AWS のお客様は、Amazon EC2 インスタンスAmazon EBS ボリュームAmazon S3 バケットなどのリソースを整理するためにタグをよく利用します。過去 2 年間、AWS ではタグ付けをより便利で強力なものにするために努めてきました。たとえば、Auto Scaling 時のタグ付け、リソースあたり最大 50 個のタグの使用、コンソールで作成する、共通のタグを共有するリソース (リソースグループとも呼ばれます)、タグの使用を強制する Config ルールを使用するオプションなど、さまざまな機能のサポートが追加されています。お客様は、何千というリソースを管理し、各リソースで最大 50 個ものタグを使用するようになると、タグ付けの作業を簡素化するためのツールやオプションが必要になります。この度、新しいリソースのタグ付け API が利用可能になりました。新しい API は、AWS SDKs または AWS Command Line Interface (CLI) から使用できます。これまでは AWS Management Console からのみアクセス可能であったリソースグループの同じオペレーションにプログラムからアクセスできるようになりました。

概要: コンソールベースのリソースグループのオペレーション
新しい API 関数について詳しく説明する前に、コンソールベースのグループ化およびタグ付けモデルを確認しておきましょう。複数のリージョンにまたがる検索機能を使用して AWS リソースを見つけてタグを付ける機能は、すでに利用できるようになっています。たとえば、次のようにリージョンの長いリストを選択して、各リージョンの EC2 インスタンスを検索できます。

すべての必要なリソースを見つけて選択したら、[Create a new tag key] をクリックして必要なタグキーを入力して、新しいタグキーを追加できます。

次に、各インスタンスの値を入力します (新しい [ProjectCode] 列)。

これで、P100 のタグが付いたすべてのリソースを含むリソースグループを作成できます。

リソースグループを作成したら、[Resource Groups] メニューをクリックしてすべてのリソースを見つけることができます。

この機能の詳細については、「Resource Groups and Tagging for AWS」を参照してください。

新しい、リソースのタグ付け API
今回発表された API を使用すると、リソースのタグ付け、タグ解除、タグを使用したリソースの検索のすべてをユーザーのコードから行うことができます。新しい API 関数を使うと、単一の関数セットで複数のリソースタイプを操作できるようになります。新しい関数は以下のとおりです。

TagResources – 最大 20 個のリソースにタグを一度に追加します。

UntagResources – 最大 20 個のリソースからタグを一度に削除します。

GetResources – リソースのリストを取得します。オプションとして、タグとリソースタイプのいずれかまたは両方でリソースをフィルタできます。

GetTagKeys – アカウントで使用されているすべての一意なタグキーのリストを取得します。

GetTagValues – 指定したタグキーのすべてのタグ値を取得します。これらの関数は、以下の AWS のサービスおよびリソースタイプをサポートしています。

AWS のサービス リソースタイプ
Amazon CloudFront ディストリビューション。
Amazon EC2 AMI、カスタマーゲートウェイ、DHCP オプション、EBS ボリューム、インスタンス、インターネットゲートウェイ、ネットワーク ACL、ネットワークインターフェイス、リザーブドインスタンス、リザーブドインスタンスのリスト、ルートテーブル、セキュリティグループ – EC2 Classic、セキュリティグループ – VPC、スナップショット、スポットバッチ、スポットインスタンスリクエスト、スポットインスタンス、サブネット、仮想プライベートゲートウェイ、VPC、VPN 接続。
Amazon ElastiCache クラスター、スナップショット。
Amazon Elastic File System ファイルシステム。
Amazon Elasticsearch Service ドメイン。
Amazon EMR クラスター。
Amazon Glacier ボールト。
Amazon Inspector 評価。
Amazon Kinesis ストリーム。
Amazon Machine Learning バッチ予測、データソース、評価、ML モデル。
Amazon Redshift クラスター。
Amazon Relational Database Service DB Instance、DB オプショングループ、DB パラメータグループ、DB セキュリティグループ、DB スナップショット、DB サブネットグループ、イベントサブスクリプション、リードレプリカ、リザーブド DB インスタンス。
Amazon Route 53 ドメイン、ヘルスチェック、ホストゾーン。
Amazon S3 バケット。
Amazon WorkSpaces WorkSpace。
AWS Certificate Manager 証明書。
AWS CloudHSM HSM。
AWS Directory Service ディレクトリ。
AWS Storage Gateway ゲートウェイ、仮想テープ、ボリューム。
Elastic Load Balancing ロードバランサー、ターゲットグループ

 

主要事項
以下は、新しい API 関数または同等の CLI コマンドを使用するコードの構築やスクリプトの記述を行う際の留意事項です。

互換性 – 古いサービス固有の関数は利用可能であり、引き続き使用できます。

書き込み権限 – 新しいタグ付け API は、AWS のサービス別の固有な既存ポリシーに別の権限を追加します。たとえば、EC2 インスタンスにタグを追加するには、 tag:tagResourcesEC2:createTags へのアクセス権が必要です。

読み取り権限 – タグとタグ値にアクセスする関数を呼び出すには、 tag:GetResourcestag:GetTagKeys、および tag:GetTagValues へのアクセス権が必要です。

料金 – これらの関数やタグの使用に伴う課金はありません。

今すぐ利用可能
新しい関数は最新バージョンの AWS SDKs でサポートされています。新しい関数を使用して、すべての商用の AWS リージョンでリソースにタグを付けて利用できます。

Jeff;

AWS LambdaのC#サポートの発表

本日、AWS Lambdaのサポート言語としてC#を発表しました。新しいオープンソースの.NET Core 1.0ランタイムを使用すると、さまざまな一般的な.NETツールからC#コードをAWS Lambdaに簡単に公開できます。 .NET開発者は、C#言語と使い慣れた.NETツールを使用して、Lambda関数とサーバーレス アプリケーションを作成できます。 Visual Studio、Yeoman、およびdotnet CLIにおけるツール サポートによって、C#で記述された個々のLambda関数またはサーバーレスアプリケーション全体をLambdaおよび Amazon API Gatewayに簡単に展開できます。

LambdaAWSサーバーレスプラットフォームの中核です。もともと2015年に発売されたLambdaでは、インフラストラクチャやスケーリングを心配することなく、Node.jsPython、およびJavaコードをAWSに展開することができます。これにより、開発者はアプリケーションのビジネスロジックに集中でき、インフラストラクチャの維持と拡張に時間を費やす必要がありません。今日まで、.NET開発者はこのモデルを利用することができませんでした。サポートされている言語のリストにC#を追加し、サーバーレスアプリケーションを作成すためにLambdaAPIゲートウェイを利用する新しいカテゴリの開発者ができたことを嬉しく思っています。

 

C#でのLambda

単純なC#ラムダ関数を見てください。 既にNode.js、Python、JavaでLambdaを使っていたなら、これはよく分かるはずです:

using System;
using System.IO;
using System.Text;

using Amazon.Lambda.Core;
using Amazon.Lambda.DynamoDBEvents;
using Amazon.Lambda.Serialization.Json;

namespace DynamoDBStreams
{
    public class DdbSample
    {
        private static readonly JsonSerializer _jsonSerializer = new JsonSerializer();

        [LambdaSerializer(typeof(JsonSerializer))]
        public void ProcessDynamoEvent(DynamoDBEvent dynamoEvent)
        {
            Console.WriteLine($"Beginning to process {dynamoEvent.Records.Count} records...");

            foreach (var record in dynamoEvent.Records)
            {
                Console.WriteLine($"Event ID: {record.EventID}");
                Console.WriteLine($"Event Name: {record.EventName}");

                string streamRecordJson = SerializeObject(record.Dynamodb);
                Console.WriteLine($"DynamoDB Record:");
                Console.WriteLine(streamRecordJson);
            }

            Console.WriteLine("Stream processing complete.");
        }


        private string SerializeObject(object streamRecord)
        {
            using (var ms = new MemoryStream())
            {
                _jsonSerializer.Serialize(streamRecord, ms);
                return Encoding.UTF8.GetString(ms.ToArray());
            }
        }
    }
}

Lambdaでサポートされている他の言語と同様に、関数の入力と戻り値の型を扱うための選択肢がいくつかあります。最も基本的な選択は、System.IO.Streamの低レベルストリームインタフェースを使用することです。また、アプリケーションのアセンブリレベルまたはメソッドレベルでデフォルトのシリアライザを適用することも、Amazon.Lambda.Coreライブラリによって提供されるILambdaSerializerインターフェイスを実装することによって独自のシリアライゼーションロジックを定義することもできます。

ProcessDynamoEvent関数の関数シグネチャを見て、シグネチャ内のDynamoDBEventに注意してください。これは、Lambdaが提供するAmazon.Lambda.Coreライブラリと、他のAWSイベントタイプのためのさらに多くのクラスから来ています。このNuGetパッケージにプロジェクトの依存関係を追加すると、staticLambdaロガー、シリアライゼーション インターフェイス、およびLambdaコンテキストオブジェクトのC#実装にアクセスできます。

ロギングでは、C#Consoleクラス、Amazon.Lambda.Core.LambdaLoggerクラスのLogメソッド、またはコンテキストオブジェクトのLoggerプロパティによって提供される静的なWriteメソッドまたはWriteLineメソッドを使用できます。 C#プログラミングモデルの詳細については、「AWS Lambda開発者ガイド」を参照してください。

 

AWS Toolkit for Visual Studio

AWS Toolki for Visual Studio は、.NET Core Lambda関数とサーバーレスアプリケーションの開発、テスト、および展開をサポートします。 このツールキットには、容易に開発を始めるために、次の2つの新しいプロジェクトテンプレートが用意されています: AWS Lambda Projectテンプレートは、単一のCLambda関数を持つ単純なプロジェクトを作成します。 AWS Serverlessアプリケーションテンプレートは、AWS Serverless Application ModelAWS SAM)に従って、小さなAWSサーバーレスアプリケーションを作成します。 このテンプレートは、API GatewayRESTエンドポイントを介して公開された複数のラムダ関数で構成された完全なサーバーレスアプリケーションを開発する方法を示しています。 また、AWS SAMでは、アプリケーションがプロジェクトのテンプレートの一部として使用するAWSリソースをモデル化できます。

コードが準備できたら、プロジェクトを右クリックし、ソリューションエクスプローラで[Publish to AWS Lambda…]を選択してVisual Studioから直接展開できます。 そこから、デプロイメント・ウィザードがデプロイメント・プロセスをガイドします。

 

.NET Core CLIを使用したクロスプラットフォーム開発

.NET Coreの優れた機能の1つは、クロスプラットフォームのサポートです。 従来の.NETフレームワークでは、開発者はWindows上でアプリケーションを構築して実行する必要があります。 ただし、.NET Coreを使用すると、任意のプラットフォームでC#コードを開発し、任意のプラットフォームに展開することができます。Windowsで開発しておらず、AWS Toolkit for Visual Studioにアクセスできない場合でも、.NETツールを使用してCLambda関数とサーバーレスアプリケーションをAWSに簡単に公開できます。 AWS Toolkit for Visual Studioを使用していても、dotnet CLIの使い方を知ることは、ビルドとデプロイメントプロセスの自動化に役立ちます。.NET Coreプロジェクトを作成したら、Yeomanのようなツールを使用してdotnet CLILambdaツールを有効にします。 Amazon.Lambda.ToolsNuGetパッケージに依存するツールを新しいプロジェクトに追加するだけです。

Amazon.Lambda.Tools NuGetパッケージは、新しいdotnet CLIにコマンドを追加します。これにより、使用しているプラットフォームに関係なく、Lambda関数とサーバレスアプリケーションをAWSにデプロイできます。 Windows上のVisual Studioで開発している場合でも、dotnet CLIAWS Lambdaツールは、アプリケーションのCI / CDパイプラインを設定するのに役立ちます。dotnet CLIの新しいラムダコマンドの詳細については、プロジェクトディレクトリに「dotnet lambda help」と入力してください。

 

まとめ

我々は、.NET Core ランタイムを通してC#アプリケーションに対してAWS Lambdaを利用可能にすることに興奮しています。 C#Lambda関数の作成に関する詳細は、「AWS Lambda開発者ガイド」を参照してください。 AWS Toolkit for Visual Studioをダウンロードして開始するか、dotnet CLIのLambda拡張を確認してください。

 

原文: Announcing C# Support for AWS Lambda (翻訳: SA福井)

改善されたAWS IoT Buttonデベロッパーエクスペリエンスの発表

5月には、正式にAWS IoT Buttonを開始し、開発者コミュニティから提供されたボタンのサポートに圧倒されました。 私たちは皆様の提案に耳を傾け、AWS IoT Buttonの改良された開発者体験を発表することを喜ばしく思います。

今日から、iOSとAndroid用の新しいモバイルアプリでAWS IoT Buttonを設定できます。 モバイルアプリケーションは、ボタンの登録、設定、およびプログラミングのプロセスを簡素化します。 あらかじめ設定されたAWS Lambdaのブループリントを使用して、このボタンをクリックするとSMSや電子メールを送信するボタンを素早くプログラムすることができます。 または、あなたが選択した機能のための独自のLambdaコードを書くことができます。

さらに、新しいバージョンのAWS IoT Buttonは、バッテリー寿命を2倍に設計しました。 amazon.comで今予約注文することができます。 それまで待ちたくない場合は、元のAWS IoTボタンは引き続き使用でき、AWSアカウントごとに20ドルのAWSクレジットを提供します。

AWS IoT Buttonの詳細については、製品ページをご覧ください。

 

原文: Announcing an Improved AWS IoT Button Developer Experience (翻訳: SA福井)

AWS CodePipeline で、失敗したアクションのリトライが可能に

AWS CodePipeline で、アクション失敗後のリトライが出来るようになりました。以前は、手動でパイプライン全体をリスタートするか、失敗したアクションをリトライするために、パイプラインの Source Stage へ新たな変更をコミットする必要がありました。

CodePipeline 内でアクションがうまく完了しなかった場合、そのアクションは失敗し、パイプラインが停止し、パイプラインを通じた更新を止めてしまいます。本日から、パイプライン全体をリスタートする必要なく、失敗したアクションをリトライできます。

本機能はマネジメントコンソール、 AWS CLI, AWS SDK, API を使用して、利用可能です。リトライ機能の詳細は こちらをご覧下さい。

CodePipelineに関する詳細:

翻訳は江川が担当しました。原文はこちら