GA&東京に来たAmazon EC2 Container Service(ECS)を触ってみた #AWSSummit

2015.04.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ども、大瀧です。
今朝未明に行われたAWS Summit - San FranciscoのKeynoteでEC2 Container ServiceのGA、東京リージョンを含む多くのアップデートが発表されました。早速触ってみたので解説します。

今回のアップデート内容

  • コンテナスケジューラ(ECS Service)の追加
  • Management Consoleのサポート
  • ELB(Elastic Load Balancing)連携の追加
  • CloudTrailのサポート
  • 東京リージョンで使用可能に

What's Newのページには、Private RepositoryとVolumeのサポートも書いてありますが、リリースはなかったもののちょっと前から使えるようになっていてフォーラムではアナウンスされていたので、上記には含めませんでした。

初期ウィザードによるECSクラスタの作成

新しいECS構成を簡単に試すための初期ウィザードができたので、それに沿ってECSクラスタを構成してみます。以下のURLにアクセスします。

  • https://console.aws.amazon.com/ecs/home#/firstRun

ecs01

今回サポートされた東京リージョンを選択しておきましょう。

ecs21

画面右下のタスク選択では、[Amazon ECS Sample]になっていることを確認し、[Next Step]をクリックします。

ecs02

サンプルタスクのタスク定義一覧が表示されます。ECSでは実行するコンテナを"タスク定義(Task Definition)"として事前に設定しておくようになっています。今回のサンプルでは、Apacheのイメージ(httpd:2.4)のsample-appタスクとBusyboxイメージ(busybox)のbusyboxの2つのタスクが含まれることがわかります。[Next Step]をクリックします。

ecs03

続いて、今回の新機能、スケジューラの設定です。ECSでは、タスク定義の実行方法を以下2つから選択します。

  • サービス(Service) : 常時実行するよう、スケジューラが監視するコンテナ
  • タスク(Task) : スケジューラによって1回は実行されるが、そのあと再実行は行われないコンテナ

KubernetesにもServiceというコンポーネントがありますが、KubernetesのServiceはPod(コンテナの集合)にトラフィックを転送するネットワーク機能ですので、ECSのサービスとは異なります。
今回は、サービスservice-webappとして1タスク実行してみます。

ecs05

サービスを選択すると、コンテナのリバースプロキシとしてELBを連携させることができます。[Container Port]からApacheのイメージを実行するsample-appタスクを選択し、[Next Step]をクリックします。

ecs06

続いて、Dockerコンテナを実行するホストの設定です。既定では、ECS-Optimized Amazon LinuxというAMIイメージ(Dockerがインストール済みのAmazon Linux)からEC2インスタンスを実行します。そのほかに、従来からCoreOSがサポートされているので、CoreOSとECSの組み合わせについてはこちらのエントリーを参照ください。今回は1台、t2.microのままとします。

ecs07

画面をスクロールすると、セキュリティグループとIAMロールの設定があります。IAMロールではECSクラスタインスタンスとなるEC2のロールとECSサービスが使用するロールの2つを指定します。既存のロールが無ければ、[Manage IAM Role]ボタンをクリックし、一括で作成できます。

ecs08

右下の[Allow]ボタンをクリックすれば、上記2つのロールが作成、選択されます。

ecs09

元の画面に戻ったら、[Review & Launch]ボタンを2回クリックしてECSクラスタの作成が開始します。

ecs10

作成の進捗が画面に表示されます。しばらく待ちましょう。

ecs11

"ECS Instances Status"の進捗が完了になったら、[Click here to view CloudFormation stack]のリンクをクリックしてみましょう。どうやら、ウィザードでのECSインスタンス作成は、CloudFormationが動作するようです。

ecs12

VPCなどのネットワーク構成を始め、ECSインスタンスに関するいくつかのリソースがCloudFormationスタックに含まれることがわかります。インスタンス自体はAuto Scalingで起動しているようですね。

ecs13

元の画面の"ECS Status"も、タスク定義およびサービスの進捗が表示されていきます。現時点ではECSコンポーネント自体はCloudFormationには対応していないようですね。右下の[View Service]をクリックしてサービス一覧画面に切り替えます。

ECSサービスの動作確認

ECSサービスの画面では、サービスの実行数や連携するELBの情報が表示されます。試しに実行数を2に増やしてみます。右上の[Update]をクリックします。

ecs14

[Number of Tasks]を「2」に変更し、[Update Service]をクリックします。

ecs15

[Desired count]が「2」に変わりましたね。[Running count]も増えるかなぁ、とちょっと待っていたのですが。。。

ecs16

[Events]タブでイベントログを見てみると、エラーになっていました。今回はECSインスタンスが1台なので、ホストポートがバッティングして「空きリソースなし」と判断されたようです *1。タスク定義でホストポートを動的にするとどうなるか、気になるところですね。

ecs17

あとは、サービスの画面にある[Load Balancer Name]をクリックしてELBの画面に切り替え、インスタンス一覧を見てみます。ECSインスタンスが通常のEC2と同様に登録されているので、コンテナを直接紐付けるようにはなっていないようですね。ちゃんとIn Serviceとなっているので、ECSのホストポートに対してHealth Checkも動いているようです。

ecs18

ELBのDNS名にWebブラウザからアクセスすると、動作しているサービスsample-webappのレスポンスがきちんと返ってきました!

ecs19

ちなみに、既定ではECSインスタンスのセキュリティグループでTCP:80番が解放されていてsample-webappサービスはホストポート80番にバインドされているので、ECSインスタンスのPublic IPへのアクセスでも同様のページが表示されます。

ecs20

まとめ

今回は大量アップデートとなりましたが、スケジューラがついてGA&東京リージョンに来たのでECSの本格検討が始められる段階に来たのではないでしょうか。Dockerを実行するサービスとしてはBeanstalk Dockerもあるので、特徴を理解しつつ、うまく活用していただければと思います。Beanstalk Dockerについては、先日のイベントで以下のセッション資料を公開しているので参考にしてください!(宣伝)

脚注

  1. t2.microのためにメモリリソースが足らないのかと思いt2.mediumにしてみましたが同じエラーになりました