Docker 1.11 から 1.12 への変更点の説明と AWS EC2 Container Service との比較

1. Docker Swarm mode 入門
＆ ECS との比較
JAWS-UG コンテナ支部 #3
2016.8.3 yteraoka

2. 自己紹介
Name: Teraoka Yoshinori
Twitter: @yteraoka
エムスリー株式会社で
インフラ全般を担当

3. 自己紹介
Name: Teraoka Yoshinori
Twitter: @yteraoka
Ansible やってました

4. 今日話すこと、話さないこと
話すこと
● Docker 1.11 から 1.12 での変更点
● ECS との比較
話さないこと
● Docker とは

5. Container Orchestration 2大勢力
なんか大変そう

6. Swarm はシンプルで楽チンだと聞いて...

7. Docker 1.11 + Swarm
Swarm Worker
Swarm Manager
Swarm Worker
Swarm Manager
Swarm Worker
Swarm Manager
KVS
(etcd, consul, zookeeper)
Reverse Proxy
nginx / HAProxy
+
consul-template
Alt.
Vulcand
gobetween
CA

8. Docker 1.11 + Swarm
● クラスタ関連通信は TLS で保護、証明書のチェックも有効
● Swarm のクラスタ管理用 KVS
● Docker の Overlay Network 用 KVS
● Reverse Proxy の Dynamic configuration 用 KVS
○ どの node のどの port でどのサービスが稼働しているかを管理
● Container の起動・停止を監視し KVS に登録する
○ registrator など

9. これが Docker 1.12 で

10. こうなった

11. Swarm Mode Architecture Topology
https://blog.docker.com/2016/07/docker-built-in-orchestration-ready-for-production-docker-1-12-goes-ga/

12. Docker 1.12 Feature highlights
● Cluster management integrated with Docker Engine
● Decentralized design
● Declarative service model
● Scaling
● Desired state reconciliation
● Multi-host networking
● Service discovery
● Load balancing
● Secure by default
● Rolling updates
https://docs.docker.com/engine/swarm/

13. Docker 1.12 Feature highlights
● Docker Engine に統合されたクラスタ管理機能
● 分散デザイン（非集中）
● 宣言型サービスモデル
● スケーリング
● 希望する状態の維持（N個のコンテナを維持）
● マルチホストネットワーキング
● サービスディスカバリ
● ロードバランサー
● 安全性（デフォルトでセキュア）
● ローリングアップデート
https://docs.docker.com/engine/swarm/

14. Cluster management integrated with Docker Engine
● 追加のオーケストレーションソフトウェア不要！！
● Docker Engine だけでクラスタが構築可能
● 別途 KVS や CA を構築する必要もなし！

15. Decentralized design
Docker Engine はマネージャーとワーカーの役割によらず同一の実行バイナリであるた
め、デプロイ時に役割を区別すること無く単一のディスクイメージで構築可能

16. Declarative service model
Service というものを定義するようになりました
名称、環境変数、CPU・メモリの制限、ログドライバ、ポートの公開、実行数、ローリング
アップデートのための設定など
これまで docker-compose.yml など外部で定義していたものを Docker Engine 内で保持
します

17. Service と Task
● Service を作成すると定義にしたがってコンテナが実行される
● この実行されたコンテナが Task
$ docker service create --name nginx --replicas 3 nginx:1.11
f4p4cot1s7nhsx6kahuqy10ou
$ docker service ls
ID NAME REPLICAS IMAGE COMMAND
f4p4cot1s7nh nginx 3/3 nginx:1.11
$ docker service ps nginx
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE
ERROR
9bbpm947yca9bf428e9r07nwe nginx.1 nginx:1.11 ip-192-168-54-4 Running Running about a minute ago
53e1tx2bnngxhrzx19pqszwpp nginx.2 nginx:1.11 ip-192-168-54-5 Running Running about a minute ago
a47go7z2wql2nvbv61hsigeys nginx.3 nginx:1.11 ip-192-168-54-6 Running Running about a minute ago

18. Scaling
Service ごとにいくつの Task（コンテナ）を実行したいか定義できます
定義数を変更すれば swarm manager が自動でタスクの追加、削除を行って希望の数を
維持します
$ docker service scale --help
Usage: docker service scale SERVICE=REPLICAS [SERVICE=REPLICAS...]
Scale one or multiple services
Options:
--help Print usage

19. Desired state reconciliation
The swarm manager node constantly monitors the cluster state and reconciles any
differences between the actual state your expressed desired state. For example, if
you set up a service to run 10 replicas of a container, and a worker machine
hosting two of those replicas crashes, the manager will create two new replicas to
replace the ones that crashed. The swarm manager assigns the new replicas to
workers that are running and available.
同じことの繰り返しなので省略

20. Multi-host networking
● Overlay Network が作成可能
● Swarm manager はコンテナに対して自動的にここのアドレスを割り当てる
● これは以前の Docker でも可能だったが外部 KVS が必要だった

21. Service discovery
Swarm manager は Service ごとにユニークな DNS ネームとロードバランサーを割り当
てます。Swarm 内のコンテナはこの DNS を用いて他のサービスと通信することができ
ます。Overlay Network を使う場合のみ
--endpoint-mode が vip (default) の場合 LoadBalancer の VIP が割り当てられて DNS
にこれが登録されます
--endpoint-mode が dnsrr の場合は DNS RoundRobin っぽい動作になります

22. Load balancing
外部向け Load Balancer でサービスポートを公開できます
どの node でコンテナが稼働しているかによらずにアクセスできます
-p, --publish を指定すると ingress ネットワークが使われるため VIP が設定され、外部
からのアクセスも可能になる
-p を指定しない場合は --network で overlay network を使うようにすれば VIP が設定
される、ingress を指定しても良い

23. Load balancing
Swarm node1
interface
ingress-
endpoint
Virtual IP
app-A
app-B
app-C
Swarm node2
interface
ingress-
endpoint
Virtual IP
app-A
app-A
app-cSource IP address は
ingress-sbox の IP address
expose した port
(ex. 30000/tcp) service の port
(ex. 80/tcp)
※実際はもうすこし複雑

24. Load balancing
Swarm node1
interface
ingress-
endpoint
Virtual IP
app-A
app-B
app-C
Swarm node2
interface
ingress-
endpoint
Virtual IP
app-A
app-A
app-C
Source IP
address は
app-B コンテ
ナの IP
address
※実際はもうすこし複雑

25. Load balancing
Swarm node1
interface
ingress-
endpoint
Virtual IP
app-A
app-B
app-C
Swarm node2
interface
ingress-
endpoint
Virtual IP
app-A
app-A
app-C
自身のVIPとはうまく
通信できない
※実際はもうすこし複雑

26. Load balancing
● Service で expose されたポートは Load Balancer はどの node でも受け、目的のコ
ンテナへルーティングされる
● このため、前段の Reverse Proxy は swarm node の全部または一部を upstream
として指定しておくだけでコンテナの実行ノード移動などの影響をうけない
● Service ごとにポートを固定する運用とすれば Reverse Proxy の設定変更は
Service と swarm node の増減時のみとなる

27. Secure by default
Swarm の各 node は TLS で相互に認証し通信も暗号化される
自己署名の root 証明書またはカスタム root CA の証明書を使うオプションもある
誰か swarm init の --external-ca オプションの使い方を教えてください...

28. Rolling updates
アプリの更新時、少しずつ更新することが可能。Swarm manager は同時にいくつの task
を更新するか、それぞれの間隔をどうするか、失敗した場合にどうするかをコントロール
できます
$ docker service update --help
…
Options:
…
--update-delay duration Delay between updates
--update-failure-action string Action on update failure ()
--update-parallelism unit Maximum number of tasks updated simultaneously
(0 to update all at once) (default 1)
…

29. Private Registry
docker image の pull に認証が必要な場合は事前に docker login して
~/.docker/config.json にログイン情報を登録した上で service create に
--with-registry-auth を指定することで
{“username”:”test001”,”password”:”secret”,”serveraddress”:” https://index.doc
ker.io/v1/”}
などどいう情報が Base64 で encode されて swarm の分散 KVS に登録される
strings /var/lib/docker/swarm/raft/wal/*
で誰かのパスワードがゲットできちゃうかも
ちなみに ~/.docker/config.json の auth の値も Base64 で encode されているだけ

30. Docker 1.12 でできなくなったこと
● docker-compose で Swarm クラスタに対しての deploy
$ docker-compose up -d
WARNING: The Docker Engine you're using is running in swarm mode.
Compose does not use swarm mode to deploy services to multiple nodes in a swarm.
All containers will be scheduled on the current node.
To deploy your application across the swarm, use the bundle feature of the Docker
experimental build.
More info:
https://docs.docker.com/compose/bundles
Creating network "wordpress_default" with the default driver
Creating wordpress_db_1
Creating wordpress_wordpress_1
https://docs.docker.com/compose/wordpress/

31. bundle / stack
docker-compose の後継（？）
Experimental なので
curl -fsSL https://experimental.docker.com/ | sh
でインストールする必要あり
https://github.com/docker/docker/blob/master/experimental/docker-stacks-and-bundles.md

32. bundle / stack
● docker-compose.yml から bundle 用の .dab を生成できます
● bundle では Image を完全なハッシュ値（SHA256）で指定する必要があるため、変換には予め
docker-compose pull が必要
● テストで WordPress 用 docker-compose.yml（MySQL + Apache & PHP）を変換して起動した例
$ docker-compose bundle
WARNING: Unsupported key 'links' in services.wordpress - ignoring
WARNING: Unsupported key 'depends_on' in services.wordpress - ignoring
WARNING: Unsupported key 'restart' in services.wordpress - ignoring
WARNING: Unsupported key 'volumes' in services.db - ignoring
WARNING: Unsupported key 'restart' in services.db - ignoring
Wrote bundle to wordpress.dab
$ docker deploy --file wordpress.dab wordpress
Loading bundle from wordpress.dab
Creating network wordpress_default
Creating service wordpress_db
Creating service wordpress_wordpress

33. bundle / stack
● Apache & PHP の Service と MySQL の Service の起動
● Apache & PHP の Service の Scale
を確認することは出来ましたが、きっとまだまだ変更されると思います

34. HEALTHCHECK
● Dockerfile もしくは docker run 時に HEALTHCHECK を指定できるようになりました
● docker run では --health-cmd, --health-interval, --health-retries, --health-timeout が指定可能だが
service では指定できないため Dockerfile にて HEALTHCHECK を設定した image を作成する必要があ
る
● healthcheck が有効な場合、docker ps の STATUS 欄に (healthy), (health: starting) などと追加される
● healthy でない場合コンテナが再起動される
● 再起動で改善されないような場合は延々と再起動が繰り返される・・・
● --restart-max-attempts で制限可能
HEALTHCHECK --interval=5s --timeout=3s --retries=5 CMD /healthcheck.sh
HEALTHEHCEK CONNECT TCP 7000
などと Dockerfile に書くことができる

35. Docker 1.12 でできなくなったこと
● クラスタ外からの deploy
証明書がらみの問題（だけ？）
node の証明書は
/var/lib/docker/swarm/certificates/
に転がってるけど...

36. Docker の課題（セキュリティ）
● パスワードなどの渡し方
環境変数は docker コマンドが使えてしまうと丸見
え
https://github.com/docker/docker/issues/13490
● そもそも docker コマンド使えたらなんでも出来てしまう
● swarm manager node にログインしないとコンテナ起動できない
$ docker inspect -f '{{range .Config.Env}}{{println .}}{{end}}'
ab3485437171
PASSWORD=michadameyo
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
NGINX_VERSION=1.11.1-1~jessie

37. Amazon EC2 Container Service

38. Amazon EC2 Container Service (ECS)
ELB ELB ELB

39. ECS 登場人物
● Cluster
● Task Definition
● Task
● Service
● Instance

40. ECS / Cluster
● Docker を実行可能な EC2 インスタンスのかたまり
● 通常は ECS-Optimized Amazon Linux AMI （Agent Container が稼働）
● VPC 内、AZ、Subnet をまたいだ構成も可能
● Instance Role はその上で動作するコンテナに影響する

41. ECS / Task Definition
● １つ以上のコンテナからなるサービスの定義
● これをひとつの単位としてスケールさせていく
● Task 内のコンテナ間は link 機能により名前解決および通信が可能
● Task 内の複数のコンテナは同一ホスト（EC2インスタンス）上で実行される
● コンテナ間に不可分な関係がある場合に複数のコンテナをまとめる
○ アプリと fluentd
○ アプリと memcached / redis
● アプリとDBは通常ひとつのTaskには入れない（アプリは増やすがDBは増やさない）
● Task Definition を元に Task もしくは Service を起動する
● Task Definition には Version があり、Rolling Update が可能
（別の Task Definition にも入れ替え可能）

42. ECS / Task
これらの箱ひとつひとつが Task
1 Task = 1 Container とは限らない
● Task Definition から直接 Task として実行したものも
● Service として実行したもの Task である

43. ECS / Service
● Task Definition を元に
● どの Cluster で
● いくつの Task を実行するか（更新時の最小、最大数も指定）
● Task の数は後から変更可能
● ELB で Load Balance させるか
● Auto Scale させるかどうか
を指定して実行したもの

44. ECS / Service
ELB ELB ELB

45. ECS / Service の制限事項
● ELB を設定する場合、コンテナ毎に別のポートを ELB に設定できないため
EC2 Instance のリソースに空きがあってもポートが開いていないとコンテナを割り
当てられない

46. ECS / Task にするか Service にするかか
● Task Definition で定義したものを単純に N 個実行する
→ Task
● Task Definition で定義したものを N 個常に実行しておきたい、
Scale Up / Down させたい
→ Service
● Task Definition で定義したものを ELB で負荷分散させたい
→ Service
● Task Definition で定義したものを Rolling Update したい
→ Service

47. ECS の Network
● EC2 Instance をまたいだコンテナ間は直接通信することができない
● ELB を経由すれば可能

48. ● AWS の場合多くのマネージメントサービスが活用できるためコンテナ間通信の需要
は低そう
ECS の Network

49. ECS / Security
コンテナ用 EC2 Instance に設定した IAM Instance role
もしくは Task 毎に設定する IAM role で各種 AWS リソースへアクセスできるためパス
ワードなどが見えてしまったりせずセキュア

50. ECS と Swarm の比較
Swarm mode ECS
Service Task Definition / Service
Task (1 Container) Task (1+ Container)
Load Balancer (VIP, L4) ELB (L4/L7)
Overlay Network -
- Instance Auto Scaling
- Container Auto Scaling
- Instalce / Task IAM Role

51. Docker 1.12 はまだちょっと不安？
● RC版を軽く触った際におや？と思うことがあった
● Docker の GitHub issue を見てるとちょっと不安だったりする
● DockerCon 2016 に合わせててんこ盛り＆急ぎすぎた？

53. Mesos も試そう
続きは M3 tech meetup #3 で
Docker ネタのスピーカー募集中!!