Category: Developer Tools

大規模なデータおよびデータレイクのワークロード用にサーバーレスETL（抽出、変換およびロード）アプリケーションを開発するためにAWS Glueはますます普及しています。 ETLアプリケーションをクラウドベースのサーバーレスETLアーキテクチャに変換する組織は、ソースコードからビルド、デプロイ、プロダクトデリバリまで、シームレスでエンドツーエンドの継続的なインテグレーションおよび継続的なデリバリ（CI / CD）パイプラインが必要です。優れたCI / CDパイプラインを持つことで、組織はプロダクションリリース前にバグを発見し、より頻繁にアップデートを提供することができます。また、開発者が高品質のコードを書いたり、ETLのジョブリリース管理プロセスを自動化したり、リスクを軽減したりするのに役立ちます。 AWS Glueは、フルマネージドのデータカタログとETLのサービスです。これは、データの発見、変換、およびジョブスケジューリングなどの困難で時間のかかる作業を簡素化し自動化します。 AWS Glueは、データソースをクロールし、CSV、Apache Parquet、JSONなどの一般的なデータフォーマットとデータタイプ用に事前に作成された分類子を使用してデータカタログを構築します。 AWS Glueを使用してETLアプリケーションを開発する場合、CI / CDの次のような課題に直面する場合があります。 ユニットテストによる繰り返しの開発 継続的なインテグレーションとビルド ETLパイプラインをテスト環境にプッシュする ETLパイプラインをプロダクション環境にプッシュする 実データを使用したETLアプリケーションのテスト（live test） データの調査と検証 この記事では、AWS Developer Tools（AWS CodePipeline、AWS CodeCommit、AWS CodeBuildなど）とAWS CloudFormationがサポートするサーバーレスAWS Glue ETLアプリケーションのCI / CDパイプラインを実装するソリューションを紹介します。 ソリューションの概要 次の図は、ワークフローのパイプラインを示しています。 このソリューションでは、AWS CodePipelineを使用して、ETLアプリケーションのソースコードのテストおよびステージへのデプロイを制御および自動化することができます。 このソリューションは、以下のステージを含むパイプラインで構成されています。 1.）Source Control：このステージでは、デプロイするETLジョブのAWS Glue ETLジョブソースコードとAWS CloudFormationテンプレートファイルの両方がバージョン管理にコミットされます。 バージョン管理にAWS CodeCommitを使用することにしました。 ETLジョブソースコードとAWS CloudFormationテンプレートを取得するには、gluedemoetl.zipファイルをダウンロードします。 このソリューションは、以前の記事、AWS Glue と Amazon S3 を使用してデータレイクの基礎を構築するに基づいて開発されました。 2.）LiveTest：このステージでは、AWS […]

このブログ記事では、AWS CodeStar プロジェクトの一部として単体テストを実行する方法についてご紹介します。AWS CodeStar は AWS 上でアプリケーションを素早く開発、ビルド、そしてデプロイするのに役立ちます。AWS CodeStar を使えば、継続的デリバリ（CD）のツールチェーンを構築しソフトウェア開発を一箇所に集約して管理することができます。 単体テストはアプリケーションのコードの個々の単位をテストし、問題を素早く特定し取り去るのに役立ちます。単体テストは、自動化された CI/CD プロセスの１部分を構成することで、バッドコードが本番環境にデプロイされてしまうことを防ぐのにも役立てられます。 多くの AWS CodeStar プロジェクト テンプレートには、単体テストのフレームワークがあらかじめ設定されています。そのため、自信を持ってコードのデプロイを開始することができるでしょう。この AWS CodeStar プロジェクトの単体テストは、ビルドステージにおいて実行されるように設定されているので、もし単体テストがパスしなかったらそのコードがデプロイされることはありません。単体テストを内包している AWS CodeStar プロジェクト テンプレートの一覧については、AWS CodeStar ユーザガイドの AWS CodeStar プロジェクト テンプレートを参照してください。

AWS Cloud9 は 2017年11月の AWS re:Invent で発表されました。Cloud9 はブラウザベースの IDE で、サーバレスアプリケーションも含め、数多くのクラウド上の開発ユースケースに適しています。AWS CloudFormation を使うことで AWS CodeCommit と連携した AWS Cloud9 の開発環境を迅速に構築することができます。このブログでは、CloudFormation を使った Cloud9 環境の構築手順を説明します。さらに Cloud9 の環境で Python と Boto3 のコードを書き、 Troposphere を使って CloudFormation の YAML テンプレートを生成する方法についても説明します。

AWS X-Ray は、開発者がマイクロサービスやサーバレス・アーキテクチャで構築された本番環境のアプリケーションを分析及びデバッグすることを手助けし、顧客への影響を定量化します。AWS X-Ray を使うと、アプリケーション及びそのアプリケーションが依存しているサービスがどのように振る舞っているかを把握し、パフォーマンスの問題やエラーに対する根本原因の究明やトラブルシュートを行うことができます。これらの洞察を駆使してアプリケーションの問題点を見つけ出し最適化の機会を得ることができます。 このブログ記事では、X-Ray がアプリケーションにおける遅延やエラー、あるいは失敗の増加を検知したときに、どうすれば Amazon CloudWatch と Amazon SNS を使って通知を受信することができるのかをお見せします。特に、エンドユーザがあなたのアプリケーションを利用していて遅延の増加やサーバサイドのエラーに遭遇した際にEメールや SMS メッセージを通して通知を受け取るためにはどうすればよいでしょうか。サンプルアプリケーションを使ってお見せしたいと思います。サンプルアプリケーションは、コードを修正することによってアラームやイベントをカスタマイズすることも可能です。

この記事はAWS Senior Technical EvangelistのAbby Fullerの投稿です。 2017年12月12日に、AWSはAWS CodePipelineのターゲットとしてAmazon Elastic Container Service (ECS)をAWS Fargateも含めてサポートしたことをアナウンスしました。このサポートにより、コンテナベースのアプリケーションやマイクロサービスを継続的デリバリするパイプラインを作成するのがより簡単になりました。 コンテナ化したサービスを手動で構築しデプロイするのは、時間がかかりますしエラーを起こしがちです。自動化されたビルドとテスト機構と組み合わせた継続的デリバリは、早期にエラーを発見し時間を短縮することを助け、失敗を減らしてくれるので、アプリケーションのデプロイモデルとして一般的なものとなってきています。以前は、ECSでコンテナワークフローを自動化するには、AWS CloudFormationを使った自前のソリューションを構築する必要がありました。これからは、わずか数ステップでCodePipelineとCodeBuildをECSと連携させてワークフローを自動かすることができます。 CodePipeline、CodeBuild、そしてECSを使った典型的な継続的デリバリのワークフローは、以下のようなものです: ソースを選択する プロジェクトをビルドする コードをデプロイする GitHub上にこのワークフローのための継続的デプロイのリファレンスアーキテクチャも公開しています。 はじめてみよう 最初に、CodePipelineで新規プロジェクトを作成し、例として”demo”というプロジェクト名を設定します。 次に、コードが保管されているソースの場所を選択します。ここには、AWS CodeCommit、GitHub、またはAmazon S3が選択できます。この例では、GitHubを入力し、CodePipelineにレポジトリへのアクセス権を与えます。 次に、ビルドステップを追加します。JenkinsサーバURLやCodeBuildプロジェクトの様に既存のビルドを持ってくることもできますし、CodeBuildで新しいステップを作成することもできます。もし既存のCodeBuildのプロジェクトがなければ、以下の様に選択してCodePipelineから新しいものを作成しましょう: Build provider: AWS CodeBuild Configure your project: Create a new build project Environment image: Use an image managed by AWS CodeBuild Operating system: Ubuntu Runtime: Docker Version: aws/codebuild/docker:1.12.1 Build specification: […]

プログラミングを始める時に最初に学ぶことは、どんな職人でも同様ですが、道具についてです。メモ帳は役に立たないでしょう。強力なエディタとテスティング パイプラインがあなたの生産性に大きく貢献します。私はまだ最初にVimの使い方を学んだ時のことを覚えています。それを使ってシステムと複雑なプログラムをZip化しました。すべてのコンパイラと依存関係を新しいマシンにセットアップすることが、どれほど大変だったか覚えていますか？新しいデベロッパーをプロジェクトに参加させるためにバージョンをマッチさせ、構成ファイルを取り繕い、ドキュメントを書くのに、どれほどのサイクルを浪費したことか。 本日（11/30）コーディング、実行、デバッグを可能にする統合開発環境（IDE）をWebブラウザ上で実現するのAWS Cloud9をローンチしました。Cloud9は多くの人気のある開発言語（Javascript、Python、PHP、その他）のための主要なツールをパッケージ化しているので、様々なコンパイラやツールなどをインストールする必要はありません。Cloud9はまたサーバーレスアプリケーションとのシームレスなエクスペリエンスを提供しておりローカルとリモートの間でテストやデバッグを素早くスイッチできます。ポピュラーなオープンソースのAce Editorとc9.io IDE（昨年買収しました）をベースに、AWS Cloud9は非常にパワフルなペアプログラミング機能と共にクラウド開発におけるコラボレーションが容易になるように設計されています。Cloud9は、このBlog記事でカバーしているものよりも多くの機能を提供していますが、ここではクイックにエディタ機能、AWSとのインテグレーション、コラボレーション機能の3つのコンポーネントに分解して掘り下げていきます。

以前の「GitとAWS CodePipelineの統合」の記事では、Amazon API Gateway、AWS Lambda、Amazon S3を使用して、サードパーティのGitリポジトリとAWS CodePipelineを統合する方法の1つを示しました。 このアプローチでは、GitリポジトリをCodePipelineと迅速に統合できますが、多くの利用者がCI/CDパイプラインで使用するソースのメタデータをCodePipelineに提供することはできません。 この記事では、ソースリポジトリから、より多くのメタデータをCodePipelineに提供するための異なる戦略を提供する、CodePipelineカスタムソースアクションについて説明します。最も一般的なソース メタデータは、コミット識別子とコミットメッセージです。Commit識別子は、ソフトウェアライフサイクル全体の変更を追跡するために頻繁に使用されますが、コミットメッセージは人間が判読可能で簡潔な記述を提供します。カスタムソースアクションを使用すると、CodePipelineがCodeCommitやGitHubと統合するのと同じ方法で、任意のソースリポジトリと統合することができ、コミット識別子とコミットメッセージにアクセスできます。 この記事では、API GatewayとLambdaをセットアップしてパイプラインをトリガし、パイプラインをカスタムソースアクションで構成し、カスタムソースアクションからジョブを処理するワーカーを構築します。このアーキテクチャを使用すると、VPCでホストされているか、またはオンプレミスに構築されておりVPCからアクセス可能なソースプロバイダにアクセスできます。

シニアクラウドアーキテクトのMichael Edge氏のCodeCommitのプルリクエストに関する素晴らしいブログに感謝します。 ~~~~~~~~~~~~~ AWS CodeCommitは、プライベートGitリポジトリを安全にホスティングするフルマネージドなサービスです。CodeCommitは今ではプルリクエストをサポートするようになりました。これによってリポジトリのユーザは、コードの変更に対するレビュー、コメント、対話的なイテレーションが可能になります。チームメンバー間のコラボレーションツールとして使用されるプルリクエストは、CodeCommitリポジトリに対する変更の可能性を、リポジトリにそれらの変更をマージする前に確認するのに役立ちます。各プルリクエストは、次のように単純なライフサイクルを通じて実行されます： マージされる新機能は、featureブランチに1つ以上のコミットとして追加されます。コミットは、宛先のブランチにマージされません。 プルリクエストが通常は2つのブランチの差異から作成されます。 チームメンバーはプルリクエストをレビューし、コメントします。プルリクエストは、追加のコミットで更新される可能性があります。これにはコメントに対応して行われる変更や宛先ブランチとの差分から発生する変更が含まれます。 チームメンバーがプルリクエストに満足すれば、それは宛先ブランチにマージされます。 コミットは、プルリクエストに追加されるのと同じ順序で宛先ブランチに適用されます。

Webアプリケーションのユーザーインターフェイスをテストすることは、開発ライフサイクルの重要なパートです。 この記事では、AWS CodePipeline, AWS CodeBuild, AWS Lambdaなどのサーバーレス技術を利用してUIテストを自動化する方法を説明します。 S3でホストされているUIテスト用のWebサイトを構築しました。Seleniumを使用して、Chrome、Firefox、PhantomJS、およびWebDriver Wire Protocolの実装であるGhost DriverのヘッドレスWebKitブラウザで、クロスブラウザのUIテストを実行します。 テストが実行されているブラウザに基づいて、Pythonを使ってChromeDriver、FirefoxDriver、またはPhatomJSDriverのテストケースを作成しています。 この記事で紹介するAWS CloudFormationテンプレート、S3でホストされているテストおよびステータスWebサイト、AWS CodeBuildビルドスペックファイル、AWS Lambdaファンクション、テストを行うPythonスクリプトなどのリソースは、serverless-automated-ui-testing GitHubリポジトリで公開しています。   S3にホストされるテストWebサイト:AWS CodeBuildはカスタムコンテナをサポートしているため、FirefoxとChromeブラウザのプレビルドを含むSelenium/standalone-FirefoxとSelenium/standalone-Chromeコンテナをそれぞれ使用できます。Xvfbは、ディスプレイハードウェアなしで仮想メモリ内でグラフィカルオペレーションを実行します。 XvfbはインストールフェーズでCodeBuildコンテナにインストールされます。   Chrome and Firefoxテスト用のビルドスペック ChromeとFirefoxのテストのビルドスペックには、複数のフェーズがあります: 環境変数セクションには、ビルドプロジェクトの作成時またはビルドのトリガー時にオーバーライドされる一連のデフォルト変数が含まれます。 インストールフェーズの一部として、XvfbやSeleniumなどの必須パッケージがyumを使用してインストールされます。 pre_buildフェーズでは、テスト実行のためにテストベッドが準備されます。 ビルドフェーズでは、適切なDISPLAYが設定され、テストが実行されます。 version: 0.2 env:   variables:     BROWSER: “chrome”     WebURL: “https://sampletestweb.s3-eu-west-1.amazonaws.com/website/index.html”     ArtifactBucket: “codebuild-demo-artifact-repository”     MODULES: “mod1”     ModuleTable: “test-modules”   […]

昨日、.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”: [ { […]