Docker概要 ：コンテナ技術と普及がシステム・インテグレータに与える影響
2016年3月4日(金)@zembutsu
Technology Evangelist; Creationline, Inc.

Dockerやコンテナは様々な方や場所で言及されていますので、そこを改めて深掘りするのではなく・・・いまここにあるDockerを、どのようにして使っていけば良いのか？
ピザであれば「どう食べるのか」という視点で、皆さんと共有したいと思っています。

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

コンテナ時代にシステムインテグレータがこの先生きのこるには？

2016年3月4日(金)第35回NCWG発表資料@zembutsu
Technology Evangelist; Creationline, Inc.

システム要件にコンテナ？

こマ？

どうすんだ
これ…

本資料の想定読者• 営業）お客さまが「Docker」を使いたいと言われたら？

• 上長）部下が「Docker」を使いたいと言ってきたら？
• 現場）上長・役員に「Docker」を使うべきと伝えるには？
・本資料における主張• 「Docker」を導入するだけでは価値を生まない。

• 「Docker」は技術選択要素の１つにすぎないので、業務フローに一致するならば、積極的に導入すべきだ。

• 継続的な技術評価を行うべきだ。
・

「SIがコンテナ時代に、この先生きのこるために」https://en.wikipedia.org/wiki/Moby-Dick本スライドの内容• 10分で分かる「Docker」の世界• なぜDockerが必要なのか、業務に何をもたらすのか？
• 導入時の技術選択要素と誤解（都市伝説）• 質疑応答

1

10分で分かるDockerの世界■□□□ What is the "Docker" ?

アクセントの悩み

docker／ドッ＼カー

ドッ／カー→
17

dockerDocker プロジェクト• 開発者やシステム管理者が、アプリを開発・移動・実行するプラットフォーム• Docker, inc. はスポンサー
primary contributor, maintainer

Docker デーモン
• イメージとコンテナを管理• ホスト上で動くプロセス• Linuxコンテナ技術を使う
namespaces, cgroups※Docker Glossary https://docs.docker.com/engine/reference/glossary/Docker, Inc.
Docker••(Docker, IBM)

Docker•Docker

•

10•

1500

•

200,000

40%
DockerGerber, Anna. “The State of Containers and theDocker Ecosystem: 2015” O’Reilly, September 2015

引用：国内企業におけるオープンソースソフトウェアの利用実態調査結果を発表
http://www.idcjapan.co.jp/Press/Current/20160204Apr.html

プラットフォーム「Docker」とは、アプリケーションを動かすための仕組みを提供
BUILD

SHIP

Docker Toolbox

RUN

Management UIDocker Hubor Trusted
Registry

Plugins: Network, Volume, Clustering

Cloud or Private Infrastructureプラットフォーム

開発者が簡単にアプリケーションを開発・デプロイできる仕組み

コンテナ

Docker Engine"docker" デーモン

ユーザ空間

docker run …

DockerクライアントTCP:2375, TCP:2376(TSL), Unix Socket

ユーザ空間

ユーザプ
ロセス

ユーザプ
ロセス

ユーザプ
ロセス

Ubuntu
レポジトリ

MySQL
レポジトリ

tag:latest

tag:latest

tag:14.04

tag:5.7…

…

• Cgroups• Namespaces

OS のカーネル空間

 mount

サーバ

 IPC

Docker サーバ

 UTS
 PID
 Network UserDocker Hub(レジストリ)
https://hub.docker.com/

docker

$ docker run …

$ docker run …
Engine$ docker run …
$ docker run …

Engine$ docker-compose up

$ docker run …
$ docker run …

$ docker run …

$ docker run …
$ docker run …

$ docker run …

Docker社が買収(2015年10月)
AWS, Digital Ocean, Azure,
SoftLayer, Packet と連携

tutum
https://www.tutum.co/

コンテナのデプロイと管理
Docker Hub を補完する役割

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

Docker Hub

http://cloud.docker.com(旧Tutum)

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

DTR
Docker Trusted Registry

Orca (beta) + UCP
Universal Control Plane

https://www.docker.com/universal-control-planeクラウドを取り巻く業界俯瞰図

Jenkins

GitHubCircle CI

Atlas

Salesforce

HerokuWindows Azure
Google Cloud Platform

IaaS
パブリック・クラウド

VMwareSlackPagerDuty

Amazon Web Services
SoftLayer

NewRelic
OpenStack

さくらのクラウド

Datadog

DigitalOcean

CloudStack
さくらのVPS

LinodeMackerel

Niftyクラウド
Cloud nクラウドを取り巻く業界俯瞰図

Jenkins

GitHub

開発環境

Atlas

CI

SaaS

Salesforce

Circle CI

PaaS Heroku
Windows Azure
Google Cloud Platform

IaaS
パブリック・クラウド

OpenStack

CloudStack

Operations
PagerDuty

Amazon Web Services
SoftLayer

VMwareプライベートクラウド

Slack

NewRelic

さくらのクラウド

日本国内
パブリッククラウド

Datadog

DigitalOcean

Monitoring
さくらのVPSVPS Linode
Mackerel

Niftyクラウド
Cloud nクラウドを取り巻く業界俯瞰図

Jenkins

GitHub

開発環境

Atlas

CI

DockerPaaS Heroku( Linux Containers)

Windows Azure
Google Cloud Platform

IaaS
パブリック・クラウド

OpenStack

CloudStackSlackOperations
PagerDuty

Amazon Web Services
SoftLayer

VMwareプライベートクラウド

SaaS

Salesforce

Circle CI

NewRelic

さくらのクラウド

日本国内
パブリック
クラウド

Datadog

DigitalOcean

Monitoring
さくらのVPSVPS Linode
Mackerel

Niftyクラウド
Cloud nクラウドを取り巻く業界俯瞰図

Jenkins

GitHub

開発環境

Atlas

CI

DockerPaaS Heroku( Linux Containers)

Windows Azure
Google Cloud Platform

IaaS
パブリック・クラウド

OpenStack

CloudStack

Slack

Operations
PagerDuty

Amazon Web Services
SoftLayer

VMwareプライベートクラウド

SaaS

Salesforce

Circle CI

NewRelic

さくらのクラウド

日本国内
パブリッククラウド

Datadog

DigitalOcean

Monitoring
さくらのVPSVPS Linode
Mackerel

Niftyクラウド
Cloud nコンテナを取り巻く業界俯瞰図

Apache Auora
MarathonCluster Management

構成管理

SkyDNSAPCERA

Mesosphere

Service Discovery

Docker Swarm
Docker Compose
Cloud Foundry

Etcd

shippable

開発環境
Build / Deploy

fleet

rkt

Amazon EC2
Container ServicePaaS

運用自動化
Orchestration

Networkingkitematic

Google Container
EngineDocker Machine
Kubernetes

IBM Containers
on Bluemix

flannelDocker コンテナ管理用プラットフォーム

Docker特化OS
CoreOS
Tectonicパブリック・クラウド陣営

Amazon EC2
IBM Containers Google Container
Container Service
on Bluemix
EngineGoogle Kubernetes

商用サポート／エンタープライズ

管理・効率化Docker ネイティブサポート

オープンソース
コミュニティ

Tectonic

Docker
競合

最小環境
CoreOSDockerCon 2015 から流れが変わる
http://www.dockercon.com/‣ Docker, Inc.主催
サンフランシスコ
6月22日・23日の2日間セッション、ハンズオン、トレーニング、ブース出展

39

Orchestration

The Open Container Project (OCP)

Google Kubernetes

Linux事務局として協力
Foundation

Amazon ECSIBM Containers Google Containeron Bluemix
EnginePROJECT ORCA

× libcontainer 廃止

runC

CoreOS

appcは独自に継続

公式レポジトリ

インフラ＆プロバイダ

ネットワーク機能
開発ツール

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

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

ストレージ

ビッグデータ管理

サービス・ディスカバリ

セキュリティ

構築／CI

設定管理

監視とログ

コンサルタント・トレーニング

ここまでのまとめ• Dockerは組織でもあり、技術でもある• 簡単にアプリケーションを開発・移動・実行するためのプラットフォームを提供する（≠インフラ）• Dockerには用途に応じた様々なツールが存在する• Dockerを中心としたエコシステムが形成されつつある2

なぜDockerが必要になったのか？
■■□□Why we need "Docker" ?

ご注文はコンテナですか？
Is the order a container?

ご注文はコンテナですか？
Is the order a container?

物理サーバ・ネットワーク環境の全盛時代

社内サーバ

ftp, rsync, scp

開発用端末

データセンタ環境の構築は大変環境をデプロイするのも大変
壊れた後の復旧も大変突然の死

仮想化・クラウド時代
MachineImage
VirtualMachineMachineImage
VirtualMachineVirtualMachineVirtualMachineVirtualMachine

構成管理ツール(Chef, Puppet, Ansible, Itamae… etc.)

社内サーバ
開発用

CI

ftp, rsync, scp
デプロイ支援ツール(Capistrano, Vagrant, Packer,Terraform, AWS CLI … etc.)

ステージング

VirtualMachineVirtualMachineVirtualMachineVirtualBox

VirtualBox

VirtualBox

開発用端末

クラウド環境本番

インフラ別の環境構築は面倒
環境によってOSが違う
開発・リモートどちらも同じにしたい開発の各段階から運用に至る流れをより効率的に！より速く！確実に！

暗黒^H^H物理時代
見積もり

機材
発
注

機材
納品

機器
設
定

設
置

O
S
設
定環
境
構
築

…

事
前
設
計

利用
開始

試
験仮想化・クラウド時代
事
前
設
計

ク
リ
ック

試
験利用
開始

開 発 段 階

…

事
前
設
計

ク
リ
ック

試
験

検 証 段 階

利用
開始

ク
リ
ック

試
験

利用
開始

本 番 段 階コンテナ時代開発試
験運用…

すべてを迅速に、一貫した環境で行いやすい← New…

社外開発環境

ステージング環境

社内共有開発環境

本番環境

社内テスト環境

個人開発環境社外開発環境CI/CD

ステージング環境

本番環境

Docker レジストリ

Docker動作環境(docker machine)ここまでのまとめ• 迅速な業務フローが求められている• ハードウェア視点：インフラを迅速かつ継続的に使いたい• ソフトウェア視点：継続的な開発・運用を続けたい3

Docker導入時の考慮点■■■□

Consideration

？？？「すべてがコンテナになる」

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

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

58利用シーンの範囲を検討‣ 開発環境のみ

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

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

59

利用シーン
開発TASK

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

運用opsチームの範囲

devチームの範囲

評価

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

運用

評価

ステージによって異なる
61

利用シーン
開発
TASK

評価

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

TASK

運用

ステージによって異なる
62

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

‣ コンテナを誰が使うのか？
開発チーム？ 運用チーム？

テスト？ 検証？ コミュニティ？

自社内？ お客さま？

‣ 何のために使うのか？
システム開発？

運用？ 商用サービス？

検証？
64たとえばピザで考えてみます！

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

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

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

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

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

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‣ ベンダーによる保守サポート有無‣ コミュニティによるサポートの有無70ストレージ・ドライバ‣ Docker イメージの内部管理方式

ストレージ・ドライバを何にするかは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-maintenance71

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

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

コピー・オン・ライト方式

なぜならDockerはイメージ管理に独特の処理を行っているため。

‣ CoW; Copy on Write• 効率的にイメージを使う仕組み
1. ファイル更新が発生する（初回）
2. イメージからコンテナ用領域にファイルをコピーする
3. コピーしたファイルを編集

CoW処理がパフォーマンスに影響
デバイス・ドライバの選択により挙動が異なるので注意が必要
詳細：イメージ、コンテナ、ストレージ・ドライバの理解 — Docker-docs-ja 1.10.0b ドキュメント
http://docs.docker.jp/engine/userguide/storagedriver/imagesandcontainers.html

73

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

AUFS

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

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

devicemapper

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

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

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

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

主なセキュリティ考慮点‣

ベース・イメージ•‣

誰がセキュリティのメンテナスを行っているのか。コミュニティ 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 通信が推奨

78

検討項目まとめ1. 利用者は誰で、用途は何か？
2. インフラをどうするのか？
3. OSを何にするのか？
4. ディストリビューションを何にするのか？
5. ストレージ・ドライバを何にするのか？
6. ベースイメージは何にするのか？
7. セキュリティをどのように考慮すべきか？
8. 性能をどのように担保するのか？
79

参考にすべきはドキュメント‣ 公式
https://docs.docker.com/‣ 日本語訳
http://docs.docker.jp80Docker Engine オススメのドキュメント‣

ユーザガイド•http://docs.docker.jp/engine/userguide/index.html•

Dockerfile ベスト・プラクティス–•

ストレージ・ドライバ–•

http://docs.docker.jp/engine/userguide/storagedriver/index.html

Docker ネットワーク機能の概要–‣

http://docs.docker.jp/engine/userguide/eng-image/dockerfile_best-practice.html

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

81ここまでのまとめ• Dockerはプラットフォームであり、全てを解決しない• Dockerコンテナのライフサイクルに対する理解が必要• 検討要素• 最終的な利用者は誰なのか• 業務範囲や用途は何なのか

技術選択のポイント

Dockerは全てを解決するインフラではない。Dockerの管理領域と、それ以外を区別して組み合わせを考える必要がある。

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

4

まとめ
■■■■

Wrap up

本資料における主張• 「Docker」を導入するだけでは価値を生まない。

• 「Docker」は技術選択要素の１つにすぎないので、業務フローに一致するならば、積極的に導入すべきだ。

• 継続的な技術評価を行うべきだ。
・

誰が？
何のために？

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

より詳しい技術情報
http://docs.docker.jp
http://slideshare.net/zembutsu

質疑応答• 何か気になる所はありますか？
• 日本語ドキュメント http://docs.docker.jp• @zembutsu

私は誰なのか？
Why am I here?

+MasahitoZembutsu‣ @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/log392