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

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 今日扱う内容 Docker基礎講座 ‣ 改めて「Docker」とは何か？用語の定義と周辺ツール基本概念の理解（コンテナ、イメージ） ‣ 技術選択の要素ライフサイクルと検討フロー技術（技法）の選択とベストプラクティス ‣ 最新動向 (Docker 1.9, 1.10) ネットワーク機能、 Docker Datacenter ( Universal Control Plane + Docker Trusted Registry)

3. 3 今日扱う内容 Docker基礎講座 ‣ 扱うこと「Dockerをどう使っていくのか？」 ‣ 扱わないこと「コンテナ技術とは何なのか？」

4. Dockerやコンテナは様々な方や場所で言及されていますので、そこを改めて深掘りするのではなく・・・

5. ピザをどう食べたらいいのか？いまここにあるDockerを、どのようにして使っていけば良いのか？ピザであれば「どう食べるのか」という視点で、皆さんと共有したいと思っています。

6. 6 docker 最近の悩み。みなさん、どう発音しますか？

7. 7 アクセントの悩み docker ／ドッ＼カードッ／カー→ ※参考「NHK日本語発音アクセント辞典」改訂項目表示形式の検討（2012年） https://www.nhk.or.jp/bunken/summary/research/report/2012_09/20120908.pdf 「クラウド」と同じ悩みであり、どちらでも構わないと思ってます。・・・が正直悩みます。。

8. 改めて「Docker」とは？ 1■□□□ What is the "Docker" ? Again

9. docker ※Docker Glossary https://docs.docker.com/engine/reference/glossary/ Docker プロジェクト Docker デーモン • 開発者やシステム管理者が、アプリを開発・移動・実行するプラットフォーム • Docker, Inc. はスポンサー primary contributor, maintainer • イメージとコンテナを管理 • ホスト上で動くプロセス • コンテナ技術を使う namespaces, cgroups

10. docker 技術文脈ではDockerデーモンを「Dockerエンジン」と呼びます。 Docker Engine

11. Dockerが登場は2013年3月。ようやく３周年になります。

12. Build Ship Run Anywhere Distributed Applications 「Docker」とは、アプリケーションを動かすための仕組みを提供

13. その中心がDockerエンジンという位置付けです。

14. 14 開発ツール公式レポジトリオペレーティング・システムビッグデータサービス・ディスカバリ構築／CI 設定管理コンサルタント・トレーニング管理ストレージクラスタ・スケジューリングネットワーク機能インフラ＆プロバイダセキュリティ監視とログ Dockerエコシステム

15. 基本のおさらい Dockerコンテナとイメージ

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. サーバ 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. サーバ 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. サーバ 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. • Cgroups • Namespaces  mount  UTS  IPC  PID  Network  User この囲んだ部分こそが、他から分離隔離されたDockerコンテナと呼ばれる環境です。

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. /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. 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. / /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. 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. 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. root@bdf6207621c7:/# exit zem@dev:~$ docker stop bdf6207621c7 コンテナの終了あと、独特なのは、コンテナを終了するとは PID 1 で起動したプロセスが終了することです。この例では /bin/bash のプロセスを「exit」で終了すると、コンテナが停止状態になります。あるいは「docker stop」コマンドもあります。

28. • Cgroups • Namespaces  mount  UTS  IPC  PID  Network  User

29. (汗どこで、どう Docker を使うのか？そのため、従来のインフラ（マシンやネットワーク）を準備した後に手作業や構成管理ツール（Chef・Puppet等）を使うよりも、コンテナなら動く環境が全て入っているから楽だよね、というアプローチです。

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. これらで赤点線で囲ったものは、仮想マシンにおける「イメージ」とは概念が全く異なります。実体は tar で固まったファイルの塊（ファイルシステム）と、コンテナ実行に必要なメタデータを格納したものです（何のコマンドを実行するか、オプションは何か、ポート番号は何か、ボリュームをマウントするか否か…等）

32. ベース・イメージ (公式) Ubuntu, CentOS等イメージ層コマンドごとに記録 Docker イメージの構造読み込み専用 (Read Only) Dockerイメージは、イメージ層（レイヤ）の積み重ね構造です。一番下に「ベース・イメージ」と呼ばれるレイヤがあります。ピザで言う所の「生地」にあたります。

33. ベース・イメージ (公式) Ubuntu, CentOS等イメージ層コマンドごとに記録 Docker イメージの構造読み込み専用 (Read Only) このレイヤを積み重ねた集合が、 Dockerイメージと呼ばれるもの。 CD-ROMやDVD-ROMのように、常に読み込み専用です。

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. ベース・イメージ (公式) イメージ層 Docker コンテナを起動するとは読み込み専用 (Read Only) ・新しいイメージ・レイヤの自動的な割り当て・隔離されたプロセスの起動 (コンテナ化された状態） docker run <opts> <image:tag> コンテナの「実行」について捕捉。実際は書き込み可能なイメージレイヤが追加され、各種の変更情報が自動保存されています。これを元に新しいイメージを作成可能です。

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. Dockerの開発環境では開発環境で実際にどのように使うのか、一番手軽な所からみていきましょう。

38. OS ( Linux ) 物理/仮想サーバ Docker エンジン ( docker デーモン ) Linux kernel コンテナコンテナコンテナリモート API docker クライアント・docker コマンド・Kitematic (GUI) Dockerコンテナを使うためには Linuxサーバの環境が必要になります。そこにクライアントから各種の命令を送ります。

39. OS ( Linux ) Docker エンジン ( docker デーモン ) Oracle VM VirtualBox 仮想マシン docker コマンド ( クライアント ) ローカルな docker ホスト環境 Mac OS X や Windows では、 Linuxカーネルを持ちません。途中に VirtualBox などで Linux仮想マシンを立ち上げ、その中にDocker をセットアップします。

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 ここまでのキーワード ‣ Docker Engine • docker デーモン（サーバ） ‣ Docker コンテナ ‣ Docker イメージ • Dockerfile ‣ Docker Machine ‣ Docker Toolbox Docker(エンジン)とは、環境をコンテナ化し、移動・実行する仕組みを提供。しかも簡単なコマンドで操作できる。

42. DockerHubから取得するコンテナをコミットする Dockerfileで構築する Dockerイメージの入手・作成は３つの方法があります。

43. 手作業は大変。そこで構成管理ツールで環境をセットアップするように、自動的にコンテナを作成する手法があります。

44. 44 ‣ Dockerfile の役割どのようなイメージにするか指示 • どのベース・イメージを使うのか？ • 何のプログラムをインストールするのか？ • どのようなコマンドを実行するのか ‣ docker build コマンドで構築 docker build –t <レポジトリ:タグ> <Dockerfileのパス> Dockerfile docker build イメージの自動構築これがあれば、誰でもコンテナ環境を確実・迅速に作れます。

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. 楽々構築できるよね^^

47. でも、WebとDBが別々のコンテナの場合は？^^;

48. Engine $ docker run … $ docker run … $ docker run … $ docker run … 必要なコンテナの数だけ「docker build」「docker run」を繰り返すのは大変・・・

49. Engine $ docker-compose up そこでDocker Compose（コンポーズ）の出番です。コマンド１つで、複数のコンテナの自動構築や、自動実行・停止などの操作を行えます。

50. 複数のコンテナをコードで管理コンテナの同時起動・停止コンテナのスケールネットワーク機能に対応(1.6～)

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. 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. 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. 続きはウェブで…！ http://docs.docker.jp/compose

55. 55 ‣ Docker Composeは複数のサービスを管理 • docker コマンドと互換性 ‣ Compose ファイルで設定 • YAML形式 • docker-compose.yml 等ここまでのまとめまだ環境構築で消耗してるの？

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. 複数のコンテナも楽に管理できるね^^

58. あれ？複数のサーバの場合は？^^;

59. $ docker run … $ docker run … $ docker run … 複数サーバでのコンテナ実行は、毎回環境を切り替えてdockerコマンド実行するのが大変・・・

60. $ docker run … $ docker run … $ docker run … そこでDocker Swarm（スウォーム）の出番。Docker Engine の代わりにリクエストを受け取り、よしなにコンテナを配置。

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

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. Docker Swarm 分散サーバ上のコンテナ（サービス）をスケジューリング Docker Machine Docker Engine動作環境や仮想マシン環境・Swarmクラスタを自動的に構築・一元管理 Docker Compose 複数のサービスを一括して管理 Docker Engine Docker Toolbox 開発環境セット

65. 続きはウェブで…！今だからこそ知りたい Docker Compose/Swarm 入門 http://www.slideshare.net/zembutsu/introduction-to-docker-compose-and-swarm

66. 技術選択の要素 2■■□□ Considering of Use Case

67. さて、よくある誤解の１つとして、何でもDockerにしておけば良い、というのがあります。Dockerを使えば全てを解決してれるかのような・・・

68. だがちょっとまって欲しい

69. 何も考えずに導入してしまうと…

70. あとには、コンテナの残骸という技術的負債が残されることになっては大変・・・

71. 検討要素ではDockerの導入にあたって、私たちは何を気をつけるべきなのでしょう。技術的検討ポイントを皆さんと見ていきます。

72. 75 Dockerコンテナのライフサイクル ※ Docker Docs より引用：https://docs.docker.com/engine/reference/api/docker_remote_api/ まずは、ライフサイクルの理解です。バッチ的なコマンド処理もサービスとしての常駐も可能です。

73. 76 ‣ 開発環境のみ ‣ 開発環境～ CI / テスト環境 ‣ 開発環境～本番環境利用シーンの範囲を検討 Dockerの基本的ライフサイクルやコマンドの使い方などの理解は前提として、次に、どのような場面でDockerを使うのかで視点が変わってきます。

74. 77 利用シーン開発運用評価ステージによって異なる例えば開発チームと運用チームが分かれているかもしれません。駅伝やリレーのように、各チームだけでは完結しません。お互い、歩み寄りが必要になります。 TASK devチームの範囲 opsチームの範囲

75. 78 利用シーン開発運用評価ステージによって異なるあるいは、自分一人（または、特定のチーム内だけ）で全てが完結する可能性も有りますし・・・

76. 79 利用シーン開発運用評価ステージによって異なる工程ごとに様々な人がいる場合も考えられます。 TASK TASK

77. 80 検討項目 1. 利用者は誰で、用途は何か？ 2. インフラをどうするのか？ 3. OSを何にするのか？ 4. ディストリビューションを何にするのか？ 5. ストレージ・ドライバを何にするのか？ 6. ベースイメージは何にするのか？ 7. セキュリティをどのように考慮すべきか？ 8. 性能をどのように担保するのか？ ★重要な警告★ 本章に含まれる以降の検討要素は私個人の見解であり頻繁にいただく質問に対する一般的見解をまとめたものです。所属会社およびDocker, Inc. の意見を代表するものではありませ。また、 Docker 1.10 現在の情報です。今後の Docker のバージョンによっては判断材料として適切ではない場合が有り得ます。常に、最新情報をご確認願います。

78. 81 ‣コンテナを誰が使うのか？開発チーム？運用チーム？テスト？検証？コミュニティ？自社内？お客さま？ ‣何のために使うのか？システム開発？運用？商用サービス？検証？技術選択にあたっての基本ポイントまず始めに誰が何のために使うのか？という視点が必須です。

79. たとえばピザで考えてみます！

80. 例えば冷凍ピザ！自分がお腹空いた、とにかくピザを今すぐ食べたい！というのであれば冷凍ピザでも良いですよね。料理の腕前に覚えがなくとも、電子レンジですぐにできます。簡単です。味もソコソコでしょう。これは、 Dockerコンテナの使い勝手と似ている所があると思います。

81. しかしお客さまに商品としてピザを出す（サービス提供する）のであれば、Dockerを使うべきでないシーンがあるかもしれません。

82. ちゃんとしたモノが必要であれば、それなりに手間暇をかけるべき場合も考えられます。改めて、誰が何のために使うのか？を考慮するのは非常に重要だと考えています。特に、仕事で使うのであれば、最終的にピザを食べるのは誰か＝Dockerコンテナを使用・運用するのは誰かという視点は欠かせないものでしょう。

83. 利用者や目的が定まれば、インフラに何を使うべきかは自ずと決まると思われます。利用シーンであったり、環境によって異なるでしょう。どれが優れているか優れていないかは、個々のユースケースに依存します。

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. 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. https://docs.docker.com/engine/userguide/storagedriver/selectadriver/ 一般的な指針として、このような区分はされていますが、鵜呑みはしないほうが良いと思います。扱うファイルサイズだったり OS やハードウェアにも影響を受けます。なので個々の環境におけるベンチマークは必要と思います。

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. こちらはレイヤを抽象化したもの。

89. AUFS AUFS ストレージ・ドライバを使う — Docker-docs-ja 1.10.0b ドキュメント http://docs.docker.jp/engine/userguide/storagedriver/aufs-driver.html AUFSはコンテナに書き込みを行う時、初回にコピーが発生します。 1GBのファイルに追記する場合、 1GBのファイルをコピー後に処理が進行します。

90. devicemapper Device Mapper ストレージ・ドライバを使う — Docker-docs-ja 1.10.0b ドキュメント http://docs.docker.jp/engine/userguide/storagedriver/device-mapper-driver.html 一方、RHEL系の場合はコピーは発生しません。64KB単位で処理が行われます。

91. コンテナのボリュームボリュームはCoW処理を行わず、ホスト上のI/O性能が直接反映。コンテナでデータを管理する — Docker-docs-ja 1.10.0b ドキュメント http://docs.docker.jp/engine/userguide/containers/dockervolumes.html

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. 96 検討項目まとめ 1. 利用者は誰で、用途は何か？ 2. インフラをどうするのか？ 3. OSを何にするのか？ 4. ディストリビューションを何にするのか？ 5. ストレージ・ドライバを何にするのか？ 6. ベースイメージは何にするのか？ 7. セキュリティをどのように考慮すべきか？ 8. 性能をどのように担保するのか？判断材料の中でも、比較的重要なものをリストアップしました。

94. 97 ‣ 公式 https://docs.docker.com/ ‣ 日本語訳 http://docs.docker.jp 参考にすべきはドキュメント

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. 課題と最新動向 3■■■□ Issues and What's new

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. Dockerの動作ホストコンテナコンテナ docker0 bridge eth0 eth0 IP: 172.17.0.2 IP: 172.17.0.2 IP: 172.17.0.1 Docker 1.8 以前のネットワーク

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. 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. 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. 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. 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. 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. 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. # 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. 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. 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. 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. 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. 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. http://docs.docker.jp/engine/userguide/networking

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

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. 引用：Deploy and Manage Any Cluster Manager with Docker Swarm | Docker Blog http://blog.docker.com/2015/11/deploy-manage-cluster-docker-swarm/

116. 最近の動向

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. tutum https://www.tutum.co/ Docker社が買収(10月) AWS, Digital Ocean, Azure, SoftLayer, Packet と連携コンテナのデプロイと管理 Docker Hub を補完する役割

119. Docker Hub Tutum パブリック環境でコンテナを実行 Docker Cloud http://cloud.docker.com

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

121. まとめ 4■■■■ Wrap up

122. 125 今日の振り返り Docker基礎講座 ‣ 改めて「Docker」とは何か？用語の定義と周辺ツール基本概念の理解（コンテナ、イメージ） ‣ 利用段階と考慮点ライフサイクルと検討フロー技術（技法）の選択とベストプラクティス ‣ 課題と最新動向 (Docker 1.9, 1.10) Docker Cloud (Tutum), Docker Datacenter ( Universal Control Plane + Docker Trusted Registry)

123. 126 誰が？何のために？

124. 127 用途に応じた技術選択のポイント Docker基礎講座 ‣ 1. 利用者は誰で、用途は何か？ ‣ 2. インフラをどうするのか？ ‣ 3. OSを何にするのか？ ‣ 4. ディストリビューションを何にするのか？ ‣ 5. ストレージ・ドライバを何にするのか？ ‣ 6. ベースイメージは何にするのか？ ‣ 7. セキュリティをどのように考慮すべきか？ ‣ 8. 性能をどのように担保するのか？

125. 128 何か気になる所はありますか？ Docker基礎講座 ‣ 日本語ドキュメントはこちら http://docs.docker.jp • v1.9  v1.10移行中 ‣ Ask the Speaker ‣ @zembutsu

126. 129 ‣ https://blog.docker.com ‣ https://docs.docker.com ‣ http://docs.docker.jp • v 1.9  v1.10 移行作業中(2016年2月現在）参考情報 References

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