Docker 17.06 Updates 最近何が変わったの？

1
Docker 17.06 Updates
Engineer / Technology Evangelist, SAKURA Internet, Inc.
@zembutsu 前佛雅人 ZEMBUTSU Masahito
2017年7月19日(水) JAWS-UG 横浜 #jawsug
What’s new in new release

2
Docker CE 17.06 stable の何が新しいの？
バージョン表記と名前
Community Edition / Edge and Stable
マルチステージ・ビルドと引数
Multi-stage builds support and build-time args
メトリクスとログの取得
Engine’s Metrics and service log
--volume オプション
mount type=bind
Swarmモード機能拡張
Swarm mode enhancement
ホスト用DNS名
Experimental DNS Name for the Host
for
client
Docker v1.13.1(17.03)以降の主な変更点をまとめました。
利用者サイドで大きな影響が考えられるのは、このあたりです。

3
Dockerコンテナ？
その前に、Dockerやコンテナについてのお復習いから始めましょう。

“Docker allows you to package an application
with all of its dependencies into a standardized
unit for software development.”
www.docker.com
全ての依存関係をパッケージ化して、コンテナとして動かす
4
そもそもDocker（ドッカー）が登場した背景は、こちらです。2013年のPythonカンファレンスUSのライトニングトークで発表。
目的は、依存関係（関連するライブラリ、ソースコード、設定ファイル、ミドルウェア）をまとめて、簡単に動かせるように。

www.docker.com
5
なぜ、このような考えが必要に至ったのでしょうか？

サービスを
提供したい
開発
環境
テスト
環境
準備
環境
本番
環境
都度、環境構築課題異なるOS環境課題
都度、プロビジョニング課題動かない課題
時間がかかる課題遅い課題面倒課題
アプリを
動かしたい
6
2013年といえば、日本でも「クラウド・コンピューティング」が注目された時代。しかし、環境の差異は必ずあり、そのまま動かない。
みなさんのPC上の仮想マシンを、クラウド上に移動するのは現実的でしょうか。無理ですよね。ネットワークの帯域や料金面で。

サービスを
提供したい
開発
環境
テスト
環境
準備
環境
本番
環境
都度、環境構築課題異なるOS環境課題
都度、プロビジョニング課題動かない課題
時間がかかる課題遅い課題面倒課題
アプリを
動かしたい
コンテナ
開発テスト準備本番
7
これを「コンテナ」(Container）を使って解決しよう、しかも、コマンドライン上の簡単な操作によって、
Dockerさえあれば、どこにでも動くような環境を作ろうという流れがポイントになります。

┌──────────────────────┐
│ドッカースウォームがあらわれた! │
│ドッカーコンポーズがあらわれた! │
│コマンド? │
│ ∨ │
└━━━━━━━━━━━━━━━━━━━━━━┘
┌────┐
│ていじで │
│かえろう │
└━━━━┘
┌──────コマンド─────┐
│ たたかうじゅもん │
│ にげるげんじつとうひ │
└━━━━━━━━━━━━━━━┘
＞
しかし、Dockerそのものは、ある日突然現れた「敵」の様な存在ではありません。
これまであった Linux カーネル上の「技術」を使っているからです。

技術と仕様
Technology Specification
コンテナ Docker
9
よく混乱されがちですが、Dockerは既存の「Linuxカーネルのコンテナ技術」を、Dockerという仕組みで使います。
また、いわゆる「コンテナ技術」と呼ばれるものは、複数の技術を組みあわせた総称としての「コンテナ状態」と言えるでしょう。

10
OS ( Linux )
物理/仮想サーバ
Docker エンジン
( dockerd デーモン )
Linux kernel
コンテナコンテナコンテナ
リモート
API
docker
クライアント TCP あるいは
Unix ソケットドメイン
containerd
Runtime: runC (OCI規格準拠)
・docker コマンド
Linux, Mac OS X, Windows
・Docker Compose
Docker はサーバ・クライアント型モデル
技術に入る前に、Dockerは「docker」という名前のCLIで操作します。
これがサーバ(Dockerエンジン)にAPIでアクセスし、DockerエンジンはLinuxカーネルの複数の技術を操作します。

11
httpd
PID 1
コンテナA コンテナB
ruby
PID 1
chris.rb
PID 2
/sbin/init
PID 1
containerd
PID 5
httpd
PID 6
ruby
PID 7
chris.rb
PID 8
alice
PID 2
bob
PID 3
PPID 1 PPID 1
PPID 4
PPID 5 PPID 5
PPID 7
PPID 1
dockerd
PID 4
コンテナのプロセス
namespaces(名前空間)は複数あり、代表的なものがプロセス空間の分離(isolate)を実現します。
１つのホスト上でありながら、コンテナ内のプロセス空間はお互いが分かれています。しかし、ホスト上からは普通に見えます。

12
コンテナAの
ファイルシステム
… …
コンテナBの
/etc /bin /etc /bin
/ /
/
/etc /data
/data/ubuntu /data/centos
/bin
コンテナのファイルシステム
例えばファイルシステムの名前空間も同様です。コンテナ内でお互いのルート以下は独立しており互いが見えません。
しかし、実体としてはホスト上のディレクトリをchrootしている状態なのです。またcgroupsも使ってプロセスツリーも管理します。

13
コンテナAの
… …
コンテナBの
/etc
(/data/ubuntu/etc)
/bin
(/data/ubuntu/bin)
/etc
(/data/centos/etc)
/bin
(/data/centos/bin)
/ /
コンテナの実行
それでは、コンテナの「実行」とは何を指すのでしょうか。具体的には、まずファイルシステム（ディスク領域のようなもの）が
ホスト上にあり、この中に何らかのファイルがあります。ここでは「httpd」と「ruby」です。
httpd ruby

14
コンテナAの
… …
コンテナBの
/etc
(/data/ubuntu/etc)
/bin
(/data/ubuntu/bin)
/etc
(/data/centos/etc)
/bin
(/data/centos/bin)
/ /
httpd
PID 1
プロセスA プロセスB
ruby
PID 1
chris.rb
PID 2
httpd ruby
そして、各ファイルシステム内にあるファイルを使って、プロセスを起動します。
この時、複数のnamespace技術およびcgroupsでプロセス空間等やリソースを制限した形で、起動できるのです。

15
コンテナA コンテナB
名前空間の isolate
・プロセス
・ファイルシステム
・ネットワーク
・ホスト名
・UID・GID
リソース制限
・CPU
・メモリ
・I/O
・ディスク・クォータ
そして、両プロセスはプロセス空間等が分離(isolate)されたままなので、（基本状態では）お互いが見えません。
つまり、「コンテナを実行する」とは「コンテナ状態のプロセスを起動する」とも言えるでしょう。
Linuxホスト
コンテナAの
… …
コンテナBの
/etc
(/data/ubuntu/etc)
/bin
(/data/ubuntu/bin)
/etc
(/data/centos/etc)
/bin
(/data/centos/bin)
/ /
httpd
PID 1
プロセスA プロセスB
ruby
PID 1
chris.rb
PID 2

16
技術と仕様
Technology Specification
コンテナ Docker
以上がLinuxカーネルを使った技術。ではDockerは何をしているのかというと、このコンテナ状態のプロセスを動かすため
Linuxカーネルとの仲介や、そのコンテナを実行する元となる「Dockerイメージ」を提供します。いわば、実装仕様です。

17
Dockerイメージ
• イメージ・レイヤの積み重ね
• 読み込み専用
Dockerコンテナ
• イメージ・レイヤを１つのファイルシステムとみなす
• 読み書き可能なイメージ・レイヤを持つ
特に重要なのは、イメージに対する理解。これは仮想マシン・イメージとは全く異なります。目的は移動(ship)のしやすさの実現。
実体はtarでアーカイブされたファイル群と、メタ情報（何のコマンドを実行するか、ポートを開く等）を含み、親子関係を持つ。

ベース・イメージ
(公式のubuntu等)
イメージ層読み込み専用
(Read Only)
・新しいイメージ・レイヤの
自動的な割り当て
・イメージ内のプログラムを
独立したプロセスで実行
(コンテナ化された状態）
Dockerコンテナの実行とは

19
Dockerコンテナ起動時に必要なのは、新しい読み書き可能なレイヤだけ。だから、仮想マシンに比べ起動は速いのです。
また、移動やコピーも全てのレイヤを複製する必要はなく、差分としてのレイヤだけしか必要としないため、移動しやすい。

20
３つの Docker 標準ネットワークモデル
bridge
(bridge)
host
(host)
none
(null)
ブリッジ(bridge0 …)
veth
eth0
ethX
そして、ネットワークも少々独自の概念（仕様）。
コンテナはデフォルトではホスト側のIPアドレス
を持てません。ホスト側のポート重複も NG です。

21
bridge
(bridge)
veth
eth0
ethX
none
(null)
host
(host)
複数のブリッジ（ネットワーク）を定義できる
デフォルトのbridge0ブリッジは、旧仕様の
ネットワークで、挙動が異なるコンテナ（のプロセス）ごとにネットワークは分
かれており、デフォルトはブリッジです。実体は
iptablesとTCP/UDPのプロキシの組み合わせ。

22
bridge
(bridge)
host
(host)
none
(null)
veth
eth0
ethX
ホスト側のネットワークに直接接続
ブリッジのオーバーヘッドがない一方で、
セキュリティに対する考慮が必要ホスト側のインターフェースに直結するホスト
モードもあります。ネットワークに直接ポートを
開きたい場合や、オーバヘッドを避けたい場合。

23
bridge
(bridge)
host
(host)
veth
eth0
ethX
ネットワークを追加しない限り疎通できない
none
(null)
あるいは、インターフェースを持たないものも。

24
bridge
(bridge)
host
(host)
none
(null)
veth
eth0
ethX
NAT
(iptables)
+
docker-proxy
ホストと
ネットワーク
共通
疎通しない
コンテナはパブリックなIPアドレスを持ない
ホスト側のポート番号を重複して、コンテナ
のポート利用（マッピング）はできない
動的なネットワークの追加・変更・削除

25
コンテナは複数のネットワーク（ブリッジ）に接続できる
ブリッジ1(bridge)
veth
eth0
ethX
各ネットワーク内部では、動的なコンテナ名
（サービス）の名前解決機能（サービス・ディス
カバリ）を標準提供
eth0 eth1 eth0
ブリッジ2(bridge)
veth192.168.0.1
172.18.0.2 172.18.0.3 172.19.0.2 172.19.0.3
172.19.0.1
172.19.0.0/16172.19.0.0/16
サービス・ディスカバリ連携の負荷分散
そして、分かれているネットワークを、ブリッジを
介在して接続することも可能です。動的な追加・
削除・変更をおこなえます。

26
データの扱い
コンテナA専用
ファイル階層
File System
…
/
/bin
/etc
/var
コンテナB専用
ファイル階層
File System
…
/
/bin
/etc
/var
もう１つ「仕様」に関することで、データの扱いがあります。
繰り返しとなりますが、個々のコンテナはファイルシステムが独立してるため、

27
データの扱い
コンテナA専用
ファイル階層
File System
…
/
/bin
/etc
/var
コンテナB専用
ファイル階層
File System
…
/
/bin
/etc
/var
hello.txt
×別のコンテナから、別のコンテナ内のファイルを参照できません。
なぜ、こうなっているかというと、単純にファイルシステムが名前空間で分けられているだけではありません。

28
データの扱い
コンテナA専用
ファイル階層
File System
…
/
/bin
/etc
/var
コンテナB専用
ファイル階層
File System
…
/
/bin
/etc
/var
hello.txt
HOST Root
File System
/var/lib/docker/overlay/
hello.txtディレクトリはストレージドライバによって異なる
A
B
UFS
Union File
System
Dockerイメージとはイメージ・レイヤ（image layer)の集合体です。実体は、ホスト上のUFSを通して、
複数のディレクトリ（レイヤ）を１つに見せます。ディスクでいうマウントポイントが異なるので、単純に互いが見えません。
個々のコンテナのマウントポイントが
違うためお互いは見えない
BA
UFS
Union File
System

29
データ・ボリューム
コンテナA専用
ファイル階層
File System
…
/
/bin
/etc
/var
コンテナからはUFSを通してデータ領域が見える
ストレージ・ドライバのオーバヘッドを受けない
複数のコンテナでボリュームを共有できる
volume
/data
/
ボリューム
Volume
/var/lib/docker/volumes/HOST Root
File System
ではどうしたらよいでしょう。そこで「ボリューム」の活用です。ボリュームはDockerのイメージ・レイヤ管理外です。
コンテナ（のプロセス）はアクセスできま、外付けドライブのような扱いができます。

30
コンテナ
ファイル階層
File System
/
UFS ( Union File System)
…
/
/bin
/var
Docker
イメージ
Docker Image
/var/lib/docker/image/
volume
/
ボリューム
Volume
/data
コンテナ用
イメージ層
Container’s
Image Layer
/
/var/lib/docker/volumes//var/lib/docker/containers/
ReadOnly
そうしておけば、UFS を通して、コンテナ上からは１つのファイルシステムとして見える状態が出来上がります。
Dockerでは、持続して残したい(persistent)データを、このボリュームに置くべきという考えがあります。これも仕様ですね。
利用者は意識せず、
１つのシステム上で
見える、見えるぞっ！！

31
ボリュームは３分類
ホストをマウント名前付き
ホスト上のディレクトリ
/docker/data
/data
名前無し
volume
ボリュームの実体は、ホスト上のディレクトリ
/var/lib/docker/volumes
ボリュームはコンテナ間でデータを共有できる
volume
/data /data /etc
そして、このボリュームを通し、
コンテナ（のプロセスおよびファイルシステム）間やホスト上でファイルの共有が可能になります。

32
でも、コンテナって
前からあったよね？

33
確かにコンテナ技術と呼ばれるものはありました。元々は Unix Version 7の流れ、chroot、jail を汲むものですし、
Linux Kernel の LXC など、確かに技術はありました。しかし、このようにコンテナが「野晒し」では実現できないことがあります。

34
どこでも簡単に移動して実行する、電車や船、あるいは
流れ作業の仕組みを提供するのが Docker なのです。

35
Dockerと愉快な仲間達
Build Run開発・構築移動実行
Ship
“Build, Ship, Run, Any App Anywhere”
Docker Engine for Linux / Commercial Support
Docker for Mac, Windows, Windows Server 2016
Docker Trusted Registry
Docker Hub
Universal Control Plane
Toolbox
Kitematic
Dev
(開発)
Ops
(運用)

36
Docker Hub
Dockerイメージの保管と共有をするためのリポジトリ（倉庫）
そして、イメージを移動するための中継点としてリポジトリの概念があります。コードを書かれる方は GitHub にコードを公開・共有
できるように、Docker イメージの公開・共有・CI/CDで中継する場所としての Docker Hub などリポジトリがあります。

37
構築・移動・実行
Build Ship Run
あらゆるアプリケーションを
するためのプラットフォーム
以上が Docker のポイントです。

38
DockerとDocker Hubの操作と概念
https://www.slideshare.net/zembutsu/docker-container-image-command-introduction-2017-03
より詳しい情報の続きはウェブで…

39
mount type=bind
ホスト用DNS名
for
client
それでは、改めて変更点についてみていきましょう。

40

v1.13
41
v1.12v1.11v1.10
Docker Engine (Open Source)
2017-01-182016-07-282016-04-132016-02-05
Docker Engine (CS; Commercial Support)
これまでDockerはリリース以来、バージョン番号を通常通り連番で振ってきていました。
また、オープンソース版とCS版＝商用サポート版の２つのラインがありました。

v1.13
42
v1.12v1.11v1.10
Docker Engine (Open Source)
2017-01-182016-07-282016-04-132016-02-05
Docker Engine (CS; Commercial Support)
v17.03
Community Edition
CE
v17.03
Enterprise Edition
EE
Docker 1.13.1から「v年.月」の形式と変更になり、
「コミュニティ・エディション」と「エンタープライズ・エディション」の２つのラインの提供に変わりました。

43
Community Edition
DockerCE
Edge
Stable
v17.03 v17.04 v17.05 v17.06 v17.07 v17.08 v17.09 v17.10
Edgeは毎月
Stableは四半期ごと
コミュニティ版は「Edge」と「Stable」の２つのラインです。Edgeは毎月更新ですが、バグ修正など翌月までのサポートです。。
安定して使いたい場合にはStableを使うべきでしょう。Stableリリース付きはEdgeリリースがないので注意が必要です。

44
Community Edition
DockerCE
Enterprise Edition
DockerEE
4ヶ月ごとに定期リリース
各バージョンを1年サポート
Edge
Stable
v17.03 v17.04 v17.05 v17.06 v17.07 v17.08 v17.09 v17.10
Announcing Docker Enterprise Edition - Docker Blog
https://blog.docker.com/2017/03/docker-enterprise-edition/
Edgeは毎月
Stableは四半期ごと

45
Community Edition
DockerCE
Enterprise Edition
DockerEE
For
Servers
For
Desktops
For Cloud
Providers
なお、今回からLinuxで対応しているOS環境は、従来の商用サポート版の対応OSとは変わったので注意が必要です。

infrakit linuxKit runC containerD Notary swarmKit
46
Community Edition
DockerCE
Enterprise Edition
DockerEE
自由に使えるDocker
(Engine)
商用サポート版
一
般
利
用
開
発
プ
ロ
ジ
ェ
ク
ト
オープンソースのフレームワーク
・各コンポーネントの統合
・ “moby” CLI ツール
先日のDockerConではmoby(モビー)プロジェクトも発表されました。これは従来の docker/docker 開発リポジトリが
moby/moby に移行し、各機能毎に分割されています（現在進行形）。これをベースに四半期毎にDocker CE/EEが出ます。

47

48
マルチステージ・ビルド
multi-stage builds
１つの Dockerfile で複数の
イメージ（中間イメージ）を作成、
ASで名前付けし、必要なバイナリ等
のみ最終イメージに入れられる
開発段階のイメージと、実行時の
イメージを分けることで、イメージ
容量を小さくできる
これは何？
どう活用？
FROM <image>:<tag> AS A
RUN ...
FROM <image>:<tag> AS B
RUN ...
FROM alpine
COPY --from=A /<dir> .
COPY --from=B <dir2>/<file> .
ビルダーの名前を AS で定義
省略時は –from=0 のように
指定可能
注目すべきはこちらです。これまでもやろうと思えばできたのですが、１つの Dockerfile で扱えるようになったのが
ポイントです。目的は容量を小さくするため。より小さなイメージで、移動やCI/CDも速くしたい。
Dockerfile

49
従来のビルド
1 2 3 4
図にすると、こちら。これまでは常に一方通行でした。キャッシュ機能がビルド時に働くので、
途中経過に変化がなければビルドが省略されるものの、基本は一方通行。

50
マルチステージ・ビルド
multi-stage builds
1 2
3
4
AS “A”
AS “B”
COPY --from
必要なものだけ
コピー可能
docker build --target=B
docker build --target=A
複数の FROM で AS を指定しておけば、「--target」指定で、そこからビルドさせることもできますし、
「--from」を使ってデータを参照可能になったところも大きいです。うまく活用できれば、ビルド時間の短縮に役立つでしょう。

51
ビルド時の引数にFROMが対応
Allow using build-time args (ARG) in FROM
Dockerfile の中でビルド時に変数
を使う機能があり、FROM にも対応
した
複数イメージ（タグ）の動的な作成、
マルチステージ・ビルドとの併用で
構築時間の短縮・効率化
これは何？
どう活用？
ARG TAG=latest
FROM centos:${TAG}
Dockerfile デフォルト値の指定を忘れずに
そして地味にもう１つ。FROMでタグが使えるようになりました（従来は指定できませんでした）。
これにより、開発時のイメージ切り替えも、割とスムーズ委なります。

52
ビルド時の引数にFROMが対応
Allow using build-time args (ARG) in FROM
ARG TAG=latest
FROM centos:${TAG}
$ docker image build --build-arg TAG=6 .
Sending build context to Docker daemon 2.048kB
Step 1/2 : ARG TAG=latest
--->
Step 2/2 : FROM centos:${TAG}
6: Pulling from library/centos
8b04204cfecd: Pull complete
Digest:
sha256:921219d7d53186068ca5043bf6d8922ac7646562b61478dd7f
e503f2fac45290
Status: Downloaded newer image for centos:6
---> 3e32556ae4ba
Successfully built 3e32556ae4ba
$ docker image build --build-arg TAG=7 .
Sending build context to Docker daemon 2.048kB
Step 1/2 : ARG TAG=latest
--->
Step 2/2 : FROM centos:${TAG}
7: Pulling from library/centos
7b6bb4652a1b: Pull complete
Digest:
sha256:c1010e2fe2b635822d99a096b1f4184becf5d1c98707cbccae
00be663a9b9131
Status: Downloaded newer image for centos:7
---> 36540f359ca3
Successfully built 36540f359ca3
「docker build –build-arg」でタグを指定しておけば、Dockerfileを編集したり、複数用意しなくても、
複数バージョンのイメージを選択したり、複数バージョンのタグを持つイメージ生成も容易です。
Dockerfile

53
Alpine Linux
https://alpinelinux.org/
$ docker images ls
REPOSITORY TAG IMAGE ID CREATED SIZE
alpine latest a41a7446062d 11 days ago 3.96MB
そして、今年に入ってDocker公式イメージで「alpine」のタグ（文字）を頻繁に見るようになってきましたね。
魅力は、たった4MBでLinuxが動くところ。一般的なディストリビューションであれば100MB軽く超えてしまいますので・・・

55
Dockerの目指す所である、アプリケーションの Build・Ship・Run を
どこでも簡単にできる下地が整った、それが今回の v17.06 Stable の目玉と言えるでしょう。

57
Docker Engine
エンジン
$ docker run …
$ docker run …
$ docker run …
$ docker run …
簡単にSwarmについて解説。今回のバージョンで Composeファイルを扱えるよう、swarm モードがより強化されました。
「複数のコンテナ」をどう扱うか。通常のEngineは、複数のコンテナを操作するのに、毎回コマンド実行が必要。疲れます。

58
Docker Swarm
スウォーム
$ docker run …
$ docker run …
$ docker run …
$ docker run …
また、複数台の環境では Docker Swarm というクラスタ管理するツールがありますが、環境の切り替えが面倒です。
※この後説明する「Docker内蔵のDocker Swarmモード」とは仕組みが異なります。

59
59
• 複数のコンテナを一斉に
操作できない
• 複数台のサーバ上で一斉に
操作できない
管理が
面倒

www.docker.com
60
これって、Dockerの目指す所から離れています。
簡単に実行するのが目的だったのに・・・

61
“Fast, isolated development environments
using Docker”
www.fig.sh
そこで Fig （フィグ）、イチジクですね、というツールが登場しました。
複数のコンテナ群をまとめて管理しようという、コマンドラインツール。

62
“Fast, isolated development environments
using Docker”
www.fig.sh
サードパーティ製のツールでしたが、Docker, Inc.に買収され、

63
Docker Compose
コンポーズ
“Compose is a tool for
defining and running
multi-container Docker
applications.”
Docker Compose という名称になりました。
複数コンテナによる Docker アプリケーションを定義し、実行するツール。

64
例えると複数のコンテナを「梱包」して、
まとめて管理・実行できるようにしたもの。

65
Mastodon
たとえば、分散ソーシャルネットワークとして有名な Mastodon は、
普通に環境を作ろうとすると結構面倒です。熟練者でも、環境構築には数十分ほど必要とするでしょう。

66
なぜなら、こんなに環境の設定が必要だからです。
ちょっと骨が折れます。心も折れそうになります。
Mastodon

67
redis
:alpine
postgres
:alpine
サービスサービス
イメージイメージ
nginx
:alpine
サービス
イメージ
gargron/mastodon
:v1.4.6
サービス
イメージ
gargron/mastodon
:v1.4.6
サービス
イメージ
gargron/mastodon
:v1.4.6
サービス
イメージ
namshi/smtp
:latest
サービス
イメージ
https://github.com/tootsuite/mastodon
ネットワーク
192.168.0.0/16 mastdon (external)
ホスト側ネットワーク
eth0等
mastodon_postgresmastodon_redis certbot
(external)
assets packs system
volumevolume volume volume volume volume
80 443
80 443
services:
volumes:
networks:
しかし、Compose を使えば、複雑なアプリケーションやネットワーク設定、データの管理を
YAMLファイルを通して管理可能になるのです。

内部分散ステート・ストア
Internal Distrubuted State Store
マネージャ
Manager
マネージャ
Manager
マネージャ
Manager
ワーカ
Worker
ワーカ
Worker
ワーカ
Worker
ワーカ
Worker
ワーカ
Worker
ワーカ
Worker
swarm mode
しかも、Docker swarm で構成されたクラスタを通して、Compose ファイルの操作可能になりました。
以前のバージョンでは swarm（という名前のクラスタ）を組む所まででしたが、Compose の機能が一部取り込まれました。

69
docker stack
それが docker stack コマンドです。

70
docker stack deploy -c docker-compose.yml [NAME]
docker service は「サービス」単位
docker stack は「アプリケーション全体」かつ
swarm mode で Docker Compose 互換機能を提供
ポイント
従来必要だった「docker-compose」のバイナリを必要とせず、かつ、
はじめから docker swarm で構成されたクラスタ上で実行するサービス群を定義できるようになりました。

71
docker stack deploy -c docker-compose.yml [NAME]
あれ、Compose は要らない子……？というわけではありません（※現時点では）。これまでどおり、
１つのホスト上で使うには便利なツールですし、swarm を使っていない場合には必要だからです。

72
$ docker stack deploy -c docker-compose.yml web
Creating service web_web
$ docker stack ps web
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE
ERROR PORTS
uhm1xxq1u70w web_web.1 zembutsu/docker-sample-nginx:latest frontend-01 Running Running 45
seconds ago
ccmokdadpjqx web_web.2 zembutsu/docker-sample-nginx:latest frontend-02 Running Running 28
seconds ago
cflckriidpt0 web_web.3 zembutsu/docker-sample-nginx:latest frontend-03 Running Running 33
seconds ago
$ docker stack services web
ID NAME MODE REPLICAS IMAGE PORTS
yunncblhngu6 web_web replicated 3/3 zembutsu/docker-sample-nginx:latest *:80->80/tcp
= docker service ps web
＝ docker service ls
swarm modeでは「docker service」コマンドでサービス群を管理していました。
同様に、docker deploy コマンドを使ったあとは互換性のある「docker stack」コマンドでサービス群を管理します。

73
version: '3'
services:
web:
image: zembutsu/docker-sample-nginx
deploy:
replicas: 3
resources:
limits:
cpus: "0.1"
restart_policy:
condition: on-failure
ports:
- "80:80"
networks:
internal:
aliases:
- web
volumes:
- /etc/localtime:/etc/localtime:ro
networks:
internal:
ちなみに、Composeの設定ファイルは YAML 形式です。最新の v3 フォーマットでは、swarm クラスタ上で、
いくつコンテナを実行するか（レプリカ数の指定）や、constraint（コンテナ配置条件／制約）も指定可能になりました。

Docker Swarm
Docker Compose
Docker Engine
swarm mode
docker
stack
Compose format
v3
最近の様子として「追加モジュール」を必要とせず、Docker Swarm はクラスタを作成・管理する「swarm モード」へ、
Docker Compose は Swarm 上の ”docker deploy” で管理するなど、Engine に機能集約されつつあるように見えます。

75
Docker Compose入門～今日から始めるComposeの初歩からswarm mode対応まで
https://www.slideshare.net/zembutsu/docker-compose-and-swarm-mode-orchestration
より詳しい情報の続きはウェブで…

77
volume volume volume
分散環境においてボリュームを共有する手段を
Docker Engine は提供しない（swarm modeでさえ）
先ほどの swarm モードですが、現状ではまだ足りない機能があります。それは、分散環境でどのようにデータを扱うべきなのか。
もしかしたら、Docker Engine の管轄外（ボリューム・プラグインに依存？）の領域かもしれません。

78
swarm mode ≠ Docker Swarm
１９２．１６８．１０．１１９２．１６８．１０．１１１９２．１６８．１０．１2
public IP address public IP address public IP addresseth0
eth1
docker swarm init ¥
--advertise-addr=eth0 ¥
--data-path-addr=192.168.10.1
docker swarm join ¥
--token <TOKEN> ¥
<public_IP>:2377
Manager Worker
なお v17.06 からは、swarm クラスタ用（Raftによる相互通信など）に使用するポートと、データ転送用のポートを分離
出来るようになりました。これにより、大量データ転送時、ネットワーク帯域が飽和しクラスタが不安定になるリスクを軽減。
--advertise-addr
--data-path-addr

79
docker service create -p 80:80 ¥
--replicas 2 ¥
--name=web ¥
--constraint 'node.role != manager' ¥
zembutsu/docker-sample-nginx
サービス作成時のテクニックの１つとして「--constraint」オプションを使い、どのノードで起動するか
きめ細やかな制御ができます。ここではroleを指定していますが、任意のラベルや、docker system info の情報も扱えます。

80
volume volume
NFS
Server nfs
client
nfs
client
docker service create -p 80:80 ¥
--replicas 2 --name=web --constraint 'node.role != manager' ¥
--mount type=bind,source=/volumes/docroot/,destination=/usr/share/nginx/html/,bind-propagation=shared ¥
zembutsu/docker-sample-nginx
--mount は docker run / docker service に対応
他には「--mount」オプションも導入されました。これは docker の –v の機能拡張であり、swarm モードでも利用可能です。
詳細な追加オプションもあります。ただし、swarm ではデータ同期機能はなく、あくまでマウントポイントの指定のみ。

81
監視用Metricsの機能追加
{
"metrics-addr" : "127.0.0.1:9323",
"experimental" : true
}
/etc/docker/daemon.json
$ curl -s http://127.0.0.1:9323/metrics | head
# HELP builder_builds_failed_total Number of failed image builds
# TYPE builder_builds_failed_total counter
builder_builds_failed_total{reason="build_canceled"} 0
builder_builds_failed_total{reason="build_target_not_reachable_error"} 0
builder_builds_failed_total{reason="command_not_supported_error"} 0
builder_builds_failed_total{reason="dockerfile_empty_error"} 0
builder_builds_failed_total{reason="dockerfile_syntax_error"} 0
builder_builds_failed_total{reason="error_processing_commands_error"} 0
builder_builds_failed_total{reason="missing_onbuild_arguments_error"} 0
builder_builds_failed_total{reason="unknown_instruction_error"} 0
※EXPERIMENTAL
他には Docker Engine のデーモンオプションで、監視用メトリクスの出力をサポートしました。
dockerコマンドやAPIを加工しなくても、ダイレクトに値を取れます。Prometheus 対応のデータフォーマットです。

82
監視用Metricsの機能追加
/etc/docker/daemon.json
# my global config
global:
scrape_interval: 15s # 巡回を15秒ごとにする。デフォルトは1分おき
evaluation_interval: 15s # 評価を15秒ごとにする。デフォルトは1分おき
# scrape_timeout 巡回タイムアウトはグローバルのデフォルト (10s)
# 外部システム（federation,remote storage, Alertmanager）との通信時、あらゆる時系列やアラートにラベルを付ける
external_labels:
monitor: 'codelab-monitor'
# グローバルな 'evaluation_interval' に従い、ローカルルールを読み込み定期的に評価
rule_files:
# - "first.rules"
# - "second.rules"
# 巡回設定には少なくとも１つの巡回エンドポイントが必要：
# ここでは Prometheus 自身
scrape_configs:
# この設定により、あらゆる時系列データにジョブ名としてのラベル `job=<job_name>` を付与
- job_name: 'prometheus'
# metrics_path はデフォルトで '/metrics'
# スキーマはデフォルト 'http'.
static_configs:
- targets: ['localhost:9090']
- job_name: 'docker'
# metrics_path はデフォルトで '/metrics'
# スキーマはデフォルト 'http'.
static_configs:
- targets: ['localhost:9323']
Prometheus.yml
※EXPERIMENTAL
{
"metrics-addr" : "127.0.0.1:9323",
"experimental" : true
}
Prometheus.yml 側で target を先のエンドポイントに指定すると、サービスの状態やクラスタ上のメトリクスも
取得できるようになりました。ただし、実験的導入であり、将来的にエンドポイントやメトリクス名が変わる可能性があります。

83
ローカルホスト用DNS名
for
client
※EXPERIMENTAL
docker.for.mac.localhost
docker.for.win.localhost
あとは、こちらですね。Docker CE for Desktop では、ローカル環境のコンテナ（サービス）にアクセスするとき、
ホスト名を使っての接続が出来ます。手順書の作成や、テスト作成時に役立つのではないでしょうか。

mount type=bind
ホスト用DNS名
for
client
他にも細かく追加された機能や変わっている所があります。
詳しくは、リリースノート https://github.com/docker/docker-ce/releases をご覧ください。

私からは以上です
ありがとうございました

References
Announcing Docker 17.06 Community Edition (CE) - Docker Blog
https://blog.docker.com/2017/06/announcing-docker-17-06-community-edition-ce/
Docker CE release notes | Docker Documentation
https://docs.docker.com/release-notes/docker-ce/
What’s New in Docker - Victor Vieux, Docker
https://www.slideshare.net/Docker/whats-new-in-docker-victor-vieux-docker

何か気になる所がありますか？
ご参考：Docker 日本語ドキュメント
http://docs.docker.jp/
http://slideshare.net/zembutsu
twitter: @zembutsu

Docker 17.06 Updates 最近何が変わったの？

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Docker 17.06 Updates 最近何が変わったの？

Semelhante a Docker 17.06 Updates 最近何が変わったの？ (20)

Mais de Masahito Zembutsu

Mais de Masahito Zembutsu (20)

Docker 17.06 Updates 最近何が変わったの？