2016年2月18日(木) 目黒雅叙園 Developers Summit 2016 発表資料 #devsumi 【18-E-3】クラウド・ネイティブ時代の2016年だから始める Docker 基礎講座 http://event.shoeisha.jp/devsumi/20160218/session/1015/

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用の
マネージャに対して行う所だけ。
利用者からはコマンドが共通。

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

64. 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 でデプロイ/プロビジョニング
ディスカバリ・バックエンド

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

90. 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

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

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

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

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

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

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

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

99. 課題と最新動向
3■■■□ Issues and What's new

100. 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

101. Dockerの動作ホスト
コンテナ コンテナ
docker0 bridge
eth0 eth0
IP: 172.17.0.2 IP: 172.17.0.2
IP: 172.17.0.1
Docker 1.8 以前のネットワーク

102. 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
…

103. 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名」で
動的な名前解決可能に
（リンク機能の代替)

104. 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
ホスト１ ホスト２

105. 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
ホスト１ ホスト２
疎通

106. 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

107. 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 … 複数ホストにまたがるオーバレイ・ネットワーク

108. 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": {}
}
]
新しいネットワーク

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

110. 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」コンテナをそこに作成
新しいネットワーク

111. 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 を追加し、インターフェースを確認

112. 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」ネットワークに接続

113. 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」の記述が自動的に追加されている

114. 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アドレス体系のみ（ネットワークを追加したら可能）。

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

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

117. 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*"

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

119. 最近の動向

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

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

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

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

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

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

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

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

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

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

130. 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