Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

42,265 views

Published on

「企業のためのDocker実戦ガイド」発表資料
2017年2月27日(月)
https://itmedia.smartseminar.jp/public/seminar/view/981

Published in: Technology
  • Be the first to comment

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

  1. 1. Dockerの期待と現実 Docker都市伝説はなぜ生まれるのか さくらインターネット株式会社 Engineer / Technology Evangelist 前佛 雅人 Masahito Zembutsu @zembutsu
  2. 2. 誰? • さくらインターネット株式会社 技術本部ミドルウェアグループ クラウドチーム/VPSチーム/エバンジェリストチーム • 運用系(サーバ) … データセンタの運用・サポート対応 • HashiCorp / Munin / Zabbix / Docker などに興味 • エンジニアのためのプレゼン研究会 • ドキュメント翻訳 • 稲作農家(富山県滑川市出身) • インターネットの力で普通の人が価値を高められる社会 2 Software Degisn 2017年2月号→ Authorized Docker Trainer (2016.6~) ZEMBUTSU Masahito 今回の発表は、これまでDockerに触 れてきた一人という、中立的な立場で 皆さんと議論したいと思っています。
  3. 3. Dockerの期待と現実 「企業のためのDocker実戦ガイド」 というセミナーで、登壇の機会をいた だきました。ありがとうございます。 Dockerやコンテナ技術に対して興味 をお持ちの方に、私が普段対面で話 している内容を中心に、発表でまとめ させていただきました。
  4. 4. Dockerの期待と現実 使える? 使えない? という話ではなく、何の解決に役立つか? よくいただくご質問は「Dockerなりコ ンテナが使えるかどうか」です。しかし 大切なのはそこではなく、どのような 課題を解決するためにDockerやコン テナに対して期待しているか、という視 点が大切だと考えています。
  5. 5. 使いどころの勘違い 仮想化≠コンテナ化 業務手順も変わる 「期待と現実」という視点で、3つの キーポイントを挙げます。そもそものス タート地点とゴールを見誤ると、何の ためにDockerやコンテナを入れたん だっけ?という話になりがちです。
  6. 6. コンテナは技術 Dockerは仕様 そして、コンテナ技術の話、Docker のプラットフォームとしての役割の話が 混同されているため、なおさら混乱を 生みがちなのが現状です。そして前提 が違うのに情報だけが伝わり、都市 伝説化しているのではないでしょうか。
  7. 7. 高まる期待 まずは、どうしてDockerやコンテナが 注目されるに至ったのか、これまでの 経緯を簡単に振り返りましょう。
  8. 8. 8 物理サーバ時代 機 材 発 注 機 材 納 品 設 置 機 器 設 定 見 積 も り O S 設 定 環 境 構 築 試 験 運 用 開 始 これまでの物理からクラウドに至る 流れを、改めて振り返ります。物理 サーバ時代はシステム調達までの 時間が長い課題がありました。
  9. 9. 9 仮想化 事 前 設 計 ク リ ッ ク 試 験 利 用 開 始 しかしそれでは、ウェブを中心とした インターネットの普及スピードに追 いつけません。ですので、速さと効 率化を求めて、仮想化技術や、
  10. 10. 10 仮想化 クラウド 事 前 設 計 ク リ ッ ク 試 験 利 用 開 始 事 前 設 計 ク リ ッ ク 試 験 利 用 開 始 事 前 設 計 ク リ ッ ク 試 験 利 用 開 始 クラウド技術の普及が進みます。 すぐに環境を作ったり壊したりでき る。あるいは、リソースの集約や有 効活用に活かすことができる。
  11. 11. 11 サーバ仮想化/デスクトップ仮想化に関するアンケート調査リポート(2016年4月) TechTargetジャパン ホワイトペーパー ダウンロードセンター http://wp.techtarget.itmedia.co.jp/contents/?cid=19841 2016年春の段階で、サーバ仮想 化技術は半数の企業で導入済み という調査結果も出ています。皆さ んの肌感覚と近いと思います。
  12. 12. 12 サーバ仮想化/デスクトップ仮想化に関するアンケート調査リポート(2016年4月) TechTargetジャパン ホワイトペーパー ダウンロードセンター http://wp.techtarget.itmedia.co.jp/contents/?cid=19841 用途は開発環境・テストサーバが 多いようですが、ウェブサーバや 様々な用途で使われています。
  13. 13. 13 サーバ仮想化/デスクトップ仮想化に関するアンケート調査リポート(2016年4月) TechTargetジャパン ホワイトペーパー ダウンロードセンター http://wp.techtarget.itmedia.co.jp/contents/?cid=19841 きっかけは、サーバ統合やリソース の有効活用、効率化といった項目 が上位を占めている状況です。
  14. 14. 14 仮想化 事 前 設 計 ク リ ッ ク 試 験 利 用 開 始 クラウド 事 前 設 計 ク リ ッ ク 試 験 利 用 開 始 事 前 設 計 ク リ ッ ク 試 験 利 用 開 始 そのため、これまでと同じように、効 率化なり、ハードウェアに対する投 資という視点で、
  15. 15. 15 仮想化 事 前 設 計 ク リ ッ ク 試 験 利 用 開 始 クラウド 事 前 設 計 ク リ ッ ク 試 験 利 用 開 始 事 前 設 計 ク リ ッ ク 試 験 利 用 開 始 Docker / コンテナ Dockerなりコンテナ技術に対する 期待、それも過剰な期待が高まっ ているものと思われます。
  16. 16. 16 仮想化 Docker / コンテナクラウド 事 前 設 計 ク リ ッ ク 試 験 利 用 開 始 事 前 設 計 ク リ ッ ク 試 験 利 用 開 始 事 前 設 計 ク リ ッ ク 試 験 利 用 開 始 サーバ統合・リソース有効活用 設置スペース・消費電力削減 運用自動化・効率化 システム可用性向上 これまでの延長上の技術と思われ てしまい、その視点で「使える」か 「使えない」かが論じられています。 ですが、それは正しいのでしょうか。
  17. 17. コンテナ技術とDocker それを判断するには、そもそも Dockerがどのように生まれたかを 理解してから論ずる必要があると 私は考えています。
  18. 18. 18 Dockerは2013年3月に登場し たばかり。間もなく4周年を迎える まだまだ若いものです。
  19. 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. 20 当時も様々なコンテナ技術は存在 していました。Dockerが実現した 価値とは何だったのでしょうか。単 にコンテナが存在するだけでは、何 も意味がありません。
  21. 21. 21 コンテナという技術を使うことで Dockerというプラットフォームが アプリケーションをコンテナの上に のせれば、どこにでも持って行ける ように、どこでも実行できるように する仕組みを生み出した所に価値 があり、プロジェクトに多くの貢献 者が参加したり、企業からの支援 を受けるようになりました。
  22. 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 innovation” http://www.docker.com/company/ 22 改めて、Dockerとはアプリケー ションを動かす仕組み・プログラム です。オープンソースのプロジェクト と、その支援と商用サポートをする 会社がお互い独立しています。
  23. 23. 23 依存関係 システム基盤 • オペレーティング・システム [Linux|Unix|Windows] • ハードウェア、ネットワーク、ストレージ • 物理 or 仮想化 or クラウド • ミドルウェア • 各種プログラミング言語環境や、システム・ライブラリなど • バイナリやソースコード • 設定用パラメータ application dependencies Infrastructure アプリ 従来のシステム開発において、か ならず基盤、ネットワークやサーバ などハードウェア・リソースありきで 前提や制約が組まれていた場面が 殆どでした。
  24. 24. 24 依存関係 システム基盤 Docker コンテナ Docker Engine (dockerd) • ミドルウェア • 各種プログラミング言語環境や、システム・ライブラリなど • バイナリやソースコード • 設定用パラメータ application dependencies Infrastructure • オペレーティング・システム [Linux|Unix|Windows] • ハードウェア、ネットワーク、ストレージ • 物理 or 仮想化 or クラウド アプリ Dockerの登場で、アプリありきで 考えられるようになりました。つまり Dockerコンテナ、正確には Dockerイメージさえあれば、イン フラを意識せずに動かせるように。
  25. 25. 25 仮想化 事 前 設 計 ク リ ッ ク 試 験 利 用 開 始 クラウド 事 前 設 計 ク リ ッ ク 試 験 利 用 開 始 事 前 設 計 ク リ ッ ク 試 験 利 用 開 始 Docker / コンテナ 改めて歴史的経緯を見直すと、こ れまでの利用シーンとはチョット違 う気がすると思います。そもそもの 目指す所が、違うため、この図の ように、一直線上には並びません。
  26. 26. 社外開発環境 本番環境ステージング環境 社内共有開発環境 個人開発環境 社内テスト環境 仮想化やクラウドの普及によって 生まれた課題は、管理すべき環境 がふえたことと、どこでも「間違い なく動く」ことを保証するのが難し い所です。Chef、Puppet、 Ansible のような構成管理ツー ルは1つのサーバ内で完結する場 合は良いかもしれませんが、インフ ラ全体、特にアプリケーションを間 違いなく動かすという視点、あるい は素早く動かすという所では、まだ 足りない所があるかもしれません。
  27. 27. 社外開発環境 本番環境ステージング環境 社内共有開発環境 個人開発環境 社内テスト環境 社外開発環境 本番環境ステージング環境 CI/CD Docker レジストリ Docker動作環境(docker machine) そのような環境の違いを意識しな くても、間違いなくアプリケーション を動かせるようにしたい。そのよう な環境を作るための土台としての プログラムがDockerです。
  28. 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. 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. 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. 31. なぜDockerが登場したのか? 物理から仮想化への流れ 課題:デプロイ時間が遅い、コストがかかる、無駄なリソースが必要、スケールしづらい ハイパーバイザ型仮想化基盤の登場により、1台のサーバ上で複数の仮想マシンを動かせる 仮想化、そしてクラウド・コンピューティング 仮想化はリソースの共有が便利、スケールもしやすい 必要な時に、必要なだけのリソース増減を行いやすい 使った分だか支払う料金体系 新たな課題 たくさんのアプリケーションを動かすには、より多くのリソースの必要性 アプリケーションのポータビリティ(移植性)は保証されない 31
  32. 32. 現実世界の移動(輸送)課題 32 様々な 種類の 「モノ」 輸送の 手段は 色々 「モノ」にお互い の影響を与えず 運ぶには? (例:コーヒーと 香辛料を運ぶ) 迅速かつスムー ズに転送可能 か? (例:船から貨物 列車への積み 替え時)
  33. 33. 規格化によって解決 33 様々な 種類の 「モノ」 輸送の 手段は 色々 「モノ」にお互い の影響を与えず 運ぶには? (例:コーヒーと 香辛料を運ぶ) 迅速かつスムー ズに転送可能 か? (例:船から貨物 列車への積み 替え時) コンテナ規格により、事実上、 あらゆるモノを運ぶことができ、 かつ送り先には封印したままで 届ける 長距離輸送中の積み込み、荷下ろ し、積み重ね、移動が効率的であり、 様々な輸送手段に切り替え可能
  34. 34. ここからヒントを得たDockerコンテナ 34 エンジンは様々なものを軽 量・移動可能・自給自足的な コンテナにカプセル化できる 標準的なOS操作により、あらゆる ハードウェア・プラットフォームで 仮想的に一貫して実行可能 複数の 開発 スタック 複数の ハード ウェア 環境 サービスとアプ リケーションは 適切に通信可 能か? 迅速かつス ムーズに移 動可能か? 静的ウェブサイト ユーザDB ウェブ・フロントエンド キュー 解析DB 開発用 仮想マシン QAサーバ お客さま データセンタ パブリック クラウド プロダクション クラスタ コントリビュータ ノートPC
  35. 35. Docker が実現したこと 実行に必要なすべてをファイルシステムへ ソースコード、システム用ツール、ライブラリなど、サーバのすべてを Docker イメージ化 Dockerfile を使った自動イメージ構築により、環境再現性を高める どのような環境でも動作を保証 Docker (Engine) が動く環境であれば、どこでもイメージをコンテナとして実行できる ソフトウェアを動かすために、環境構築やセットアップ作業が不要に 軽量 仮想化・クラウド環境と比べ、ホストOSを必要としないので、必要なリソース容量が少ない Docker イメージを複数のレイヤ(層)で共有するため、移動時の容量を少なくできる 35
  36. 36. 仮想マシン vs Docker ではない!! コンテナはプラットフォームに依存しない コンテナであれば、ある環境で構築したら、別の環境に迅速に移動可 Dockerイメージはソフトウェアのスケール(増減)を迅速かつ簡単に コンテナは OS とアプリを明確に役割分担 開発者はアプリケーション開発に集中、運用担当はデプロイ作業や運用に集中 仮想化は手軽に厳密なリソース管理が可能 仮想化システムの利用には業務手順の(大きな)変更を伴わない リソースの集約と管理をしやすい 単純な比較は無意味 システム基盤としてのコンテナ導入や、コスト削減・省力化視点でのコンテナ化は無意味 36 技術要素は似てますが方向が別
  37. 37. 37 仮想化 Docker コンテナ 独立した環境 仮想ハードウェア Dockerイメージ リソース集約 様々なOSが動作 Linux kernel 技術を活用 ※ Dockerコンテナは、アプリケーションが複数サーバにスケール する前提なら、環境の繰り返し作成・廃棄を高速に行える ※ スケールが必要なければ、必要なハードウェアや OS に あわせた環境を自由に構築できる • プロセスは namespace を通して PID 、 ファイルシステムなど、様々な名前空間を分離 プロセスを起動後、瞬時に分離かつリソースを制限可能 な点が仮想化と似て見えますが、実装や仕組みや操作 性は全く異なる。 • Control groups の機能を使い、1つ1つの コンテナ(Linuxのプロセス) に対して CPU、メモリ、 I/O の制限をかけられます 使い捨て型 (再利用性) 共通要素 • ハイパーバイザ型もしくはホスト型の仮想化 技術により仮想マシンを実行 • ハイパーバイザ技術により仮想マシンを実行 インフラのコード化 • Dockerfile や docker-compose.yml で 確実にアプリが動作する環境再現性を管理 • 階層化したイメージ・レイヤにファイルシステムや メタデータを格納 • 親子関係により、ディスク容量節約や移動高速化 • 厳密なリソース定義や確実な環境分離を 提供 環境の移行がスムーズ • サーバ管理する業務フローが確定しているの であれば、変更しなくてもシステムの移行や 集約をしやすいので、導入しやすい • Windows / Linux など選べる • 32bit / 64bit などアーキテクチャを選択できる 自由度の高いハードウェア・エミュレーションや 管理性を提供する。
  38. 38. コンテナは技術 Dockerは仕様
  39. 39. Dockerを動かす技術 • Docker Engine (dockerd) がリクエストを受信後、各種処理 • 名前空間(namespace)はプロセスごとに独立した環境を作る • コントロール・グループ(cgroups)はリソースを制限・管理 • Linux カーネル技術や業界共通の規格を採用
  40. 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. 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. 42 コンテナのプロセス httpd PID 1 コンテナA コンテナB ruby PID 1 chris.rb PID 2 PPID 7 名前空間(ネームスペース)技術 はいくつかありますが、重要なのも の1つに、プロセス空間の分離 (isolation)を実現します。 たとえば、2つのコンテナがあると して、プロセス空間は PID 1 のプ ロセスを持ち、お互いを認識できま せん。
  43. 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. 44 コンテナのファイルシステム コンテナAの ファイルシステム … … コンテナBの ファイルシステム /etc /bin /etc /bin / / / 以下の /etc /bin 等のディレ クトリを持つファイルシステムも同 様です。それぞれのコンテナは全くお 互いを認識できず、独立しているよ うに見えるのですが
  45. 45. 45 コンテナのファイルシステム コンテナAの ファイルシステム … … コンテナBの ファイルシステム /etc /bin /etc /bin / / / /etc /data /data/ubuntu /data/centos /bin 実際にはホスト上のどこかのディレ クトリをchrootしている様な状態 なのです。
  46. 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. 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. 48 Docker コンテナのライフサイクル このような仕組みはサーバ仮想化 とは全く違う仕組みのため、専用の 管理コマンドが存在します。
  49. 49. images イメージ・レイヤ(読み込み専用) コンテナ・レイヤ(読み書き可能) イメージ1の リポジトリ イメージ2の リポジトリ イメージnの リポジトリ … save load tartar import commit … Dockerfile build … tag rmi 削除したレイヤ inspect history レジストリ (Docker Hub) リポジトリ pull イメージ管理用コマンド
  50. 50. start イメージの リポジトリ コンテナ用 レイヤ作成 親子 関係 create diff プロセス (PID1) コンテナ内のプロセスやファイルシステム 追加 プロセ ス pause stop kill exec ps stats top attach logs inspect port restart run ホスト上の コンテナ 全体を管理 ホストから 各コンテナを 管理・操作 events コンテナの PID1を操作 rm pull レジストリ イメージ・レイヤ(読み込み専用) コンテナ・レイヤ(読み書き可能) 削除したレイヤ コンテナ管理用コマンド
  51. 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. イメージを作るには? 52 $ docker commit [コンテナID] [イメージ名:タグ] docker commit コマンド $ docker build –t [イメージ名:タグ] . docker bulid コマンド $ docker build –t [イメージ名:タグ] . Dockerfile ファイル Dockerイメージの作成も独特に 見える概念の1つですが、これもア プリケーションをいかに様々な場所 に移すかを考えたら、このような仕 組みになっています。
  53. 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コマンドは1つの コンテナしか扱えません。複数のコ ンテナを操作するためには、 Docker コンポーズというツールも 提供されています。
  54. 54. イメージを配るには? レジストリ(registry)はDockerイメージの保管場所 Dockerコンテナを実行するにはイメージが必要 イメージが保管されている場所をレジストリと呼ぶ レジストリは3種類 Docker Hub はパブリック・レジストリと呼ばれ、誰でも利用可能 Registry はプライベートで使える最低限のレジストリ機能 Docker Trusted Registry (DTR) は商用サポート版のプライベート・レジストリの位置付け 54 レジストリ Docker Engine Dockerイメージ そしてもう1つ、Dockerハブとい う、Dockerイメージの配布や自 動構築を行う仕組みも提供されて います。これも仮想化との違いです。
  55. 55. 55 うまく活用しますと、Zabbixの手 間が掛かるセットアップもコマンド 1つで実行できます。
  56. 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. 57. 変わるべき業務手順 開発環境では導入が進んでいると はいえ、プロダクションではまだまだ 途上という数値が出ています。これ はDocker導入によって、間違い なく運用フローや手順が変わってし まうからです。
  58. 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. 59 単にコンテナ化しても意味が無い のは、なんとなく皆さんもお気づき になってきませんでしょうか。単にコ ンテナが並んでいても、それでは全 く価値が生まれない。
  60. 60. 60 そうではなく、迅速に移動すること。 この写真なら、Dockerエンジンは 牽引車の役割であり、
  61. 61. 61 あらゆる場所へ、コンテナを運ぶ、 船という役割でもあります。
  62. 62. 62 最近「パイプライン」という言葉を耳 にするようになりました。
  63. 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. 64 個別要素としての技術云々ではな く、工場の生産ラインのように、全 ての工程を効率的に回す手段とし ての考え。Dockerも同じような 考え方、視点に立っています。この 視点がなければ、コンテナ技術を 導入しても「仮想化と変わらない」 「クラウドと変わらない」という話に なってしまいます。
  65. 65. コンテナだから全てを解決するので はない、というのも共有したいです。 現実的な課題はあります。
  66. 66. Dockerと課題 セキュリティ対策は従来と同じ べースの OS は通常の Linux ないし Windows なので、セキュリティ対応は欠かせない 従来の手法に比べ、更新しやすい(イメージの自動構築機能) Content Trust や Notary といった技術を利用しセキュリティを高める 運用や監視も特に変わらない Docker Engine の管理が必要になるが、その他は通常のサーバ管理と同じ Docker 導入が目的化すると方向を見失いがち リソース削減や集約が、そのまま開発・運用コストの削減にはつながらない
  67. 67. Dockerに不向きと思われる場面 リソース集約やコスト削減の目的 確かにリソースは集約できるかもしれないが、仮想化技術とは手法が違う 結果として業務フローの変更や Docker コンテナ変換作業が発生して、コストは増える 既存のシステムをそのまま移行 Docker は開発・テスト・運用のサイクルを加速する場合には有用 単純に Docker に対応しても速さや利便性を求めないのなら、結果として仮想化やクラウドと同じ そもそものシステム要件にあわない環境 厳密なセキュリティの確保や長期の安定性を求めるのであれば、別の適切なシステム検討を 全ての要件を満たす完璧なシステムは存在しない。トレードオフを考慮 ※ Dockerはインフラ(システム基盤)ではなく、あくまでアプリケーションのプラットフォーム
  68. 68. 68 Docker以外のコンテナ技術を使う選択肢 LXC LXD 他にも選択肢があるため、何をし たいかによって、使い分けではいか がでしょうか。
  69. 69. 69 物理サーバだけの時代 とある物理サーバ 故障すると大変 CPU メモリ ディスク 調達・管理コストの課題 基本、ハードウェア固定 オペレーティングシステム ミドルウェアやライブラリA B C アプリ 1 リソース有効活用のしづらさ たとえばリソースを有効活用したい のが目的であればMesosという選 択肢もあります。
  70. 70. 70 仮想化技術の時代 とある仮想サーバA とある仮想サーバB とある仮想サーバC OS ミドルウェア アプリケーション OS ミドルウェア アプリケーション OS ミドルウェア アプリケーション 時間 リ ソ ー ス 使 用 率 時間 時間 サーバが増減できるよ、やったね! アプリケーション アプリケーション アプリケーション 仮想化によって物理に比べればリ ソースを有効活用できますが、やっ ぱり勿体ないところがあります。
  71. 71. 71 思い描く理想 サーバ1台で3台分の仕事ができるよ、やったね! 本当にやりたいのは、これ
  72. 72. 72 とある仮想サーバA とある仮想サーバB とある仮想サーバC OS OS OS 時間 リ ソ ー ス 使 用 率 時間 時間 効率的に使えるよ、やったね! Mesosの出番 Apache Mesos アプリ アプリアプリ アプリ アプリ アプリアプリアプリ アプリ 動くアプリが増えるね!!
  73. 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. 74. 用途の見極め 結局の所、何のために導入したい のですか?という所に立ち返ります。
  75. 75. 75 改めて、コンテナだけでは意味が無 くて、それを動かす仕組みが必要だ から。技術面というよりは、業務面 なりビジネス上の価値追求に重点 が置かれることも多いでしょう。
  76. 76. 76 そして、いかに業務を回していくか。 効率的に速く開発サイクルを回す のであれば、Dockerが適してい る場面もあるでしょう。あるいは、 他のコンテナ技術なり、目的が適 わなければ仮想化・クラウド、ある いは物理でだっていいのです。結 局私たちは何を解決したいのか? という視点ではないでしょうか。
  77. 77. 振り返り
  78. 78. 使いどころの勘違い 仮想化≠コンテナ化 業務手順も変わる 色々な都市伝説化が進んでいると 思われますが、基本は目的なき技 術選定の結果ではと、個人的に 思っています。
  79. 79. コンテナは技術 Dockerは仕様 そして、Dockerを使うのは非常に 簡単です。使えるかどうか論じる前 に、まず手を動かして試してみませ んか?と主張したいです。
  80. 80. 課題は何であり 何を解決したいのか? そして現場によって解決したい課題 は違うはずです。技術ありきではな く、問題を解決するための手段とし ての技術だという心構えが必要で はないでしょうか。
  81. 81. 何か気になる所がありますか? ご参考:Docker 日本語ドキュメント http://docs.docker.jp/ http://slideshare.net/zembutsu twitter: @zembutsu 最後までありがとうございました。
  82. 82. まだ時間あります? 82
  83. 83. 83 Dockerの役割を再定義 導入コスト 高い 導入コスト 低い 運用コスト 低い 運用コスト 高い Public Cloud 基盤 Private Cloud 基盤 chef Ansible Docker 開発用 OpenShift Docker 運用系 kubernetes
  84. 84. 背景画像CREDIT:rvika/ PIXTA(ピクスタ) https://pixta.jp/@prof261092 2017年2月27日(月) @zembutsu Revision 2017.02 Dockerの誤解と疑問に答える 一問一答と技術Tips
  85. 85. とし-でんせつ【都市伝説】 • 『友達の友達』など身近なようで実際には顔も名前も分からない人々に起きた出来事として 語られる奇妙な噂話(松山ひろし氏) • 本当にあったとして語られる『実際には起きていない話』(宇佐話通氏) • 都市を中心に伝播していく都市伝説には、いくつかの特徴が挙げられる。 1. 過去の事件、事故に由来する 2. 場所に由来する 3. 発祥が不確定、或いは特定しづらい • 都市伝説の内容はいかにもありそうな話が殆どであり、 教訓めいた要素が盛り込まれている事も多い。 【参考】都市伝説 - Wikipedia https://ja.wikipedia.org/wiki/都市伝説
  86. 86. "楽して地雷を避けたい" "都市伝説化" • 個人的な情報の伝達は「噂」 • 事実が確認されないままに情報が人々の間を伝達 【参考】「噂」も消費するパワーゾーン 渋谷「都市伝説」はこうして生まれる? - シブヤ経済新聞 http://www.shibukei.com/special/69/
  87. 87. 1. 導入前の疑問  Dockerは全てを解決しない 2. 利用直後の困りどころ  ドキュメントを読もう 3. 運用面の課題  Docker以外の知見も必要
  88. 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. 89. 18. 定番のOSが無い。どれを選ぶべきか分からない 19. よく落ちる 20. ネットワークが貧弱だ 21. データの可用性が貧弱 22. データベースが重い、使えない 23. データベースやキャッシュサーバの用途にDockerは向かない 24. Dockerはディスク容量を無駄に消費する 25. コンテナが止まるとログが記録されない 26. Dockerfileのビルドに毎回かなり時間がかかる 27. 複数のコンテナを立ち上げるのは大変だ 28. マシンを再起動すると、コンテナで動かしていたサービスをまた起動する必要があるので面倒 29. Docker Registryは不安定だ。使い物にならない。可用性が無い 30. 英語のドキュメントを読むのが大変だ。日本語の情報が古い 利用直後の困りどころ
  90. 90. 31. 本番環境では使えない 32. DockerにはSLAが無いから使えない 33. Dockerは冗長化できない 34. Dockerは(運用チームにとって)学習コストが高い 35. 商用サポートを受けられない 36. 1サーバ1コンテナで運用すべきだ 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. 91. ネット上の日本語情報は古い場合がある 最新情報の見極めを 手を動かそう get.docker.com

×