SSSSLIDE

Dockerの期待と現実
Docker都市伝説はなぜ生まれるのか
さくらインターネット株式会社
Engineer / Technology Evangelist
前佛雅人 Masahito Zembutsu @zembutsu

誰？
• さくらインターネット株式会社
技術本部ミドルウェアグループ
クラウドチーム／VPSチーム／エバンジェリストチーム
• 運用系（サーバ） … データセンタの運用・サポート対応
• HashiCorp / Munin / Zabbix / Docker などに興味
• エンジニアのためのプレゼン研究会
• ドキュメント翻訳
• 稲作農家（富山県滑川市出身）
• インターネットの力で普通の人が価値を高められる社会
2
Software Degisn 2017年2月号→
Authorized Docker Trainer (2016.6～)
ZEMBUTSU Masahito
今回の発表は、これまでDockerに触
れてきた一人という、中立的な立場で
皆さんと議論したいと思っています。

「企業のためのDocker実戦ガイド」
というセミナーで、登壇の機会をいた
だきました。ありがとうございます。
Dockerやコンテナ技術に対して興味
をお持ちの方に、私が普段対面で話
している内容を中心に、発表でまとめ
させていただきました。

使える？使えない？という話ではなく、何の解決に役立つか？
よくいただくご質問は「Dockerなりコ
ンテナが使えるかどうか」です。しかし
大切なのはそこではなく、どのような
課題を解決するためにDockerやコン
テナに対して期待しているか、という視
点が大切だと考えています。

使いどころの勘違い
仮想化≠コンテナ化
業務手順も変わる
「期待と現実」という視点で、３つの
キーポイントを挙げます。そもそものス
タート地点とゴールを見誤ると、何の
ためにDockerやコンテナを入れたん
だっけ？という話になりがちです。

コンテナは技術
Dockerは仕様
そして、コンテナ技術の話、Docker
のプラットフォームとしての役割の話が
混同されているため、なおさら混乱を
生みがちなのが現状です。そして前提
が違うのに情報だけが伝わり、都市
伝説化しているのではないでしょうか。

高まる期待
まずは、どうしてDockerやコンテナが
注目されるに至ったのか、これまでの
経緯を簡単に振り返りましょう。

8
物理サーバ時代
機
材
発
注
機
材
納
品
設
置
機
器
設
定
見
積
も
り
O
S
設
定
環
境
構
築
試
験
運
用
開
始
これまでの物理からクラウドに至る
流れを、改めて振り返ります。物理
サーバ時代はシステム調達までの
時間が長い課題がありました。

9
仮想化
事
前
設
計
ク
リ
ッ
ク
試
験
利
用
開
始
しかしそれでは、ウェブを中心とした
インターネットの普及スピードに追
いつけません。ですので、速さと効
率化を求めて、仮想化技術や、

10
仮想化クラウド
事
前
設
計
ク
リ
ッ
ク
試
験
利
用
開
始
事
前
設
計
ク
リ
ッ
ク
試
験
利
用
開
始
事
前
設
計
ク
リ
ッ
ク
試
験
利
用
開
始
クラウド技術の普及が進みます。
すぐに環境を作ったり壊したりでき
る。あるいは、リソースの集約や有
効活用に活かすことができる。

11
サーバ仮想化／デスクトップ仮想化に関するアンケート調査リポート（2016年4月）
TechTargetジャパンホワイトペーパーダウンロードセンター
http://wp.techtarget.itmedia.co.jp/contents/?cid=19841
2016年春の段階で、サーバ仮想
化技術は半数の企業で導入済み
という調査結果も出ています。皆さ
んの肌感覚と近いと思います。

12
用途は開発環境・テストサーバが
多いようですが、ウェブサーバや
様々な用途で使われています。

13
きっかけは、サーバ統合やリソース
の有効活用、効率化といった項目
が上位を占めている状況です。

14
仮想化
事
前
設
計
ク
リ
ッ
ク
試
験
利
用
開
始
クラウド
事
前
設
計
ク
リ
ッ
ク
試
験
利
用
開
始
事
前
設
計
ク
リ
ッ
ク
試
験
利
用
開
始
そのため、これまでと同じように、効
率化なり、ハードウェアに対する投
資という視点で、

15
仮想化
事
前
設
計
ク
リ
ッ
ク
試
験
利
用
開
始
クラウド
事
前
設
計
ク
リ
ッ
ク
試
験
利
用
開
始
事
前
設
計
ク
リ
ッ
ク
試
験
利
用
開
始
Docker / コンテナ
Dockerなりコンテナ技術に対する
期待、それも過剰な期待が高まっ
ているものと思われます。

16
仮想化 Docker / コンテナクラウド
事
前
設
計
ク
リ
ッ
ク
試
験
利
用
開
始
事
前
設
計
ク
リ
ッ
ク
試
験
利
用
開
始
事
前
設
計
ク
リ
ッ
ク
試
験
利
用
開
始
サーバ統合・リソース有効活用
設置スペース・消費電力削減
運用自動化・効率化
システム可用性向上
これまでの延長上の技術と思われ
てしまい、その視点で「使える」か
「使えない」かが論じられています。
ですが、それは正しいのでしょうか。

コンテナ技術とDocker
それを判断するには、そもそも
Dockerがどのように生まれたかを
理解してから論ずる必要があると
私は考えています。

18
Dockerは2013年3月に登場し
たばかり。間もなく4周年を迎える
まだまだ若いものです。

19
“Docker allows you to package an application with
all of its dependencies into a standardized unit for
software development.”
Dockerはアプリケーションと全ての依存関係をパッケージ化します。その
ソフトウェア開発の全依存関係は、標準化したユニットに入っています。
www.docker.com
Dockerを作ったのはdotCloud
というPaaSを提供する会社の方。
利用者はインフラの面倒をみたい
のではなく、アプリを動かしたいの
だと利用者との対話で気づきます。

20
当時も様々なコンテナ技術は存在
していました。Dockerが実現した
価値とは何だったのでしょうか。単
にコンテナが存在するだけでは、何
も意味がありません。

21
コンテナという技術を使うことで
Dockerというプラットフォームが
アプリケーションをコンテナの上に
のせれば、どこにでも持って行ける
ように、どこでも実行できるように
する仕組みを生み出した所に価値
があり、プロジェクトに多くの貢献
者が参加したり、企業からの支援
を受けるようになりました。

Docker
アプリを開発・移動・実行するプラットフォーム
設計思想は「開発者が簡単にアプリケーションを動かす環境を作る」こと
Dockerプロジェクト
PyCon 2013 (PythonカンファレンスUS) 3月13日、 LT でオープンソース・プロジェクトを発表 [1]
Solomon Hykes … dotcloud 創業者であり、 Docker プロジェクトを開始
32,000以上の GitHub Stars、40億 Docker コンテナのダウンロード、2,900人以上の貢献者
Dockr Inc.
Docker におけるミッションとは、膨大な革新を生み出すツールを作る [2]
Docker プロジェクトのオリジナル開発者、かつ、プロジェクトのスポンサー、商業サポート
[1] “The future of Linux Containers” https://www.youtube.com/watch?v=wW9CAH9nSLs
[2] “Our mission at Docker to create tools of mass inｎovation” http://www.docker.com/company/ 22
改めて、Dockerとはアプリケー
ションを動かす仕組み・プログラム
です。オープンソースのプロジェクト
と、その支援と商用サポートをする
会社がお互い独立しています。

23
依存関係
システム基盤
• オペレーティング・システム [Linux|Unix|Windows]
• ハードウェア、ネットワーク、ストレージ
• 物理 or 仮想化 or クラウド
• ミドルウェア
• 各種プログラミング言語環境や、システム・ライブラリなど
• バイナリやソースコード
• 設定用パラメータ
application
dependencies
Infrastructure
アプリ
従来のシステム開発において、か
ならず基盤、ネットワークやサーバ
などハードウェア・リソースありきで
前提や制約が組まれていた場面が
殆どでした。

24
依存関係
システム基盤
Docker
コンテナ
Docker Engine
(dockerd)
• ミドルウェア
• 各種プログラミング言語環境や、システム・ライブラリなど
• バイナリやソースコード
• 設定用パラメータ
application
dependencies
Infrastructure
• オペレーティング・システム [Linux|Unix|Windows]
• ハードウェア、ネットワーク、ストレージ
• 物理 or 仮想化 or クラウド
アプリ
Dockerの登場で、アプリありきで
考えられるようになりました。つまり
Dockerコンテナ、正確には
Dockerイメージさえあれば、イン
フラを意識せずに動かせるように。

25
仮想化
事
前
設
計
ク
リ
ッ
ク
試
験
利
用
開
始
クラウド
事
前
設
計
ク
リ
ッ
ク
試
験
利
用
開
始
事
前
設
計
ク
リ
ッ
ク
試
験
利
用
開
始
Docker / コンテナ
改めて歴史的経緯を見直すと、こ
れまでの利用シーンとはチョット違
う気がすると思います。そもそもの
目指す所が、違うため、この図の
ように、一直線上には並びません。

社外開発環境本番環境ステージング環境
社内共有開発環境
個人開発環境
社内テスト環境
仮想化やクラウドの普及によって
生まれた課題は、管理すべき環境
がふえたことと、どこでも「間違い
なく動く」ことを保証するのが難し
い所です。Chef、Puppet、
Ansible のような構成管理ツー
ルは１つのサーバ内で完結する場
合は良いかもしれませんが、インフ
ラ全体、特にアプリケーションを間
違いなく動かすという視点、あるい
は素早く動かすという所では、まだ
足りない所があるかもしれません。

社内共有開発環境
個人開発環境
社内テスト環境
CI/CD Docker レジストリ
Docker動作環境(docker machine)
そのような環境の違いを意識しな
くても、間違いなくアプリケーション
を動かせるようにしたい。そのよう
な環境を作るための土台としての
プログラムがDockerです。

28
Dockerと愉快な仲間達
Build RunShip
“Build, Ship, Run, Any App Anywhere”
Docker Engine for Linux / Commercial Support
Docker for Mac, Windows, Windows Server 2016
そして構築・移動・実行、どの段階
でもアプリが間違いなく動く環境を
Dockerが、正しくはDockerエン
ジンが動く環境であれば実現でき
るのを目指しました。

29
Build Run開発・構築移動実行
Ship
Docker Trusted Registry
Docker Hub
Universal Control Plane
Toolbox
Kitematic
Dev
(開発)
Ops
(運用)
アプリはDockerイメージとして構
築・移動し、コンテナ状態として実
行できるようになったのです。

Docker ツール群
• Docker Engine
• Docker Machine
• Docker Swarm
• Docker Compose
• Docker Toolbox
• Kitematic
• Docker Hub
• Docker Registry
• Docker Content Trust
• Docker Cloud
30
そして、そのような環境を実現する
べくツール群やサービスが提供され
ています。が、今日はDockerの
宣伝するつもりはないので、詳しい
解説は避けさせてください。

なぜDockerが登場したのか？
物理から仮想化への流れ
課題：デプロイ時間が遅い、コストがかかる、無駄なリソースが必要、スケールしづらい
ハイパーバイザ型仮想化基盤の登場により、1台のサーバ上で複数の仮想マシンを動かせる
仮想化、そしてクラウド・コンピューティング
仮想化はリソースの共有が便利、スケールもしやすい
必要な時に、必要なだけのリソース増減を行いやすい
使った分だか支払う料金体系
新たな課題
たくさんのアプリケーションを動かすには、より多くのリソースの必要性
アプリケーションのポータビリティ（移植性）は保証されない
31

現実世界の移動（輸送）課題
32
様々な
種類の
「モノ」
輸送の
手段は
色々
「モノ」にお互い
の影響を与えず
運ぶには？
（例：コーヒーと
香辛料を運ぶ）
迅速かつスムー
ズに転送可能
か？
（例：船から貨物
列車への積み
替え時）

規格化によって解決
33
様々な
種類の
「モノ」
輸送の
手段は
色々
「モノ」にお互い
の影響を与えず
運ぶには？
（例：コーヒーと
香辛料を運ぶ）
迅速かつスムー
ズに転送可能
か？
（例：船から貨物
列車への積み
替え時）
コンテナ規格により、事実上、
あらゆるモノを運ぶことができ、
かつ送り先には封印したままで
届ける
長距離輸送中の積み込み、荷下ろ
し、積み重ね、移動が効率的であり、
様々な輸送手段に切り替え可能

ここからヒントを得たDockerコンテナ
34
エンジンは様々なものを軽
量・移動可能・自給自足的な
コンテナにカプセル化できる
標準的なOS操作により、あらゆる
ハードウェア・プラットフォームで
仮想的に一貫して実行可能
複数の
開発
スタック
複数の
ハード
ウェア
環境
サービスとアプ
リケーションは
適切に通信可
能か？
迅速かつス
ムーズに移
動可能か？
静的ウェブサイトユーザDB ウェブ・フロントエンドキュー解析DB
開発用
仮想マシン
QAサーバお客さま
データセンタ
パブリック
クラウド
プロダクション
クラスタ
コントリビュータ
ノートPC

Docker が実現したこと
実行に必要なすべてをファイルシステムへ
ソースコード、システム用ツール、ライブラリなど、サーバのすべてを Docker イメージ化
Dockerfile を使った自動イメージ構築により、環境再現性を高める
どのような環境でも動作を保証
Docker (Engine) が動く環境であれば、どこでもイメージをコンテナとして実行できる
ソフトウェアを動かすために、環境構築やセットアップ作業が不要に
軽量
仮想化・クラウド環境と比べ、ホストOSを必要としないので、必要なリソース容量が少ない
Docker イメージを複数のレイヤ（層）で共有するため、移動時の容量を少なくできる
35

仮想マシン vs Docker ではない！！
コンテナはプラットフォームに依存しない
コンテナであれば、ある環境で構築したら、別の環境に迅速に移動可
Dockerイメージはソフトウェアのスケール（増減）を迅速かつ簡単に
コンテナは OS とアプリを明確に役割分担
開発者はアプリケーション開発に集中、運用担当はデプロイ作業や運用に集中
仮想化は手軽に厳密なリソース管理が可能
仮想化システムの利用には業務手順の（大きな）変更を伴わない
リソースの集約と管理をしやすい
単純な比較は無意味
システム基盤としてのコンテナ導入や、コスト削減・省力化視点でのコンテナ化は無意味
36
技術要素は似てますが方向が別

37
仮想化 Docker コンテナ
独立した環境
仮想ハードウェア
Dockerイメージ
リソース集約
様々なOSが動作
Linux kernel
技術を活用
※ Dockerコンテナは、アプリケーションが複数サーバにスケール
する前提なら、環境の繰り返し作成・廃棄を高速に行える
※ スケールが必要なければ、必要なハードウェアや OS に
あわせた環境を自由に構築できる
• プロセスは namespace を通して PID 、
ファイルシステムなど、様々な名前空間を分離
プロセスを起動後、瞬時に分離かつリソースを制限可能
な点が仮想化と似て見えますが、実装や仕組みや操作
性は全く異なる。
• Control groups の機能を使い、１つ１つの
コンテナ(Linuxのプロセス) に対して CPU、メモリ、
I/O の制限をかけられます
使い捨て型
(再利用性)
共通要素
• ハイパーバイザ型もしくはホスト型の仮想化
技術により仮想マシンを実行
• ハイパーバイザ技術により仮想マシンを実行
インフラのコード化
• Dockerfile や docker-compose.yml で
確実にアプリが動作する環境再現性を管理
• 階層化したイメージ・レイヤにファイルシステムや
メタデータを格納
• 親子関係により、ディスク容量節約や移動高速化
• 厳密なリソース定義や確実な環境分離を
提供
環境の移行がスムーズ
• サーバ管理する業務フローが確定しているの
であれば、変更しなくてもシステムの移行や
集約をしやすいので、導入しやすい
• Windows / Linux など選べる
• 32bit / 64bit などアーキテクチャを選択できる
自由度の高いハードウェア・エミュレーションや
管理性を提供する。

Dockerは仕様

Dockerを動かす技術
• Docker Engine (dockerd) がリクエストを受信後、各種処理
• 名前空間(namespace)はプロセスごとに独立した環境を作る
• コントロール・グループ(cgroups)はリソースを制限・管理
• Linux カーネル技術や業界共通の規格を採用

40
Docker Engine とデーモンの変遷
Docker Engine
Linux Kernel
・namespaces
・cgroups
LXC libcontainer runC
containerd
v0.9～
v1.11～
Version 7 Unix
chroot
jail
dockerd
v1.12～
デーモン
ライブラリ
ランタイム
docker daemon
Docker: the container engine
v1.11～
バージョンによって実装面の変遷
はありましたが、Linuxカーネルの
機能を「良い感じ」に処理してくれ
るのがDockerエンジン（という名
前のデーモン）の役割です。

41
Docker はサーバ・クライアント型モデル
OS ( Linux )
物理/仮想サーバ
Docker エンジン
( dockerd デーモン )
Linux kernel
コンテナコンテナコンテナ
リモート
API
docker
クライアント TCP あるいは
Unix ソケットドメイン
containerd
Runtime: runC (OCI規格準拠)
・docker コマンド
Linux, Mac OS X, Windows
・Kitematic (GUI)
Mac OS X, Windows
・Docker Compose
・Docker Swarm

42
コンテナのプロセス
httpd
PID 1
コンテナA コンテナB
ruby
PID 1
chris.rb
PID 2
PPID 7
名前空間（ネームスペース）技術
はいくつかありますが、重要なのも
の１つに、プロセス空間の分離
（isolation）を実現します。
たとえば、２つのコンテナがあると
して、プロセス空間は PID 1 のプ
ロセスを持ち、お互いを認識できま
せん。

43
コンテナのプロセス
httpd
PID 1
ruby
PID 1
chris.rb
PID 2
/sbin/init
PID 1
containerd
PID 5
httpd
PID 6
ruby
PID 7
chris.rb
PID 8
alice
PID 2
bob
PID 3
PPID 1 PPID 1
PPID 4
PPID 5 PPID 5
PPID 7
PPID 1
dockerd
PID 4
実際のホスト上ではdockerd
（dockerエンジン）のプロセスツ
リー以下に存在しています。コンテ
ナの中では、あたかも自分たちしか
見えない状態。

44
コンテナのファイルシステム
コンテナAの
ファイルシステム
… …
コンテナBの
/etc /bin /etc /bin
/ /
/ 以下の /etc /bin 等のディレ
クトリを持つファイルシステムも同
様です。それぞれのコンテナは全くお
互いを認識できず、独立しているよ
うに見えるのですが

45
コンテナのファイルシステム
コンテナAの
… …
コンテナBの
/etc /bin /etc /bin
/ /
/
/etc /data
/data/ubuntu /data/centos
/bin
実際にはホスト上のどこかのディレ
クトリをchrootしている様な状態
なのです。

46
コンテナの実行
コンテナAの
… …
コンテナBの
/etc
(/data/ubuntu/etc)
/bin
(/data/ubuntu/bin)
/etc
(/data/centos/etc)
/bin
(/data/centos/bin)
/ /
httpd
PID 1
プロセスA プロセスB
ruby
PID 1
chris.rb
PID 2
つまりコンテナの実行、あるいは、
あるプロセスをコンテナ状態で起動
するとは、名前空間を分離する技
術を使い、お互いを分けて、

47
コンテナの実行
コンテナAの
… …
コンテナBの
/etc
(/data/ubuntu/etc)
/bin
(/data/ubuntu/bin)
/etc
(/data/centos/etc)
/bin
(/data/centos/bin)
/ /
httpd
PID 1
プロセスA プロセスB
ruby
PID 1
chris.rb
PID 2
名前空間の isolate
・プロセス
・ファイルシステム
・ネットワーク
・ホスト名
・UID・GID
リソース制限
・CPU
・メモリ
・I/O
・ディスク・クォータ
さらにプロセスにはリソースを制限
可能な状態と言えます。

48
Docker コンテナのライフサイクル
このような仕組みはサーバ仮想化
とは全く違う仕組みのため、専用の
管理コマンドが存在します。

images
イメージ・レイヤ(読み込み専用）
コンテナ・レイヤ(読み書き可能）
イメージ1の
リポジトリ
イメージ2の
リポジトリ
イメージnの
リポジトリ
…
save
load
tartar
import
commit
…
Dockerfile
build
…
tag
rmi
削除したレイヤ
inspect
history
レジストリ
(Docker Hub)
リポジトリ
pull
イメージ管理用コマンド

start
イメージの
リポジトリ
コンテナ用
レイヤ作成親子
関係
create
diff
プロセス
(PID1)
コンテナ内のプロセスやファイルシステム
追加
プロセ
ス
pause
stop
kill
exec
ps
stats
top
attach
logs
inspect
port
restart
run ホスト上の
コンテナ
全体を管理
ホストから
各コンテナを
管理・操作
events
コンテナの
PID1を操作
rm
pull
レジストリ
イメージ・レイヤ(読み込み専用）
コンテナ・レイヤ(読み書き可能）
削除したレイヤ
コンテナ管理用コマンド

コンテナを動かすには？
51
$ docker run hello-world
hello-world コンテナの実行
$ docker run –i –t ubuntu bash
ubuntu コンテナの実行
$ docker run –d –p 80:80 –v /data/:/usr/share/nginx/html nginx:latest
nginx コンテナの実行
一見すると難しいように見えますが、
分かりやすい英単語が機能を表し
ていますので、Dockerが何を行っ
ているか？と適切に理解していれ
ば、さほど障壁は高くありません。

イメージを作るには？
52
$ docker commit [コンテナID] [イメージ名:タグ]
docker commit コマンド
$ docker build –t [イメージ名:タグ] .
docker bulid コマンド
$ docker build –t [イメージ名:タグ] .
Dockerfile ファイル
Dockerイメージの作成も独特に
見える概念の１つですが、これもア
プリケーションをいかに様々な場所
に移すかを考えたら、このような仕
組みになっています。

複数のイメージを使うには？
Docker Compose
ウェブ（アプリ）＋DBのような環境で、docker-compose を使えば、同時に起動・管理
53
$ docker-compose up
実行例
version: '2'
services:
wordpress:
image: wordpress
ports:
- 8080:80
environment:
WORDPRESS_DB_PASSWORD: example
mysql:
image: mariadb
environment:
MYSQL_ROOT_PASSWORD: example
docker-compose.yaml
ちなみにdockerコマンドは１つの
コンテナしか扱えません。複数のコ
ンテナを操作するためには、
Docker コンポーズというツールも
提供されています。

イメージを配るには？
レジストリ(registry)はDockerイメージの保管場所
Dockerコンテナを実行するにはイメージが必要
イメージが保管されている場所をレジストリと呼ぶ
レジストリは3種類
Docker Hub はパブリック・レジストリと呼ばれ、誰でも利用可能
Registry はプライベートで使える最低限のレジストリ機能
Docker Trusted Registry (DTR) は商用サポート版のプライベート・レジストリの位置付け
54
レジストリ Docker Engine
Dockerイメージ
そしてもう１つ、Dockerハブとい
う、Dockerイメージの配布や自
動構築を行う仕組みも提供されて
います。これも仮想化との違いです。

55
うまく活用しますと、Zabbixの手
間が掛かるセットアップもコマンド
１つで実行できます。

56
開発環境でDockerを使用
アプリ環境の管理のため
Dockerを使用
開発の機敏性を高めるため
Dockerを使用
アプリのポータビリティを
達成するためにDockerを使用
プロダクション用の
アプリでDocker使用
伝統的データベース
分散データベース
ビッグデータ
アプリ・サーバ
ウェブ・アプリ
ウェブ API
Dockerの役割
開発環境周辺で
Dockerの利用を計画
DevOps周辺で
Dockerの利用を計画
“Docker provides the software supply chain with agility, control and portability for app development.”
Dockerは開発のための機敏なソフトウェアのサプライチェーン、管理、ポータビリティを提供 [1]
[1] The Evolution of the Modern Software Supply Chain - The Docker Survey, 2016
https://www.docker.com/survey-2016

変わるべき業務手順
開発環境では導入が進んでいると
はいえ、プロダクションではまだまだ
途上という数値が出ています。これ
はDocker導入によって、間違い
なく運用フローや手順が変わってし
まうからです。

58
Build Run開発・構築移動実行
Ship
Docker Trusted Registry
Docker Hub
Universal Control Plane
Toolbox
Kitematic
Dev
(開発)
Ops
(運用)
ここで改めてDockerとはアプリ
ケーションを迅速に構築・移動・実
行するための役割を担います。

59
単にコンテナ化しても意味が無い
のは、なんとなく皆さんもお気づき
になってきませんでしょうか。単にコ
ンテナが並んでいても、それでは全
く価値が生まれない。

60
そうではなく、迅速に移動すること。
この写真なら、Dockerエンジンは
牽引車の役割であり、

61
あらゆる場所へ、コンテナを運ぶ、
船という役割でもあります。

62
最近「パイプライン」という言葉を耳
にするようになりました。

63
“Pipelines as code
Teams are pushing for automation across their environments, including their
development infrastructure. Pipelines as code is defining the deployment pipeline
through code instead of configuring a running CI/CD tool.”
開発インフラを含む環境全体を横断する自動化を努める用語。コードとしてのパイプラインは、
CI/CDツールを調整するのではなく、コードを通してデプロイ用のパイプライン（業務ライン）を
定義すること。
Technology Radar, https://www.thoughtworks.com/radar/techniques/pipelines-as-code
CI/CDを通してのコード化という
意味で、Pipeline as codeとい
う言葉も生まれています。

64
個別要素としての技術云々ではな
く、工場の生産ラインのように、全
ての工程を効率的に回す手段とし
ての考え。Dockerも同じような
考え方、視点に立っています。この
視点がなければ、コンテナ技術を
導入しても「仮想化と変わらない」
「クラウドと変わらない」という話に
なってしまいます。

コンテナだから全てを解決するので
はない、というのも共有したいです。
現実的な課題はあります。

Dockerと課題
セキュリティ対策は従来と同じ
べースの OS は通常の Linux ないし Windows なので、セキュリティ対応は欠かせない
従来の手法に比べ、更新しやすい（イメージの自動構築機能）
Content Trust や Notary といった技術を利用しセキュリティを高める
運用や監視も特に変わらない
Docker Engine の管理が必要になるが、その他は通常のサーバ管理と同じ
Docker 導入が目的化すると方向を見失いがち
リソース削減や集約が、そのまま開発・運用コストの削減にはつながらない

Dockerに不向きと思われる場面
リソース集約やコスト削減の目的
確かにリソースは集約できるかもしれないが、仮想化技術とは手法が違う
結果として業務フローの変更や Docker コンテナ変換作業が発生して、コストは増える
既存のシステムをそのまま移行
Docker は開発・テスト・運用のサイクルを加速する場合には有用
単純に Docker に対応しても速さや利便性を求めないのなら、結果として仮想化やクラウドと同じ
そもそものシステム要件にあわない環境
厳密なセキュリティの確保や長期の安定性を求めるのであれば、別の適切なシステム検討を
全ての要件を満たす完璧なシステムは存在しない。トレードオフを考慮
※ Dockerはインフラ（システム基盤）ではなく、あくまでアプリケーションのプラットフォーム

68
Docker以外のコンテナ技術を使う選択肢
LXC LXD
他にも選択肢があるため、何をし
たいかによって、使い分けではいか
がでしょうか。

69
物理サーバだけの時代
とある物理サーバ
故障すると大変
CPU メモリディスク
調達・管理コストの課題
基本、ハードウェア固定
オペレーティングシステム
ミドルウェアやライブラリA B C
アプリ
1
リソース有効活用のしづらさ
たとえばリソースを有効活用したい
のが目的であればMesosという選
択肢もあります。

70
仮想化技術の時代
とある仮想サーバA とある仮想サーバB とある仮想サーバC
OS
ミドルウェア
アプリケーション
OS
ミドルウェア
OS
ミドルウェア
時間
リ
ソ
ー
ス
使
用
率
時間時間
サーバが増減できるよ、やったね！
アプリケーションアプリケーションアプリケーション
仮想化によって物理に比べればリ
ソースを有効活用できますが、やっ
ぱり勿体ないところがあります。

71
思い描く理想
サーバ１台で3台分の仕事ができるよ、やったね！
本当にやりたいのは、これ

72
とある仮想サーバA とある仮想サーバB とある仮想サーバC
OS OS OS
時間
リ
ソ
ー
ス
使
用
率
時間時間
効率的に使えるよ、やったね！
Mesosの出番
Apache Mesos
アプリアプリアプリアプリアプリアプリアプリアプリアプリ
動くアプリが増えるね！！

73
Mesos Master
Mesos Slave群
処理(Executor) APIフレームワーク
Marathon
Apache Aurora
Chronos
…etc
汎用スケジューラ
meta-scheduler
Mesos Slave
Mesos Slave Mesos Slave
Mesos Slave Mesos Slave Mesos Slave
タスクをスケジュール
リソース要求
Mesos Slave
Mesos Slave
Mesos Slave
俺がルール
ブックだ！！
Executor Containerlizer 拡大縮小可能かつ効率的リソース利用
プラガブル
Pluggable
障害耐性
Zookeeper Quorum
タスクを処理（実行）

用途の見極め
結局の所、何のために導入したい
のですか？という所に立ち返ります。

75
改めて、コンテナだけでは意味が無
くて、それを動かす仕組みが必要だ
から。技術面というよりは、業務面
なりビジネス上の価値追求に重点
が置かれることも多いでしょう。

76
そして、いかに業務を回していくか。
効率的に速く開発サイクルを回す
のであれば、Dockerが適してい
る場面もあるでしょう。あるいは、
他のコンテナ技術なり、目的が適
わなければ仮想化・クラウド、ある
いは物理でだっていいのです。結
局私たちは何を解決したいのか？
という視点ではないでしょうか。

振り返り

使いどころの勘違い
仮想化≠コンテナ化
業務手順も変わる
色々な都市伝説化が進んでいると
思われますが、基本は目的なき技
術選定の結果ではと、個人的に
思っています。

Dockerは仕様
そして、Dockerを使うのは非常に
簡単です。使えるかどうか論じる前
に、まず手を動かして試してみませ
んか？と主張したいです。

課題は何であり
何を解決したいのか？
そして現場によって解決したい課題
は違うはずです。技術ありきではな
く、問題を解決するための手段とし
ての技術だという心構えが必要で
はないでしょうか。

何か気になる所がありますか？
ご参考：Docker 日本語ドキュメント
http://docs.docker.jp/
http://slideshare.net/zembutsu
twitter: @zembutsu
最後までありがとうございました。

まだ時間あります？
82

83
Dockerの役割を再定義
導入コスト
高い
導入コスト
低い
運用コスト
低い
運用コスト
高い
Public Cloud 基盤
Private Cloud 基盤
chef
Ansible
Docker
開発用
OpenShift
Docker
運用系
kubernetes

背景画像CREDIT:rvika/ PIXTA(ピクスタ)
prof261092" target="_blank">https://pixta.jp/@prof261092
2017年2月27日(月)
@zembutsu
Revision 2017.02
Dockerの誤解と疑問に答える
一問一答と技術Tips

とし－でんせつ【都市伝説】
• 『友達の友達』など身近なようで実際には顔も名前も分からない人々に起きた出来事として
語られる奇妙な噂話（松山ひろし氏）
• 本当にあったとして語られる『実際には起きていない話』（宇佐話通氏）
• 都市を中心に伝播していく都市伝説には、いくつかの特徴が挙げられる。
1. 過去の事件、事故に由来する
2. 場所に由来する
3. 発祥が不確定、或いは特定しづらい
• 都市伝説の内容はいかにもありそうな話が殆どであり、
教訓めいた要素が盛り込まれている事も多い。
【参考】都市伝説 - Wikipedia
https://ja.wikipedia.org/wiki/都市伝説

"楽して地雷を避けたい"
"都市伝説化"
• 個人的な情報の伝達は「噂」
• 事実が確認されないままに情報が人々の間を伝達
【参考】「噂」も消費するパワーゾーン渋谷「都市伝説」はこうして生まれる？ - シブヤ経済新聞
http://www.shibukei.com/special/69/

1. 導入前の疑問
Dockerは全てを解決しない
2. 利用直後の困りどころ
ドキュメントを読もう
3. 運用面の課題
Docker以外の知見も必要

1. Dockerは難しい
2. 今すぐ始めなくてはいけない
3. すべての環境をコンテナにしなくてはいけない
4. 仮想化システムは不要になる
5. 構成管理ツール（Chef,Puppet,Ansible等）は不要になる
6. VagrantがあればDockerは不要だ
7. Dockerは構成管理ツールを使っていれば不要だ
8. クラウド環境は不要になる
9. クラウド上でなければDockerの価値は無い
10. Windows上でLinuxのコンテナが動く
11. Dockerやコンテナが全てを解決してくれる
12. Docker であれば業務効率化できる
13. Docker があればコスト削減できる
14. Docker やコンテナを使うとベンダーロックインされる
15. いまあるシステムを、Dockerで作り直さなくてはいけない
16. システム・インテグレータにはコンテナは向かない
17. 閉じた環境では使えない・使う意味が無い
導入前の疑問

18. 定番のOSが無い。どれを選ぶべきか分からない
19. よく落ちる
20. ネットワークが貧弱だ
21. データの可用性が貧弱
22. データベースが重い、使えない
23. データベースやキャッシュサーバの用途にDockerは向かない
24. Dockerはディスク容量を無駄に消費する
25. コンテナが止まるとログが記録されない
26. Dockerfileのビルドに毎回かなり時間がかかる
27. 複数のコンテナを立ち上げるのは大変だ
28. マシンを再起動すると、コンテナで動かしていたサービスをまた起動する必要があるので面倒
29. Docker Registryは不安定だ。使い物にならない。可用性が無い
30. 英語のドキュメントを読むのが大変だ。日本語の情報が古い
利用直後の困りどころ

31. 本番環境では使えない
32. DockerにはSLAが無いから使えない
33. Dockerは冗長化できない
34. Dockerは（運用チームにとって）学習コストが高い
35. 商用サポートを受けられない
36. １サーバ１コンテナで運用すべきだ
37. Docker は kubernetes がないと意味が無い
38. kubernetesがあればDockerやDocker Swarmは不要だ
39. Kernelのチューニングができない
40. Dockerはオワコン、これからはrkt
41. Docker ではなく CoreOS を使うべきだ
42. Docker環境は監視ができない
43. Dockerの導入事例がない
44. セキュリティや信頼性に問題がある
45. そもそも、Docker を使う意味が無い
46. Dockerは生産性や効率性に寄与しない
47. 5年後10年後もDockerで大丈夫なのか？
48. Dockerには恨み辛みがある
運用面での疑問や課題

ネット上の日本語情報は古い場合がある
最新情報の見極めを
手を動かそう get.docker.com

SSSSLIDE

Dockerの期待と現実～Docker都市伝説はなぜ生まれるのか～

Masahito Zembutsu さんの他のスライド

関連するスライド

このスライドの内容

関連するタグ

SSSSLIDE