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

クラウド・ネイティブ時代の2 0 1 6年だから始める

Docker基礎講座

2016年2月18日(木)

@zembutsuTechnology Evangelist; Creationline, Inc.

Introduction to Docker, because of the age of "cloud native"

背景画像CREDIT:スフィア / PIXTA(ピクスタ)

#devsumi #devsumiE

2

今日扱う内容Docker基礎講座

‣ 改めて「Docker」とは何か？用語の定義と周辺ツール

基本概念の理解（コンテナ、イメージ）

‣ 技術選択の要素ライフサイクルと検討フロー

技術（技法）の選択とベストプラクティス

‣ 最新動向 (Docker 1.9, 1.10)ネットワーク機能、 Docker Datacenter ( Universal Control Plane + Docker Trusted Registry)

3

今日扱う内容Docker基礎講座

‣ 扱うこと

「Dockerをどう使っていくのか？」

‣ 扱わないこと

「コンテナ技術とは何なのか？」

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

ピザをどう食べたらいいのか？

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

6

docker

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

7

アクセントの悩み

docker／ドッ＼カー ドッ／カー→

※参考 「NHK日本語発音アクセント辞典」改訂 項目表示形式の検討（2012年）https://www.nhk.or.jp/bunken/summary/research/report/2012_09/20120908.pdf

「クラウド」と同じ悩みであり、どちらでも構わないと思ってます。・・・が正直悩みます。。

改めて「Docker」とは？

1■□□□ What is the "Docker" ? Again

docker

※Docker Glossary https://docs.docker.com/engine/reference/glossary/

Docker プロジェクト Docker デーモン

• 開発者やシステム管理者が、アプリを開発・移動・実行するプラットフォーム

• Docker, Inc. はスポンサーprimary contributor, maintainer

• イメージとコンテナを管理

• ホスト上で動くプロセス

• コンテナ技術を使うnamespaces, cgroups

docker

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

Docker Engine

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

Build Ship Run

Anywhere

Distributed Applications

「Docker」とは、アプリケーションを動かすための仕組みを提供

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

14

開発ツール

公式レポジトリ

オペレーティング・システム

ビッグデータ

サービス・ディスカバリ

構築／CI

設定管理 コンサルタント・トレーニング

管理

ストレージ

クラスタ・スケジューリング

ネットワーク機能

インフラ＆プロバイダ

セキュリティ

監視とログ

Dockerエコシステム

基本のおさらい

Dockerコンテナとイメージ

サーバ

OS のカーネル空間

Docker サーバ

ユーザプロセス

ユーザプロセス

ユーザ空間

ユーザプロセス

ユーザ空間

• Cgroups

• Namespaces

mount

UTS

IPC

PID

Network

User

コンテナ

https://hub.docker.com/

Docker Hub(レジストリ)

Dockerクライアント

"docker" デーモン

TC

P:2

37

5, T

CP

:23

76

(TS

L),

Un

ix S

ock

et

Ubuntuレポジトリ

MySQLレポジトリ

tag:latest

tag:14.04

…

tag:latest

tag:5.7

…docker run … Dockerコンテナ

そもそも「Dockerコンテナ」とは何なのでしょうか？

サーバ

OS のカーネル空間

Docker サーバ

ユーザプロセス

ユーザプロセス

ユーザ空間 ユーザ空間

コンテナ

Dockerクライアント

"docker" デーモン

TC

P:2

37

5, T

CP

:23

76

(TS

L),

Un

ix S

ock

et

docker run …

Dockerはサーバ・クライアント型のアーキテクチャです。Linuxカーネルの技術を使い、OS上にプロセスを隔離(isolate)した環境を作ります。

• Cgroups

• Namespaces

mount

UTS

IPC

PID

Network

User

Dockerコンテナを実行するとは、この図では「docker」というコマンドライン上のクライアントが、Dockerデーモン（Dockerの動くホスト環境上）にプロセス実行を命令します。

サーバ

OS のカーネル空間

Docker サーバ

ユーザプロセス

ユーザプロセス

ユーザ空間 ユーザ空間

• Cgroups

• Namespaces

mount

UTS

IPC

PID

Network

User

コンテナ

https://hub.docker.com/

Docker Hub(レジストリ)

Dockerクライアント

"docker" デーモン

TC

P:2

37

5, T

CP

:23

76

(TS

L),

Un

ix S

ock

et

Ubuntuレポジトリ

MySQLレポジトリ

tag:latest

tag:14.04

…

tag:latest

tag:5.7

…docker run …

プロセスを実行するためのファイルの集合体が「Dockerイメージ」です。デフォルトでは、Docker Hub からダウンロードします。GitHubのような場所です。それを、Dockerがダウンロードします。

サーバ

OS のカーネル空間

Docker サーバ

ユーザプロセス

ユーザプロセス

ユーザ空間

ユーザプロセス

ユーザ空間

• Cgroups

• Namespaces

mount

UTS

IPC

PID

Network

User

コンテナ

https://hub.docker.com/

Docker Hub(レジストリ)

Dockerクライアント

"docker" デーモン

TC

P:2

37

5, T

CP

:23

76

(TS

L),

Un

ix S

ock

et

Ubuntuレポジトリ

MySQLレポジトリ

tag:latest

tag:14.04

…

tag:latest

tag:5.7

…docker run …

ダウンロードしたイメージ上のバイナリをプロセスとして実行します。このプロセスは他のプロセスとは分離・隔離（isolate）された状態です。

• Cgroups

• Namespaces

mount

UTS

IPC

PID

Network

User

この囲んだ部分こそが、他から分離隔離されたDockerコンテナと呼ばれる環境です。

zem@dev:~$ docker run -ti ubuntu /bin/bashroot@bdf6207621c7:/# ps -efUID PID PPID C STIME TTY TIME CMDroot 1 0 0 01:11 ? 00:00:00 /bin/bashroot 16 1 0 01:11 ? 00:00:00 ps -efroot@bdf6207621c7:/#

コ ン テ ナ 内 の プ ロ セ ス

ホスト側から分離・隔離されているため、コンテナ内でプロセスID(PID)を確認しようとすると、起動時に指定したコマンドのPIDが「1」になります。

/sbin/initPID 1

alicePID 2

bobPID 3

dockerPID 4

httpdPID 1

コンテナA コンテナB

rubyPID 1

chris.rbPID 2

httpdPID 5

chris.rbPID 7

rubyPID 6

実際のホスト側では、オレンジ色のPIDを持っています。しかし、コンテナの中（青色）では、個々のPIDが1で始まっているように見えます。

root@bdf6207621c7:/# lsbin dev home lib64 mnt proc run srv tmp varboot etc lib media opt root sbin sys usr

root@bdf6207621c7:/# dfFilesystem 1K-blocks Used Available Use% Mounted onrootfs 20511356 12952564 6493836 67% /none 20511356 12952564 6493836 67% /tmpfs 250896 0 250896 0% /devshm 65536 0 65536 0% /dev/shmtmpfs 250896 0 250896 0% /sys/fs/cgroup/dev/disk/by-label/DOROOT 20511356 12952564 6493836 67% /etc/hoststmpfs 250896 0 250896 0% /proc/kcoretmpfs 250896 0 250896 0% /proc/latency_statstmpfs 250896 0 250896 0% /proc/timer_stats

コ ン テ ナ 内 の フ ァ イ ル シ ス テ ム 分離・隔離されているのはプロセスだけでもありません。ファイルシステムもコンテナ内で固有の環境を持ちます。ただし、容量はあくまでホスト上のものが表示されます。他が見えないだけ。

/

/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技術のように、コンテナごとに各々のファイルシステムを割り当てられています。また、ホスト上とディレクトリやファイルを共有することも可能です。

root@bdf6207621c7:/# ip addr show1: 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:00inet 127.0.0.1/8 scope host lo

valid_lft forever preferred_lft foreverinet6 ::1/128 scope host

valid_lft forever preferred_lft forever361: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UPgroup default

link/ether 02:42:ac:11:00:25 brd ff:ff:ff:ff:ff:ffinet 172.17.0.37/16 scope global eth0

valid_lft forever preferred_lft foreverinet6 fe80::42:acff:fe11:25/64 scope link

valid_lft forever preferred_lft forever

root@bdf6207621c7:/# ip routedefault via 172.17.42.1 dev eth0172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.37

コ ン テ ナ 内 の ネ ッ ト ワ ー ク

他にもコンテナはネットワークの隔離・分離も可能です。ホスト側と共有することもできますし、ネットワークを持たないコンテナの作成も可能です。

root@bdf6207621c7:/# freetotal used free shared buffers cached

Mem: 501792 485128 16664 460 127028 164560-/+ buffers/cache: 193540 308252Swap: 0 0 0

コ ン テ ナ 内 の メ モ リ

メモリもディスク容量のようにホスト上で共有されているため、合計容量はホスト側のものです。ただし、コンテナが利用可能なメモリ上限を設定できます。

root@bdf6207621c7:/# exit

zem@dev:~$ docker stop bdf6207621c7

コ ン テ ナ の 終 了

あと、独特なのは、コンテナを終了するとは PID 1 で起動したプロセスが終了することです。この例では /bin/bash のプロセスを「exit」で終了すると、コンテナが停止状態になります。あるいは「docker stop」コマンドもあります。

• Cgroups

• Namespaces

mount

UTS

IPC

PID

Network

User

(汗

どこで、どう Docker を使うのか？

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

サーバ

OS のカーネル空間

Docker サーバ

ユーザプロセス

ユーザプロセス

ユーザ空間

ユーザプロセス

ユーザ空間

• Cgroups

• Namespaces

mount

UTS

IPC

PID

Network

User

コンテナ

https://hub.docker.com/

Docker Hub(レジストリ)

Dockerクライアント

"docker" デーモン

TC

P:2

37

5, T

CP

:23

76

(TS

L),

Un

ix S

ock

et

Ubuntuレポジトリ

MySQLレポジトリ

tag:latest

tag:14.04

…

tag:latest

tag:5.7

…docker run … Dockerイメージ

Dockerコンテナと同様、独特の概念を持つのがDockerイメージです。

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

ベース・イメージ(公式)Ubuntu, CentOS等

イメージ層コマンドごとに記録

Docker イメージの構造

読み込み専用(Read Only)

Dockerイメージは、イメージ層（レイヤ）の積み重ね構造です。一番下に「ベース・イメージ」と呼ばれるレイヤがあります。ピザで言う所の「生地」にあたります。

ベース・イメージ(公式)Ubuntu, CentOS等

イメージ層コマンドごとに記録

Docker イメージの構造

読み込み専用(Read Only)

このレイヤを積み重ねた集合が、Dockerイメージと呼ばれるもの。CD-ROMやDVD-ROMのように、常に読み込み専用です。

例：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 nginxIMAGE CREATED CREATED BY SIZE COMMENT

docker history <image id/name>

例えばNginxコンテナを実行するとは、Nginxイメージを利用し、その中にある"nginx"バイナリをコンテナの分離・隔離されたプロセスとして実行することです。

ベース・イメージ(公式)

イメージ層

Docker コンテナを起動するとは

読み込み専用(Read Only)

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

・隔離されたプロセスの起動(コンテナ化された状態）

docker run <opts> <image:tag>

コンテナの「実行」について捕捉。実際は書き込み可能なイメージレイヤが追加され、各種の変更情報が自動保存されています。これを元に新しいイメージを作成可能です。

サーバ

OS のカーネル空間

Docker サーバ

ユーザプロセス

ユーザプロセス

ユーザ空間

ユーザプロセス

ユーザ空間

• Cgroups

• Namespaces

mount

UTS

IPC

PID

Network

User

Dockerコンテナ

https://hub.docker.com/

Docker Hub(レジストリ)

Dockerクライアント

"docker" デーモン

TC

P:2

37

5, T

CP

:23

76

(TS

L),

Un

ix S

ock

et

Ubuntuレポジトリ

MySQLレポジトリ

tag:latest

tag:14.04

…

tag:latest

tag:5.7

…docker run …Dockerイメージ

以上がDocker固有のコンテナとイメージに関する基礎概念です。

Dockerの開発環境

では開発環境で実際にどのように使うのか、一番手軽な所からみていきましょう。

OS ( Linux )

物理/仮想サーバ

Docker エンジン( docker デーモン )

Linux kernel

コンテナ コンテナ コンテナ

リモートAPI

dockerクライアント

・docker コマンド・Kitematic (GUI)

Dockerコンテナを使うためにはLinuxサーバの環境が必要になります。そこにクライアントから各種の命令を送ります。

OS ( Linux )

Docker エンジン( docker デーモン )

Oracle VM VirtualBox

仮想マシン

docker コマンド( クライアント )

ローカルな docker ホスト環境 Mac OS X や Windows では、Linuxカーネルを持ちません。途中に VirtualBox などでLinux仮想マシンを立ち上げ、その中にDocker をセットアップします。

Docker動作環境の構築

ローカルで構築 リモートで構築 クラウドサービスの利用

Docker Machine(旧boot2docker)

Docker社によるバイナリ・パッケージ

Amazon EC2Container Service

(ECS)

IBM Bluemix

Microsoft Azure

Google ContainerEngine

VirtualBox

Windows or Mac OSX Virtual or Physical Linux Machine

コミュニティによるバイナリ・パッケージ

商用サポート版

ソースコードからビルド

＋

Docker Toolbox

Docker Toolbox に含まれているDocker Machine（マシン）が環境構築とDOckerセットアップを自動的に行います。

41

ここまでのキーワード

‣ Docker Engine

• docker デーモン（サーバ）

‣ Docker コンテナ

‣ Docker イメージ

• Dockerfile

‣ Docker Machine

‣ Docker Toolbox

Docker(エンジン)とは、環境をコンテナ化し、移動・実行する仕組みを提供。しかも簡単なコマンドで操作できる。

DockerHubから取得する

コンテナをコミットする

Dockerfileで構築する

Dockerイメージの入手・作成は３つの方法があります。

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

44

‣ Dockerfile の役割

どのようなイメージにするか指示

• どのベース・イメージを使うのか？

• 何のプログラムをインストールするのか？

• どのようなコマンドを実行するのか

‣ docker build コマンドで構築

docker build –t <レポジトリ:タグ> <Dockerfileのパス>

Dockerfile

docker build

イメージの自動構築

これがあれば、誰でもコンテナ環境を確実・迅速に作れます。

FROM ubuntu:14.04

RUN apt-get install -y wgetCMD /usr/bin/wget

FROM nginx

ADD ./contents /usr/share/nginx/html

FROM centos:7MAINTAINER <自分の名前>RUN yum update -yRUN yum install -y epel-releaseRUN yum install -y nginxADD index.html /usr/share/nginx/html/EXPOSE 80CMD ["nginx", "-g", "daemon off;"]

ex1 ex2

ex3記述そのものは、どれもシンプルです。「FROM」は何のDockerイメージを元にするかを指定。「RUN」は構築時にコンテナ内で実行するコマンド、「CMD」はコンテナ実行時の標準コマンドを指定。「ADD」はコンテナに対してファイルを追加。「EXPOSE」はコンテナの公開用ポート番号を指定できます。

楽々構築できるよね^^

でも、WebとDBが別々の

コンテナの場合は？^^;

Engine

$ docker run …

$ docker run …

$ docker run …

$ docker run …

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

Engine

$ docker-compose up

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

複数のコンテナをコードで管理

コンテナの同時起動・停止

コンテナのスケール

ネットワーク機能に対応(1.6～)

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コマンドになれていれば扱いやすいと思います。

wordpress:image: wordpresslinks:

- db:mysqlports:

- 8080:80

db:image: mariadbenvironment:

MYSQL_ROOT_PASSWORD: example

WordPress 用の docker-compose.yml 例

参照：https://hub.docker.com/_/wordpress/

設定ファイルは YAML 形式のファイルです。ここで Dockerfile を呼び出すこともできます。また、コンテナ間をリンクする設定や、ネットワーク情報の定義も可能。

サービス"wordpress"・イメージ: wordpress・dbサービスをリンク・ホスト側ポート8080に

コンテナのポート80を

サービス"db"・イメージ: mariadb・環境変数を指定

mongo:image: mongocommand: mongod --smallfiles --oplogSize 128

rocketchat:image: rocketchat/rocket.chat:latestenvironment:

- 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のセットアップも同時に可能です。

続きはウェブで…！

http://docs.docker.jp/compose

55

‣ Docker Composeは

複数のサービスを管理

• docker コマンドと互換性

‣ Compose ファイルで設定

• YAML形式

• docker-compose.yml 等

ここまでのまとめまだ環境構築で消耗してるの？

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 run …

$ docker run …

$ docker run …

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

$ docker run …

$ docker run …

$ docker run …

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

サーバ

・Docker クライアント（Swarm操作）

・Docker Machine（環境構築）

Swarm Manager

サーバ

swarm-master

Dockerデーモン

サーバ

Swarm Agent

サーバ

swarm-node-01

Dockerデーモン

サーバ

Swarm Agent

サーバ

swarm-node-02

Dockerデーモン

リモート操作

コンテナのスケジュール

Dockerとの違いは、dockerコマンドのリクエスト先がSwarm用のマネージャに対して行う所だけ。利用者からはコマンドが共通。

コンテナのスケジューリング

Docker API と互換性

ディスカバリ・バックエンドと連携

ネットワーク機能に対応

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 docker01export 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 でデプロイ/プロビジョニング

ディスカバリ・バックエンド

Docker Swarm分散サーバ上のコンテナ（サービス）をスケジューリング

Docker MachineDocker Engine動作環境や仮想マシン環境・Swarmクラスタを自動的に構築・一元管理

Docker Compose複数のサービスを一括して管理

DockerEngine

Docker Toolbox開発環境セット

続きはウェブで…！今だからこそ知りたい Docker Compose/Swarm 入門

http://www.slideshare.net/zembutsu/introduction-to-docker-compose-and-swarm

技術選択の要素

2■■□□ Considering of Use Case

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

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

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

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

検討要素

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

75

Dockerコンテナのライフサイクル

※ Docker Docs より引用：https://docs.docker.com/engine/reference/api/docker_remote_api/

まずは、ライフサイクルの理解です。バッチ的なコマンド処理もサービスとしての常駐も可能です。

76

‣ 開発環境のみ

‣ 開発環境～ CI / テスト環境

‣ 開発環境～本番環境

利用シーンの範囲を検討 Dockerの基本的ライフサイクルやコマンドの使い方などの理解は前提として、次に、どのような場面でDockerを使うのかで視点が変わってきます。

77

利用シーン

開発 運用

評価 ステージによって異なる

例えば開発チームと運用チームが分かれているかもしれません。駅伝やリレーのように、各チームだけでは完結しません。お互い、歩み寄りが必要になります。

TASK

devチームの範囲

opsチームの範囲

78

利用シーン

開発 運用

評価 ステージによって異なる

あるいは、自分一人（または、特定のチーム内だけ）で全てが完結する可能性も有りますし・・・

79

利用シーン

開発 運用

評価 ステージによって異なる

工程ごとに様々な人がいる場合も考えられます。

TASK TASK

80

検討項目

1. 利用者は誰で、用途は何か？

2. インフラをどうするのか？

3. OSを何にするのか？

4. ディストリビューションを何にするのか？

5. ストレージ・ドライバを何にするのか？

6. ベースイメージは何にするのか？

7. セキュリティをどのように考慮すべきか？

8. 性能をどのように担保するのか？

★重要な警告★本章に含まれる以降の検討要素は私個人の見解であり頻繁にいただく質問に対する一般的見解をまとめたものです。所属会社およびDocker, Inc. の意見を代表するものではありませ。また、Docker 1.10 現在の情報です。今後の Docker のバージョンによっては判断材料として適切ではない場合が有り得ます。常に、最新情報をご確認願います。

81

‣コンテナを誰が使うのか？開発チーム？ 運用チーム？ テスト？ 検証？ コミュニティ？

自社内？ お客さま？

‣何のために使うのか？システム開発？ 運用？ 商用サービス？ 検証？

技術選択にあたっての基本ポイントまず始めに誰が何のために使うのか？という視点が必須です。

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

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

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

ちゃんとしたモノが必要であれば、それなりに手間暇をかけるべき場合も考えられます。改めて、誰が何のために使うのか？を考慮するのは非常に重要だと考えています。

特に、仕事で使うのであれば、最終的にピザを食べるのは誰か＝Dockerコンテナを使用・運用するのは誰かという視点は欠かせないものでしょう。

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

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

‣ ベンダーによる保守サポート有無

‣ コミュニティによるサポートの有無

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独特の判断ポイントです。こちらもどのような用途に使うのか、あるい経験を持っているかによって異なります。

https://docs.docker.com/engine/userguide/storagedriver/selectadriver/

一般的な指針として、このような区分はされていますが、鵜呑みはしないほうが良いと思います。扱うファイルサイズだったり OS やハードウェアにも影響を受けます。なので個々の環境におけるベンチマークは必要と思います。

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

こちらはレイヤを抽象化したもの。

AUFS

AUFS ストレージ・ドライバを使う — Docker-docs-ja 1.10.0b ドキュメントhttp://docs.docker.jp/engine/userguide/storagedriver/aufs-driver.html

AUFSはコンテナに書き込みを行う時、初回にコピーが発生します。1GBのファイルに追記する場合、1GBのファイルをコピー後に処理が進行します。

devicemapper

Device Mapper ストレージ・ドライバを使う — Docker-docs-ja 1.10.0b ドキュメントhttp://docs.docker.jp/engine/userguide/storagedriver/device-mapper-driver.html

一方、RHEL系の場合はコピーは発生しません。64KB単位で処理が行われます。

コンテナのボリューム ボリュームはCoW処理を行わず、ホスト上のI/O性能が直接反映。

コンテナでデータを管理する — Docker-docs-ja 1.10.0b ドキュメントhttp://docs.docker.jp/engine/userguide/containers/dockervolumes.html

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 通信が推奨

主なセキュリティ考慮点

96

検討項目まとめ

1. 利用者は誰で、用途は何か？

2. インフラをどうするのか？

3. OSを何にするのか？

4. ディストリビューションを何にするのか？

5. ストレージ・ドライバを何にするのか？

6. ベースイメージは何にするのか？

7. セキュリティをどのように考慮すべきか？

8. 性能をどのように担保するのか？

判断材料の中でも、比較的重要なものをリストアップしました。

97

‣ 公式

https://docs.docker.com/

‣ 日本語訳

http://docs.docker.jp

参考にすべきはドキュメント

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 オススメのドキュメント

課題と最新動向

3■■■□ Issues and What's new

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

Dockerの動作ホスト

コンテナ コンテナ

docker0 bridge

eth0 eth0

IP: 172.17.0.2 IP: 172.17.0.2

IP: 172.17.0.1

Docker 1.8 以前のネットワーク

Dockerの動作ホスト

コンテナ コンテナ

docker0 bridge

eth0 eth0

IP: 172.17.0.2IP: 172.18.0.10

IP: 172.17.0.2IP: 172.18.0.11

IP: 172.17.0.1

任意 bridge

IP: 172.18.0.1

デフォルトのブリッジ・ホストネットワーク

ユーザ定義ネットワーク

Docker 1.9 からのブリッジ・ネットワーク

eth1eth1

…

Dockerの動作ホスト

コンテナ コンテナ

docker0 bridge

eth0 eth0

IP: 172.17.0.2IP: 172.18.0.10

IP: 172.17.0.2IP: 172.18.0.11

IP: 172.17.0.1

任意 bridge

IP: 172.18.0.1

デフォルトのブリッジ・ホストネットワーク

ユーザ定義ネットワーク

Docker 1.9 からのブリッジ・ネットワーク

eth1eth1

…

「--link」機能はdocker 0 ブリッジのみ対応

「コンテナ名.net名」で動的な名前解決可能に（リンク機能の代替)

docker0ネットワーク172.17.0.1/16

docker0bridge

IP: 172.17.0.1

ホスト側のインターフェース

ブリッジ

overlayネットワーク192.168.10.1/16

コンテナA

eth0

overlaynetwork

IP: 192.168.10.1

docker0bridge

eth0

overlaynetwork

eth0 IP: 172.17.0.2veth..

コンテナB

ホスト１ ホスト２

docker0ネットワーク172.17.0.1/16

docker0bridge

IP: 172.17.0.1

ホスト側のインターフェース

ブリッジ

overlayネットワーク192.168.10.1/16

コンテナA

eth0

overlaynetwork

eth1 IP: 192.168.10.2veth..

IP: 192.168.10.1

docker0bridge

eth0

overlaynetwork

eth0 IP: 172.17.0.2veth..

eth1 IP: 192.168.10.3veth..

コンテナB

ホスト１ ホスト２

疎通

swarm-kvsswarm-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

swammaster

コンテナ コンテナ

コンテナ

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

root@demo1210:~# docker network lsNETWORK ID NAME DRIVER1a34c54ac517 bridge bridge97f64692c37a none null7bfea31360e9 host host

コマンド「network ls」は、ネットワーク一覧を表示

ドライバは４種類

・bridge … bridgeという名前は「docker0」ネットワーク

・host … ホスト・ネットワーキングは、コンテナが直接ホストを参照

・null … コンテナ内に仮想インターフェースを付けないモード

・overlay … 複数ホストにまたがるオーバレイ・ネットワーク

root@demo:~# docker network create front9959a6e12da55fa6deacffa0146ae351204d8a89d72d900ddde969fdf1f3fe40root@demo:~# docker network lsNETWORK ID NAME DRIVER28a6c2d24224 none null49ef940103f8 host host9959a6e12da5 front bridge1ad2e3648872 bridge bridge

新しく「front」という名称のブリッジ・ネットワークを作成・確認

root@demo:~# docker network inspect front[

{"Name": "front","Id": "9959a6e12da55fa6deacffa0146ae351204d8a89d72d900ddde969fdf1f3fe40","Scope": "local","Driver": "bridge","IPAM": {

"Driver": "default","Config": [

{}]

},"Containers": {},"Options": {}

}]

新しいネットワーク

# docker run -itd --net=front --name=web ubuntu bashecc0e1d7ee23792a9bbd5b127e84af5534d66e92b10750413a8ff686c954c44e

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ではない）

root@demo:~# docker network create back6afc733feeaf46aaff80c5a605bacba63ae3463d1cfb925a9cdc9d82c3e9184broot@demo:~# docker network lsNETWORK ID NAME DRIVER28a6c2d24224 none null49ef940103f8 host host9959a6e12da5 front bridge6afc733feeaf back bridge1ad2e3648872 bridge bridgeroot@demo:~# docker run -itd --net=back --name=db ubuntu bash0c3da94b22aa6d260a68ec7763e0962b2b273e6656e1d875a0c7c371244ebb41

新しいブリッジネットワーク「back」と、「db」コンテナをそこに作成

新しいネットワーク

root@demo:~# docker exec -it web bashroot@ecc0e1d7ee23:/# ifconfigeth0 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.0inet6 addr: fe80::42:acff:fe12:2/64 Scope:LinkUP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1RX packets:16 errors:0 dropped:0 overruns:0 frame:0TX packets:8 errors:0 dropped:0 overruns:0 carrier:0collisions:0 txqueuelen:0RX bytes:1296 (1.2 KB) TX bytes:648 (648.0 B)

（省略）

「web」コンテナにプロセス bash を追加し、インターフェースを確認

root@demo:~# docker network connect back webroot@ecc0e1d7ee23:/# ifconfigeth0 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.0inet6 addr: fe80::42:acff:fe12:2/64 Scope:LinkUP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1RX packets:16 errors:0 dropped:0 overruns:0 frame:0TX packets:8 errors:0 dropped:0 overruns:0 carrier:0collisions:0 txqueuelen:0RX bytes:1296 (1.2 KB) TX bytes:648 (648.0 B)

eth1 Link encap:Ethernet HWaddr 02:42:ac:13:00:03inet addr:172.19.0.3 Bcast:0.0.0.0 Mask:255.255.0.0inet6 addr: fe80::42:acff:fe13:3/64 Scope:LinkUP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1RX packets:8 errors:0 dropped:0 overruns:0 frame:0TX packets:8 errors:0 dropped:0 overruns:0 carrier:0collisions:0 txqueuelen:0RX bytes:648 (648.0 B) TX bytes:648 (648.0 B)

「web」「db」の両コンテナをつなげるには？「back」ネットワークに接続

root@ecc0e1d7ee23:/# cat /etc/hosts172.18.0.2 ecc0e1d7ee23127.0.0.1 localhost::1 localhost ip6-localhost ip6-loopbackfe00::0 ip6-localnetff00::0 ip6-mcastprefixff02::1 ip6-allnodesff02::2 ip6-allrouters172.19.0.2 db172.19.0.2 db.back

さらに/etc/hostsを確認すると、「db」コンテナの名前解決も可能に

「コンテナ名.ネットワーク名」で名前解決使用例：DB名やキャッシュ・サーバ等

※network connect をした時点で、ping 等、お互いが疎通する※逆に、dbコンテナ上で/etc/hostsを確認すると、

「172.19.0.3 web.back」の記述が自動的に追加されている

root@0c3da94b22aa:/# cat /etc/hosts172.19.0.2 0c3da94b22aa127.0.0.1 localhost::1 localhost ip6-localhost ip6-loopbackfe00::0 ip6-localnetff00::0 ip6-mcastprefixff02::1 ip6-allnodesff02::2 ip6-allrouters172.19.0.3 web172.19.0.3 web.back

「db」コンテナ内から「web」コンテナを確認

「ホスト名.ネットワーク名」で名前解決使用例：DB名やキャッシュ・サーバ等

※webコンテナは172.18.0.2のIPアドレスも持つが、疎通できない。あくまで web と db コンテナが共通している back ネットワーク内のIPアドレス体系のみ（ネットワークを追加したら可能）。

http://docs.docker.jp/engine/userguide/networking

Docker APISwarm

Manager

ディスカバリ・バックエンド

リソース・プール

スケジューラ

fleet

etcd:image: gcr.io/google_containers/etcd:2.0.13container_name: etcdcommand: ['/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.7container_name: apiserverports:- "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.7command: ["/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.7command: ["/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.7command: ['/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 nodeenvironment:- "affinity:container!=*kubelet*"

proxy:image: gcr.io/google_containers/hyperkube:v1.0.7command: ['/hyperkube', 'proxy', '--master=http://apiserver:8080', '--v=2']privileged: true# A proxy should run alongside another kubeletenvironment:- "affinity:container==*kubelet*"

引用：Deploy and Manage Any Cluster Manager with Docker Swarm | Docker Bloghttp://blog.docker.com/2015/11/deploy-manage-cluster-docker-swarm/

最近の動向

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 リリース情報

tutumhttps://www.tutum.co/

Docker社が買収(10月)

AWS, Digital Ocean, Azure,

SoftLayer, Packet と連携

コンテナのデプロイと管理

Docker Hub を補完する役割

Docker Hub Tutum

パブリック環境でコンテナを実行

Docker Cloudhttp://cloud.docker.com

DTRDocker Trusted Registry

Orca (beta) + UCPUniversal Control Plane

より安全にコンテナを実行

https://www.docker.com/universal-control-plane

まとめ

4■■■■ Wrap up

125

今日の振り返りDocker基礎講座

‣ 改めて「Docker」とは何か？用語の定義と周辺ツール

基本概念の理解（コンテナ、イメージ）

‣ 利用段階と考慮点ライフサイクルと検討フロー

技術（技法）の選択とベストプラクティス

‣ 課題と最新動向 (Docker 1.9, 1.10)Docker Cloud (Tutum), Docker Datacenter ( Universal Control Plane + Docker Trusted Registry)

126

誰が？何のために？

127

用途に応じた技術選択のポイントDocker基礎講座

‣ 1. 利用者は誰で、用途は何か？

‣ 2. インフラをどうするのか？

‣ 3. OSを何にするのか？

‣ 4. ディストリビューションを何にするのか？

‣ 5. ストレージ・ドライバを何にするのか？

‣ 6. ベースイメージは何にするのか？

‣ 7. セキュリティをどのように考慮すべきか？

‣ 8. 性能をどのように担保するのか？

128

何か気になる所はありますか？Docker基礎講座

‣ 日本語ドキュメントはこちら

http://docs.docker.jp

• v1.9 v1.10移行中

‣ Ask the Speaker

‣ @zembutsu

129

‣ https://blog.docker.com

‣ https://docs.docker.com

‣ http://docs.docker.jp

• v 1.9 v1.10 移行作業中(2016年2月現在）

参考情報References

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