Docker swarm mode 入門と ECS との比較
?
5 likes?2,612 views
Docker 1.11 から 1.12 への変更点の説明と AWS EC2 Container Service との比較
![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](https://image.slidesharecdn.com/dockerswarmmodeandecs-160804051108/85/Docker-swarm-mode-ECS-18-320.jpg)
Docker swarm mode 入門と ECS との比較
- 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 とは
- 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 ネタのスピーカー募集中!!