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

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

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

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

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

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

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

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

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

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

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

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

12. 12 サーバ仮想化／デスクトップ仮想化に関するアンケート調査リポート（2016年4月） TechTargetジャパンホワイトペーパーダウンロードセンター http://wp.techtarget.itmedia.co.jp/contents/?cid=19841 用途は開発環境・テストサーバが多いようですが、ウェブサーバや様々な用途で使われています。

13. 13 サーバ仮想化／デスクトップ仮想化に関するアンケート調査リポート（2016年4月） TechTargetジャパンホワイトペーパーダウンロードセンター http://wp.techtarget.itmedia.co.jp/contents/?cid=19841 きっかけは、サーバ統合やリソースの有効活用、効率化といった項目が上位を占めている状況です。

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

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

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

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

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

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

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

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

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

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

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

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

28. 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. 29 Dockerと愉快な仲間達 Build Run開発・構築移動実行 Ship “Build, Ship, Run, Any App Anywhere” Docker Engine for Linux / Commercial Support Docker for Mac, Windows, Windows Server 2016 Docker Trusted Registry Docker Hub Universal Control Plane Toolbox Kitematic Dev (開発) Ops (運用) アプリはDockerイメージとして構築・移動し、コンテナ状態として実行できるようになったのです。

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

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

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

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

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

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

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

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

38. コンテナは技術 Dockerは仕様

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

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

43. 43 コンテナのプロセス httpd PID 1 コンテナA コンテナB 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. 44 コンテナのファイルシステムコンテナAのファイルシステム … … コンテナBのファイルシステム /etc /bin /etc /bin / / / 以下の /etc /bin 等のディレクトリを持つファイルシステムも同様です。それぞれのコンテナは全くお互いを認識できず、独立しているように見えるのですが

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

46. 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 コンテナA コンテナB つまりコンテナの実行、あるいは、あるプロセスをコンテナ状態で起動するとは、名前空間を分離する技術を使い、お互いを分けて、

47. 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 コンテナA コンテナB 名前空間の isolate ・プロセス・ファイルシステム・ネットワーク・ホスト名・UID・GID リソース制限・CPU ・メモリ・I/O ・ディスク・クォータさらにプロセスにはリソースを制限可能な状態と言えます。

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

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

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

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

53. 複数のイメージを使うには？ 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 コンポーズというツールも提供されています。

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

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

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

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

58. 58 Dockerと愉快な仲間達 Build Run開発・構築移動実行 Ship “Build, Ship, Run, Any App Anywhere” Docker Engine for Linux / Commercial Support Docker for Mac, Windows, Windows Server 2016 Docker Trusted Registry Docker Hub Universal Control Plane Toolbox Kitematic Dev (開発) Ops (運用) ここで改めてDockerとはアプリケーションを迅速に構築・移動・実行するための役割を担います。

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

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

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

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

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

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

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

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

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

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

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

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

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

73. 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 Mesos Slave Mesos Slave Mesos Slave Mesos Slave Mesos Slave Mesos Slave Mesos Slave Mesos Slave Mesos Slave Mesos Slave 俺がルールブックだ！！ Executor Containerlizer 拡大縮小可能かつ効率的リソース利用プラガブル Pluggable 障害耐性 Zookeeper Quorum タスクを処理（実行）

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

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

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

77. 振り返り

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

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

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

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

82. まだ時間あります？ 82

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

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

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

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

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

88. 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. 閉じた環境では使えない・使う意味が無い導入前の疑問

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

90. 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には恨み辛みがある運用面での疑問や課題

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