2015-01-27 Docker introduction ( http://goo.gl/gPtECf )の最新版です。 @uzyexe

1. 1
Docker Introduction
By @uzyexe Jul 27, 2015
- ∼Dockerの基礎とユースケースに関する考察∼

2. 山田 修司（Shuji Yamada）
@uzyexe
2
whoami
2

3. 3
パラダイムシフト
https://www.flickr.com/photos/shawnclover/6287072270/

4. 4
ユーザークライアントのパラダイムシフト
1995 2015
Mobile
or
Tablet devices
Thick and fat
client

5. 5
ユーザークライアントのパラダイムシフト
1995 2015
Mobile
or
Tablet devices
Thick and fat
client

6. 6
インフラ環境のパラダイムシフト
1995 2015
Monothilic many Resources

7. インフラ環境のパラダイムシフト
1995 2015
Monothilic many Resources
7

8. Defined-stack:
- OS
- Middle-ware
- Runtime
- etc...
8
サービススタックのパラダイムシフト
1995 2015
best services
and
best app

9. From 1995 to 2015
9
Thick Thin
Defined-Stack
best services
and
best app
Monothilic many Resources
1995 2015

10. IaaS
Infrastructure as a Services
10
Host
PaaS
Platform as a Services
Build
&

11. IaaSがもたらしたパラダイムシフト
• あらゆる意味でハードだったインフラに対して柔軟性をもたらした
• セルフサービス： 自分自身で自由にインフラ構成を作れる
• オンデマンド課金： 使った分だけ課金
• APIセントリック： APIを活用することでCI/CDや運用自働化や
infrastructure as a codeを実現。
• プラガブル： 各種ストレージやネットワーク、データベースやネー
ムサーバなどを好きなように統合連携できる。
11

12. PaaSがもたらしたパラダイムシフト
• サービス開発にアジャイリティ（迅速性）をもたらした。
• オンデマンド課金： 使った分だけ課金
• インフラの抽象化： アプリケーション開発に専念できる。
• APIセントリック： APIを活用することでCI/CDや運用自働化を
実現。一方で、NoOps（運用技術者不要論）の登場。
• プラガブル： 各種サードパーティサービスを好きなように統合連
携できる。
12

13. 13
Container
https://www.flickr.com/photos/dahlstroms/3144199355/

14. 最新のコンテナ技術がもたらすパラダイムシフト
• より迅速にアプリケーションをスケールアウトできるようになる。
• アプリケーションをコンテナにパッケージングすることで、世界中
のほとんどのコンピューティングリソース上で再現可能かつ再利用
可能なイメージを迅速にプロビジョニングできるようになる。
• 1-Role/1-VM => 1-Role/1-Contaienr、環境構築に必要なリソー
スが省力化され、従来の仮想マシンよりも高効率な収容構成が可能
になる。
14

15. 15
物理サーバ 仮想マシン（VM） コンテナ
4 72時間
5 15分
5 30秒
インスタンスの立ち上げまでにかかる平均的な時間
15

16. HelloWorld
$ time docker run debian echo "hello world"
Unable to find image 'debian:latest' locally
debian:latest: The image you are pulling has been verified
1aeada447715: Pull complete
479215127fa7: Pull complete
511136ea3c5a: Already exists
Status: Downloaded newer image for debian:latest
hello world
real 0m15.250s
user 0m0.050s
sys 0m0.027s
16
# 外部レジストリからイメージをダウンロードしてきた場合

17. HelloWorld
$ time docker run debian echo "hello world"
hello world
real 0m0.169s
user 0m0.009s
sys 0m0.010s
17
# 最新イメージのキャッシュがローカルに存在する場合

18. イメージサイズ
18
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
postgres latest 2389997c2ef2 3 days ago 213.3 MB
nginx latest 90081fa15a0c 3 days ago 91.62 MB
mysql latest 335228ceb173 3 days ago 282.6 MB
debian latest 4d6ce913b130 8 days ago 84.98 MB
centos latest 8efe422e6104 2 weeks ago 210 MB
fedora latest 834629358fe2 3 weeks ago 241.3 MB
busybox latest 4986bf8c1536 3 weeks ago 2.433 MB
ubuntu latest ed5a78b7b42b 4 weeks ago 188.3 MB

19. 19
未回答
不明
10,000 ~
5,000 - 9,999
2,000 - 4,999
500 - 1,999 100 - 499
~ 100 < 100
100-499
500-1999
2000-4999
5000-9999
10000 >
不明
未回答 2.0%
8.0%
8.5%
4.9%
8.4%
16.9%
23.0%
28.3%
企業におけるサーバ台数
http://www.slideshare.net/realgenekim/2014-state-of-devops-findings-velocity-conference

20. 20
スケーラビリティ

21. 21
スケーラビリティ 高効率

22. 22
スケーラビリティ 高効率
汎用性

23. On
23

24. Cloud?
24

25. Cloud?
Bare-metal?
25

26. Cloud?
Laptop?
Bare-metal?
26

27. 27
CloudLaptop Bare-metal

28. 28
On
CloudLaptop Bare-metal

29. 29
CloudLaptop Bare-metal
On

30. 30
コンテナ技術がもたらす変化
https://www.flickr.com/photos/mattmflickr/7461949414/

31. ワークフローにどのような変化が起こるか？
• アプリケーションやミドルウェアを簡単にイメージ化できる。
（ChefやPuppetなどの高機能で複雑なデプロイツールのコード簡
略化を併せて実現できる。）
• デザイナーでもローカルPC上で開発環境を再現したコンテナを起動
して、コンテナ上でデザインをコーディングできる。
31

32. コンテナが世の中の開発にもたらす変化
• より手軽で、より壊しやすく、より柔軟な環境を手にいれることが
できるようになる。
• 自身でコンテナを構築し、自身のローカル環境上でアプリケーショ
ンを手軽に実行することができるようになった。
• コンテナが実行される『場所』のインフラ特性を気にしなくても
良くなった。
• 引き換えに、コンテナの構築方法や操作手法を習得する必要がある。
32

33. コンテナが世の中の運用にもたらす変化
• よりセットアップしやすく、よりメンテナンスしやすい環境を手に
いれることができるようになる。
• 膨大で煩雑なセットアップスクリプトを書いて『イメージ』を作成
しなくても良くなった。
• Devが作ったコンテナイメージをサーバ上に直接展開できるよう
になり、アプリケーションのセットアップコストが削減された。
• 引き換えに、大量のコンテナの管理操作手法を習得する必要がある。
33

34. 開発と運用に共通して課される役割
• VMよりも処理性能的なオーバーヘッドが少なく、ランニングコスト
を削減できるコンテナ技術を活用してシステムを構築するスキルが
求められる。
• VMよりも迅速にアプリケーションを展開できるコンテナを活用して、
従来よりも高速にサービスを構築するスキルが求められる。
• コンテナ技術を活用して、従来のワークフローを改善するスキルが
求められる。
34

35. 35
Learning Step
https://www.flickr.com/photos/nomadic_lass/6820209341/

36. 学習ステップ
1. Dockerで遊んでみる。
2. 本格的に利用する場合の課題を考えてみる。
3. 本格的に使ってみる。
36

37. stage1. Dockerで遊んでみる
• 自身の環境で Docker を動かしてみる。
• 自身の環境で Docker コンテナのイメージを作ってみる。
• ネームスペースや cgroups などの Linux 由来の特徴を理解する。
37

38. stage2. 本格的に利用するときの課題
• データの永続化
• イメージの正当性確認
• イメージ転送の暗号化
• 監視、ロギング
• 複数台のコンテナ管理
• アップデート
38

39. stage3. 本格的に使ってみる
• コンテナ複数台のスタティックなオーケストレーション
• CircleCI や Drone.io との CI/CD 連携
• aufs, btrfs, devicemapper
• Capabilities
• セキュリティ
• Networking (iptabels, bridge, pipework, ...)
• レポジトリ
39

40. Future stage
• DockerUI, Panamax, Rancher.io
• CoreOS (etcd+fleet+flannel), Atomic Host
• Docker Compose, Docker Swarm, Docker Machine...
• Mesos+docker, Consul+docker, kubernetes, Helios, ...
• Deis, Flynn, ...
• Rocket, RunC, ...
40

41. 41
https://www.flickr.com/photos/yukop/11941236015/

42. 42
Docker Engine
HyperVisor
Guest
OS
Server
Guest
OS
Guest
OS
App-1
App-2
App-1
App-1’
App-3
App-4
App-1
App-2
App-1
App-1’
App-2
App-3
Docker
Type-1
HyperVisor
OS
HyperVisor
Server
App-1
App-2
App-1
App-1’
App-3
App-4
Type-2
HyperVisor
Bins/Libs Bins/LibsBins/Libs Bins/Libs
Bins/Libs Bins/Libs
Bins/Libs Bins/Libs
Guest
OS
Guest
OS
Guest
OS
OS
Server

43. コンテナ技術の代表的な特徴
• バージョンに依存しない。
• OSディストリビューションに依存しない。
• 特定のモジュールに依存しない。
• どこでも同じ動作をする。
43

44. Dockerコンテナの特徴
• コンテナ ＝ ホストから分離されているプロセス（ネームスペース）
• 各コンテナはホストOSのkernelを共有する。
• コンテナから見えるデバイスはエミュレーション動作ではない。
• 実際にほとんどの環境上でコンテナを動かせる。
Linux, Windows, OSX, FreeBSD...
Cloud, Server, Windows PC, Macbook, RaspberryPi...
44

45. 45
On
CloudLaptop Bare-metal

46. コンテナに何を入れればいいの？
• コード
• ライブラリ
• バイナリ
• アプリケーション
• データ
• その他、なんでも
46

47. コンテナを何に使えばいいの？
• webアプリケーション
• APIバックエンド
• データベース（SQL, NoSQL）
• メッセージキュー
• アプリケーションのビルド環境
• その他、なんでも
47

48. Dockerを動かすために必要な環境
• 64bit 版の Linux, Mac OSX, Windows マシン
• Linux の場合は kernel 3.10 以上
• RHEL6/CentOS6 (kernel 2.6 系) のサポートは Docker 1.8
で打ち切られます。
• FreeBSD の場合は 2015 年 7 月以降の FreeBSD 11-CURRENT
ただし、公式サポートはされてません。
48

49. Dockerのインストール
49
$ sudo apt-get update
$ sudo apt-get install wget
$ wget -qO- https://get.docker.com/ | sh
$ sudo yum update
$ curl -sSL https://get.docker.com/ | sh
• Ubuntu 14.04
• RHEL7/CentOS7

50. or Boot2Docker for Windows
50

51. or Boot2Docker for Mac OS X
51

52. Docker Platform
• Linux環境上で動作するアプリケーションのコンテナ化
• コンテナの実行とコンテナの各種リソース制御
• コピー·オン·ライトなファイルシステムを活用したプロビジョニング
• 簡単にコンテナイメージを構築するための手法の提供 (Dockerfile)
• コンテナイメージを世界中に共有できる環境の提供 (DockerHub)
52

53. Dockerfile
• Dockerfileはコンテナイメージを構築す
るためのレシピ。
• FROMでベースイメージを宣言する。
• RUNでアプリケーションセットアッ
プ用のコマンドを宣言する。
• CMDで実行コマンドを宣言する。
• EXPOSEで開放ポートを宣言する。
53
# vim Dockerfile
FROM ubuntu:14.04
RUN apt-get update
RUN apt-get install -y nginx
RUN echo ‘Hi, hello my container’ /
> /usr/share/nginx/html/index.html
CMD nginx -g “daemon off”
EXPOSE 80
典型的なDockerfileのサンプル

54. Dockerfile
• Dockerfileはコンテナイメージを構築す
るためのレシピ。
• FROMでベースイメージを宣言する。
• RUNでアプリケーションセットアッ
プ用のコマンドを宣言する。
• CMDで実行コマンドを宣言する。
• EXPOSEで開放ポートを宣言する。
54
# vim Dockerfile
FROM ubuntu:14.04
RUN apt-get update
RUN apt-get install -y nginx
RUN echo ‘Hi, hello my container’ /
> /usr/share/nginx/html/index.html
CMD nginx -g “daemon off”
EXPOSE 80
典型的なDockerfileのサンプル

55. Dockerfile
• Dockerfileはコンテナイメージを構築す
るためのレシピ。
• FROMでベースイメージを宣言する。
• RUNでアプリケーションセットアッ
プ用のコマンドを宣言する。
• CMDで実行コマンドを宣言する。
• EXPOSEで開放ポートを宣言する。
55
# vim Dockerfile
FROM ubuntu:14.04
RUN apt-get update
RUN apt-get install -y nginx
RUN echo ‘Hi, hello my container’ /
> /usr/share/nginx/html/index.html
CMD nginx -g “daemon off”
EXPOSE 80
典型的なDockerfileのサンプル

56. Dockerfile
• Dockerfileはコンテナイメージを構築す
るためのレシピ。
• FROMでベースイメージを宣言する。
• RUNでアプリケーションセットアッ
プ用のコマンドを宣言する。
• CMDで実行コマンドを宣言する。
• EXPOSEで開放ポートを宣言する。
56
# vim Dockerfile
FROM ubuntu:14.04
RUN apt-get update
RUN apt-get install -y nginx
RUN echo ‘Hi, hello my container’ /
> /usr/share/nginx/html/index.html
CMD nginx -g “daemon off”
EXPOSE 80
典型的なDockerfileのサンプル

57. Dockerfile
• Dockerfileはコンテナイメージを構築す
るためのレシピ。
• FROMでベースイメージを宣言する。
• RUNでアプリケーションセットアッ
プ用のコマンドを宣言する。
• CMDで実行コマンドを宣言する。
• EXPOSEで開放ポートを宣言する。
57
# vim Dockerfile
FROM ubuntu:14.04
RUN apt-get update
RUN apt-get install -y nginx
RUN echo ‘Hi, hello my container’ /
> /usr/share/nginx/html/index.html
CMD nginx -g “daemon off”
EXPOSE 80
典型的なDockerfileのサンプル

58. EXPOSE
• EXPOSEは明示的に宣言しなくても構わない。
• runするときに、-p 80:80という感じでポートを明示して指定し
てあげるだけでもポートは割り当てられる。
• -PオプションはEXPOSEしているポートをすべて割り当てる。
• --link は連携対象のコンテナを指定するとEXPOSE宣言している
ポートに接続するための環境変数を付加してコンテナを起動する
オプション。
58

59. Build caching
• build実行時にはDockerfileの行単位でビルドキャッシュが生成される。
• 次回build実行時はキャッシュが利用され、変更差分のみビルドされる。
• キャッシュが存在しない行以降はキャッシュが利用されない。
• ADD行は前回ビルド以降に対象ファイルの変更があった場合において
はキャッシュが利用されない。その場合、以降の行も引き続きキャッ
シュが利用されないのでADD行の埋め込み位置には注意が必要。
• apt-get updateなどのキャッシュも残る。--no-cacheを指定しないと
次回のビルド実行時に最新の状態にアップデートされない。
59

60. Docker Hub
60

61. Docker Hub
61

62. Automated Build
62

63. Automated Build
63

64. Docker Registry s
• DockerHub以外にもDockerイメージを保管するためのレジストリ
サービスが存在する。
• DockerHub (official)
• Quay.io
• Google Container Registry
• $(docker pull registry)
64

65. 65
Dockerfile Docker Image
build Push Provisioning
Case1
• とてもシンプルなプロビジョニング手順。
• 初回ビルドには時間がかかる。初回ビルド後はあ
る程度キャッシュが効くので高速にビルドできる。
Docker Hub

66. 66
Docker Image
Dockerfile Docker Hub
Push
Automated
Build
Push
Push
GitHub
or
Bitbucket
Provisioning
Case2
• ビルドを Docker Hub に任せるやり方。
• GitHub or Bitbucketライクなフローで自動ビルドまでできる。
• でも、Docker Hub での Automated build は遅いのが難点。

67. 67
Docker Base Image
Dockerfile Docker Hub
Push
Automated
Build
Push
Hook
GitHub
Dockerfile
Docker Image
Build
FROM
<Base Image>
Case3
Containerized
Commit Push
Docker Hub
Provisioning
Docker Image
Patch
• Patchライクなパターン。
• ビルドが必要な箇所を最小限に。
• 迅速にプロビジョニングできる。
Container
in Machine

68. Rebuild-pattern VS Upgrade-pattern
• Rebuild (Immutable-like)
• 更新の都度、Dockerfileをbuildして最新版のイメージを作成。
• 冪等性を担保しやすい。
• 変更内容の影響を受けるスコープが大きい。
• 工夫しないとbuild完了までに時間がかかる。
• 設定が複雑なコンテナや頻繁な更新が必要なコンテナには不向き。
68

69. Rebuild-pattern VS Upgrade-pattern
• Upgrade (Patch-like)
• 開発用コンテナにログイン作業するなどして最新の状態に更新。
• 最新の状態に更新されたコンテナを都度commitしてイメージ化。
• 最新イメージはイメージレポジトリにpushしてバージョン管理。
• build待ちの時間を最小限に抑制できる。
• 充分なテストを準備していたとしても、冪等性は担保しにくい。
69

70. Dockerコミュニティの規模
• 40,000,000+ Docker Container download
• 75,000+ repogitories on DockerHub
• 150+ Meetup Groups in 50+ countries
• 900+ contributors
• 50,000+ third-party projects on GitHub
• 100+ user-generated case studies available from companies
70
https://www.docker.com/company

71. Docker のマイルストーン
• 2013-03-21: Docker v0.1.0 リリース
• 2014-06-09: Docker v1.0.0 リリース
• 2014-12-31: 100M Container のダウンロードを達成
• 2015-04-01: 300M Container のダウンロードを達成
• 2015-06-21: コンテナ標準化団体「Open Container Project」発足
71

72. ChangeLog
• v0.1.0 (2013-03-23): initial public release
• v0.2.0 (2013-04-23): automatic bridge setup
• v0.3.0 (2013-05-06): volume
• v0.4.0 (2013-06-03): API, docker build
• v0.5.0 (2013-07-17): host volume, UDP ports
• v0.6.0 (2013-08-22): privileged mode
72

73. ChangeLog
73
• v0.7.0 (2013-11-25): links, storage drivers(aufs, DM, vfs)
• v0.8.0 (2014-02-04): BTRFS, OSX CLI, ONBUILD, ADD cache
• v0.9.0 (2014-03-10): libcontainer, Execution Drivers
• v0.10.0 (2014-04-08): TLS API Supports
• v0.11.0 (2014-05-07): SELinux, DNS links, --net=host
• v0.12.0 (2014-06-05): pause/unpause
• v1.0.0 (2014-06-09): Production support

74. ChangeLog
74
• v1.1.0 (2014-07-03): .dockerignore, commit, logs --tail
• v1.2.0 (2014-08-20): auto-restart policies, capability
• v1.3.0 (2014-10-14): docker exec, docker create
• v1.4.0 (2014-12-11): overlayfs Support
• v1.5.0 (2015-02-10): IPv6, docker rename

75. ChangeLog
75
• v1.6.0 (2015-04-07): Logging drivers, Windows Client, ulimit
• v1.7.0 (2015-06-16): ZFS Support
• v1.8.0-rc1 (2015-07-26): Fluented logging driver

76. v1.0.0 v1.5.0
• .dockerignore: 特定のファイルやディレクトリを無視
• docker logs: コンテナのログを表示
• --restart=alway/no/on-failure: コンテナの自動再起動ポリシー
• --cap-add/cap-drop: Linux Kernel Capability
• --device=: 利用するデバイス名指定
76

77. v1.0.0 v1.5.0
• docker exec: 起動中コンテナへのログイン機能
• docker create: コンテナ作成コマンド（起動はしない。）
• Signature (official image only)
• --security-opts (SELinux/AppArmor)
• overlayfs support
• IPv6 support
77

78. v1.6.0 v1.8.0-rc1
• --ulimit: ulimit によるリソース制御をサポート
• Logging driver: fluentd, json, syslog 形式でのログの吐き出しに
対応
• ZFS Support: ZFS対応、FreeBSD環境でDockerが動作可能に
• Windows Client Preview: ネイティブなDockerクライアント
• Docker Registry v2: Webhook, Native TLS Support
78

79. 79
Dockerのアーキテクチャ
https://www.flickr.com/photos/laughingsquid/5283377604/

80. Dockerデーモン自体の役割
• コンテナとイメージの管理、ビルド
• embedded CLI talking to the API
• HTTP API (over UNIX or TCP socket)
80

81. docker.sock
• -d付きで起動したdockerはTCPソケット、またはUNIXドメインソ
ケットで起動され、コンテナを起動するためのデーモンになる。
• socketへの書き込みにはroot権限、もしくはdockerグループの権限
を必要とする。
• TCPソケットの場合でもUnixドメインソケットの場合でもHTTP
APIとして動作する。
• ほぼRESTfulな実装なので、curlとかでjsonを引き渡せば動く。
81

82. Dockerの実行ドライバー
• Dockerの実行ドライバーはオプションで指定可能。
• lxc (=legacy)
• native (=libcontainer) (default)
• あえてlxcを選ぶ理由がない限りは、libcontainerのほうが挙動も安
定していて安全。
82

83. libcontainer
• コンテナを実行するためのGo製のドライバーパッケージ。
• namespaces, cgroups, capabilitiesなどのLinuxネイティブコンテ
ナのための機能を実装したビルトイン可能なライブラリ。
• LXCユーザーランドは未使用。
• 現在のDockerはLXCが必須ではなくなっている。
83

84. docker server (docker daemon)
docker API server
network driver
84
Container
libcontainer
docker.sock
exec driver
(native or lxc)
(docker build...)
(docker run...)
(docker pull...)
API CLI
Docker Daemon
Docker Container
Engine
rootfs (aufs, btrfs, devicemapper...)
graph driver
Driver
other drivers...
Dockerfile
Registry
(DockerHub, etc...)
DockerEngine Client

85. コンテナはとても軽量
• だってプロセスみたいなものなんだもん。
• プロセスっていうことは？
• ノートPC上でも10∼100台くらいのコンテナを動かせる。
• サーバ上なら1000台以上のコンテナを動かせる。
85

86. 本当にオーバーヘッドないの？
• Yes。コンテナはnativeな速度で動く。
• コンテナ上で動くプロセスはホスト上でダイレクトに動いてる。
• CPUの処理性能はnativeな速度。
• メモリの処理性能はnativeな速度。
• ネットワークのI/O性能はブリッジなどを経由すると遅くなる。
• ディスクI/Oは利用するストレージドライバによって異なる。
86

87. 対応ファイルシステム
• Dockerコンテナは各種ファイルシステムに対応している。
• AuFS
• Btrfs
• DeviceMapper (Direct LVM, Loop LVM)
• VFS
• overlayfs
87

88. 主要なストレージドライバ
• 主要なOSとデフォルトのストレージドライバの対応関係
• Ubuntu/Debian: aufs
• RHEL/CentOS: devicemapper (loop-lvm)
• CoreOS: overlayfs
88

89. --netオプション
• --net=bridge, Linux Bridge(docker 0)経由の通信。ホスト側で自動
的にNAPTされ、グローバルと通信できる。(default)
• --net=container, 他のコンテナとNICを共有する。IPアドレスと
MACアドレスも同一のアドレスを共有する。
• --net=none, NICを利用しない。
• --net=host, ホストのすべてのネットワークをnativeに利用する。
89

90. Host Serverveth veth veth
ネットワーク
90
--net=bridge
Container Container
--net=container
Container
--net=none
Container
eth0
(veth)
--net=host
Container
Bridge (docker0)
eth0
Container
eth0
(veth)
eth1
(veth)

91. Network Port Mapping
• コンテナにはランダムなポートがマッピングされる。(default)
（下図において、コンテナのPort 5000はホストのPort 49154に
マッピングされている。）
91
49154
Bridge
5000
eth0
Host Container
$ docker run -d --name=myapp -P training/webapp python app.py
$ docker port myapp
5000/tcp -> 0.0.0.0:49154

92. Network Port Mapping
• ただし、DockerfileでEXPOSEを宣言していないコンテナの場合は、
明示的に-Pオプションを指定しても無視される。
92
Bridge
eth0
Host Container
$ docker run -d --name=myapp -P busybox yes
$ docker port myapp

93. Network Port Mapping
• -pオプションでポートマップを指定することも可能。
（下図において、コンテナのPort 5000はホストのPort 5000に
マッピングされるよう明示的に指定している。）
93
5000
Bridge
5000
eth0
Host Container
$ docker run -d --name=myapp -p 5000:5000 training/webapp python app.py
$ docker port myapp
5000/tcp -> 0.0.0.0:5000

94. Network Port Mapping
• -pオプションでポートマップを指定することも可能。
（下図において、コンテナのPort 5000はホストのPort 15000に
マッピングされるよう明示的に指定している。）
94
15000
Bridge
5000
eth0
Host Container
$ docker run -d --name=myapp -p 15000:5000 training/webapp python app.py
$ docker port myapp
5000/tcp -> 0.0.0.0:15000

95. Network Port Mapping
• DockerfileでEXPOSEを宣言していないコンテナの場合でも、明示
的に-pオプションを指定するとポートマッピングされる。
95
5000
Bridge
5000
eth0
Host Container
$ docker run -d --name=myapp -p 5000:5000 busybox yes
$ docker port myapp
5000/tcp -> 0.0.0.0:5000

96. Network Port Mapping
• --net=hostオプションを指定するとコンテナはホストのネットワー
クを利用する。その場合、DockerfileでEXPOSEを宣言しているポー
トがホスト上でListenを開始する。
96
5000
eth0
Host
Container
$ docker run -d --name=myapp --net=host training/webapp python app.py
$ docker port myapp
Bridge

97. Host Server
use pipework
97
Bridge (docker0)
Container
eth0
(veth)
veth
--net=bridge
pipework br1 ...
eth1
(veth)
Bridge (br1)
Container
eth0
(veth)
--net=bridge
pipework br1 ...
eth1
(veth)
Container
eth0
(veth)
--net=bridge
pipework eth1 ...
eth1
macvlan
eth0 eth1
veth veth veth veth

98. ネットワークパフォーマンス
• Linux Bridge経由の通信：ごく かなオーバヘッドが発生する。
• iptables経由の通信：ごく かなオーバーヘッドが発生する。
• コンテナ間通信：大きいオーバヘッドが発生する。
• --net=host：nativeな速度で動作する。
• SR-IOV：nativeな速度で動作する。
• macvlan：nativeな速度で動作する。
98

99. ネームスペースの分離
• Dockerコンテナはホストとはネームスペースが分離されている
• PID: Process IDs
• Mount: mount points
• Network: network access
• UTS (Unix Time-sharing System) : hostname, domainname
• IPC: Inter-Process Communication
• User: User and Group IDs
99

100. PIDネームスペースの分離
100
$ ps auxww | wc -l
102
$ docker run -it ubuntu /bin/bash
root@cdaa11112f53:/# ps auxww | wc -l
4
• コンテナ側から収容ホスト側のプロセスを覗くことはできない。

101. Mountネームスペースの分離
101
$ cat /proc/mounts | wc -l
31
$ docker run -it ubuntu /bin/bash
root@43b9f12ca56b:/# cat /proc/mounts | wc -l
17
• コンテナ側から収容ホスト側でマウントされているデバイスを覗く
ことはできない。

102. Networkネームスペースの分離
102
# ip addr show | egrep "UP|inet"
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000
inet 153.120.104.254/24 brd 153.120.104.255 scope global eth0
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000
inet 192.168.0.1/24 brd 192.168.0.255 scope global eth1
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
inet 172.17.42.1/16 scope global docker0
$ docker run -it ubuntu /bin/bash
root@8fbffca705a2:/# ip addr show | egrep "UP|inet"
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
inet 127.0.0.1/8 scope host lo
17: eth0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
inet 172.17.0.4/16 scope global eth0

103. UTSネームスペースの分離
103
$ hostname
test.example.com
$ domainname
example.com
$ docker run -it ubuntu /bin/bash
root@8fbffca705a2:/# hostname
8fbffca705a2
root@8fbffca705a2:/# domainname
example.com

104. IPCネームスペースの分離
104
$ ipcs
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x0052e2c1 0 postgres 600 48 5
0x00000000 229377 s-yamada 700 1694000 2 dest
$ docker run -it ubuntu /bin/bash
root@c739668e223a:/# ipcs
------ Message Queues --------
key msqid owner perms used-bytes messages

105. Userネームスペースの分離
105
$ docker run -it ubuntu /bin/bash
root@c739668e223a:/# id -a
uid=0(root) gid=0(root) groups=0(root)
• コンテナのUIDは実際にはホストのUID1000番台以降にマッピング
される。

106. cgroups
• Dockerはcgroupsに対応している。
• cpu
• cpuset
• memory
• blkio
• devices
• network
• freezer
106

107. cgroupsによるリソース制限
• libcontainerはcgroupsの一部機能のみ対応。
• libcontainerをcgroupsにほぼ対応させるには、systemdと連携させ
るのが現在のベストプラクティス。
• RHEL7のdockerはsystemdと連携してcgroupsを取り扱える。
• その他の手段：https://github.com/ibuildthecloud/systemd-docker
107

108. メディアアクセス制御機能
• Linux Kernel Capabilities
• Drop mout capabilities
• Enable what a task needs
• Grsecurity and PaX
• SELinux
• AppArmor
108

109. 109
Kernel
Server
Containers
NameSpaces
• UTS
• IPC
• PID
• User
• Network
• ...
cgroups
• memory
• cpu
• blkio
• devices
• network
• .....
Namespace
Ubuntu base
nginx
Namespace
Debian base
Rails
Namespace
CentOS base
Apache2
MySQLpostgresql
Host
Network
• veth
• bridge
• iptables
• ...
Storage
• aufs
• btrfs
• devicemapper
• overlayfs
• ...
Security
• SElinux
• apparrmor
• capability
• Grsecurity
• PaX
...
Docker EngineDocker
OS

110. コンテナにしておくと少しでも便利になるケース
• ちょっとしたOSの動作確認。
• 構成管理ツールを使うとセットアップが煩雑なアプリケーション。
• 桁違いな並列度が必要とされるアプリケーション。
• 手軽にパッケージインストールできない実行バイナリのビルド。
• Cronで定期的に動くスクリプト。
110

111. コンテナを使わないほうがいいケース
• ステートフルなwebアプリケーション。
• 堅牢なデータ永続化が必須なアプリケーション。
• シビアなI/O処理性能やパケット処理が必要なアプリケーション。
• 頻繁にクラッシュするアプリケーション。
• アプリケーションのアップデート方法を一切検討していない場合。
• 障害の発生やデータロストを前提として考慮していない場合。
111

112. 複数台のプロビジョニング
• 自身でコンテナを定義する場合
• Docker Compose(Fig), Maestro-NG, Ansible, Chef, etc...
• APIライク
• Mesos(+ Marathon), Kubernetes, Helios
• PaaSライク
• Flynn, Deis, CloudFoundry, Dokku, Tsuru, OpenShift
• OpenStack (because OpenStack can do everything!)
112

113. ログのルーティング
• 数台のコンテナ相手ならjournarlctlだけでも頑張れる。
• 数十台のコンテナ相手になってくるとvolumeコンテナにログを集約
しつつ rsyslog で飛ばすだけでも頑張れなくもないけどツラい。
• Docker 1.8.0 で fluentd に対応！これで勝つる！
113

114. コンテナの監視に関する課題
• リソース（CPU, Mem, trafic）の可視化は必要。
• 最低限の外系監視（Ping, HTTP, HTTPS, TCP/UDP）も必要。
• コンテナ自体がプロセスみたいなものなのでプロセス監視は概ね不要。
• その他、コンテナの種類に応じて各種リソースの監視が必要。
• 各種レスポンス・遅延、各種サイズ、同時接続数。
• 比較的手軽なエージェントはsensuとdatadogくらい？
• Prometheusはスケールするか不安。（それでも、きちんとチューニングされてればコンテ
ナ1000台くらいまでなら余裕で収容できると思う。）
• とは言うものの、コンテナの場合は別に頑張って監視するほどでもないケースも多い・・・
114

115. ストレージの外部化
• ボリュームコンテナを作成して利用すればUID/GIDは崩れない。
• 手法を誤るとUID/GIDのマッピングが崩れる。
• 特定の要件においてのみ有効なワークアラウンドとしては・・・
• /var/lib/dockerを専用のストレージにmountする。
• 対象コンテナに特定のストレージを専用に割り当てる。
115

116. セキュリティ
• Dockerでも脆弱性を突かれて、最悪の場合はホストのroot権限を悪
意ある第三者に奪取されてしまう可能性はある。
• これは、Docker 単体で防ぎきれる問題とは考えないほうがいい。
• 脆弱性を突かれたとしても、SELinux や AppArmor を適切に設定
していれば被害は最小限に食い止められる。
• これはKVMのような仮想化技術や、Linuxの各種デーモンでも同じ
こと。極端に恐れるほどのことではない。
116

117. その他の補足とか
• buildするときやpullするときはキャッシュに注意する。
• 挙動が怪しいときは--no-cacheを指定してbuildする。
• pullしてきたイメージが古い内容だと思ったら、イメージのハッシュとタ
イムスタンプを確認する。
• キャッシュでビルド時間が大幅短縮されるはずが、キャッシュに時間を食
い潰されていく不思議。
• Dockerデーモンが中途半端にdownしていないか注意する。
• 変だと思ったら、Dockerデーモンを再起動してみる。
117

118. その他の補足とか
• 別に1コンテナあたり1アプリケーションでなくてもいい。
• コンテナの使い方は自由。
• コンテナに固定IPアドレスを振るのは結構手間。
• コマンドを駆使すれば、すごく複雑なこともできるけど手間・・・
• 中途半端に残っているコンテナやイメージは自分で消すしかない・・・
• データの永続化が必要なものはコンテナ内以外の場所に保存したほうがいい。ブ
ロックストレージでもS3でもRDSでもいい。
• そういうコンテナはLXCでコンテナ化しちゃうのだってありだと思う。
118

119. その他の補足とか
• 稀に、自分のローカルPCでbuildしたときとDockerHubで
Automated buildしたときとでは微妙に挙動が異なるアプリケーショ
ンもあったりする・・・
119

120. KubernatesとかMesosとかあるけど？
• 自前で基盤を動かすのって大変・・・
• 仮想化基盤の標準とも言える VMware や OpenStack だって、会
社の中の本番環境で大々的に動かすのは楽ではない。
• 大量のコンテナを動かす予定が出てきたら、自前で基盤の運用は
せずにクラウド事業者のコンテナ基盤に頼ったほうが楽。
• 10000コンテナ＋くらい動かす予定が出てきたら、逆に自前で基
盤を動かすか自作してしまうほうが安上がりになるかも。
120

121. 121
in
UseCase
Server
Newrelic
container
Send Status
Newrelic

122. 122
*.tf
CI-Service
(CircleCI, travis)
Push Test
GitHub
UseCase
ssh
&&
*.tf pull
apply
DNS-Service
(Route53, DNSimple)
Terraform
container

123. 123
UseCase
ssh-keychain server
container
Online-Storage
(Amazon S3, etc...)
POST
Client
GET, POST
Server
GET, POST

124. What?
124

125. それ普通のサーバでもできるよ
• Yes, コンテナが果たす役割自体は既存のアプリケーションと何ら変
わらない。（だって、アプリケーションなんだもん。。）
• でも、アプリケーションがDockerイメージによってパッケージ化さ
れることでセットアップが迅速かつ簡単になったり、異なるサーバ
へのアプリケーション移行作業も比較的容易になった。
• コンテナとしてパッケージをあらかじめイメージ化することで、ア
プリケーションセットアップ作業のムダと各作業者ごとの作業のム
ラを省かれる。
125

126. コンテナを利用することによってもたらされる
一般的なメリット
• サーバの利用効率アップ（サーバ台数の削減）
• 各アプリケーションがコンテナという単位で隔離されることによっ
てもたらされるセキュアなマルチテナント化と収容効率の拡大。
• 開発プロセスの高速化
• コンテナのシンプルな設定管理によってもたらされる、迅速なCI/
CDの実現、再利用可能な開発環境やデバッグ環境の容易な構築。
126

127. 本格的なサービスに利用できる？
• マルチテナント環境を想定すると大きな課題が残っている。
• フォーク爆弾対策
• rootユーザーで動くコンテナは ulimit の nprocではプロセス数
制限できない。cgroup pids subsystem に期待・・・
• コンテナ単位でのディスク容量のクォート
• loop-lvm でのみ対応。aufs や btrfs では未対応。
• etc...
127

128. • 従来型のサーバ管理やアプリケーションからの思考転換が必要。
• コンテナ型技術のアーキテクチャ自体への理解。
• アプリケーション設計と構成管理手法の転換。
• Container != Server
• ただし、従来的なLinuxシステム管理や、細かなチューニング作業か
ら逃げきれるわけではない。
まとめ
https://www.flickr.com/photos/kzys/838011150/
128

129. • 動かすだけなら簡単。でも、まだ全然枯れてない。
• 日本語ドキュメントが少ない。
• 管理ツール類やサービスが いきっていない。
• 自分で調べて自分で組み立てたりしないといけないことが多い。
• たぶん、この資料自体もすぐに古い内容になってしまう。
まとめ
https://www.flickr.com/photos/kzys/838011150/
129

130. • もう十分にトレンドっぽいし、今後のデファクトスタンダードにな
ることも規定路線っぽいけど、Dockerはまだまだ国内の一部のエン
ジニアにしか知られていない。（と思う。）
• 本格的なデファクトスタンダードになるには、より多くの貢献者と
エネルギーがDockerには必要。
• 未来の貢献者は誰？YOUでしょ？
まとめ
https://www.flickr.com/photos/kzys/838011150/
130

131. 131
FAQ?
https://www.flickr.com/photos/kzys/838011150/