Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

8,227 views

Published on

JAWS-UG横浜 #10 - Docker #jawsug
https://jawsug-yokohama.connpass.com/event/60066/
平成29年7月19日(水)の発表資料配布バージョン(スクリプト付き)です。

入口としての「そもそもDockerとは」から、最新の更新情報まで。

Published in: Software

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

  1. 1. 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. 2. 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. 3. 3 Dockerコンテナ? その前に、Dockerやコンテナについてのお復習いから始めましょう。
  4. 4. “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のライトニングトークで発表。 目的は、依存関係(関連するライブラリ、ソースコード、設定ファイル、ミドルウェア)をまとめて、簡単に動かせるように。
  5. 5. “Docker allows you to package an application with all of its dependencies into a standardized unit for software development.” www.docker.com 全ての依存関係をパッケージ化して、コンテナとして動かす 5 なぜ、このような考えが必要に至ったのでしょうか?
  6. 6. サービスを 提供したい 開発 環境 テスト 環境 準備 環境 本番 環境 都度、環境構築課題 異なるOS環境課題 都度、プロビジョニング課題 動かない課題 時間がかかる課題 遅い課題 面倒課題 アプリを 動かしたい 6 2013年といえば、日本でも「クラウド・コンピューティング」が注目された時代。しかし、環境の差異は必ずあり、そのまま動かない。 みなさんのPC上の仮想マシンを、クラウド上に移動するのは現実的でしょうか。無理ですよね。ネットワークの帯域や料金面で。
  7. 7. サービスを 提供したい 開発 環境 テスト 環境 準備 環境 本番 環境 都度、環境構築課題 異なるOS環境課題 都度、プロビジョニング課題 動かない課題 時間がかかる課題 遅い課題 面倒課題 アプリを 動かしたい コンテナ 開発 テスト 準備 本番 7 これを「コンテナ」(Container)を使って解決しよう、しかも、コマンドライン上の簡単な操作によって、 Dockerさえあれば、どこにでも動くような環境を作ろうという流れがポイントになります。
  8. 8. ┌──────────────────────┐ │ドッカースウォームが あらわれた! │ │ドッカーコンポーズが あらわれた! │ │コマンド? │ │ ∨ │ └━━━━━━━━━━━━━━━━━━━━━━┘ ┌────┐ │ていじで │ │かえろう │ └━━━━┘ ┌──────コマンド─────┐ │ たたかう じゅもん │ │ にげる げんじつとうひ │ └━━━━━━━━━━━━━━━┘ > しかし、Dockerそのものは、ある日突然現れた「敵」の様な存在ではありません。 これまであった Linux カーネル上の「技術」を使っているからです。
  9. 9. 技術と仕様 Technology Specification コンテナ Docker 9 よく混乱されがちですが、Dockerは既存の「Linuxカーネルのコンテナ技術」を、Dockerという仕組みで使います。 また、いわゆる「コンテナ技術」と呼ばれるものは、複数の技術を組みあわせた総称としての「コンテナ状態」と言えるでしょう。
  10. 10. 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. 11. 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)を実現します。 1つのホスト上でありながら、コンテナ内のプロセス空間はお互いが分かれています。しかし、ホスト上からは普通に見えます。
  12. 12. 12 コンテナAの ファイルシステム … … コンテナBの ファイルシステム /etc /bin /etc /bin / / / /etc /data /data/ubuntu /data/centos /bin コンテナのファイルシステム 例えばファイルシステムの名前空間も同様です。コンテナ内でお互いのルート以下は独立しており互いが見えません。 しかし、実体としてはホスト上のディレクトリをchrootしている状態なのです。またcgroupsも使ってプロセスツリーも管理します。
  13. 13. 13 コンテナAの ファイルシステム … … コンテナBの ファイルシステム /etc (/data/ubuntu/etc) /bin (/data/ubuntu/bin) /etc (/data/centos/etc) /bin (/data/centos/bin) / / コンテナの実行 それでは、コンテナの「実行」とは何を指すのでしょうか。具体的には、まずファイルシステム(ディスク領域のようなもの)が ホスト上にあり、この中に何らかのファイルがあります。ここでは「httpd」と「ruby」です。 httpd ruby
  14. 14. 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. 15. 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. 16. 16 技術と仕様 Technology Specification コンテナ Docker 以上がLinuxカーネルを使った技術。ではDockerは何をしているのかというと、このコンテナ状態のプロセスを動かすため Linuxカーネルとの仲介や、そのコンテナを実行する元となる「Dockerイメージ」を提供します。いわば、実装仕様です。
  17. 17. 17 Dockerイメージ • イメージ・レイヤの積み重ね • 読み込み専用 Dockerコンテナ • イメージ・レイヤを1つのファイルシステムとみなす • 読み書き可能なイメージ・レイヤを持つ 特に重要なのは、イメージに対する理解。これは仮想マシン・イメージとは全く異なります。目的は移動(ship)のしやすさの実現。 実体はtarでアーカイブされたファイル群と、メタ情報(何のコマンドを実行するか、ポートを開く等)を含み、親子関係を持つ。
  18. 18. ベース・イメージ (公式のubuntu等) イメージ層読み込み専用 (Read Only) ・新しいイメージ・レイヤの 自動的な割り当て ・イメージ内のプログラムを 独立したプロセスで実行 (コンテナ化された状態) Dockerコンテナの実行とは
  19. 19. 19 Dockerコンテナ起動時に必要なのは、新しい読み書き可能なレイヤだけ。だから、仮想マシンに比べ起動は速いのです。 また、移動やコピーも全てのレイヤを複製する必要はなく、差分としてのレイヤだけしか必要としないため、移動しやすい。
  20. 20. 20 3つの Docker 標準ネットワークモデル bridge (bridge) host (host) none (null) ブリッジ(bridge0 …) veth eth0 ethX そして、ネットワークも少々独自の概念(仕様)。 コンテナはデフォルトではホスト側のIPアドレス を持てません。ホスト側のポート重複も NG です。
  21. 21. 21 3つの Docker 標準ネットワークモデル bridge (bridge) ブリッジ(bridge0 …) veth eth0 ethX none (null) host (host) 複数のブリッジ(ネットワーク)を定義できる デフォルトのbridge0ブリッジは、旧仕様の ネットワークで、挙動が異なるコンテナ(のプロセス)ごとにネットワークは分 かれており、デフォルトはブリッジです。実体は iptablesとTCP/UDPのプロキシの組み合わせ。
  22. 22. 22 3つの Docker 標準ネットワークモデル bridge (bridge) host (host) none (null) ブリッジ(bridge0 …) veth eth0 ethX ホスト側のネットワークに直接接続 ブリッジのオーバーヘッドがない一方で、 セキュリティに対する考慮が必要ホスト側のインターフェースに直結するホスト モードもあります。ネットワークに直接ポートを 開きたい場合や、オーバヘッドを避けたい場合。
  23. 23. 23 3つの Docker 標準ネットワークモデル bridge (bridge) host (host) ブリッジ(bridge0 …) veth eth0 ethX ネットワークを追加しない限り疎通できない none (null) あるいは、インターフェースを持たないものも。
  24. 24. 24 3つの Docker 標準ネットワークモデル bridge (bridge) host (host) none (null) ブリッジ(bridge0 …) veth eth0 ethX NAT (iptables) + docker-proxy ホストと ネットワーク 共通 疎通しない コンテナはパブリックなIPアドレスを持ない ホスト側のポート番号を重複して、コンテナ のポート利用(マッピング)はできない 動的なネットワークの追加・変更・削除
  25. 25. 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. 26. 26 データの扱い コンテナA専用 ファイル階層 File System … / /bin /etc /var コンテナB専用 ファイル階層 File System … / /bin /etc /var もう1つ「仕様」に関することで、データの扱いがあります。 繰り返しとなりますが、個々のコンテナはファイルシステムが独立してるため、
  27. 27. 27 データの扱い コンテナA専用 ファイル階層 File System … / /bin /etc /var コンテナB専用 ファイル階層 File System … / /bin /etc /var hello.txt ×別のコンテナから、別のコンテナ内のファイルを参照できません。 なぜ、こうなっているかというと、単純にファイルシステムが名前空間で分けられているだけではありません。
  28. 28. 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を通して、 複数のディレクトリ(レイヤ)を1つに見せます。ディスクでいうマウントポイントが異なるので、単純に互いが見えません。 個々のコンテナのマウントポイントが 違うためお互いは見えない BA UFS Union File System
  29. 29. 29 データ・ボリューム コンテナA専用 ファイル階層 File System … / /bin /etc /var コンテナからはUFSを通してデータ領域が見える ストレージ・ドライバのオーバヘッドを受けない 複数のコンテナでボリュームを共有できる volume /data / ボリューム Volume /var/lib/docker/volumes/HOST Root File System ではどうしたらよいでしょう。そこで「ボリューム」の活用です。ボリュームはDockerのイメージ・レイヤ管理外です。 コンテナ(のプロセス)はアクセスできま、外付けドライブのような扱いができます。
  30. 30. 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 を通して、コンテナ上からは1つのファイルシステムとして見える状態が出来上がります。 Dockerでは、持続して残したい(persistent)データを、このボリュームに置くべきという考えがあります。これも仕様ですね。 利用者は意識せず、 1つのシステム上で 見える、見えるぞっ!!
  31. 31. 31 ボリュームは3分類 ホストをマウント 名前付き ホスト上のディレクトリ /docker/data /data 名前無し volume ボリュームの実体は、ホスト上のディレクトリ /var/lib/docker/volumes ボリュームはコンテナ間でデータを共有できる volume /data /data /etc そして、このボリュームを通し、 コンテナ(のプロセスおよびファイルシステム)間やホスト上でファイルの共有が可能になります。
  32. 32. 32 でも、コンテナって 前からあったよね?
  33. 33. 33 確かにコンテナ技術と呼ばれるものはありました。元々は Unix Version 7の流れ、chroot、jail を汲むものですし、 Linux Kernel の LXC など、確かに技術はありました。しかし、このようにコンテナが「野晒し」では実現できないことがあります。
  34. 34. 34 どこでも簡単に移動して実行する、電車や船、あるいは 流れ作業の仕組みを提供するのが Docker なのです。
  35. 35. 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. 36. 36 Docker Hub Dockerイメージの保管と共有をするためのリポジトリ(倉庫) そして、イメージを移動するための中継点としてリポジトリの概念があります。コードを書かれる方は GitHub にコードを公開・共有 できるように、Docker イメージの公開・共有・CI/CDで中継する場所としての Docker Hub などリポジトリがあります。
  37. 37. 37 構築・移動・実行 Build Ship Run あらゆるアプリケーションを するためのプラットフォーム 以上が Docker のポイントです。
  38. 38. 38 DockerとDocker Hubの操作と概念 https://www.slideshare.net/zembutsu/docker-container-image-command-introduction-2017-03 より詳しい情報の続きはウェブで…
  39. 39. 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. 40. 40 バージョン表記と名前
  41. 41. 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版=商用サポート版の2つのラインがありました。
  42. 42. 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年.月」の形式と変更になり、 「コミュニティ・エディション」と「エンタープライズ・エディション」の2つのラインの提供に変わりました。
  43. 43. 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」の2つのラインです。Edgeは毎月更新ですが、バグ修正など翌月までのサポートです。。 安定して使いたい場合にはStableを使うべきでしょう。Stableリリース付きはEdgeリリースがないので注意が必要です。
  44. 44. 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. 45. 45 Community Edition DockerCE Enterprise Edition DockerEE For Servers For Desktops For Cloud Providers なお、今回からLinuxで対応しているOS環境は、従来の商用サポート版の対応OSとは変わったので注意が必要です。
  46. 46. 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. 47. 47 マルチステージ・ビルドと引数
  48. 48. 48 マルチステージ・ビルド multi-stage builds 1つの 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 のように 指定可能 注目すべきはこちらです。これまでもやろうと思えばできたのですが、1つの Dockerfile で扱えるようになったのが ポイントです。目的は容量を小さくするため。より小さなイメージで、移動やCI/CDも速くしたい。 Dockerfile
  49. 49. 49 従来のビルド 1 2 3 4 図にすると、こちら。これまでは常に一方通行でした。キャッシュ機能がビルド時に働くので、 途中経過に変化がなければビルドが省略されるものの、基本は一方通行。
  50. 50. 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. 51. 51 ビルド時の引数にFROMが対応 Allow using build-time args (ARG) in FROM Dockerfile の中でビルド時に変数 を使う機能があり、FROM にも対応 した 複数イメージ(タグ)の動的な作成、 マルチステージ・ビルドとの併用で 構築時間の短縮・効率化 これは何? どう活用? ARG TAG=latest FROM centos:${TAG} Dockerfile デフォルト値の指定を忘れずに そして地味にもう1つ。FROMでタグが使えるようになりました(従来は指定できませんでした)。 これにより、開発時のイメージ切り替えも、割とスムーズ委なります。
  52. 52. 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. 53. 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軽く超えてしまいますので・・・
  54. 54. 54
  55. 55. 55 Dockerの目指す所である、アプリケーションの Build・Ship・Run を どこでも簡単にできる下地が整った、それが今回の v17.06 Stable の目玉と言えるでしょう。
  56. 56. 56 Swarmmodeの機能追加
  57. 57. 57 Docker Engine エ ン ジ ン $ docker run … $ docker run … $ docker run … $ docker run … 簡単にSwarmについて解説。今回のバージョンで Composeファイルを扱えるよう、swarm モードがより強化されました。 「複数のコンテナ」をどう扱うか。通常のEngineは、複数のコンテナを操作するのに、毎回コマンド実行が必要。疲れます。
  58. 58. 58 Docker Swarm ス ウ ォ ー ム $ docker run … $ docker run … $ docker run … $ docker run … また、複数台の環境では Docker Swarm というクラスタ管理するツールがありますが、環境の切り替えが面倒です。 ※この後説明する「Docker内蔵のDocker Swarmモード」とは仕組みが異なります。
  59. 59. 59 59 • 複数のコンテナを一斉に 操作できない • 複数台のサーバ上で一斉に 操作できない 管理が 面倒
  60. 60. “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. 61. 61 “Fast, isolated development environments using Docker” www.fig.sh そこで Fig (フィグ)、イチジクですね、というツールが登場しました。 複数のコンテナ群をまとめて管理しようという、コマンドラインツール。
  62. 62. 62 “Fast, isolated development environments using Docker” www.fig.sh サードパーティ製のツールでしたが、Docker, Inc.に買収され、
  63. 63. 63 Docker Compose コ ン ポ ー ズ “Compose is a tool for defining and running multi-container Docker applications.” Docker Compose という名称になりました。 複数コンテナによる Docker アプリケーションを定義し、実行するツール。
  64. 64. 64 例えると複数のコンテナを「梱包」して、 まとめて管理・実行できるようにしたもの。
  65. 65. 65 Mastodon たとえば、分散ソーシャルネットワークとして有名な Mastodon は、 普通に環境を作ろうとすると結構面倒です。熟練者でも、環境構築には数十分ほど必要とするでしょう。
  66. 66. 66 なぜなら、こんなに環境の設定が必要だからです。 ちょっと骨が折れます。心も折れそうになります。 Mastodon
  67. 67. 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ファイルを通して管理可能になるのです。
  68. 68. 内部分散ステート・ストア Internal Distrubuted State Store マネージャ Manager マネージャ Manager マネージャ Manager ワーカ Worker ワーカ Worker ワーカ Worker ワーカ Worker ワーカ Worker ワーカ Worker swarm mode しかも、Docker swarm で構成されたクラスタを通して、Compose ファイルの操作可能になりました。 以前のバージョンでは swarm(という名前のクラスタ)を組む所まででしたが、Compose の機能が一部取り込まれました。
  69. 69. 69 docker stack それが docker stack コマンドです。
  70. 70. 70 docker stack deploy -c docker-compose.yml [NAME] docker service は「サービス」単位 docker stack は「アプリケーション全体」かつ swarm mode で Docker Compose 互換機能を提供 ポイント 従来必要だった「docker-compose」のバイナリを必要とせず、かつ、 はじめから docker swarm で構成されたクラスタ上で実行するサービス群を定義できるようになりました。
  71. 71. 71 docker stack deploy -c docker-compose.yml [NAME] あれ、Compose は要らない子……?というわけではありません(※現時点では)。これまでどおり、 1つのホスト上で使うには便利なツールですし、swarm を使っていない場合には必要だからです。
  72. 72. 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. 73. 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(コンテナ配置条件/制約)も指定可能になりました。
  74. 74. Docker Swarm Docker Compose Docker Engine swarm mode docker stack Compose format v3 最近の様子として「追加モジュール」を必要とせず、Docker Swarm はクラスタを作成・管理する「swarm モード」へ、 Docker Compose は Swarm 上の ”docker deploy” で管理するなど、Engine に機能集約されつつあるように見えます。
  75. 75. 75 Docker Compose入門~今日から始めるComposeの初歩からswarm mode対応まで https://www.slideshare.net/zembutsu/docker-compose-and-swarm-mode-orchestration より詳しい情報の続きはウェブで…
  76. 76. 76 その他のトピック
  77. 77. 77 volume volume volume 分散環境においてボリュームを共有する手段を Docker Engine は提供しない(swarm modeでさえ) 先ほどの swarm モードですが、現状ではまだ足りない機能があります。それは、分散環境でどのようにデータを扱うべきなのか。 もしかしたら、Docker Engine の管轄外(ボリューム・プラグインに依存?)の領域かもしれません。
  78. 78. 78 swarm mode ≠ Docker Swarm 192.168.10.1 192.168.10.11 192.168.10.12 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. 79. 79 docker service create -p 80:80 ¥ --replicas 2 ¥ --name=web ¥ --constraint 'node.role != manager' ¥ zembutsu/docker-sample-nginx サービス作成時のテクニックの1つとして「--constraint」オプションを使い、どのノードで起動するか きめ細やかな制御ができます。ここではroleを指定していますが、任意のラベルや、docker system info の情報も扱えます。
  80. 80. 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. 81. 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. 82. 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" # 巡回設定には少なくとも1つの巡回エンドポイントが必要: # ここでは 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. 83. 83 ローカルホスト用DNS名 for client ※EXPERIMENTAL docker.for.mac.localhost docker.for.win.localhost あとは、こちらですね。Docker CE for Desktop では、ローカル環境のコンテナ(サービス)にアクセスするとき、 ホスト名を使っての接続が出来ます。手順書の作成や、テスト作成時に役立つのではないでしょうか。
  84. 84. 84 振り返り
  85. 85. 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 をご覧ください。
  86. 86. 私からは以上です ありがとうございました
  87. 87. 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
  88. 88. 何か気になる所がありますか? ご参考:Docker 日本語ドキュメント http://docs.docker.jp/ http://slideshare.net/zembutsu twitter: @zembutsu

×