AWSのマネージドなコンテナサービスEC2 Container Service、略してECSのTask definitionを操作していて思うのが、これって**Docker Composeじゃーーん!**です。
各コンテナに必要な定義を別の様式で記述しているわけです。
ECSでもdocker-compose.yml使えたらな〜、と思ったらありました。
Using the Amazon ECS Command Line Interface
http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/ECS_CLI.html
ECSをコマンドラインから使うものではあるのですが、おまけ(?)として、コンテナをデプロイするのにdocker-compose.ymlが使えます。操作があいまいになりがちなGUIを使わなくていい上に、Composeのymlまで使えてしまうという。ステキ。
とりあえずノウハウが豊富なWordPressを題材にやってみます。
なお、2016年9月26日現在、ecs-cliのWindows版は提供されておらず、Mac版とLinux版だけの模様。
Windowsな方、すみません。
なお今回の記事にはクラスメソッドさんの記事を超参考にさせて頂きました。
WordPress用 docker-compose.ymlを作成する
まずローカルで動かそう、ということでymlを作成します。
wordpress:
image: wordpress
mem_limit: 268435456
ports:
- "80:80"
links:
- mysql
mysql:
image: mysql
mem_limit: 268435456
environment:
MYSQL_ROOT_PASSWORD: password
mem_limitでコンテナのメモリを制限しています。これは本来いらない設定なのですが、後ほどAWS上のt2-microで動作させようと目論んでおり、その際に必要となります。
WordPressをローカルで起動する
では早速起動。
$ docker-compose up -d
Creating tmp_mysql_1
Creating tmp_wordpress_1
確認が済んだので停止してお掃除します。
$ docker-compose stop
Stopping tmp_wordpress_1 ... done
Stopping tmp_mysql_1 ... done
$ docker-compose rm -f
Going to remove tmp_wordpress_1, tmp_mysql_1
Removing tmp_wordpress_1 ... done
Removing tmp_mysql_1 ... done
ECS-CLIをインストールする
ではECSにコンテナをデプロイするための準備としてECS-CLIをダウンロード、インストールします。
brewでECS-CLIをインストールする
ちなみにMacの場合はbrewでインストールできます。
brew install amazon-ecs-cli
ECS-CLIを設定する
ecs-cliが使用するAWSの情報を設定します。
リージョン、アクセスキー、シークレットキーが必要になりますので事前に準備してください。
ecs-cli configure --region ap-northeast-1 --access-key XXXXXXXX --secret-key XXXXXXXX --cluster ecs-cli-test
--clusterでクラスタ名を指定しています。これはてきとうで。
ECSクラスタを起動する
では、クラスタを起動します。テストなのでケチってt2.microインスタンスX2です。
ecs-cli up --keypair KEY_NAME --capability-iam --size 2 --instance-type t2.micro
KEY_NAMEにはインスタンスアクセス用の鍵名を指定します。
この時点でAWSのコンソールにアクセスすると、クラスタが起動していることが確認できます。
なお、クラスタの作成には結構時間がかかります。約5分。お茶でも飲みながら待ちましょう。
INFO[0000] Created cluster cluster=ecs-cli-test
INFO[0001] Waiting for your cluster resources to be created
INFO[0001] Cloudformation stack status stackStatus=CREATE_IN_PROGRESS
INFO[0061] Cloudformation stack status stackStatus=CREATE_IN_PROGRESS
INFO[0121] Cloudformation stack status stackStatus=CREATE_IN_PROGRESS
INFO[0182] Cloudformation stack status stackStatus=CREATE_IN_PROGRESS
INFO[0242] Cloudformation stack status stackStatus=CREATE_IN_PROGRESS
ECS上でコンテナを起動する
ではいよいよコンテナを起動します。使用するのはローカルで使ったymlそのまんまです。
ecs-cli compose -f docker-compose.yml up
うまくいけば、コンテナがデプロイされます。 AWSのコンソールでタスクが走っているのがわかります。
コンテナの起動状況を確認
$ ecs-cli ps
Name State Ports TaskDefinition
9070ad27-7798-4018-9389-42842eb5ee7d/wordpress RUNNING 52.xx.xx.xx:80->80/tcp ecscompose-tmp:3
9070ad27-7798-4018-9389-42842eb5ee7d/mysql RUNNING ecscompose-tmp:3
表示されたIPにアクセスすればWordPressが表示されます。
ローカルで動作させたコンテナがそのまんまAWSでも動作する。しかもこんなに簡単に。すごい!
ECS上でコンテナをスケールさせる
せっかくEC2を2つ使っているのでスケールさせてみます。
ecs-cli compose -f docker-compose.yml scale 2
かくにん。
$ ecs-cli ps
Name State Ports TaskDefinition
9070ad27-7798-4018-9389-42842eb5ee7d/wordpress RUNNING 52.xx.xx.xxx:80->80/tcp ecscompose-tmp:3
9070ad27-7798-4018-9389-42842eb5ee7d/mysql RUNNING ecscompose-tmp:3
caad2e0b-6ad6-48fc-a9b0-2d2a23cdea13/mysql RUNNING ecscompose-tmp:3
caad2e0b-6ad6-48fc-a9b0-2d2a23cdea13/wordpress RUNNING 52.xx.xxx.xxx:80->80/tcp ecscompose-tmp:3
無事増えてます!
なお今回はmysqlごとまとめてタスクにしているので、スケールしたコンテナ毎にストレージがついていることになります。そのため、片方のタスクで操作しても、もう一方のタスクには反映されないという悲しいことになっております。実運用ではmysqlはRDSを使って、アプリケーション部分のみコンテナにするのが常套手段と思われます。
ECSのサービスを定義する
最後にサービスを定義します。サービスを定義することにより、オートスケールやコンテナがコケた場合の再起動が可能になります。詳しい設定はただいま調査中のため、とりあえずサービスを定義するところまでです。
まずコンテナを落とす
$ ecs-cli compose -f ./docker-compose.yml down
サービスとして起動する
$ ecs-cli compose -f ./docker-compose.yml service up
無事サービスが上がってますね。
ECSクラスタを削除する
では最後にクラスタを削除します。まるっと綺麗に消えちゃうので本番運用している場合には注意が必要です。
ecs-cli compose -f ./docker-compose.yml service rm
ecs-cli down --force
--forceで稼働中であろうが無慈悲に削除します。気をつけましょう。
以上です。参考になれば。