Tag: Amazon ECS

同僚のKiuk ChungがAWS Batchを使って深層学習をするという素晴らしい記事を書いてくれました。 GPUインスタンスは当然のように深層学習とペアになりますが、それはそのニューラルネットワークのアルゴリズムがGPUインスタンスの超並列処理能力を活かすことができるからです。AWSではg2やp2といったGPUインスタンスを提供しており、お客様はスケーラブルなGPUワークロードを実行することができます。AWS Batchを使うことでそのスケーラビリティをもっと効率よく使うことができます。(訳注: 丁度GTC 2017のKeynoteにて次期NVIDIA GPUであるV100に関する情報も発表されましたのでご参考頂ければ幸いです: AWS and NVIDIA Expand Deep Learning Partnership at GTC 2017) AWS Batchは皆さんの代わりに下回りの計算リソースを管理してくれるので、リソース管理のオーバーヘッド無しにモデリングすることに集中できます。AWS Batchにおける計算環境 (すなわちクラスタ)とは、皆さんのアカウント内のインスタンスのプールであり、AWS Batchはジョブの数に応じてインスタンスを起動したり削除したりしながらそれを動的にスケールしてくれます。これによって無駄なインスタンスを最小化でき、コストを最適化することができます。 さらに、AWS Batchは登録されたジョブが適切なインスタンスに配置されるように確実にスケジュールしてくれるので、ジョブのライフサイクルが管理されます。お客様独自のAMI利用の機能追加によって、AWS Batchの利用者はGPUが必要とされるジョブのためにもこの弾力性や利便性を活用することができるようになりました。 この記事ではGPUベースの深層学習ワークロードをAWS Batch上でどのように動かせばよいかをお見せします。Apache MXNetを使ってMNISTデータセットから手書きの数字を認識するための、畳み込みニューラルネットワーク(LeNetアーキテクチャ)の学習を例として使います。 MXNetのジョブをAWS Batchで実行する Apache MXNetは機能が豊富で、柔軟にプログラムが書け、高いスケーラビリティをもった深層学習フレームワークで、畳み込みニューラルネットワーク (CNNs)やlong short-term memory networks (LSTMs)を含む最新の深層モデルをサポートしています。 AWS Batchでジョブを実行するには3つのステップがあります: カスタムAMIを作成 AWS Batchのリソースを作成 学習ジョブを登録 カスタムAMIを作成 まず、NVIDIAドライバとAmazon ECSエージェントを含むAMIを作成するところから始めます。AWS Batchでは、計算環境を作成する時にimage_idを指定することで特定のAMIからインスタンスを起動させることができます。GPUが必要なジョブを実行しようとしているので、NVIDIAドライバが含まれたAMIが必要となります。 Launch Stackを選択して、あなたのアカウント上でus-east-1にCloudFromationテンプレートを起動します:  下にある様に、CloudFormationスタックのOutputsタブの中にあるAMIという値をメモしておきます。次のセクションで計算環境を作成する時にこれをimage_idの値として使います。 または、AWS BatchのドキュメンテーションのGPU有効なAMIを作成するに従っても良いです。 AWS Batchのリソースを作成 AMIを作成したら、以下のリソースを作成します: […]

あなたは刺激的な仮説を思いつきました。そして今、あなたは、それを証明する（あるいは反論する）ためにできるだけ多くのデータを見つけて分析したいと思っています。適用可能な多くのデータセットがありますが、それらは異なる人によって異なる時間に作成され、共通の標準形式に準拠していません。異なるものを意味する変数に対して同じ名前を、同じものを意味する変数に対して異なる名前を使用しています。異なる測定単位と異なるカテゴリを使用しています。あるものは他のものより多くの変数を持っています。そして、それらはすべてデータ品質の問題を抱えています（例えば、日時が間違っている、地理座標が間違っているなど）。 最初に、これらのデータセットを適合させ、同じことを意味する変数を識別し、これらの変数が同じ名前と単位を持つことを確認する方法が必要です。無効なデータでレコードをクリーンアップまたは削除する必要もあります。 データセットが適合したら、データを検索して、興味のあるデータセットを見つける必要があります。それらのすべてにあなたの仮説に関連するレコードがあるわけではありませんので、いくつかの重要な変数に絞り込んでデータセットを絞り込み、十分に一致するレコードが含まれていることを確認する必要があります。 関心のあるデータセットを特定したら、そのデータにカスタム分析を実行して仮説を証明し、美しいビジュアライゼーションを作成して世界と共有することができます。 このブログ記事では、これらの問題を解決する方法を示すサンプルアプリケーションについて説明します。サンプルアプリケーションをインストールすると、次のようになります。 異なる3つのデータセットを適合させて索引付けし、検索可能にします。 事前分析を行い、関連するデータセットを見つけるために、データセットを検索するための、データ駆動のカスタマイズ可能なUIを提示します。 Amazon AthenaやAmazon QuickSightとの統合により、カスタム解析やビジュアライゼーションが可能です

同僚のStas Vonholskyが、Amazon ECSアプリケーションの秘密情報管理に関する素晴らしいブログを寄稿してくれました。 —– コンテナ化されたアプリケーションとマイクロサービス指向のアーキテクチャが普及するにつれて、アプリケーションデータベースにアクセスするためのパスワードなどの秘密情報を管理することは、より困難かつ重要になっています。 いくつか課題の例を挙げます： dev、test、prodなどのさまざまなアクセスパターンをコンテナ環境全体でサポートしたい ホストレベルではなくコンテナ/アプリケーションレベルで秘密情報へのアクセスを隔離したい サービスとしても、他サービスのクライアントとしても、アクセスが必要である疎結合なサービスが複数存在する この記事では、Amazon ECS上で動作するコンテナアプリケーションの秘密情報管理をサポートする、新しくリリースされた機能に焦点を当てています。同僚のMatthew McCleanもAWSセキュリティブログに、S3とDockerを使用してECSベースのアプリケーションの秘密情報を管理する方法についての素晴らしい記事を公開しています。この記事では、コンテナパラメータ変数を使って秘密情報を受け渡し／保存する際の制限について説明しています。 多くの秘密情報管理ツールは、次のような機能を提供しています。 高セキュアなストレージシステム 集中管理機能 セキュアな認証と認証メカニズム 鍵管理および暗号化プロバイダとの統合 アクセスのための安全な導入メカニズム 監査 秘密情報のローテーションと失効 Amazon EC2 Systems Manager パラメータストア パラメータストアは、Amazon EC2 Systems Managerの１機能です。秘密情報のための集中化／暗号化されたデータストアを提供し、Run CommandやステートマネージャーなどのSystems Managerの他の機能と組み合わせることで多くの利点をもたらします。このサービスはフルマネージドで、高い可用性・セキュリティを持っています。 System Manager API、AWS CLI、およびAWS SDKを使用してパラメータストアにアクセスできるため、汎用の秘密情報管理ストアとして使用することができます。秘密情報は簡単にローテートしたり取り消したりすることができます。パラメータストアはAWS Key Management Service (KMS)と統合されているため、デフォルトまたはカスタムのKMSキーを使用して特定のパラメータを暗号化できます。 KMSキーをインポートすることで、独自のキーを使用して機密データを暗号化することも可能です。 パラメータストアへのアクセスはIAMポリシーによって実現にされ、リソースレベルのアクセス許可をサポートします。特定のパラメータまたは名前空間にアクセス権を持つIAMポリシーを使用して、これらのパラメータへのアクセスを制限することができます。 CloudTrailログを有効にすると、パラメータへのアクセスを記録することも可能です。 Amazon S3も上記の機能の多くを持つので、集約秘密情報ストアの実装にも使用できますが、パラメータストアにはさらに次のような利点があります。 アプリケーションライフサイクルのさまざまなステージをサポートするためのネームスペースを簡単に作成できる インスタンスまたはコンテナからKMSキーにアクセスし、ローカルメモリ内で復号化を実行することで、アプリケーションからパラメータの暗号化を抽象化するKMS統合機能を提供する パラメータの変更履歴を保管できる 他の多くのアプリケーションで使用されるS3とは別に制御できる 複数システムを実装する際のオーバーヘッドを削減する構成情報ストアとなる 使用料がかからない 注：本記事の公開時点では、Systems ManagerはVPCプライベートエンドポイント機能をサポートしていません。プライベートVPCからのパラメータストアエンドポイントへのより厳密なアクセスを強制するには、限られたIPアドレスセットからのみにアクセスを制限するIAMポリシーConditionとともに、Elastic IPアドレスを持つNATゲートウェイを使用します。 タスクIAMロール […]

同僚のMadhuri Periが素晴らしい記事を書いてくれました。AutoScalingグループのクラスタをスケールダウンする際にインスタンスからタスクを事前に削除するために、コンテナ インスタンス ドレイニングを利用する方法です。 —– Amazon ECSクラスタでは、クラスタからインスタンスを削除する必要があるタイミングというのがいくつかあります。例えば、システムを更新するとき、Dockerデーモンを更新するとき、あるいはクラスタのサイズをスケールダウンするときなどです。コンテナ インスタンス ドレイニング機能によって、クラスタ上のタスクに影響を与えることなく、コンテナインスタンスを削除することができます。この機能により、コンテナインスタンスがDRAINING状態である間はそのインスタンスに対して新しいタスクの配置がスケジュールされないようになり、利用可能なリソースがあればサービスがタスクをクラスタ上の他のコンテナインスタンスに移動してくれ、インスタンスを削除する前にタスクの移動が成功したことを待機できるようになります。 コンテナインスタンスの状態は、手動でDRAININGに変更することが可能です。しかしこの記事では、これらのプロセスを自動化するためにAutoScalingグループとAWS Lambdaを利用してコンテナ インスタンス ドレイニングを行う方法を説明します。 Amazon ECS オーバービュー Amazon ECSはコンテナ管理サービスです。クラスタやEC2インスタンスの論理グループ上でDockerコンテナの実行、停止、そして管理を容易にしてくれます。ECSを使ってタスクを実行するとき、タスクはクラスタに配置されます。Amazon ECSは指定されたレジストリからコンテナイメージをダウンロードし、そしてそのイメージをクラスタ内のコンテナインスタンス上で実行します。 コンテナ インスタンス ドレイニングの状態を扱う AutoScalingグループはライフサイクルフックをサポートしています。ライフサイクルフックは、インスタンスの起動や削除の前に独自の処理を完了するために呼び出されます。今回の例では、ライフサイクルフックは、2つの処理を実行するLambdaファンクションを呼び出します。 ECSコンテナインスタンスの状態をDRAININGに変更します。 コンテナインスタンス上にタスクが1つも残っていないことを確認します。もしドレイニング中のタスクがまだ存在する場合は、Lambdaファンクションを再度呼び出すためにSNSにメッセージを送信します。 コンテナインスタンス上で実行中のタスクがなくなるか、あるいはライフサイクルフックのハートビートタイムアウト（サンプルのCloudFormationテンプレートではTTL15分に設定）に達するか、どちらかの状態になるまでLambdaによってステップ2が繰り返されます。その後、制御はオートスケーリングのライフサイクルフックに戻され、そのインスタンスは削除されます。このプロセスを次の図に示します。 試してみましょう! この記事で説明した一連のリソースをセットアップするためにCloudFormationテンプレートを使用します。このCloudFormationテンプレートを使用するには、あなたのアカウントのS3バケットにLambdaデプロイメントパッケージをアップロードする必要があります。このテンプレートは次のリソースを作成します。 VPCと関連するネットワーク要素（サブネット、セキュリティグループ、ルートテーブルなど。） ECSクラスタ、ECSサービス、そしてサンプルのECSタスク定義 削除のライフサイクルフックと2つのEC2インスタンスが設定されたAutoScalingグループ Lambdaファンクション SNSトピック Lambdaを実行するために必要なIAMロール CloudFormationスタックを作成し、インスタンスの終了イベントをトリガーすることによってどのようにこのスタックが機能するのか見ていきます。 Amazon EC2のコンソールにおいて、AutoScalingグループを選択し、CloudFormationによって作成されたAutoScalingグループの名前（CloudFormationテンプレートのリソースのセクションから）を選択します。 操作、編集を選択し、インスタンスの希望の数を “1” に減らすようにサービスを更新します。これによって、2つのインスタンスのどちらか一方で終了プロセスが開始されます。 AutoScalingグループのインスタンスタブを選択します。1つのインスタンスのライフサイクルの状態が “Terminating:Wait” という値を示すはずです。 この状態になると、ライフサイクルフックが発火してSNSにメッセージが送信されます。そして、SNSメッセージトリガーに反応してLambdaファンクションが実行されます。 Lambdaファンクションによって、ECSコンテナインスタンスの状態がDRAININGに変更されます。その後、ECSサービススケジューラによってこのインスタンス上のタスクは停止され、利用可能なインスタンス上でタスクが起動されます。 ECSのコンソールに移動すれば、コンテナインスタンスの状態がDRAININGになっていることを確認できます。 タスクが全て完了すると、AutoScalingグループのアクティビティ履歴でEC2インスタンスの削除を確認できます。 どのように動作しているか 少しLambdaファンクションの内部的な動作を見てみましょう。ファンクションはまず最初に、受け取ったイベントのLifecycleTransitionの値が autoscaling:EC2_INSTANCE_TERMINATING にマッチするかをチェックします。 # もし受け取ったイベントがインスタンス終了中ならば・・・ if ‘LifecycleTransition’ […]

本日、Amazon ECSはクラスタ上にどのようにしてタスクを配置するかを汎用的に制御することのできる機能を発表しました。以前は、特定のリソースの要求(例えば、特定のインスタンスタイプ)を満たすコンテナインスタンス上にタスクを配置する必要がある時は、カスタムスケジューラを作成してリソースをフィルタし、発見し、グループ化する必要がありました。 次の図は、新しいタスク配置処理の概要を示しています: これによって、コードを一切書かずともタスクがどのように配置されるかをカスタマイズすることができます。ECSは、インスタンスタイプやアベイラビリティゾーンの様な組み込み済の属性を付与していますし、加えてカスタムの属性もサポートしています。例えば、environment=productionといった属性でコンテナインスタンスをラベル付することができ、これらのリソースを見つけるためにList APIで操作することや、RunTaskとCreateService API操作でこれらのリソース上にタスクを配置することができます。 また、bin packやspreadといったplacement strategy (配置戦略)を使って、タスクがさらにどこに配置されるかを定義することもできます。ポリシーを連鎖させて洗練された配置を達成することもできます。例えば、g2.*のインスタンス上にのみタスクを配置し、アベイラビリティゾーンに渡って幅広く(spread)配置し、そして各ゾーンではメモリを基準にタスクをなるべく詰め込む(bin pack)というポリシーを作成できます。 はじめに、attribute (属性)を見てましょう。インスタンスタイプ等の組み込み済の属性を使って、コンテナインスタンスを見つけ、その上にタスクを配置することができます。以下の例では、クラスタ上の全てのt2インスタンスを見ることができます: aws ecs list-container-instances –filter “attribute:ecs.instance-type matches t2.*” { “containerInstanceArns”: [ “arn:aws:ecs:us-east-1:123456789000:container-instance/40f0e62c-38cc-4cd2-a28e-770fa9796ca1”, “arn:aws:ecs:us-east-1:123456789000:container-instance/eb6680ac-407e-42a6-abd3-1bbf57d7401f”, “arn:aws:ecs:us-east-1:123456789000:container-instance/ecc03e17-6cbd-4291-bf24-870fa9796bf2”, “arn:aws:ecs:us-east-1:123456789000:container-instance/fbc03e17-acbd-2291-df24-4324ab342a24”, “arn:aws:ecs:us-east-1:123456789000:container-instance/f9a69f54-9ce7-4f1d-bc62-b8a9cfe8e8e5” ] } 続いて、us-east-1aのアベイラビリティゾーンにあるt2インスタンスのみをリストしています: aws ecs list-container-instances –filter “attribute:ecs.instance-type matches t2.* and attribute:ecs.availability-zone == us-east-1a” { “containerInstanceArns”: [ “arn:aws:ecs:us-east-1:123456789000:container-instance/40f0e62c-38cc-4cd2-a28e-770fa9796ca1”, “arn:aws:ecs:us-east-1:123456789000:container-instance/eb6680ac-407e-42a6-abd3-1bbf57d7401f”, “arn:aws:ecs:us-east-1:123456789000:container-instance/ecc03e17-6cbd-4291-bf24-870fa9796bf2” ] } カスタム属性はECSのデータモデルを自身のカスタムメタデータ用にキーバリューのペアを使って拡張します。以下の例では、stack=prodという属性を特定のコンテナインスタンスに追加しています: aws ecs put-attributes –attributes […]

お客様がコンテナベースのコンピューティングについて習熟していて、コンテナ化の価値について少なくとも基礎的な理解があることを心から願っています。私が 2014 年に述べたように、クラウドベースのアプリケーションをコンテナのコレクションとしてパッケージ化し、それぞれを宣言により指定することで、開発環境と本稼働環境の一貫性、アーキテクチャベースとしての分散アプリケーションプラットフォーム、開発効率、運用効率など、数多くの利点が得られます。当社は 2014 年後半に、Linux コンテナのサポートを含む Amazon EC2 Container Service をリリースしました。今年は、これまでにアプリケーションの負荷分散のサポート、ECS タスクの IAM ロール、サービスの Auto Scaling、Amazon Linux コンテナイメージ、Blox オープンソーススケジューラを追加しました。 Windows コンテナのサポート 本日は、ECS の一連のリリースを継続し、Windows コンテナのベータレベルのサポートを追加します。当社が本稼働環境での使用に向けてこの機能を最終的に完成させる間、お客様は Windows アプリケーションのコンテナ化とテストを今すぐ開始できます。使用を開始するには、クラスターの作成時に Windows Server 2016 Base with Containers AMI を指定するだけです (同じクラスターに Linux と Windows を混在させることはできません)。また、Windows コンテナ AWS CloudFormation テンプレートを開始点として使用することもできます。テンプレートは VPC で実行され、コンテナインスタンスの設定可能な数で Windows を利用するクラスターが作成されます。また、IAM ロール、Application Load Balancer、セキュリティグループ、Amazon ECS タスク定義、Amazon ECS サービス、および Auto […]

2014年、私はAmazon ECSについてお話して、Dockerベースのアプリケーションをビルドし実行し、そしてスケールさせることを如何に手助けしてくれるかをご紹介しました。そこでは3つのスケジューリングの選択肢(自動、手動、そしてカスタム)について話をし、スケジューラがインスタンスにどの様にタスクを割り当てるかを説明しました。 その時書いた記事では、カスタムスケジューラは現在のクラスタの状態を見るためにListContainerInstancesとDescribeContainerInstancesを定期的に呼び出す必要があると記しました。数週前、CloudWatch Eventsのサポートを追加することで各クラスタの状態を追跡する処理を簡素化しました。(これについて詳しくは、Amazon ECSイベントストリームで、クラスタの状態を監視をご覧下さい) この新しいイベントストリームが出たので、我々はカスタムスケジューラの作成をもっと簡単にしたいと思います。 本日、我々はBloxを開始します。この新しいオープンソースプロジェクトには、イベントストリームを処理してクラスタの状態を追跡し、状態をREST APIで利用可能にするサービスが含まれています。また、クラスタ内の各コンテナインスタンスにタスクを1つだけ実行するデーモンスケジューラも含まれています。このコンテナを1つずつ配置するモデルで、ログ処理やメトリクス収集のワークロードをサポートします。 こちらが”ブロック図”です (ダジャレじゃありません ※訳注 BloxとBlockをかけています): これはオープンソースのプロジェクトです; プルリクエストや機能要望を楽しみにしています。詳しい情報は、Amazon EC2 Container Serviceより、Bloxをご紹介をご覧下さい。 — Jeff; 原文: Blox – New Open Source Scheduler for Amazon EC2 Container Service (翻訳: SA岩永)

今までは、実行中のAmazon ECSクラスタの状態の更新を取得するためには、AWS CLIやSDKを使ってコンテナインスタンスとタスクの状態を定期的にポーリングする必要がありました。新しいAmazon ECSイベントストリーム機能によって、これからはAmazon ECSのタスクとコンテナインスタンスの状態更新を準リアルタイムにイベント駆動で受け取ることが可能になりました。イベントはAmazon CloudWatch Eventsを通して配送され、AWS Lambda関数やAmazon SNSトピックといった、あらゆるCloudWatch Eventsのターゲットに向けることができます。 この記事では、簡単なサーバレスアーキテクチャを作って、イベントストリームの更新を受け取り、処理し、そして保存する方法をお見せします。まず最初にLambda関数を作成し、入ってきた全てのイベントをスキャンして実行中のタスクに関連したエラーが無いかを探し、もしあれば即座にSNSの通知を送ります。その後、関数は全てのメッセージをAmazon Elasticsearch Serviceを使ったElasticsearchのクラスタにドキュメントとして保存することで、皆さんや開発チームの方がKibanaのインタフェースを通じてクラスタの状態を監視したり、ユーザから報告された問題に返答するための診断情報を検索することができます。

コンテナは素晴らしいのですが、それを管理することは非常に難しい問題です。私達のお客様は、マイクロサービスからバッチジョブにいたるまで、多くのワークロードでコンテナをAWS上で使ってきました。彼らが私達に教えてくれたのは、EC2インスタンスやコンテナの状態を含むクラスタ管理はトリッキーで、特に環境が大きくなってくると問題になってくるということでした。また、AWSプラットフォームで利用可能な、ロードバランサー、スケーリング、セキュリティ、モニタリング等の機能とコンテナとの連携は重要な要件であるとも教えてくれました。Amazon ECSはこれら全ての要求とそれ以上に応えるために設計されました。 我々はお客様がコンテナ化したアプリケーションを本番環境で稼働させることを簡単にするためにAmazon ECSを作りました。コンテナ管理のためのソフトウェアをインストールしたり運用したりする必要は全くなく、これらは全てサービスとして提供されます。必要となるEC2のキャパシティをクラスタに追加して、使いたいコンテナイメージをアップロードするだけで良いです。Amazon ECSが残りの面倒をみてくれて、EC2インスタンスのクラスタ上にコンテナをデプロイしてそのヘルス状態を監視してくれます。ExpediaやRemind等のお客様は、Amazon ECSを開発ワークフローに組み込み、その上にPaaSプラットフォームを構築しています。他には、PreziやShippableはECSを使ってコンテナを実行するための運用の複雑さを削減し、より多くの時間をアプリケーションの機能を提供することに使えるようにしています。 AWSは高い信頼性とスケーラビリティを持ったフルマネージドのサービスとして、ロードバランサー、Auto Scaling、IAM、ロギング、そしてモニタリングを提供してます。この1年間、EC2インスタンスで利用できるものと同じものを利用できるように、ECSを通じたこれらAWSプラットフォームの機能とのネイティブな連携を続けてきました。 Amazon ECSはここ最近で、アプリケーションロードバランサーの対応(本日)、IAMロールの対応(7月)、そしてAuto Scalingの対応(5月)に提供しました。これからも、より多くのAWSプラットフォームをコンテナに持ってくることを楽しみにしています。 それでは、新しい特徴を見てみましょう！ アプリケーションロードバランサー 負荷分散とサービスディスカバリは、どのマイクロサービスアーキテクチャでも必要不可欠なものです。Amazon ECSはElastic Load Balancingを使っているので、負荷分散のレイヤーで管理やスケールをする必要はありません。またELBをサポートする他のAWSサービスも直接扱うことができます。例えば、AWS Certificate Manager (ACM)でサービスの証明書を自動的に管理したり、Amazon API Gatewayで呼び出しの認証を行ったりできます。 本日、ECSは新しいアプリケーションロードバランサーをサポートすることを発表できることをとても嬉しく思います。高いパフォーマンスを持ったアプリケーションレイヤで行われる負荷分散の選択肢で、コンテントベースのルーティングルールを定義することができます。アプリケーションロードバランサーは、マイクロサービスの実行を簡潔にしてくれる2つの機能を含んでいます: 動的ポートと、複数サービスで1つのロードバランサーを共有できる機能です。 動的ポートによって、ポートの衝突を心配する必要がなくなるので、クラスタ上でのタスクの開始がとても簡単になります。以前は、Elastic Load Balancerをアプリケーションのトラフィックのルーティングに使っていると、ECSタスクではホスト側のポートを固定で定義する必要がありました。これは、各アプリケーションが使っているポートを管理しなければならないという運用の複雑さを招き、また1つのタスクしか1つのインスタンスに配置できないのでクラスタの効率も下げていました。これからは、ECSのタスク定義では動的ポートを指定することができ、EC2インスタンスがスケジュールされた時に未使用のポートが割り当てられます。ECSスケジューラは自動的にそのタスクをアプリケーションロードバランサーのターゲットグループに登録する時にこのポートを使います。使いはじめるには、アプリケーションロードバランサーをEC2コンソールやAWS Command Line Interface (CLI)で作成できます。そしてECSコンソールでタスク定義を作る時にコンテナのホストポートを0としておきます。このコンテナはスケジュールされた時に自動的にエフェメラルポートのレンジからポートを受け取ります。 以前は、ECSサービスとロードバランサーの間には1対1のマッピングしかありませんでした。これからは、パスベースのルーティングを使うことで、複数のサービスでロードバランサーを共有できます。各サービスがそれぞれのURIを定義することで、サービスにトラフィックを向けることができます。加えて、基本的なサービスディスカバリをサポートするために、そのサービスのDNS名を環境変数に指定することができます。例えば、株価のサービスを http://example.com/stock で、天気のサービスを http://example.com/weather で、同一のロードバランサーから提供することができれば、ニュースポータルは株価と天気のサービスのどちらにもロードバランサー経由でアクセスすることができます。 ECSタスクのIAMロール Amazon ECSでは、EC2コンテナインスタンスのIAMロールを使って、コンテナからのAPIリクエストを簡略化することはいつでもできます。これによって、AWSのベストプラクティスである、AWSの認証情報をコードや設定ファイル内に保存しない、が実現できますし、同時に自動的なキーローテーションといった利点も得ることができます。 最近発表したECSタスクのIAMロールを使うことで、EC2コンテナインスタンスではなくECSタスクに直接IAMロールを紐付けられ、基盤をよりセキュアにすることができます。このやり方であれば、例えばS3にアクセスするためのIAMロールを指定されたタスクと、DynamoDBテーブルにアクセスするためのIAMロールを使っている別のタスクを、同一のEC2インスタンス上で実行することができます。 サービスAuto Scaling 3つ目の強調したい特徴が、サービスのAuto Scalingです。サービスAuto ScalingとAmazon CloudWatchアラームを使うことで、EC2インスタンスを増やしたり減らしたりするのと同じやり方で、ECSサービスをスケールさせるポリシーを定義することができます。サービスAuto Scalingによって、負荷が上がった時にはスケールアウトすることで高い可用性を維持したり、負荷が下がったサービスとクラスタをスケールインすることでコストを最適化することができ、これらは全て自動的かつリアルタイムで起こります。 タスクの希望数、最小数、そして最大数を選び、1つ以上のスケーリングポリシーを作成するだけで、あとはサービスAuto Scalingが処理してくれます。サービススケジューラはアベイラビリティゾーンを意識してくれるので、ECSタスクが複数のゾーンに渡って分散しているかを気にする必要もありません。 今日から利用可能です これらの特徴は既に利用可能なので、今日から使いはじめることができます！ — Jeff; 原文: Powerful AWS […]

Amazon ECSでは、コンテナから簡単にAPIリクエストを行うために、Amazon EC2のIAMロールをいつでも使うことができます。これによって、AWSの認証情報をコードや設定ファイルに保存しないというAWSのベストプラクティスに従うことができる上に。鍵の自動ローテーションといった利点も得られます。 例えば、ECSとAmazon S3を使った秘匿情報管理システムを作ったり、Amazon DynamoDBを使って状態管理したり、S3を使ってコンテナによって生成された成果物を保存したり、ということがロールによって可能であり、全てにおいてAWSの認証情報をコードの中に全く持つ必要がありません。 今までは、Amazon EC2のIAMロールを使う必要がありました。つまり、ECSクラスタのEC2インスタンスに紐付いたIAMポリシーは同一クラスタ内で実行されるタスクが必要な全てのIAMポリシーを含んでいる必要がありました。これは、もし1つのコンテナが特定のS3バケットへのアクセスが必要で、他のコンテナがDynamoDBテーブルへのアクセスが必要であった時、同一のEC2インスタンスに両方のIAM権限を与える必要があることを意味しています。 新しく公開されたECSタスクのためのIAMロールの導入によって、EC2コンテナインスタンスではなくECSタスクに直接IAMロールを紐付けることで、基盤をより安全に保つことができます。この手法によって、1つのタスクはS3にアクセスする特定のIAMロールを使いながら他のタスクはDynamoDBテーブルへにアクセスするIAMロールを使うことができます。 この機能によって、ECSクラスタインスタンスのIAMポリシーも最小限にすることが可能です。なぜなら、ECSサービスとやり取りするために必要な2,3のIAM権限を与えるだけで良いからです。 この記事で、タスクIAMロールのセットアップを眺めてみましょう。 必要条件 もしまだであればECSクラスタを作成し、最低でも1つのEC2インスタンスをクラスタ内に起動します。EC2インスタンスを起動するとき、Container instance IAM roleとして、AmazonEC2ContainerServiceforEC2RoleポリシーがアタッチされたIAMロールを選択します。 もし既存のクラスタがあれば、ECS最適AMIの2016.03.eを使い、この機能を使うために2016年7月13日リリースかそれより新しいSDKを使います。 デモンストレーション このデモでは、Amazon S3バケットを作成し’Hello World’ファイルをアップロードするだけの簡単なNode.jsアプリケーションを使います。アプリケーションのソースコードはaws-nodejs-sampleのGitHubレポジトリにあります。 Dockerイメージをビルドしプッシュする ターミナルアプリケーションで、以下のコマンドを実行します: $ git clone https://github.com/awslabs/aws-nodejs-sample すると現在のディレクトリの下にaws-nodejs-sampleという名前のディレクトリが作られ、サンプルアプリのコードが配置されます。そのディレクトリでDockerfileというファイルを作成し、以下のテキストを貼り付け保存します。 FROM node:argon # Create app directory RUN mkdir -p /usr/src/app WORKDIR /usr/src/app # Install app dependencies COPY package.json /usr/src/app/ RUN npm install # Bundle app source COPY […]