(レポート)DVO317: Local Docker開発から実稼働デプロイメントまで #reinvent

丹内です。掲題のセッションをレポートします。

スピーカー

• Jérôme Petazzoni - Tinkerer Extraordinaire, Docker Inc.

背景

Dockerを使って、ローカルでの動作確認からデプロイ後の設定までを行うセッションです。複数コンテナの協調動作を、ローカルでの開発からデプロイまで、デモンストレーションを交えて詳細に解説しています。
このセッションのデモではElasticBanstalkのMulti-Containerスタックは使用していません。
サンプルアプリは、簡単なもの(trainingwheel)と複雑なもの(dockercoin)があります。 また、デプロイの方針も大きく分けて、AWSのエコシステムに乗っかる(ECS)ものと、Dockerのエコシステムに乗っかる(Swarm)があります。

ローカルでの開発時の動作確認

書いたコードの動作確認は、以下のように行います。ここでは、docker-composeコマンドを使います。

• docker-compose build
• docker-compose up

これでコンテナが起動するようにして、ローカルで確認できるようにするところがスタート地点です。
うまく行ったら、デプロイに向けて準備をしていきます。

クラスタのプロビジョニング

デプロイ先の作成方法はいくつかありますが、例としてAmazon ECSを使う場合を考えます。 ECSを使うと、CFテンプレートの適用やAuto Scaling Groupの設定、IAM設定まで行ってくれて、すぐに動くところまで設定できます。
デモでは、ECS CLIを使っていました。その際、ELBへのコンテナの登録やAS Groupsの設定、DNSの設定までECSが行ってくれるようです。

ビルドとデプロイ

以下の手順で行います。

• composeでコンテナのビルドを行う
• ユニークな値(ビルドナンバーなど)をタグ付けする
• RegistryにPushする
• デプロイ先で参照するように新しいdocker-compose.ymlを生成する

これらはjpetazzo/orchestration-workshopのスクリプトで行うことができるようです。

サービスディスカバリ

複数コンテナの協調動作で重要なのは、いかにして他のコンテナを発見するかにあります。単一のホストで動かすなら問題ないのですが、複数ホストで動的に変わる接続先に対応するために、いくつかのパターンが考えられているようです。その中でもオススメなのは、アンバサダーパターンです。
これは、他のコンテナを知っているコンテナを参照することです。アンバサダーコンテナの参照には、localのhostsによるlookupを利用します。
この際、12Factorに基づき、IPを環境変数で渡すようにしましょう。
接続先は、redisコンテナで一括管理します。

このアンバサダーコンテナには、jpetazzo/hambaを使うと、必要なことが実装されているので良さそうです。
ここでの必要なこととは、以下の2点です。

• Proxy: 接続先コンテナの情報を知っている
• Load Balancing: 同じroleのコンテナが複数あった場合、ロードバランシングする

このパターンでコンテナを運用中にスケールさせる際は、以下の流れで行います。

• 複数ホストに複数種のコンテナを配置し、起動する
• 各コンテナに対するアンバサダーコンテナを起動する(同じホスト)
• アンバサダーコンテナを同ホストのコンテナ(webなど)が発見できるように、適切にハンドリングする(アンバサダーコンテナを新たな設定で再起動するなど)
• コンテナはアンバサダーと通して別ホストのredisにアクセスできる

感想

セッションはデモが多く、またスピーカーのJérômeさんもジョークを交えながら、常時LTのような勢いでセッションが続いていきました。聴講していて、心から楽しいと思いました。
サービスディスカバリのredisコンテナについては、consulを使うとまた別のパターンがあるのかもしれません。
セッションの内容を一から実践するのは大変そうですが、動くものが提供されているため、まずはそれで試して感覚を掴んでみると良いと思いました。