【18-E-3】クラウド・ネイティブ時代の2016年だから始める Docker 基礎講座

【18-E-3】クラウド・ネイティブ時代の2016年だから始める Docker 基礎講座

1. 1. ク ラ ウ ド ・ ネ イ テ ィ ブ 時 代 の 2 0 1 6 年 だ か ら 始 め る Docker 基礎講座 2016年2月18日(木) @zembutsu Technology Evangelist; Creationline, Inc. Introduction to Docker, because of the age of "cloud native" 背景画像CREDIT:スフィア / PIXTA(ピクスタ) #devsumi #devsumiE
2. 2. 2 今日扱う内容 Docker基礎講座 ‣ 改めて「Docker」とは何か？ 用語の定義と周辺ツール 基本概念の理解（コンテナ、イメージ） ‣ 技術選択の要素 ライフサイクルと検討フロー 技術（技法）の選択とベストプラクティス ‣ 最新動向 (Docker 1.9, 1.10) ネットワーク機能、 Docker Datacenter ( Universal Control Plane + Docker Trusted Registry)
3. 3. 3 今日扱う内容 Docker基礎講座 ‣ 扱うこと 「Dockerをどう使っていくのか？」 ‣ 扱わないこと 「コンテナ技術とは何なのか？」
4. 4. Dockerやコンテナは様々な方や 場所で言及されていますので、 そこを改めて深掘りするのでは なく・・・
5. 5. ピザをどう食べたらいいのか？ いまここにあるDockerを、どのよ うにして使っていけば良いのか？ ピザであれば「どう食べるのか」 という視点で、皆さんと共有した いと思っています。
6. 6. 6 docker 最近の悩み。 みなさん、どう発音しますか？
7. 7. 7 アクセントの悩み docker ／ドッ＼カー ドッ／カー→ ※参考 「NHK日本語発音アクセント辞典」改訂 項目表示形式の検討（2012年） https://www.nhk.or.jp/bunken/summary/research/report/2012_09/20120908.pdf 「クラウド」と同じ悩みであり、 どちらでも構わないと思ってます。 ・・・が正直悩みます。。
8. 8. 改めて「Docker」とは？ 1■□□□ What is the "Docker" ? Again
9. 9. docker ※Docker Glossary https://docs.docker.com/engine/reference/glossary/ Docker プロジェクト Docker デーモン • 開発者やシステム管理者が、 アプリを開発・移動・実行する プラットフォーム • Docker, Inc. はスポンサー primary contributor, maintainer • イメージとコンテナを管理 • ホスト上で動くプロセス • コンテナ技術を使う namespaces, cgroups
10. 10. docker 技術文脈ではDockerデーモンを 「Dockerエンジン」と呼びます。 Docker Engine
11. 11. Dockerが登場は2013年3月。 ようやく３周年になります。
12. 12. Build Ship Run Anywhere Distributed Applications 「Docker」とは、アプリケーションを動かすための仕組みを提供
13. 13. その中心がDockerエンジンとい う位置付けです。
14. 14. 14 開発ツール 公式レポジトリ オペレーティング・システム ビッグデータ サービス・ディスカバリ 構築／CI 設定管理 コンサルタント・トレーニング 管理 ストレージ クラスタ・スケジューリング ネットワーク機能 インフラ＆プロバイダ セキュリティ 監視とログ Dockerエコシステム
15. 15. 基本のおさらい Dockerコンテナとイメージ
16. 16. サーバ 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コンテナ」とは 何なのでしょうか？
17. 17. サーバ OS のカーネル空間 Docker サーバ ユ ー ザ プ ロ セ ス ユ ー ザ プ ロ セ ス ユーザ空間 ユーザ空間 コンテナ Docker クライアント "docker" デーモン TCP:2375,TCP:2376(TSL),UnixSocket docker run … Dockerはサーバ・クライアント型 のアーキテクチャです。Linux カーネルの技術を使い、OS上に プロセスを隔離(isolate)した環 境を作ります。 • Cgroups • Namespaces  mount  UTS  IPC  PID  Network  User Dockerコンテナを実行するとは、 この図では「docker」というコマ ンドライン上のクライアントが、 Dockerデーモン（Dockerの動く ホスト環境上）にプロセス実行 を命令します。
18. 18. サーバ 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 Hub からダウンロードします。 GitHubのような場所です。 それを、Dockerがダウンロード します。
19. 19. サーバ 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 … ダウンロードしたイメージ上の バイナリをプロセスとして実行し ます。このプロセスは他のプロ セスとは分離・隔離（isolate） された状態です。
20. 20. • Cgroups • Namespaces  mount  UTS  IPC  PID  Network  User この囲んだ部分こそが、他から 分離隔離されたDockerコンテナ と呼ばれる環境です。
21. 21. 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:/# コ ン テ ナ 内 の プ ロ セ ス ホスト側から分離・隔離されてい るため、コンテナ内でプロセス ID(PID)を確認しようとすると、 起動時に指定したコマンドのPID が「1」になります。
22. 22. /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 実際のホスト側では、オレンジ 色のPIDを持っています。しかし、 コンテナの中（青色）では、 個々のPIDが1で始まっているよ うに見えます。
23. 23. 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 コ ン テ ナ 内 の フ ァ イ ル シ ス テ ム 分離・隔離されているのはプロセ スだけでもありません。ファイル システムもコンテナ内で固有の 環境を持ちます。ただし、容量 はあくまでホスト上のものが表示 されます。他が見えないだけ。
24. 24. / /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) / / Linuxでも一般的なchroot技術 のように、コンテナごとに各々の ファイルシステムを割り当てられ ています。また、ホスト上とディ レクトリやファイルを共有するこ とも可能です。
25. 25. 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 valid_lft forever preferred_lft forever 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 valid_lft forever preferred_lft forever inet6 fe80::42:acff:fe11:25/64 scope link valid_lft forever preferred_lft forever 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 コ ン テ ナ 内 の ネ ッ ト ワ ー ク 他にもコンテナはネットワークの 隔離・分離も可能です。ホスト側 と共有することもできますし、 ネットワークを持たないコンテナ の作成も可能です。
26. 26. root@bdf6207621c7:/# free total used free shared buffers cached Mem: 501792 485128 16664 460 127028 164560 -/+ buffers/cache: 193540 308252 Swap: 0 0 0 コ ン テ ナ 内 の メ モ リ メモリもディスク容量のようにホ スト上で共有されているため、 合計容量はホスト側のものです。 ただし、コンテナが利用可能な メモリ上限を設定できます。
27. 27. root@bdf6207621c7:/# exit zem@dev:~$ docker stop bdf6207621c7 コ ン テ ナ の 終 了 あと、独特なのは、コンテナを 終了するとは PID 1 で起動した プロセスが終了することです。 この例では /bin/bash のプロセ スを「exit」で終了すると、コン テナが停止状態になります。 あるいは「docker stop」コマンド もあります。
28. 28. • Cgroups • Namespaces  mount  UTS  IPC  PID  Network  User
29. 29. (汗 どこで、どう Docker を使うのか？ そのため、従来のインフラ（マシンやネット ワーク）を準備した後に手作業や構成管理 ツール（Chef・Puppet等）を使うよりも、 コンテナなら動く環境が全て入っているから 楽だよね、というアプローチです。
30. 30. サーバ 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コンテナと同様、独特の 概念を持つのがDockerイメージ です。
31. 31. これらで赤点線で囲ったものは、 仮想マシンにおける「イメージ」 とは概念が全く異なります。 実体は tar で固まったファイルの 塊（ファイルシステム）と、コン テナ実行に必要なメタデータを 格納したものです（何のコマン ドを実行するか、オプションは何 か、ポート番号は何か、ボリュー ムをマウントするか否か…等）
32. 32. ベース・イメージ (公式) Ubuntu, CentOS等 イメージ層 コマンドごとに記録 Docker イメージの構造 読み込み専用 (Read Only) Dockerイメージは、イメージ層 （レイヤ）の積み重ね構造です。 一番下に「ベース・イメージ」と呼 ばれるレイヤがあります。ピザ で言う所の「生地」にあたります。
33. 33. ベース・イメージ (公式) Ubuntu, CentOS等 イメージ層 コマンドごとに記録 Docker イメージの構造 読み込み専用 (Read Only) このレイヤを積み重ねた集合が、 Dockerイメージと呼ばれるもの。 CD-ROMやDVD-ROMのように、 常に読み込み専用です。
34. 34. 例：Nginx イメージの構造 902b87aaaec9 3 months ago /bin/sh -c #(nop) ADD file:e1dd18493a216ecd0c 125.2 MB 9a61b6b1315e 3 months ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0 B aface2a79f55 3 months ago /bin/sh -c #(nop) MAINTAINER NGINX Docker Mai 0 B 5dd2638d10a1 3 months ago /bin/sh -c apt-key adv --keyserver hkp://pgp. 1.997 kB 97df1ddba09e 3 months ago /bin/sh -c echo "deb http://nginx.org/package 221 B e7e7a55e9264 10 weeks ago /bin/sh -c #(nop) ENV NGINX_VERSION=1.9.4-1~j 0 B 72b67c8ad0ca 10 weeks ago /bin/sh -c apt-get update && apt-get inst 7.695 MB 9108e25be489 10 weeks ago /bin/sh -c ln -sf /dev/stdout /var/log/nginx/ 11 B 6dda3f3a8c05 10 weeks ago /bin/sh -c ln -sf /dev/stderr /var/log/nginx/ 11 B 42d2189f6cbe 10 weeks ago /bin/sh -c #(nop) VOLUME [/var/cache/nginx] 0 B 3cb7f49c6bc4 10 weeks ago /bin/sh -c #(nop) EXPOSE 443/tcp 80/tcp 0 B a486da044a3f 10 weeks ago /bin/sh -c #(nop) CMD ["nginx" "-g" "daemon o 0 B $ docker history nginx IMAGE CREATED CREATED BY SIZE COMMENT docker history <image id/name> 例えばNginxコンテナを実行する とは、Nginxイメージを利用し、 その中にある"nginx"バイナリを コンテナの分離・隔離されたプロ セスとして実行することです。
35. 35. ベース・イメージ (公式) イメージ層 Docker コンテナを起動するとは 読み込み専用 (Read Only) ・新しいイメージ・レイヤの 自動的な割り当て ・隔離されたプロセスの起動 (コンテナ化された状態） docker run <opts> <image:tag> コンテナの「実行」について捕捉。 実際は書き込み可能なイメージ レイヤが追加され、各種の変更 情報が自動保存されています。 これを元に新しいイメージを作成 可能です。
36. 36. サーバ OS のカーネル空間 Docker サーバ ユ ー ザ プ ロ セ ス ユ ー ザ プ ロ セ ス ユーザ空間 ユ ー ザ プ ロ セ ス ユーザ空間 • Cgroups • Namespaces  mount  UTS  IPC  PID  Network  User Dockerコンテナ 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固有の コンテナとイメージに 関する基礎概念です。
37. 37. Dockerの開発環境 では開発環境で実際にどのよう に使うのか、一番手軽な所から みていきましょう。
38. 38. OS ( Linux ) 物理/仮想サーバ Docker エンジン ( docker デーモン ) Linux kernel コンテナ コンテナ コンテナ リモート API docker クライアント ・docker コマンド ・Kitematic (GUI) Dockerコンテナを使うためには Linuxサーバの環境が必要になり ます。そこにクライアントから各 種の命令を送ります。
39. 39. OS ( Linux ) Docker エンジン ( docker デーモン ) Oracle VM VirtualBox 仮想マシン docker コマンド ( クライアント ) ローカルな docker ホスト環境 Mac OS X や Windows では、 Linuxカーネルを持ちません。 途中に VirtualBox などで Linux仮想マシンを立ち上げ、 その中にDocker をセット アップします。
40. 40. Docker動作環境の構築 ローカルで構築 リモートで構築 クラウドサービスの利用 Docker Machine (旧boot2docker) Docker社による バイナリ・パッケージ Amazon EC2 Container Service (ECS) IBM Bluemix Microsoft Azure Google Container Engine VirtualBox Windows or Mac OSX Virtual or Physical Linux Machine コミュニティによる バイナリ・パッケージ 商用サポート版 ソースコードからビルド ＋ Docker Toolbox Docker Toolbox に含まれている Docker Machine（マシン）が環 境構築とDOckerセットアップを 自動的に行います。
41. 41. 41 ここまでのキーワード ‣ Docker Engine • docker デーモン（サーバ） ‣ Docker コンテナ ‣ Docker イメージ • Dockerfile ‣ Docker Machine ‣ Docker Toolbox Docker(エンジン)とは、 環境をコンテナ化し、 移動・実行する仕組み を提供。しかも簡単な コマンドで操作できる。
42. 42. DockerHubから取得する コンテナをコミットする Dockerfileで構築する Dockerイメージの入手・作成は ３つの方法があります。
43. 43. 手作業は大変。そこで構成管理 ツールで環境をセットアップする ように、自動的にコンテナを作成 する手法があります。
44. 44. 44 ‣ Dockerfile の役割 どのようなイメージにするか指示 • どのベース・イメージを使うのか？ • 何のプログラムをインストールするのか？ • どのようなコマンドを実行するのか ‣ docker build コマンドで構築 docker build –t <レポジトリ:タグ> <Dockerfileのパス> Dockerfile docker build イメージの自動構築 これがあれば、誰でもコンテナ 環境を確実・迅速に作れます。
45. 45. FROM ubuntu:14.04 RUN apt-get install -y wget CMD /usr/bin/wget FROM nginx ADD ./contents /usr/share/nginx/html FROM centos:7 MAINTAINER <自分の名前> RUN yum update -y RUN yum install -y epel-release RUN yum install -y nginx ADD index.html /usr/share/nginx/html/ EXPOSE 80 CMD ["nginx", "-g", "daemon off;"] ex1 ex2 ex3 記述そのものは、どれもシンプ ルです。「FROM」は何のDocker イメージを元にするかを指定。 「RUN」は構築時にコンテナ内で 実行するコマンド、 「CMD」はコンテナ実行時の標準 コマンドを指定。 「ADD」はコンテナに対してファ イルを追加。 「EXPOSE」はコンテナの公開用 ポート番号を指定できます。
46. 46. 楽々構築できるよね^^
47. 47. でも、WebとDBが別々の コンテナの場合は？^^;
48. 48. Engine $ docker run … $ docker run … $ docker run … $ docker run … 必要なコンテナの数だけ 「docker build」「docker run」 を繰り返すのは大変・・・
49. 49. Engine $ docker-compose up そこでDocker Compose（コン ポーズ）の出番です。コマンド １つで、複数のコンテナの自動 構築や、自動実行・停止などの 操作を行えます。
50. 50. 複数のコンテナをコードで管理 コンテナの同時起動・停止 コンテナのスケール ネットワーク機能に対応(1.6～)
51. 51. Engine • docker run … • docker run –d • docker ps • docker logs … • docker stop … • docker restart • docker-compose up • docker-compose up –d • docker-compose ps • docker-compose logs • docker-compose stop • docker-compose restart どちらも docker クライアントで操作可能 コマンド体系が似ているため、 dockerコマンドになれていれば 扱いやすいと思います。
52. 52. wordpress: image: wordpress links: - db:mysql ports: - 8080:80 db: image: mariadb environment: MYSQL_ROOT_PASSWORD: example WordPress 用の docker-compose.yml 例 参照：https://hub.docker.com/_/wordpress/ 設定ファイルは YAML 形式のファ イルです。ここで Dockerfile を 呼び出すこともできます。また、 コンテナ間をリンクする設定や、 ネットワーク情報の定義も可能。 サービス"wordpress" ・イメージ: wordpress ・dbサービスをリンク ・ホスト側ポート8080に コンテナのポート80を サービス"db" ・イメージ: mariadb ・環境変数を指定
53. 53. mongo: image: mongo command: mongod --smallfiles --oplogSize 128 rocketchat: image: rocketchat/rocket.chat:latest environment: - PORT=3000 - ROOT_URL=http://localhost:3000 - MONGO_URL=mongodb://mongo:27017/rocketchat links: - mongo:mongo ports: - 3000:3000 Rocket.Chat 用の docker-compose.yml 例 参照：https://github.com/RocketChat/Rocket.Chat/blob/master/docker-compose.yml Slack風のチャット環境もコンテ ナで簡単に構築できます。 Rocket.ChatはHubotのセット アップも同時に可能です。
54. 54. 続きはウェブで…！ http://docs.docker.jp/compose
55. 55. 55 ‣ Docker Composeは 複数のサービスを管理 • docker コマンドと互換性 ‣ Compose ファイルで設定 • YAML形式 • docker-compose.yml 等 ここまでのまとめ まだ環境構築で 消耗してるの？
56. 56. Engine • docker run … • docker run –d • docker ps • docker logs … • docker stop … • docker restart • docker-compose up • docker-compose up –d • docker-compose ps • docker-compose logs • docker-compose stop • docker-compose restart どちらも docker クライアントで操作可能
57. 57. 複数のコンテナも 楽に管理できるね^^
58. 58. あれ？ 複数のサーバの場合は？^^;
59. 59. $ docker run … $ docker run … $ docker run … 複数サーバでのコンテナ実行は、 毎回環境を切り替えてdockerコ マンド実行するのが大変・・・
60. 60. $ docker run … $ docker run … $ docker run … そこでDocker Swarm（スウォー ム）の出番。Docker Engine の 代わりにリクエストを受け取り、 よしなにコンテナを配置。
61. 61. サーバ ・Docker クライアント （Swarm操作） ・Docker Machine （環境構築） Swarm Manager サーバ swarm-master Dockerデーモン サーバ Swarm Agent サーバ swarm-node-01 Dockerデーモン サーバ Swarm Agent サーバ swarm-node-02 Dockerデーモン リモート 操作 コンテナの スケジュール Dockerとの違いは、dockerコマ ンドのリクエスト先がSwarm用の マネージャに対して行う所だけ。 利用者からはコマンドが共通。
62. 62. コンテナのスケジューリング Docker API と互換性 ディスカバリ・バックエンドと連携 ネットワーク機能に対応
63. 63. 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 でデプロイ/プロビジョニング ディスカバリ・バックエンド
64. 64. Docker Swarm 分散サーバ上の コンテナ（サービス）を スケジューリング Docker Machine Docker Engine動作環境や 仮想マシン環境・Swarmクラスタを 自動的に構築・一元管理 Docker Compose 複数のサービスを 一括して管理 Docker Engine Docker Toolbox 開発環境セット
65. 65. 続きはウェブで…！ 今だからこそ知りたい Docker Compose/Swarm 入門 http://www.slideshare.net/zembutsu/introduction-to-docker-compose-and-swarm
66. 66. 技術選択の要素 2■■□□ Considering of Use Case
67. 67. さて、よくある誤解の１つとして、 何でもDockerにしておけば良い、 というのがあります。Dockerを 使えば全てを解決してれるかの ような・・・
68. 68. だが ちょっとまって欲しい
69. 69. 何も考えずに導入してしまうと…
70. 70. あとには、コンテナの残骸という 技術的負債が残されることになっ ては大変・・・
71. 71. 検討要素 ではDockerの導入にあたって、 私たちは何を気をつけるべきな のでしょう。技術的検討ポイント を皆さんと見ていきます。
72. 72. 75 Dockerコンテナのライフサイクル ※ Docker Docs より引用：https://docs.docker.com/engine/reference/api/docker_remote_api/ まずは、ライフサイクルの 理解です。バッチ的なコマ ンド処理もサービスとしての 常駐も可能です。
73. 73. 76 ‣ 開発環境のみ ‣ 開発環境 ～ CI / テスト環境 ‣ 開発環境 ～ 本番環境 利用シーンの範囲を検討 Dockerの基本的ライフサイクル やコマンドの使い方などの理解 は前提として、次に、どのような 場面でDockerを使うのかで視点 が変わってきます。
74. 74. 77 利用シーン 開発 運用 評価 ステージによって異なる 例えば開発チームと運用チーム が分かれているかもしれません。 駅伝やリレーのように、各チーム だけでは完結しません。お互い、 歩み寄りが必要になります。 TASK devチームの範囲 opsチームの範囲
75. 75. 78 利用シーン 開発 運用 評価 ステージによって異なる あるいは、自分一人（または、 特定のチーム内だけ）で全てが 完結する可能性も有りますし・・・
76. 76. 79 利用シーン 開発 運用 評価 ステージによって異なる 工程ごとに様々な人がいる場合 も考えられます。 TASK TASK
77. 77. 80 検討項目 1. 利用者は誰で、用途は何か？ 2. インフラをどうするのか？ 3. OSを何にするのか？ 4. ディストリビューションを何にするのか？ 5. ストレージ・ドライバを何にするのか？ 6. ベースイメージは何にするのか？ 7. セキュリティをどのように考慮すべきか？ 8. 性能をどのように担保するのか？ ★重要な警告★ 本章に含まれる以降の検討要素 は私個人の見解であり頻繁にい ただく質問に対する一般的見解 をまとめたものです。所属会社 およびDocker, Inc. の意見を代 表するものではありませ。また、 Docker 1.10 現在の情報です。 今後の Docker のバージョンに よっては判断材料として適切では ない場合が有り得ます。常に、 最新情報をご確認願います。
78. 78. 81 ‣コンテナを誰が使うのか？ 開発チーム？ 運用チーム？ テスト？ 検証？ コミュニティ？ 自社内？ お客さま？ ‣何のために使うのか？ システム開発？ 運用？ 商用サービス？ 検証？ 技術選択にあたっての基本ポイント まず始めに誰が何のために使う のか？という視点が必須です。
79. 79. たとえばピザで考えてみます！
80. 80. 例えば冷凍ピザ！自分がお腹空 いた、とにかくピザを今すぐ食べ たい！というのであれば冷凍ピ ザでも良いですよね。料理の腕 前に覚えがなくとも、電子レンジ ですぐにできます。簡単です。 味もソコソコでしょう。これは、 Dockerコンテナの使い勝手と似 ている所があると思います。
81. 81. しかしお客さまに商品としてピザ を出す（サービス提供する）の であれば、Dockerを使うべきで ないシーンがあるかもしれません。
82. 82. ちゃんとしたモノが必要であれば、 それなりに手間暇をかけるべき 場合も考えられます。改めて、 誰が何のために使うのか？を考 慮するのは非常に重要だと考え ています。 特に、仕事で使うのであれば、 最終的にピザを食べるのは誰か ＝Dockerコンテナを使用・運用 するのは誰かという視点は欠か せないものでしょう。
83. 83. 利用者や目的が定まれば、インフラに何を使うべきか は自ずと決まると思われます。利用シーンであったり、 環境によって異なるでしょう。どれが優れているか優 れていないかは、個々のユースケースに依存します。
84. 84. 87 Linuxディストリビューションの選択 ‣ Docker Engine 商用サポートの有無 • Docker Commercial Suport （商用サポート）版対応（2015年2月現在） – Red Hat Enterprise Linux 7.0 , 7.1 – CentOS 7.1 – Ubuntu 14.04 LTX • 最新リストは https://www.docker.com/compatibility-maintenance ‣ ベンダーによる保守サポート有無 ‣ コミュニティによるサポートの有無
85. 85. 88 ‣ Docker イメージの内部管理方式 • aufs, Devicemapper, btrfs, overlayfs, zfs … 全てのユースケースを満たすものは存在しないため、 特性に応じて使い分ける必要がある ‣ Dockerのドキュメントでは • これまで使ったことがあるドライバを優先すべき（経験重視） • 次に、ディストリビューションごとの標準ドライバ（コミュニティがサポート） • なお、CS 版 ( Commercial Support ) 版 Dockerは（商用／ベンダのサポート重視） – RHEL7.0, 7.1, Ubuntu 14.04 LTS, CentOS 7.1 ※2016年2月現在 – https://www.docker.com/compatibility-maintenance ストレージ・ドライバ ストレージ・ドライバを何にする かはDocker独特の判断ポイント です。こちらもどのような用途に 使うのか、あるい経験を持ってい るかによって異なります。
86. 86. https://docs.docker.com/engine/userguide/storagedriver/selectadriver/ 一般的な指針として、このような 区分はされていますが、鵜呑み はしないほうが良いと思います。 扱うファイルサイズだったり OS やハードウェアにも影響を受けま す。なので個々の環境における ベンチマークは必要と思います。
87. 87. 90 コピー・オン・ライト方式 ‣ CoW; Copy on Write • 効率的にイメージを使う仕組み 1. ファイル更新が発生する（初回） 2. イメージからコンテナ用領域に ファイルをコピーする 3. コピーしたファイルを編集 CoW処理がパフォーマンスに影響 デバイス・ドライバの選択により 挙動が異なるので注意が必要 なぜならDockerはイメージ管理 に独特の処理を行っているため。 詳細：イメージ、コンテナ、ストレージ・ドライバの理解 — Docker-docs-ja 1.10.0b ドキュメント http://docs.docker.jp/engine/userguide/storagedriver/imagesandcontainers.html
88. 88. こちらはレイヤを抽象化したもの。
89. 89. AUFS AUFS ストレージ・ドライバを使う — Docker-docs-ja 1.10.0b ドキュメント http://docs.docker.jp/engine/userguide/storagedriver/aufs-driver.html AUFSはコンテナに書き込みを行 う時、初回にコピーが発生します。 1GBのファイルに追記する場合、 1GBのファイルをコピー後に処理 が進行します。
90. 90. devicemapper Device Mapper ストレージ・ドライバを使う — Docker-docs-ja 1.10.0b ドキュメント http://docs.docker.jp/engine/userguide/storagedriver/device-mapper-driver.html 一方、RHEL系の場合はコピーは 発生しません。64KB単位で処理 が行われます。
91. 91. コンテナのボリューム ボリュームはCoW処理を行わず、 ホスト上のI/O性能が直接反映。 コンテナでデータを管理する — Docker-docs-ja 1.10.0b ドキュメント http://docs.docker.jp/engine/userguide/containers/dockervolumes.html
92. 92. 95 ‣ ベース・イメージ • 誰がセキュリティのメンテナスを行っているのか。コミュニティ or 独自？ ‣ Dockerコンテナ • Dockerコンテナの操作には事実上の root ユーザ権限が必要 • SELinux, AppArmor など OS 側の対応状況 • ホスト上の UID とコンテナが内部で使う UID が不意に一致する恐れ – v1.10 で user namespace をサポートしたことで、 --userns-remap を使った subuid, subgid を活用可能に • Docker デーモンの脆弱性発生リスクと対処手段 – ベンダによるサポートの有無 • 特権ユーザの処理 http://blog.docker.com/2013/09/docker-can-now-run-within-docker/ • デバイス・ドライバ毎のバグが許容できるかどうか – 参考：aufs/overlayfs/btrfs bugs – Qiita ( AkihiroSuda 氏 の投稿) http://qiita.com/AkihiroSuda/items/7db89f48d50b98fa1fa8 ‣ ネットワーク通信 • クライアント・デーモン間は TLS 通信が推奨 主なセキュリティ考慮点
93. 93. 96 検討項目まとめ 1. 利用者は誰で、用途は何か？ 2. インフラをどうするのか？ 3. OSを何にするのか？ 4. ディストリビューションを何にするのか？ 5. ストレージ・ドライバを何にするのか？ 6. ベースイメージは何にするのか？ 7. セキュリティをどのように考慮すべきか？ 8. 性能をどのように担保するのか？ 判断材料の中でも、比較的重要 なものをリストアップしました。
94. 94. 97 ‣ 公式 https://docs.docker.com/ ‣ 日本語訳 http://docs.docker.jp 参考にすべきはドキュメント
95. 95. 98 ‣ ユーザガイド • http://docs.docker.jp/engine/userguide/index.html • Dockerfile ベスト・プラクティス – http://docs.docker.jp/engine/userguide/eng-image/dockerfile_best-practice.html • ストレージ・ドライバ – http://docs.docker.jp/engine/userguide/storagedriver/index.html • Docker ネットワーク機能の概要 – http://docs.docker.jp/engine/userguide/networking/index.html ‣ リファレンス • docker run リファレンス – http://docs.docker.jp/engine/reference/run.html • コマンドライン・リファレンス – コマンドラインで使う http://docs.docker.jp/engine/reference/commandline/cli.html – daemon http://docs.docker.jp/engine/reference/commandline/daemon.html – run http://docs.docker.jp/engine/reference/commandline/run.html Docker Engine オススメのドキュメント
96. 96. 課題と最新動向 3■■■□ Issues and What's new
97. 97. 100 3. 課題と最新動向 Issues ‣ Docker 1.9 と 1.10 以降の新機能と変更点 • Docker 1.9 以降のネットワーク機能とリンク • リソースの制約 • 細かな仕様変更と機能の拡張 • Docker Compose 1.6 の新機能 ‣ 新しいプロダクト • Docker Datacenter – Universal Control Plane – Docker Trusted Registry • Docker Cloud
98. 98. Dockerの動作ホスト コンテナ コンテナ docker0 bridge eth0 eth0 IP: 172.17.0.2 IP: 172.17.0.2 IP: 172.17.0.1 Docker 1.8 以前のネットワーク
99. 99. Dockerの動作ホスト コンテナ コンテナ docker0 bridge eth0 eth0 IP: 172.17.0.2 IP: 172.18.0.10 IP: 172.17.0.2 IP: 172.18.0.11 IP: 172.17.0.1 任意 bridge IP: 172.18.0.1 デフォルトのブリッジ・ホスト ネットワーク ユーザ定義 ネットワーク Docker 1.9 からのブリッジ・ネットワーク eth1eth1 …
100. 100. Dockerの動作ホスト コンテナ コンテナ docker0 bridge eth0 eth0 IP: 172.17.0.2 IP: 172.18.0.10 IP: 172.17.0.2 IP: 172.18.0.11 IP: 172.17.0.1 任意 bridge IP: 172.18.0.1 デフォルトのブリッジ・ホスト ネットワーク ユーザ定義 ネットワーク Docker 1.9 からのブリッジ・ネットワーク eth1eth1 … 「--link」機能は docker 0 ブリッジ のみ対応 「コンテナ名.net名」で 動的な名前解決可能に （リンク機能の代替)
101. 101. docker0ネットワーク 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 ホスト１ ホスト２
102. 102. docker0ネットワーク 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 ホスト１ ホスト２ 疎通
103. 103. 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
104. 104. 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 … 複数ホストにまたがるオーバレイ・ネットワーク
105. 105. root@demo:~# docker network create front 9959a6e12da55fa6deacffa0146ae351204d8a89d72d900ddde969fdf1f3fe40 root@demo:~# docker network ls NETWORK ID NAME DRIVER 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": {} } ] 新しいネットワーク
106. 106. # 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ではない）
107. 107. root@demo:~# docker network create back 6afc733feeaf46aaff80c5a605bacba63ae3463d1cfb925a9cdc9d82c3e9184b root@demo:~# docker network ls NETWORK ID NAME DRIVER 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」コンテナをそこに作成 新しいネットワーク
108. 108. 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 を追加し、インターフェースを確認
109. 109. root@demo:~# docker network connect back web 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) eth1 Link encap:Ethernet HWaddr 02:42:ac:13:00:03 inet addr:172.19.0.3 Bcast:0.0.0.0 Mask:255.255.0.0 inet6 addr: fe80::42:acff:fe13:3/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8 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:648 (648.0 B) TX bytes:648 (648.0 B) 「web」「db」の両コンテナをつなげるには？「back」ネットワークに接続
110. 110. 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」の記述が自動的に追加されている
111. 111. 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アドレス体系のみ（ネットワークを追加したら可能）。
112. 112. http://docs.docker.jp/engine/userguide/networking
113. 113. Docker API Swarm Manager ディスカバリ・バックエンド リソース・プール スケジューラ fleet
114. 114. 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: image: gcr.io/google_containers/hyperkube:v1.0.7 command: ["/hyperkube", "controller-manager", "--address=0.0.0.0", "--master=http://apiserver:8080", "--v=2"] environment: - "affinity:container==*apiserver*" scheduler: image: gcr.io/google_containers/hyperkube:v1.0.7 command: ["/hyperkube", "scheduler", "--address=0.0.0.0", "--master=http://apiserver:8080", "--v=2"] environment: - "affinity:container==*apiserver*" kubelet: image: gcr.io/google_containers/hyperkube:v1.0.7 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: image: gcr.io/google_containers/hyperkube:v1.0.7 command: ['/hyperkube', 'proxy', '--master=http://apiserver:8080', '--v=2'] privileged: true # A proxy should run alongside another kubelet environment: - "affinity:container==*kubelet*"
115. 115. 引用：Deploy and Manage Any Cluster Manager with Docker Swarm | Docker Blog http://blog.docker.com/2015/11/deploy-manage-cluster-docker-swarm/
116. 116. 最近の動向
117. 117. 120 ‣ Engine 1.10 • 2016年2月にリリース • 参考訳：Docker 1.10 新しい Compose ファイル、セキュリティ改善、ネットワーク機能等 http://pocketstudio.jp/log3/2016/02/06/docker-1-10-ja/ ‣ Compose 1.6 • 参考訳：Compose 1.6: ネットワークとボリュームを定義する新しい Compose ファイル http://pocketstudio.jp/log3/2016/02/06/compose-1-6-ja/ Docker リリース情報
118. 118. tutum https://www.tutum.co/ Docker社が買収(10月) AWS, Digital Ocean, Azure, SoftLayer, Packet と連携 コンテナのデプロイと管理 Docker Hub を補完する役割
119. 119. Docker Hub Tutum パブリック環境でコンテナを実行 Docker Cloud http://cloud.docker.com
120. 120. DTR Docker Trusted Registry Orca (beta) + UCP Universal Control Plane より安全にコンテナを実行 https://www.docker.com/universal-control-plane
121. 121. まとめ 4■■■■ Wrap up
122. 122. 125 今日の振り返り Docker基礎講座 ‣ 改めて「Docker」とは何か？ 用語の定義と周辺ツール 基本概念の理解（コンテナ、イメージ） ‣ 利用段階と考慮点 ライフサイクルと検討フロー 技術（技法）の選択とベストプラクティス ‣ 課題と最新動向 (Docker 1.9, 1.10) Docker Cloud (Tutum), Docker Datacenter ( Universal Control Plane + Docker Trusted Registry)
123. 123. 126 誰が？ 何のために？
124. 124. 127 用途に応じた技術選択のポイント Docker基礎講座 ‣ 1. 利用者は誰で、用途は何か？ ‣ 2. インフラをどうするのか？ ‣ 3. OSを何にするのか？ ‣ 4. ディストリビューションを何にするのか？ ‣ 5. ストレージ・ドライバを何にするのか？ ‣ 6. ベースイメージは何にするのか？ ‣ 7. セキュリティをどのように考慮すべきか？ ‣ 8. 性能をどのように担保するのか？
125. 125. 128 何か気になる所はありますか？ Docker基礎講座 ‣ 日本語ドキュメントはこちら http://docs.docker.jp • v1.9  v1.10移行中 ‣ Ask the Speaker ‣ @zembutsu
126. 126. 129 ‣ https://blog.docker.com ‣ https://docs.docker.com ‣ http://docs.docker.jp • v 1.9  v1.10 移行作業中(2016年2月現在） 参考情報 References
127. 127. 130 私は誰なのか？ ‣ @zembutsu a.k.a. 前佛雅人 - Technology Evangelist; Creationline, Inc. – 2 yrs - Technical Trainer; Docker Authorized Trainer – 0.5 yr - Data Center Operations Engineer – 15+ yrs 興味：運用監視自動化、趣味でOSSやクラウド系の検証・情報発信 - SlideShare http://slideshare.net/zembutsu - Blog http://pocketstudio.jp/log3 Why am I here? +MasahitoZembutsu