Docker技術情報アップデート v1.9 ネットワークとオーケストレーション

Docker技術情報アップデート
v1.9-ネットワークとオーケストレーション
2015年12月10日(木)
DockerCon EU 2015 Catch Up
@zembutsu
Technology Evangelist; Creationline, Inc.
Networking and Orchestration
背景画像CREDIT:スフィア / PIXTA(ピクスタ)

2
スライドで得られる知識
Docker技術情報アップデート 2015年12月号
‣ Docker コンテナの復習と 1.9
‣ Docker 1.9 の新ネットワーク機能
• 「docker network」コマンドで、複数のネットワーク管理機能
• リンク機能(--link)とネットワーキング機能
• マルチホスト・ネットワーキング（オーバレイ・ネットワーク）
‣ オーケストレーションが見えてきた
• Machine・Swarm・Composeがより一体化
• DTR, ORCA, UCP(Universal Control Plane)
前回の発表から半年過ぎました。
振り返ると、ネットワーク機能と
オーケストレーションの連携強化。
これが大きなポイントだと思い、
スライドにまとめたのがこちら。

1 32 4 5 6 7 8 9 10 11 12
2015 Timeline
DockerCon 2015
Docker 1.7 Release
Open Container Initiative
Docker 1.9
Release
LXC 1.0
Release
Docker 1.8,
Toolbox
Release
DockerCon
EU
HashiConf
2010
ギリシャ
金融危機
北陸新幹線開業
COP21
シャーロット
ちゃん
中国株式市場混乱パリ同時多発テロ
官邸ドローン墜落事件
安全保障関連法成立
ISIS情勢
泥沼化
Docker Machine,
Swarm, Compose
Announcement
今年１年を振り返るとDockerを
取り巻く環境は、大きく変化。
関東東北豪雨

Dockerコンテナの復習と1.9
1■□□

サーバ
OS のカーネル空間
Docker サーバ
ユ
ー
ザ
プ
ロ
セ
ス
ユ
ー
ザ
プ
ロ
セ
ス
ユーザ空間
ユ
ー
ザ
プ
ロ
セ
ス
ユーザ空間
• Cgroups
• Namespaces
 mount
 UTS
 IPC
 PID
 Network
 User
コンテナ
https://hub.docker.com/
Docker Hub
(レジストリ)
Docker
クライアント
"docker" デーモン
TCP:2375,TCP:2376(TSL),UnixSocket
Ubuntu
レポジトリ
MySQL
レポジトリ
tag:latest
tag:14.04
…
tag:latest
tag:5.7
…docker run …
Docker
コンテナ
そもそもDockerコンテナとは？
13年3月のPyConでdotCloud社
(当時)のCEO、Hyke氏が発表。
dockerコマンドで簡単にアプリを
コンテナとして動かせるように。

サーバ
Docker サーバ
ユ
ー
ザ
プ
ロ
セ
ス
ユ
ー
ザ
プ
ロ
セ
ス
ユーザ空間
コンテナ
Docker
クライアント
docker run …
Dockerコンテナとはプロセスの
１つ１つを隔離して起動すること。
正確には「隔離」または「分離」
する(英語のisolate)のは、単に
プロセスだけではありません。
ファイルシステムを(chroot風に)
マウントし、ネットワークを持ち、
メモリやCPUリソースの上限を
設定できます。Linuxカーネルの
機能を使います。
あくまでもDockerのホスト側から
は単純にプロセスが起動してい
るだけですし、ファイルシステム
が見えるにすぎません。
もう１つ重要な概念が、Docker
イメージです。Dockerコンテナ
の実行とは、Dockerイメージ上
のプロセスを実行することでもあ
るのです。もしイメージが手許
になければ…？

サーバ
Docker サーバ
ユ
ー
ザ
プ
ロ
セ
ス
ユ
ー
ザ
プ
ロ
セ
ス
ユーザ空間ユーザ空間
• Cgroups
• Namespaces
 mount
 UTS
 IPC
 PID
 Network
 User
コンテナ
https://hub.docker.com/
Docker Hub
(レジストリ)
Docker
クライアント
Ubuntu
レポジトリ
MySQL
レポジトリ
tag:latest
tag:14.04
…
tag:latest
tag:5.7
…docker run …
レジストリ(DockerHub等)から
イメージをダウンロードします。
そして、その中に含まれるプロ
セスを、Dockerコンテナとして
実行するものでした。

• Cgroups
• Namespaces
 mount
 UTS
 IPC
 PID
 Network
 User
そして、そのプロセスの実行を
コンテナを実行していると表現し、
プロセスが停止するとコンテナ
も停止しているものと扱います。

zem@dev:~$ docker run -ti ubuntu /bin/bash
root@bdf6207621c7:/# ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 01:11 ? 00:00:00 /bin/bash
root 16 1 0 01:11 ? 00:00:00 ps -ef
root@bdf6207621c7:/#
コンテナ内のプロセス
Dockerコンテナ内のプロセスは
PIDが「１」です。各々のコンテ
ナは、全てPID「１」として動作
します。

Dockerコンテナ内のプロセスは
PIDが「１」です。しかし、ホス
ト側からは、通常のPIDを持って
います。これはマジックミラーの
ようなものです。ホスト側から
は見えますが、コンテナＡＢは
互いのことが見えません。
/sbin/init
PID 1
alice
PID 2
bob
PID 3
docker
PID 4
httpd
PID 1
コンテナA コンテナB
ruby
PID 1
chris.rb
PID 2
httpd
PID 5
chris.rb
PID 7
ruby
PID 6

root@bdf6207621c7:/# ls
bin dev home lib64 mnt proc run srv tmp var
boot etc lib media opt root sbin sys usr
root@bdf6207621c7:/# df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 20511356 12952564 6493836 67% /
none 20511356 12952564 6493836 67% /
tmpfs 250896 0 250896 0% /dev
shm 65536 0 65536 0% /dev/shm
tmpfs 250896 0 250896 0% /sys/fs/cgroup
/dev/disk/by-label/DOROOT 20511356 12952564 6493836 67% /etc/hosts
tmpfs 250896 0 250896 0% /proc/kcore
tmpfs 250896 0 250896 0% /proc/latency_stats
tmpfs 250896 0 250896 0% /proc/timer_stats
コンテナ内のファイルシステムまた、ファイルシステム（単に
ディレクトリのこと）もコンテナ
ごとに独立していますが、あくま
でもホスト側と共有しているため、
dfで見た時のディスク容量は、
ホスト側のものがそのまま表示
されます。

この図のように、ホスト側にある
ディレクトリが、コンテナ中では、
自分自身の(chrootした）ディレ
クトリしか見えません。
プロセスと同様、コンテナＡＢ
は相互を参照できません（設定
追加で可能になります）
Kernelは共通ですから、ホスト
側とは違うLinuxが動くようにも
見えるでしょう。
/
/etc /bin /data
コンテナAのファイルシステム
… …
コンテナBのファイルシステム
/etc
(/data/ubuntu/etc)
/data/ubuntu /data/centos
/bin
(/data/ubuntu/bin)
/etc
(/data/ubuntu/etc)
/bin
(/data/ubuntu/bin)
/ /

root@bdf6207621c7:/# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
361: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
group default
link/ether 02:42:ac:11:00:25 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.37/16 scope global eth0
inet6 fe80::42:acff:fe11:25/64 scope link
root@bdf6207621c7:/# ip route
default via 172.17.42.1 dev eth0
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.37
コンテナ内のネットワーク
ネットワークも、個々のコンテナ
は別々のIPアドレスを持ちます。
ここでは eth0 に 127.0.0.37 と
いう IP アドレスが割り当てられ
ています。正確にはデフォルトは
ホスト上の docker0 ブリッジを
使用しています。
v1.9 以降は、任意のブリッジを
コンテナに追加したり、外したり
できるようになりました。詳細は
後述します。

root@bdf6207621c7:/# free
total used free shared buffers cached
Mem: 501792 485128 16664 460 127028 164560
-/+ buffers/cache: 193540 308252
Swap: 0 0 0
コンテナ内のメモリ
ディスク領域と同じく、メモリも
ホスト側と共有しています。その
ため、freeコマンドを実行しても、
ホスト側の情報が表示されます。
※個々のコンテナには利用可能
なメモリ上限を設定できます。

root@bdf6207621c7:/# exit
zem@dev:~$ docker stop bdf6207621c7
コンテナの終了
そして、コンテナの終了とは、
PID 1 のプロセスを停止すること
をさします。docker stop や
docker kill コマンドも利用でき
ます。

• Cgroups
• Namespaces
 mount
 UTS
 IPC
 PID
 Network
 User
これがDockerコンテナとDocker
イメージの関係です。コンテナ
で重要なのは、プロセスやファ
イルシステムやネットワークが、
お互いに分かれていること。

17
Docker 1.9
‣ 2015年11月の更新
• Docker Engine 1.9 リリース
– マルチホスト・ネットワーキングのサポート
– ボリューム用プラグインの再設計
• Docker Swarm 1.0.0 リリース
– ネットワーク機能・ボリューム機能のサポート
• Docker Compose 1.5 リリース
– ネットワーク機能の実験的サポート
11月の更新ではDockerエンジン
だけでなく、Swarm・Compose・
Machineの各ツールもバージョン
アップ。一番大きな変更点は、
ネットワーク機能の強化と、新し
い docker network コマンドの
サポートでしょう。

18
‣ Docker Engine 1.9
• Dockerfile 構築時のオプション追加
• イメージの並列取得
• 停止シグナルのカスタマイズ
• AWS CloudWatch ロギングドライバ対応
• docker stats コマンドにディスク I/O データを追加

19
‣ Docker Compose 1.5
• Windows に対応
• Compose ファイル(.yml)で環境変数が利用可能に
• 複数の Compose ファイルを読み込み可能
• ネットワーク機能の統合
• Compose ファイルの構文確認

20
‣ Docker Registry 2.2
• Google Cloud Storage 対応
• 読み込み専用モードのサポート
• ホスト名の設定
• ファイル存在と HTTP ヘルスチェック設定
• HTTP レスポンス・ヘッダ

Docker のネットワーク機能
2■■□ Docker Networking Features

Dockerの動作ホスト
docker0 bridge
eth0 eth0IP: 172.17.0.2 IP: 172.17.0.3
IP: 172.17.0.1
Docker 1.8 以前のネットワーク
これまでのDockerでは、コンテ
ナがホスト側のポートを利用した
り通信するには、docker0ブリッ
ジを通して通信していました。
vtehd... vtehd...

docker0ネットワーク
172.17.0.1/16
eth0 eth0IP: 172.17.0.2 IP: 172.17.0.3
docker0 bridge
IP: 172.17.0.1
veth.. veth..
eth0
ホスト側の
インターフェース
ブリッジ
docker0のブリッジを通し、コン
テナはホスト側やホストの外と
通信できるようになっていました。

コンテナコンテナ
docker0 bridge
IP: 172.17.0.1
デフォルトのブリッジ・ホスト
ネットワーク
Docker 1.9 からのブリッジ・ネットワーク Docker 1.9からは、
複数のブリッジが利用
できるようになります。
eth0 eth0IP: 172.17.0.2 IP: 172.17.0.3

docker0 bridge 任意 bridge
ネットワーク
ユーザ定義
ネットワーク
Docker 1.9 からのブリッジ・ネットワーク
…
Docker 1.9からは、
複数のブリッジが利用
できるようになります。
docker0はデフォルト
のネットワークという
位置付けです。
IP: 172.17.0.1 IP: 172.18.0.1
eth0 eth0
IP: 172.17.0.2 IP: 172.17.0.3
eth1
IP: 172.18.0.12172.18.0.11
eth1

docker0 bridge 任意 bridge
ネットワーク
ユーザ定義
ネットワーク
Docker 1.9 からのブリッジ・ネットワーク
…
詳しくは後述しますが、
これまでのリンク機能
はdocker0ブリッジの
みで利用可能です。
代替機能として新しく
コンテナ名とネット
ワークで名前解決が
可能になります。
IP: 172.17.0.1 IP: 172.18.0.1
eth0 eth0
IP: 172.17.0.2 IP: 172.17.0.3
eth1
IP: 172.18.0.12172.18.0.11
eth1
「--link」機能は
docker 0 ブリッジ
のみ対応
「コンテナ名.net名」で
動的な名前解決可能に
（リンク機能の代替)

172.17.0.1/16
eth0 eth0IP: 172.17.0.2 IP: 172.17.0.3
docker0 bridge
IP: 172.17.0.1
veth.. veth..
ホスト側の
ブリッジ
改めて、先ほどのネットワー
ク図に置き換えますと、従来
はdocker0だけでしたが
eth0

172.17.0.1/16
eth0 eth0IP: 172.17.0.2 IP: 172.17.0.3
docker0 bridge
IP: 172.17.0.1
veth.. veth..
ホスト側の
ブリッジ
Docker1.9からネットワークは
複数のブリッジを持ち、コン
テナも複数のインターフェー
スを持てます。この設定はコ
ンテナの再起動が不要です。
ユーザ定義ネットワーク
172.18.0.1/16
eth0
user bridge
eth1 eth1IP: 172.18.0.2 IP: 172.18.0.3veth.. veth..
IP: 172.18.0.1

172.17.0.1/16
eth0 IP: 172.17.0.3
docker0 bridge
IP: 172.17.0.1
veth..
ホスト側の
ブリッジ
Docker1.9からネットワークは
複数のブリッジを持ち、コン
テナも複数のインターフェー
スを持てます。この設定はコ
ンテナの再起動が不要です。
172.18.0.1/16
eth0
user bridge
eth1 eth1IP: 172.18.0.2 IP: 172.18.0.3veth.. veth..
IP: 172.18.0.1

172.17.0.1/16
docker0 bridge
IP: 172.17.0.1
ホスト側の
ブリッジ
ネットワークを持たないコン
テナ作成も可能です。
（docker run --net=none）
もちろん、あとから追加削除
できます。
172.18.0.1/16
コンテナA コンテナC
eth0
user bridge
eth1 IP: 172.18.0.2veth..
IP: 172.18.0.1

オーバレイ・ネットワーク
$ docker network create --driver overlay internal
172.17.0.2 172.17.0.3 172.18.0.5
192.168.0.3192.168.0.1 192.168.0.2
実際のコンテナ利用において、
複数のサーバで共通のネット
ワーク通信を安全に行う場合
があります。そこで使えるの
が、新しいオーバレイ・ネット
ワーク。

172.17.0.1/16
docker0
bridge
IP: 172.17.0.1
ホスト側の
ブリッジ
overlayネットワーク
192.168.10.1/16
コンテナA
eth0
overlay
network
IP: 192.168.10.1
docker0
bridge
eth0
overlay
network
eth0 IP: 172.17.0.2veth..
コンテナB
ホスト１ホスト２
オーバレイ・ネットワーク
ドライバは、VXLAN技術
(virtual extention lan)
を使い、複数ホスト上に
またがる仮想ネットワーク
の利用が可能です。

172.17.0.1/16
docker0
bridge
IP: 172.17.0.1
ホスト側の
ブリッジ
overlayネットワーク
192.168.10.1/16
コンテナA
eth0
overlay
network
eth1 IP: 192.168.10.2veth..
IP: 192.168.10.1
docker0
bridge
eth0
overlay
network
eth0 IP: 172.17.0.2veth..
eth1 IP: 192.168.10.3veth..
コンテナB
ホスト１ホスト２
ネットワークには、ホスト
毎にネットワークIDが割り
振られます。オーバレイ・
ネットワークの場合、ホス
トが異なってもネットワー
クIDは同じです。
疎通

swarm-kvs
swarm-node0
(master)
swarm-node1
$ docker …
$ docker-compose …
tcp://<ip>:2376 tcp://<ip>:2376tcp://<ip>:2376
$ docker-machine …
docker docker docker
KVS ( consul )
bridge overlaybridge(docker0) bridgeoverlay
swam
master
コンテナ
tcp:8500
eth0: 172.17.0.2 eth0: 172.17.0.2
eth0: 172.17.0.2
eth0: 172.17.0.5
eth0:172.17.0.4
eth1:172.18.0.2 eth1:172.18.0.3

35
docker network コマンド
‣ docker network create  ネットワーク作成
‣ docker network ls  ネットワーク一覧
‣ docker network connect  コンテナに接続
‣ docker network disconnect  切断
‣ docker network rm  ネットワーク削除

36
‣ docker network inspect  ネットワーク調査
‣ docker run --net=<ネットワーク名>

root@demo1210:~# docker network ls
NETWORK ID NAME DRIVER
1a34c54ac517 bridge bridge
97f64692c37a none null
7bfea31360e9 host host
コマンド「network ls」は、ネットワーク一覧を表示
ドライバは４種類
・bridge … bridgeという名前は「docker0」ネットワーク
・host … ホスト・ネットワーキングは、コンテナが直接ホストを参照
・null … コンテナ内に仮想インターフェースを付けないモード
・overlay … 複数ホストにまたがるオーバレイ・ネットワーク

root@demo:~# docker network create front
9959a6e12da55fa6deacffa0146ae351204d8a89d72d900ddde969fdf1f3fe40
root@demo:~# docker network ls
28a6c2d24224 none null
49ef940103f8 host host
9959a6e12da5 front bridge
1ad2e3648872 bridge bridge
新しく「front」という名称のブリッジ・ネットワークを作成・確認
root@demo:~# docker network inspect front
[
{
"Name": "front",
"Id": "9959a6e12da55fa6deacffa0146ae351204d8a89d72d900ddde969fdf1f3fe40",
"Scope": "local",
"Driver": "bridge",
"IPAM": {
"Driver": "default",
"Config": [
{}
]
},
"Containers": {},
"Options": {}
}
]
新しいネットワーク

# docker run -itd --net=front --name=web ubuntu bash
ecc0e1d7ee23792a9bbd5b127e84af5534d66e92b10750413a8ff686c954c44e
root@demo:~# docker network inspect front
[
{
"Name": "front",
…
"Containers": {
"ecc0e1d7ee23792a9bbd5b127e84af5534d66e92b10750413a8ff686c954c44e": {
"EndpointID": "d5f681684213da53f558d34ce3359ac30053c2b2addc22caf99be8271e7bf603",
"MacAddress": "02:42:ac:12:00:02",
"IPv4Address": "172.18.0.2/16",
"IPv6Address": ""
}
},
"Options": {}
}
]
コンテナを「front」ネットワークに作成
(docker0の127.17.0.0/16ではない）

root@demo:~# docker network create back
6afc733feeaf46aaff80c5a605bacba63ae3463d1cfb925a9cdc9d82c3e9184b
root@demo:~# docker network ls
28a6c2d24224 none null
49ef940103f8 host host
9959a6e12da5 front bridge
6afc733feeaf back bridge
1ad2e3648872 bridge bridge
root@demo:~# docker run -itd --net=back --name=db ubuntu bash
0c3da94b22aa6d260a68ec7763e0962b2b273e6656e1d875a0c7c371244ebb41
新しいブリッジネットワーク「back」と、「db」コンテナをそこに作成

root@demo:~# docker exec -it web bash
root@ecc0e1d7ee23:/# ifconfig
eth0 Link encap:Ethernet HWaddr 02:42:ac:12:00:02
inet addr:172.18.0.2 Bcast:0.0.0.0 Mask:255.255.0.0
inet6 addr: fe80::42:acff:fe12:2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:16 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1296 (1.2 KB) TX bytes:648 (648.0 B)
（省略）
「web」コンテナにプロセス bash を追加し、インターフェースを確認

root@demo:~# docker network connect back web
root@ecc0e1d7ee23:/# ifconfig
RX bytes:1296 (1.2 KB) TX bytes:648 (648.0 B)
RX bytes:648 (648.0 B) TX bytes:648 (648.0 B)
「web」「db」の両コンテナをつなげるには？「back」ネットワークに接続

root@ecc0e1d7ee23:/# cat /etc/hosts
172.18.0.2 ecc0e1d7ee23
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.19.0.2 db
172.19.0.2 db.back
さらに/etc/hostsを確認すると、「db」コンテナの名前解決も可能に
「コンテナ名.ネットワーク名」で名前解決
使用例：DB名やキャッシュ・サーバ等
※network connect をした時点で、ping 等、お互いが疎通する
※逆に、dbコンテナ上で/etc/hostsを確認すると、
「172.19.0.3 web.back」の記述が自動的に追加されている

root@0c3da94b22aa:/# cat /etc/hosts
172.19.0.2 0c3da94b22aa
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.19.0.3 web
172.19.0.3 web.back
「db」コンテナ内から「web」コンテナを確認
「ホスト名.ネットワーク名」で名前解決
使用例：DB名やキャッシュ・サーバ等
※webコンテナは172.18.0.2のIPアドレスも持つが、疎通できない。
あくまで web と db コンテナが共通している back ネットワーク内の
IPアドレス体系のみ（ネットワークを追加したら可能）。

ネットワークに関する詳細な情報は
コンテナのネットワーク — Docker-docs-ja 1.9.0b ドキュメント
http://docs.docker.jp/engine/userguide/networkingcontainers.html
Docker コンテナ・ネットワークの理解 — Docker-docs-ja 1.9.0b ドキュメント
http://docs.docker.jp/engine/userguide/networking/dockernetworks.html
【参考訳】 Docker 1.9 発表：Swarm とマルチホスト・ネットワーキングの
プロダクション対応
http://pocketstudio.jp/log3/2015/11/04/docker-1-9-production-ready-ja/
【参考訳】プロダクションに対応するマルチホスト Docker ネットワーク機能
http://pocketstudio.jp/log3/2015/11/04/docker-multi-host-networking-ga/

オーケストレーションが見えてきた
3■■■Docker's Orchestration

┌──────────────────────┐
│ドッカースウォームがあらわれた! │
│ドッカーコンポーズがあらわれた! │
│コマンド? │
│ ∨ │
└━━━━━━━━━━━━━━━━━━━━━━┘
┌────┐
│ていじで │
│かえろう │
└━━━━┘
┌──────コマンド─────┐
│ たたかうじゅもん │
│ にげるげんじつとうひ │
└━━━━━━━━━━━━━━━┘
＞
今年2月の時点では、なんだか
よく分からないツールが出たの？
オーケストレーション何？でした。

2015年2月
v1.5.0 v0.1.0 v1.1.0v0.1.0
experimental experimental
実験的だったツール群は、

2015年12月
v1.9.1 v0.5.2 v1.5.2v1.0.1
どれもβの扱いが外れています。

Docker API
Swarm
Manager
ディスカバリ・バックエンド
リソース・プール
スケジューラ
fleet

Docker環境の管理ツール
仮想サーバ環境
Dockerの自動セットアップ
Swarmクラスタの自動構築
Docker Machine

コンテナのスケジューリング
Docker API と互換性
ディスカバリ・バックエンドと連携
ネットワーク機能に対応

Swarm Manager
machine
docker client
$ docker run
docker engine
(docker daemon)
machine
docker engine
(docker daemon)
machine
docker engine
(docker daemon)
machine
docker engine
(docker daemon)
machine
コンテナ
$ docker-machine env docker01
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://104.131.113.166:2376"
export DOCKER_CERT_PATH="/home/zem/.docker/machine/machines/docker01"
export DOCKER_MACHINE_NAME="docker01"
$ docker run –d –P swarm manage ¥
token://<token>
docker engine
(docker daemon)
コンテナコンテナコンテナコンテナ
Docker互換 API
リソース・プール
ストラテジフィルタ
• spread
• binpack
• randam
• constraint
• affinity
• port
• dependency
• health
コンテナの配置を
スケジューリング
docker machine でデプロイ/プロビジョニング
ディスカバリ・バックエンド

複数のコンテナをコードで管理
コンテナの同時起動・停止
コンテナのスケール
ネットワーク機能に対応（実験的）

web:
image: wordpress
environment:
- "WORDPRESS_DB_HOST=cms_db_1"
- "WORDPRESS_DB_USER=root"
-
"WORDPRESS_DB_PASSWORD=example"
- "constraint:node==swarm-node0"
ports:
- 8080:80
db:
image: mariadb
environment:
MYSQL_ROOT_PASSWORD: example
docker-compose.yml

etcd:
image: gcr.io/google_containers/etcd:2.0.13
container_name: etcd
command: ['/usr/local/bin/etcd', '--bind-addr=0.0.0.0:4001', '--data-dir=/var/etcd/data']
apiserver:
image: gcr.io/google_containers/hyperkube:v1.0.7
container_name: apiserver
ports:
- "8080"
command: ["/hyperkube", "apiserver", "--service-cluster-ip-range=172.17.17.1/24", "--address=0.0.0.0", "--etcd_servers=http://etcd:4001", "--cluster_name=kubernetes", "--v=2"]
controller:
command: ["/hyperkube", "controller-manager", "--address=0.0.0.0", "--master=http://apiserver:8080", "--v=2"]
environment:
- "affinity:container==*apiserver*"
scheduler:
command: ["/hyperkube", "scheduler", "--address=0.0.0.0", "--master=http://apiserver:8080", "--v=2"]
environment:
- "affinity:container==*apiserver*"
kubelet:
command: ['/hyperkube', 'kubelet', '--containerized' , '--api_servers=http://apiserver:8080', '--v=2', '--address=0.0.0.0', '--enable_server']
volumes:
- /:/rootfs:ro
- /sys:/sys:ro
- /dev:/dev
- /var/run/docker.sock:/var/run/docker.sock
- /var/lib/docker/:/var/lib/docker:ro
- /var/lib/kubelet/:/var/lib/kubelet:rw
- /var/run:/var/run:rw
privileged: true
# A kubelet shouldn't run alongside another kubelet - One privileged kubelet per node
environment:
- "affinity:container!=*kubelet*"
proxy:
command: ['/hyperkube', 'proxy', '--master=http://apiserver:8080', '--v=2']
privileged: true
# A proxy should run alongside another kubelet
environment:
- "affinity:container==*kubelet*"
これはComposeの設定ファイル
例です。複雑なコンテナの構成
だとしても、Composeのコマンド
１つで構築できます。

引用：Deploy and Manage Any Cluster Manager with Docker Swarm | Docker Blog
http://blog.docker.com/2015/11/deploy-manage-cluster-docker-swarm/
Docker Machineによって作られ
たSwarmクラスタ上だとしても
Composeが利用可能です。

swarm-kvs
swarm-node0
(master)
swarm-node1
$ docker …
$ docker-compose …
tcp://<ip>:2376 tcp://<ip>:2376tcp://<ip>:2376
$ docker-machine …
docker docker docker
KVS ( consul )
bridge overlaybridge(docker0) bridgeoverlay
swam
master
コンテナ
tcp:8500
eth0: 172.17.0.2 eth0: 172.17.0.2
eth0: 172.17.0.2
eth0: 172.17.0.5
eth0:172.17.0.4
eth1:172.18.0.2 eth1:172.18.0.3
DigitalOcean上の環境を
あらかじめ作成しておき
ました。

$ docker-machine ls
NAME ACTIVE DRIVER STATE URL SWARM
default - virtualbox Stopped
demo - digitalocean Running tcp://188.166.210.114:2376
demo1210 * digitalocean Running tcp://188.166.212.234:2376
dodocker - digitalocean Error tcp://188.166.218.71:2376
swarm-kvs - digitalocean Running tcp://188.166.223.150:2376
swarm-node0 - digitalocean Running tcp://188.166.223.157:2376 swarm-node0 (master)
swarm-node1 - digitalocean Running tcp://188.166.223.165:2376 swarm-node0
あらかじめ Docker Machine で Swarm クラスタを構築済みでした
手許PC(Windows)から、dockerクライアントで直接Swarmを操作できます
$ eval $(docker-machine env --swarm swarm-node0)
このSwarmクラスタ上で、WordPressを分散配置します。

$ docker info
Containers: 6
Images: 7
Role: primary
Strategy: spread
Filters: health, port, dependency, affinity, constraint
Nodes: 2
swarm-node0: 188.166.223.157:2376
m Containers: 4
m Reserved CPUs: 0 / 1
m Reserved Memory: 0 B / 514 MiB
m Labels: executiondriver=native-0.2, kernelversion=3.16.0-41-generic, operatingsystem=Ubuntu
14.04.3 LTS, provider=digitalocean, storagedriver=aufs
swarm-node1: 188.166.223.165:2376
m Containers: 2
m Reserved CPUs: 0 / 1
m Reserved Memory: 0 B / 514 MiB
m Labels: executiondriver=native-0.2, kernelversion=3.16.0-41-generic, operatingsystem=Ubuntu
14.04.3 LTS, provider=digitalocean, storagedriver=aufs
CPUs: 2
Total Memory: 1.004 GiB
Name: bea1b4473d7c
Swarm manager で docker info を実行すると、クラスタ情報を表示します。

$ docker network create cms
$ docker network ls
660a83d7dceb swarm-node1/none null
2f172240c30a swarm-node1/docker_gwbridge bridge
f31873cbef24 cms overlay
570d49557344 swarm-node1/bridge bridge
91a996769d0d swarm-node1/host host
64b008dee355 swarm-node0/docker_gwbridge bridge
7031059b130a swarm-node0/bridge bridge
cmsという名称のオーバレイ・ネットワークを作成します。
※dockerクライアントが操作しているのは、Swarmクラスタです。
特に明示しなければ、自動的にoverlayネットワークが有効になっています。
ただし、この機能はSwarmの各ノードが Linux 3.16以上の必要があります。

$ docker-compose --x-networking --x-network-driver overlay up –d
$ docker-compose ps
Name Command State Ports
--------------------------------------------------------------------------------------------
98531c0a86_cms_web_1 /entrypoint.sh apache2-for ... Up 188.166.223.157:8080->80/tcp
cms_db_1 /docker-entrypoint.sh mysqld Up 3306/tcp
Compose を使って、WordPressを起動します。
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS
PORTS NAMES
ebf14768eacb mariadb "/docker-entrypoint.s" 6 days ago Up 26 hours
3306/tcp swarm-node1/cms_db_1
98531c0a8643 wordpress "/entrypoint.sh apach" 6 days ago Up 26 hours
188.166.223.157:8080->80/tcp swarm-node0/98531c0a86_cms_web_1
直接Swarmのリソースプールを操作。コンテナにホスト名が付与されています。
同一ネットワーク上に、Docker Swarm のストラテジとフィルタに従い
コンテナは自動的にスケジューリングされました。
（デフォルトは分散の Spread ストラテジ）

より詳細な情報は
Dockerのoverlayネットワークでコンテナを分散実行 - Qiita
http://qiita.com/zembutsu/items/4cd756ff8be4be76e5a3
docker - 参考訳：マルチホスト・ネットワーキングを始めよう - Qiita
http://qiita.com/zembutsu/items/36032ee78e82278b3c6a

tutum
https://www.tutum.co/
Docker社が買収(10月)
AWS, Digital Ocean, Azure,
SoftLayer, Packet と連携
コンテナのデプロイと管理
Docker Hub を補完する役割
その他の細かなトピックを紹介。

Docker Hub Tutum
パブリック環境でコンテナを実行

DTR
Docker Trusted Registry
Orca (beta) + UCP
Universal Control Plane
より安全にコンテナを実行
https://www.docker.com/universal-control-plane

72
まとめ
‣ Docker 1.9 の新ネットワーク機能
• 「docker network」コマンドで、複数のネットワーク管理機能
• リンク機能(--link)とネットワーキング機能
• マルチホスト・ネットワーキング（オーバレイ・ネットワーク）
‣ オーケストレーションが見えてきた
• Machine・Swarm・Composeがより一体化
• DTR, ORCA, UCP(Universal Control Plane)

73
何か気になる所はありますか？
‣ SwarmとKubernetesとの違いは？
• かつては同じようなクラスタ管理を指向していたように思えます。
今年のDockrCon以降は、Swarmはあくまで
コンテナ実行基盤としてのクラスタ管理に
特化しているように見えます。
KubernetesやMesos等の高度なコンテナの
スケジューリングは提供していません。
そこはプラグインのような形態で、利用者に
使い分けを求めているのかもしれません。

Docker に関するより詳細な情報は
Dockerドキュメント日本語化プロジェクト
http://docs.docker.jp/
・Docker Engine
・Docker Machine
・Docker Swarm
・Docker Compose
v1.9 対応

Docker技術情報アップデート v1.9 ネットワークとオーケストレーション

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Docker技術情報アップデート v1.9 ネットワークとオーケストレーション

Similar to Docker技術情報アップデート v1.9 ネットワークとオーケストレーション (20)

More from Masahito Zembutsu

More from Masahito Zembutsu (20)

Docker技術情報アップデート v1.9 ネットワークとオーケストレーション