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のライトニングトークで発表。

目的は、依存関係（関連するライブラリ、ソースコード、設定ファイル、ミドルウェア）をまとめて、簡単に動かせるように。

“Docker allows you to package an application

with all of its dependencies into a standardized

unit for software development.”www.docker.com

全ての依存関係をパッケージ化して、コンテナとして動かす

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

サービスを提供したい

開発環境

テスト環境

準備環境

本番環境

都度、環境構築課題 異なるOS環境課題

都度、プロビジョニング課題 動かない課題

時間がかかる課題 遅い課題 面倒課題アプリを

動かしたい

62013年といえば、日本でも「クラウド・コンピューティング」が注目された時代。しかし、環境の差異は必ずあり、そのまま動かない。

みなさんの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 ソケットドメイン

containerdRuntime: runC (OCI規格準拠)

・docker コマンドLinux, Mac OS X, Windows

・Docker Compose

Docker はサーバ・クライアント型モデル

技術に入る前に、Dockerは「docker」という名前のCLIで操作します。これがサーバ(Dockerエンジン)にAPIでアクセスし、DockerエンジンはLinuxカーネルの複数の技術を操作します。

11

httpdPID 1

コンテナA コンテナB

rubyPID 1

chris.rbPID 2

/sbin/initPID 1

containerdPID 5

httpdPID 6

rubyPID 7

chris.rbPID 8

alicePID 2

bobPID 3

PPID 1 PPID 1

PPID 4

PPID 5 PPID 5

PPID 7

PPID 1

dockerdPID 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)

/ /

httpdPID 1

プロセスA プロセスB

rubyPID 1

chris.rbPID 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)

/ /

httpdPID 1

プロセスA プロセスB

rubyPID 1

chris.rbPID 2

16

技術と仕様Technology Specification

コンテナ Docker

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

17

Dockerイメージ• イメージ・レイヤの積み重ね

• 読み込み専用

Dockerコンテナ• イメージ・レイヤを１つのファイルシステムとみなす

• 読み書き可能なイメージ・レイヤを持つ

特に重要なのは、イメージに対する理解。これは仮想マシン・イメージとは全く異なります。目的は移動(ship)のしやすさの実現。実体はtarでアーカイブされたファイル群と、メタ情報（何のコマンドを実行するか、ポートを開く等）を含み、親子関係を持つ。

ベース・イメージ(公式のubuntu等)

イメージ層読み込み専用(Read Only)

・新しいイメージ・レイヤの自動的な割り当て

・イメージ内のプログラムを独立したプロセスで実行(コンテナ化された状態）

Dockerコンテナの実行とは

19Dockerコンテナ起動時に必要なのは、新しい読み書き可能なレイヤだけ。だから、仮想マシンに比べ起動は速いのです。

また、移動やコピーも全てのレイヤを複製する必要はなく、差分としてのレイヤだけしか必要としないため、移動しやすい。

20

３つの Docker 標準ネットワークモデル

bridge(bridge)

host(host)

none(null)

ブリッジ(bridge0 …)

veth

eth0

ethXそして、ネットワークも少々独自の概念（仕様）。コンテナはデフォルトではホスト側のIPアドレスを持てません。ホスト側のポート重複も NG です。

21

３つの Docker 標準ネットワークモデル

bridge(bridge)

ブリッジ(bridge0 …)

veth

eth0

ethX

none(null)

host(host)

複数のブリッジ（ネットワーク）を定義できる

デフォルトのbridge0ブリッジは、旧仕様のネットワークで、挙動が異なるコンテナ（のプロセス）ごとにネットワークは分

かれており、デフォルトはブリッジです。実体はiptablesとTCP/UDPのプロキシの組み合わせ。

22

３つの Docker 標準ネットワークモデル

bridge(bridge)

host(host)

none(null)

ブリッジ(bridge0 …)

veth

eth0

ethX

ホスト側のネットワークに直接接続

ブリッジのオーバーヘッドがない一方で、セキュリティに対する考慮が必要ホスト側のインターフェースに直結するホスト

モードもあります。ネットワークに直接ポートを開きたい場合や、オーバヘッドを避けたい場合。

23

３つの Docker 標準ネットワークモデル

bridge(bridge)

host(host)

ブリッジ(bridge0 …)

veth

eth0

ethX

ネットワークを追加しない限り疎通できない

none(null)

あるいは、インターフェースを持たないものも。

24

３つの Docker 標準ネットワークモデル

bridge(bridge)

host(host)

none(null)

ブリッジ(bridge0 …)

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

UFSUnion File

System

Dockerイメージとはイメージ・レイヤ（image layer)の集合体です。実体は、ホスト上のUFSを通して、複数のディレクトリ（レイヤ）を１つに見せます。ディスクでいうマウントポイントが異なるので、単純に互いが見えません。

個々のコンテナのマウントポイントが違うためお互いは見えない

BA

UFSUnion 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 SupportDocker 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

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

それでは、改めて変更点についてみていきましょう。

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

Docker CE

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

Docker CE

Enterprise Edition

Docker EE

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 Bloghttps://blog.docker.com/2017/03/docker-enterprise-edition/

Edgeは毎月Stableは四半期ごと

45

Community Edition

Docker CEEnterprise Edition

Docker EE

For

Servers

For

Desktops

For Cloud

Providers

なお、今回からLinuxで対応しているOS環境は、従来の商用サポート版の対応OSとは変わったので注意が必要です。

infrakit linuxKit runC containerD Notary swarmKit

46

Community Edition

Docker CEEnterprise Edition

Docker EE

自由に使えるDocker(Engine)

商用サポート版

一般利用

開発

プロジェクト

オープンソースのフレームワーク

・ 各コンポーネントの統合・ “moby” CLI ツール

先日のDockerConではmoby(モビー)プロジェクトも発表されました。これは従来の docker/docker 開発リポジトリがmoby/moby に移行し、各機能毎に分割されています（現在進行形）。これをベースに四半期毎にDocker CE/EEが出ます。

47

マルチステージ・ビルドと引数

48

マルチステージ・ビルド

multi-stage builds

１つの Dockerfile で複数のイメージ（中間イメージ）を作成、ASで名前付けし、必要なバイナリ等のみ最終イメージに入れられる

開発段階のイメージと、実行時のイメージを分けることで、イメージ容量を小さくできる

これは何？

どう活用？

FROM <image>:<tag> AS ARUN ...

FROM <image>:<tag> AS BRUN ...

FROM alpineCOPY --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=latestFROM centos:${TAG}

Dockerfile デフォルト値の指定を忘れずに

そして地味にもう１つ。FROMでタグが使えるようになりました（従来は指定できませんでした）。これにより、開発時のイメージ切り替えも、割とスムーズ委なります。

52

ビルド時の引数にFROMが対応

Allow using build-time args (ARG) in FROM

ARG TAG=latestFROM centos:${TAG}

$ docker image build --build-arg TAG=6 .Sending build context to Docker daemon 2.048kBStep 1/2 : ARG TAG=latest--->

Step 2/2 : FROM centos:${TAG}6: Pulling from library/centos8b04204cfecd: Pull completeDigest: sha256:921219d7d53186068ca5043bf6d8922ac7646562b61478dd7fe503f2fac45290Status: Downloaded newer image for centos:6---> 3e32556ae4ba

Successfully built 3e32556ae4ba

$ docker image build --build-arg TAG=7 .Sending build context to Docker daemon 2.048kBStep 1/2 : ARG TAG=latest--->

Step 2/2 : FROM centos:${TAG}7: Pulling from library/centos7b6bb4652a1b: Pull completeDigest: sha256:c1010e2fe2b635822d99a096b1f4184becf5d1c98707cbccae00be663a9b9131Status: Downloaded newer image for centos:7---> 36540f359ca3

Successfully built 36540f359ca3

「docker build –build-arg」でタグを指定しておけば、Dockerfileを編集したり、複数用意しなくても、複数バージョンのイメージを選択したり、複数バージョンのタグを持つイメージ生成も容易です。

Dockerfile

53

Alpine Linux

https://alpinelinux.org/

$ docker images lsREPOSITORY TAG IMAGE ID CREATED SIZEalpine latest a41a7446062d 11 days ago 3.96MB

そして、今年に入ってDocker公式イメージで「alpine」のタグ（文字）を頻繁に見るようになってきましたね。魅力は、たった4MBでLinuxが動くところ。一般的なディストリビューションであれば100MB軽く超えてしまいますので・・・

54

55Dockerの目指す所である、アプリケーションの Build・Ship・Run を

どこでも簡単にできる下地が整った、それが今回の v17.06 Stable の目玉と言えるでしょう。

56

Swarm mode の機能追加

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

• 複数のコンテナを一斉に操作できない

• 複数台のサーバ上で一斉に操作できない

管理が

面倒

“Docker allows you to package an application

with all of its dependencies into a standardized

unit for software development.”

www.docker.com

60

全ての依存関係をパッケージ化して、コンテナとして動かす

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

61

“Fast, isolated development environmentsusing Docker”

www.fig.sh

そこで Fig （フィグ）、イチジクですね、というツールが登場しました。複数のコンテナ群をまとめて管理しようという、コマンドラインツール。

62

“Fast, isolated development environmentsusing Docker”

www.fig.sh

サードパーティ製のツールでしたが、Docker, Inc.に買収され、

63

Docker Composeコ ン ポ ー ズ

“Compose is a tool fordefining and running multi-container Dockerapplications.”

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-nginxdeploy:replicas: 3resources:

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

dockerstack

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

より詳しい情報の続きはウェブで…

76

その他のトピック

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 nfsclient

nfsclient

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 counterbuilder_builds_failed_total{reason="build_canceled"} 0builder_builds_failed_total{reason="build_target_not_reachable_error"} 0builder_builds_failed_total{reason="command_not_supported_error"} 0builder_builds_failed_total{reason="dockerfile_empty_error"} 0builder_builds_failed_total{reason="dockerfile_syntax_error"} 0builder_builds_failed_total{reason="error_processing_commands_error"} 0builder_builds_failed_total{reason="missing_onbuild_arguments_error"} 0builder_builds_failed_total{reason="unknown_instruction_error"} 0

※EXPERIMENTAL

他には Docker Engine のデーモンオプションで、監視用メトリクスの出力をサポートしました。dockerコマンドやAPIを加工しなくても、ダイレクトに値を取れます。Prometheus 対応のデータフォーマットです。

82

監視用Metricsの機能追加

/etc/docker/daemon.json

# my global configglobal: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 では、ローカル環境のコンテナ（サービス）にアクセスするとき、ホスト名を使っての接続が出来ます。手順書の作成や、テスト作成時に役立つのではないでしょうか。

84

振り返り

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

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

私からは以上です

ありがとうございました

References

Announcing Docker 17.06 Community Edition (CE) - Docker Bloghttps://blog.docker.com/2017/06/announcing-docker-17-06-community-edition-ce/

Docker CE release notes | Docker Documentationhttps://docs.docker.com/release-notes/docker-ce/

What’s New in Docker - Victor Vieux, Dockerhttps://www.slideshare.net/Docker/whats-new-in-docker-victor-vieux-docker

何か気になる所がありますか？

ご参考：Docker 日本語ドキュメント

http://docs.docker.jp/

http://slideshare.net/zembutsutwitter: @zembutsu