鯨物語～Dockerコンテナとオーケストレーションの理解

鯨物語～Dockerコンテナとオーケストレーションの理解

1. 1. Dockerコンテナとオーケストレーションの理解 今なぜDockerなのか？何ができるのか？ 前佛雅人 @zembutsu Version1.1
2. 2. • Docker とは何で、どこで使うのか？ • Docker を動かす技術 • Docker コンテナとイメージ • オーケストレーション • 課題 • 導入事例 「今さら他人に訊けないDocker」 的な内容を目指しています。技術 要素というよりは、利用シーンや 使いどころの紹介が中心です。 本資料は公開時点(2016年6月) のものです。常に最新のドキュメン トをご確認願います。
3. 3. https://en.wikipedia.org/wiki/Moby-Dick 白鯨 – Moby-Dick 今回の私の立場は「Dockerはい いぞ」や「バスに乗り遅れるな！」 ではありません。 あるいは、Dockreとは鯨のマス コットですが、メルヴィルの「白鯨」 に出てきたような得体の知れない 白い悪魔ではありません。あるい は、エイハブ船長のように鯨に対し て何かしら執念めいたものは私に はありません。
4. 4. Docker Dockerが業務に使えそうならば 支援いたします。もし、あわなけれ ば無視いただいて結構です。あく までも選択肢の１つとして活用で きたらいいですね、という立ち位置 での説明です。 海に棲むのは鯨だけではないので すから。 https://www.docker.com
5. 5. Dockerとは？
6. 6. Dockerとは？ • アプリを構築・移動・実行するためのプラットフォーム • 設計思想は、開発者がアプリを簡単に動かす環境の構築 • オープンソース・プロジェクトを Docker, Inc. が支援 • Linux カーネル技術を使い、コンテナ化を実現
7. 7. “Docker allows you to package an application with all of its dependencies into a standardized unit for software development.” Dockerはアプリケーションと全ての依存関係をパッケージ化します。その ソフトウェア開発の全依存関係は、標準化したユニットに入っています。 www.docker.com
8. 8. アプリ ケーション 依存関係 システム基盤(インフラ) アプリケーションを実行するには、まず土 台としてのシステム基盤（インフラ）が 必要です。 その上に、ミドルウェアなどアプリケーショ ンを実行するための依存関係を準備し、 ようやくアプリケーションが動作します。 つまり、常にインフラを起点として考える 必要がありました。 • オペレーティング・システム [Linux|Unix|Windows] • ハードウェア、ネットワーク、ストレージ ［物理|仮想化|クラウド］ • ミドルウェア • 各種プログラミング言語環境や、システム・ライブラリなど • バイナリやソースコード • 設定用パラメータ application dependencies Infrastructure
9. 9. アプリ ケーション 依存関係 システム基盤(インフラ) 一方Dockerが目指す方向は逆です。 まず実行したいアプリケーションがあり、 それを簡単に実現する手段として、ア プリケーションとその依存関係を 「Dockerコンテナ」という単位で扱えるよ うにします。Dockerエンジンが動く環境 であれば、どのようなDockerコンテナも 実行可能なのです。 次ページ以降で、Dockerを詳しくみて いきましょう。 • オペレーティング・システム [Linux|Unix|Windows] • ハードウェア、ネットワーク、ストレージ ［物理|仮想化|クラウド］ • ミドルウェア • 各種プログラミング言語環境や、システム・ライブラリなど • バイナリやソースコード • 設定用パラメータ application dependencies Infrastructure Docker コンテナ Docker Engine (dockerd)
10. 10. Docker アプリケーションを開発・移動・実行するプラットフォーム 「開発者が簡単にアプリケーションを動かす環境を作る」設計思想が始まり 2013年3月に発表 Linuxカーネル技術でコンテナ化 名前空間(namespace)はプロセスやリソースを分離(独立)する コントロール・グループ(cgroup)はリソースの管理・制限する 開発状況 オープンソース (Apache License 2.0) コミュニティ(GitHub)を支援する Docker, Inc. コンテナ標準規格化団体 OCI と協調
11. 11. 2つのDocker Docker プロジェクト • 開発者やシステム管理者が、 アプリを開発・移動・実行する プラットフォーム • オープンソース • Docker, inc. はスポンサーと 商用サポートを提供 primary contributor, maintainer • イメージとコンテナを管理 • ホスト上で動くプロセス • Linux カーネルの技術を使う namespaces, cgroups, netfilter 等 Docker デーモンとツール群 プロジェクトとツール、どちらもDocker （ドッカー）と呼びます。技術サポート や支援をしているのがDocker社です。
12. 12. Docker, Inc. 商用Dockerソリューションの提供 開発・移動・実行を統合するソリューションと製品群 商用技術サポート 前身はPaaS 事業者 アプリケーション・プラットフォーム dotCloud、事業売却済 Dockerプロジェクトのスポンサー オープンソース版 Docker のプライマリ・コントリビュータ＆メンテナ 10億以上の Docker イメージのダウンロード 1,500 人以上の貢献者 20万以上の Docker 対応アプリケーション (p.11) 開発86%, テスト64%, … プロダクション40% http://offers.ruxit.com/rs/987-BEQ-874/images/State_of_Containers_Ruxit_compressed_V2.pdf (コンテナ技術利用者の割合)
13. 13. Dockerのミッション build ship run 分散システムやデータ解析など様々な システムやアプリケーションが提供されて います。しかし環境ごとに検証が必要 であり、どこでも必ず動く保証はありま せん。いかに速く動かすかが重要です。
14. 14. 変わる環境 暗黒^H^H物理時代 仮想化・クラウド時代 コンテナ時代 機 材 発 注 機 材 納 品 設 置 機 器 設 定 事 前 設 計 ク リ ッ ク 見 積 も り O S 設 定 環 境 構 築 試 験 利 用 開 始 試 験 開 発 試 験 運 用 利 用 開 始 … … 事 前 設 計 ク リ ッ ク 試 験 利 用 開 始 … 事 前 設 計 ク リ ッ ク 試 験 利 用 開 始 … 開 発 段 階 検 証 段 階 本 番 段 階 すべてを迅速に、一貫した環境で 仮装化技術により、物理に比べれば 迅速にアプリを動かせるようになりまし た。しかし、環境が増えた分だけ検証 も必要ですし、実行にも時間が必要。
15. 15. なぜ Docker は誕生したのか？ 物理から仮想化の流れ デプロイ時間が遅い、コストが大きい、無駄なリソースやスケールしづらさ ハイパーバイザ型仮想化基盤の登場で、１台のサーバ上で複数の仮想マシンを動かせる 仮想化からクラウドへ 仮想化はリソースの共有が優れており、スケールも簡単 必要な場面ですぐに仮想マシンを用意でき、使った分だけ支払うモデル 新たな課題 多くの仮想マシンを動かすには、より多くのリソースを必要 アプリケーションのポータビリティは保証しない インフラの視点であればリソースの集約 の延長線上に見えるかもしれません。 しかし、そうではなく、あくまでアプリを速 く簡単に「構築・移動・実行」に焦点を あてているのがDockerです。
16. 16. デプロイの悪夢 ウェブ・スタック ウェブ・フロントエンド バックグラウンド ワーカー ユーザ DB 解析 DB キュー 開発用 VM QA サーバ 本番用 サーバ クラスタ パブリック クラウド ノートPC お客さま サーバ 仮想化・クラウド技術の活用により、 様々な環境でシステムを動かすことは 可能です。ですが、それぞれの環境で、 デプロイの検証・時間・手間が必要。 それだけではなく、アプリケーションは 作って終わりではありません。今日のア プリケーションやサービスは、作った後も、 継続した開発や拡張が行われることが 増えつつあります。
17. 17. 現実世界の移動 これに似た課題が、現実世界における モノの輸送でしょう。運ぶモノや手段の 組み合わせは様々です。 様々な 種類の 「モノ」 輸送の 手段は 色々 「モノ」にお互いの 影響を与えず 運ぶには？ （例：コーヒーと 香辛料を運ぶ） 迅速かつスムーズ に転送可能か？ （例：船から貨 物列車への積み 替え時）
18. 18. コンテナ規格で問題解決 モノをコンテナという共通規格の中に入 れることで、移動手段が変わってもス ムーズに、かつモノに影響を与えません。 様々な 種類の 「モノ」 輸送の 手段は 色々 「モノ」にお互いの 影響を与えず 運ぶには？ （例：コーヒーと 香辛料を運ぶ） 迅速かつスムーズ に転送可能か？ （例：船から貨 物列車への積み 替え時） コンテナ規格により、事実上、あ らゆるモノを運ぶことができ、かつ 送り先には封印したままで届ける 長距離輸送中の積み込み、荷下ろし、 積み重ね、移動が効率的であり、 様々な輸送手段に切り替え可能
19. 19. Dockerコンテナ エンジンは様々なものを軽量・ 移動可能・自給自足的なコン テナにカプセル化できる 標準的なOS操作により、あらゆる ハードウェア・プラットフォームで仮想 的に一貫して実行可能 複数の 開発 スタック 複数の ハードウェア 環境 サービスとアプリ ケーションは適切 に通信可能か？ 迅速かつス ムーズに移動 可能か？ 静的ウェブサイト ユーザDB ウェブ・フロントエンド キュー 解析DB 開発用 仮想マシン QAサーバ お客さま データセンタ パブリックク ラウド プロダクション クラスタ コントリビュータ ノートPC アプリが必要なものをDockerコンテナと して扱えば、アプリの環境が変わっても、 スムーズな移動や実行ができます。
20. 20. ウェブ・スタック ウェブ・フロントエンド バックグラウンド ワーカー ユーザ DB 解析 DB キュー 開発用 VM QA サーバ 本番用 サーバ クラスタ パブリック クラウド ノートPC お客さま サーバ つまり、様々な環境の差異があったと しても、Dockerコンテナであれば、実行 に至るまでの検証の手間やデプロイ時 間を確実かつ短くできる得るのです。
21. 21. Docker が実現したこと ソフトウェアが必要な全てをファイルシステムに包む コード、ランタイム、システム・ツール、シスラム・ライブラリなど サーバにインストールする全てをイメージ化 どのような環境でも実行を保証 Docker イメージは、Docker エンジンの動く環境上であればどこでも実行可能 ソフトウェアを動かすのに環境構築やセットアップ作業は不要 軽量・オープン・安全 ホスト OS を必要としないためメモリはより少なく、イメージにはファイルだけなのでサイズが小さい 様々なインフラで動く Linux ディストリビューションや Microsoft Windowsをベースにする インフラとアプリケーションを分離
22. 22. このDockerコンテナは、開発者だけでな なく、運用担当者でさえも、開発・移 動・実行の各場面で利用できます。 開発 バージョン 管理 1. 開発 2. テスト 3. ステージング / 本番 QA / QE 運用担当
23. 23. 他にも、商用製品のトラステッド・レジス トリやユニバーサル・コントロール・プレーン を使えば、インフラごとにアプリケーション の連携・切り替えも可能になるでしょう。 対応前 Docker対応後 アプリケーション・チーム ユニバーサル・コントロール・プレーントラステッド レジストリ
24. 24. Docker Datacenter 必要があれば、DTR(DockerTrusted Registry)、UCP(UniversalContorl Plane)を組みあわせることも。 クラウドの ポータビリティ アプリの ポータビリティ アプリで必要なプライベートなデータセンタ あらゆるアプリが対応するクラウド リソースのプロビジョン(自動設定) ロールベースアクセス制御(RBAC) トラステッド・レジストリ上に アプリケーションのテンプレート 中央ポータル
25. 25. 仮想マシン vs Docker、ではない コンテナはプラットフォームに依存しない コンテナであれば、ある環境で構築したら、別の環境に迅速に移動可 Dockerイメージはソフトウェアのスケール（増減）を迅速かつ簡単に コンテナは OSとアプリを明確に役割分担 開発者はアプリケーション開発に集中、運用担当はデプロイ作業や運用に集中 仮想化は手軽に厳密なリソース管理が可能 仮想化システムの利用には業務手順の（大きな）変更を伴わない リソースの集約と管理がやりやすい 開発単純な比較は無意味 システム基盤としてのコンテナ導入や、コスト削減・省力化の視点でのコンテナ化は意味が無い さて、ここで皆さんの中で１つの疑問が 浮かぶかもしれません。これまでのコンテ ナの使いどころとは、仮想化と同じなの では？と。 機能的には似通っている部分もありま すが、それを実現する手法や利用シー ンは異なります。どちらが優れているか 否かではなく、用途に応じた使い分け や、双方の組み合わせが効果的です。
26. 26. 仮想化 Docker コンテナ 独立した環境 仮想ハードウェア Dockerイメージ リソース集約 様々なOSが動作 Linux kernel 技術を活用 ※ Dockerコンテナは、アプリケーションが複数サーバにスケール する前提なら、環境の繰り返し作成・廃棄を高速に行える ※ スケールが必要なければ、必要なハードウェアや OS に あわせた環境を自由に構築できる • プロセスは namespace を通して PID 、 ファイルシステムなど、様々な名前空間を分離 プロセスを起動後、瞬時に分離かつリソースを制限可能 な点が仮想化と似て見えますが、実装や仕組みや操作 性は全く異なる。 • Control groups の機能を使い、１つ１つの コンテナ(Linuxのプロセス) に対して CPU、メモリ、 I/O の制限をかけられます 使い捨て型 (再利用性) 共通要素 • ハイパーバイザ型もしくはホスト型の仮想化 技術により仮想マシンを実行 • ハイパーバイザ技術により仮想マシンを実行 インフラのコード化 • Dockerfile や docker-compose.yml で 確実にアプリが動作する環境再現性を管理 • 階層化したイメージ・レイヤにファイルシステムや メタデータを格納 • 親子関係により、ディスク容量節約や移動高速化 • 厳密なリソース定義や確実な環境分離を 提供 環境の移行がスムーズ • サーバ管理する業務フローが確定しているの であれば、変更しなくてもシステムの移行や 集約をしやすいので、導入しやすい • Windows / Linux など選べる • 32bit / 64bit などアーキテクチャを選択できる 自由度の高いハードウェア・エミュレーションや 管理性を提供する。
27. 27. プラットフォームとしての Docker システム要件としては、Dockreを動かす ためにDockerエンジン(dockerd)が必 要であり、現状ではLinuxカーネル機 能を必要とします。
28. 28. Dockerが適している環境 開発速度を加速 Docker コンテナ化は直ちに起動するので、セットアップや環境構築に時間を浪費しない 本来のアプリケーション開発、バグ修正、新機能追加に集中 開発者の想像力を強化 適切な言語環境の選定と構築が可能 ホスト環境上の OS やライブラリの整合性を考慮しなくてよい 環境の矛盾や依存の問題を撲滅 アプリケーションの依存関係や設定を、コンテナ（イメージ）に包み込める 「私の環境では動くけど、別の環境では動かない」問題は、もう起こらない
29. 29. Dockerを動かす技術
30. 30. Dockerを動かす技術 • Docker Engine (dockerd) がリクエストを受信後、各種処理 • 名前空間(namespace)はプロセスごとに独立した環境を作る • コントロール・グループ(cgroups)はリソースを制限・管理 • Linux カーネル技術や業界共通の規格を採用
31. 31. Docker と Linux カーネル Docker Engineはコンテナを移動・実行するプログラム Engine (dockerd) はデーモン（サーバ）であり、Linux カーネルとクライアントとの処理を仲介 Dockerコンテナ ホスト OS のカーネル機能を使い、複数のルート・ファイルシステムを実行 コンテナは個々のリソース（CPU、メモリ、デバイス、ネットワーク）を持つ Dockerコンテナの実行にはDockerイメージが必要 コンテナの起動は、Linuxカーネルの技術を使う 名前空間（namespace）は、プロセス間を分離、独立（isolation） コントロール・グループ（cgroup）は、CPU、メモリ、I/Oなどのリソース管理と制限 技術について軽く触れます。Dockerコ ンテナを実行するにはDockerエンジン が必要です。現状はLinux上で動作。
32. 32. Docker に影響を与えた技術 chrootシステム・コール 1979年 Version 7 Unix で実装が計画 特定のプロセスとその子プロセスに対して、見かけ上のルート・ディレクトリを指定 jail 2000年 FreeBSD 4.0 のリリース Linux Containers (LXC) 2008年 Linux kernel 2.6.24 で実装 Docker内部で使う技術は、突然新し く湧き出てきた技術ではありません。古 くからのリソース独立(isolation)を実現 する各種技術の延長上にあります。
33. 33. Docker Engine Linux Kernel ・namespaces ・cgroups ・capabilities … etc LXC libcontainer runC containerdv0.9～ v1.11～ Version 7 Unix chroot jail dockerd v1.12～ DockerEngineはLinuxカーネルにアク セスするため、従来はLXCを使っていま した。開発速度の都合上、一時的に 独自実装をしていました。 現在は業界標準化団体の仕様に則 る、互換ランタイムで実行可能です。 デーモン ライブラリ ランタイム
34. 34. コンテナ標準規格 OCI : オープン・コンテナ・イニシアティブ 共通のコンテナ規格を策定する業界標準化団体が 2015 年夏に発足 Docker, Inc. が libcontainer のライブラリを供与 Amazon、Microsoft、IBM 等のクラウド・ベンダをはじめ、Red Hat や Docker も参画 https://www.opencontainers.org/ Dockerの独自仕様ではない Docker コンテナも OCI に準拠した規格に対応 (v1.11～ runC を採用) OCI 準拠のランタイムであれば、コンテナごとに任意に切り替え可能 (v1.12～) コンテナ利用はベンダ・ロックインにつながらない Docker を中心としたエコシステムも拡がりつつある コンテナの仕様は、もはやDocker社の ものではありません。Docker社は共通 規格化への取り組みを進めています。 規格に則る他のランタイムもDocker 上でも実行可能になりつつあります。
35. 35. Dockerコンテナとイメージ
36. 36. Dockerコンテナとイメージ • コンテナはLinux ホスト上で独立しているプロセス空間、等 • Dockerイメージを使って、コンテナを起動する • Dockerイメージは親子関係のあるレイヤ(層)の積み重ね isolation もう少しだけ技術的な話題が続きます。 どうしてコンテナを起動するのが速くて、 他の場所へ移動するのも速いのか？と いう問いに対する答えがこちらです。
37. 37. Docker の操作 OS ( Linux ) 物理/仮想サーバ Docker エンジン ( dockerd デーモン ) Linux kernel コンテナ コンテナ コンテナ リモート APIdocker クライアント ・docker コマンド Linux, Mac OS X, Windows ・Kitematic (GUI) Mac OS X, Windows ・Docker Compose ・Docker Swarm TCP あるいは Unix ソケットドメイン Dockerはクライアント・サーバ型アプリ ケーションです。Dockerコンテナを起動 するには、Dockerエンジンが必要です。
38. 38. httpd PID 1 コンテナA コンテナB ruby PID 1 chris.rb PID 2 コンテナのプロセス それでは、コンテナを起動した時のプロ セスの状態を見てみます。ここでは２つ のコンテナを起動しました。 それぞれのプロセスのPIDが「1」になって います。各プロセスは名前空間が独立 しているため、お互いのことを知ることが できません。つまり、２つの独立したコン テナが起動している状態です。
39. 39. コンテナのプロセス httpd PID 1 コンテナA コンテナB ruby PID 1 chris.rb PID 2 /sbin/init PID 1 dockerd PID 4 httpd PID 5 ruby PID 6 chris.rb PID 7 alice PID 2 bob PID 3 PPID 1 PPID 1 PPID 1 PPID 4 PPID 4 PPID 6 しかし、あくまで独立して見えるのはお 互いのコンテナ（で独立したプロセスの 名前空間）内だけです。実際のLinux ホスト上からは、通常通りプロセスが起 動している状態にすぎません。また、ホ スト上からは通常のPIDを持っているよ うにも見えます。 Dockerは、このコンテナ状態のプロセス に対し、リソース制限やファイルシステム の割り当て、ネットワーク指定が可能。
40. 40. コンテナのファイルシステム コンテナAのファイルシステム … … コンテナBのファイルシステム /etc (/data/ubuntu/etc) /bin (/data/ubuntu/bin) /etc (/data/centos/etc) /bin (/data/centos/bin) / / ファイルシステムの場合も、やはりコンテ ナごとにLinuxの「/」以下のファイルシ ステム(/bin,/etc,/var…)を持っている ように見えます。そして、お互いのコンテ ナは独立していますので、通常は互い にアクセスできません。
41. 41. コンテナのファイルシステム コンテナAのファイルシステム … … コンテナBのファイルシステム /etc (/data/ubuntu/etc) /bin (/data/ubuntu/bin) /etc (/data/centos/etc) /bin (/data/centos/bin) / / / /etc /data /data/ubuntu /data/centos /bin そして、コンテナのプロセスがホスト側か らは普通に見えたのと同様、コンテナの ファイルシステムも、実体としてはホスト 側に特定のディレクトリ（正確にはユニ オン・マウント・ポイントと呼ばれる複数 のディレクトリを１つのディレクトリに見 せる技術）があります。 そこをコンテナ状態のプロセスに対し、 ファイルシステムをchrootしているような 状態です。
42. 42. Docker イメージ コンテナ実行時に必要なファイルシステム イメージ・レイヤ（層）の集合体。実体は tar アーカイブ 読み込み専用で変更できない イメージはレイヤを共有できる レイヤには親子関係があり、イメージ構築時は差分を記録 無駄なディスク両々の増加を防ぎ、移動しやすく コンテナ起動時、イメージを使う コンテナ内のファイルを隔離した状態で実行する 読み書き可能なレイヤをイメージの上に追加する それではDockerイメージとは何でしょう か。ポイントはDVDやBlu-rayのように 読み込み専用な点と、レイヤごとに共 有できる点。特に後者は、合計ディス ク容量を減らします。ネットワークを経 由しても、コスト面・速度面で移動しや すくなる利点。仮想化はこれが大変。
43. 43. $ docker pull ubuntu Using default tag: latest latest: Pulling from library/ubuntu 203137e8afd5: Pull complet 2ff1bbbe9310: Pull complete 933ae2486129: Pull complete a3ed95caeb02: Pull complete Digest: sha256:1bea66e185d3464fec1abda32ffaf2a11de69833cfcf81bd2b9a5be147776814 Status: Downloaded newer image for ubuntu:latest/ Ubuntuのイメージは４つのレイヤが重 なっています。新しくコンテナを起動する と、この上に読み書き可能なレイヤが 自動的に追加されます。 そのため、コンテナを沢山同時に起動し ても、多くのディスク容量を必要としま せんし、起動に必要な時間は瞬間的 です（ほぼ、読み書き可能なレイヤを 追加するだけ）。
44. 44. $ docker pull wordpress Using default tag: latest latest: Pulling from library/wordpress fdd5d7827f33: Already exists a3ed95caeb02: Download complete 8c80f2e38113: Download complete 2da85bfb1ac0: Download complete 1da50ec818af: Download complete b2799c7ad5c9: Downloading 1.113 MB/2.844 MB 4893554c0107: Download complete b1d739e1b940: Waiting bd103e3f6195: Waiting aa560ff33ce6: Waiting 1deabfa10759: Waiting 91e6991f7a34: Waiting 7234c82b998e: Waiting 6bf8bdf2e550: Waiting a5c7e6ead07c: Waiting fe011342f195: Waiting c6dd706ba27e: Waiting 35d564cafd69: Waiting 730edfa5d07f: Waiting Digest: sha256:bfd7e102741d73cce4ec58b2d937586c670f31df1c80aeaf4d5c525eb3c6ac06 Status: Downloaded newer image for wordpress:latest イメージによっては、このように多くのレイ ヤが重なっているものもあります。イメー ジ・レイヤは並列に送受できるだけでな く送信も可能です（デフォルトは３）。
45. 45. Demo https://youtu.be/bHEgg9Hg8LM Docker コンテナの起動デモです。 Docker Machine で Docker の動く環境を構築し、 hello-world コンテナ、nginx コンテナを起動します。
46. 46. オーケストレーション
47. 47. オーケストレーション • Docker コンテナのライフサイクルは１コンテナ前提 • 複数の Docker コンテナや Docker の動作環境を一斉管理 するための純正ツール群 • いずれもオープンソース・プロジェクトとして公開 もう少しだけ技術的な話題が続きます。 どうしてコンテナを起動するのが速くて、 他の場所へ移動するのも速いのか？と いう問いに対する答えがこちらです。
48. 48. Dockerコンテナのライフサイクル Dockerイメージとコンテナを管理するコ マンドは、こちらの画面にある通りです。
49. 49. Engine $ docker run … $ docker run … $ docker run … $ docker run … 一般的なアプリケーションでは、ウェブ用 インターフェースとデータベースなど、複数 のコンテナを起動する必要があるでしょ う。そのような時、毎回dockerコマンド を実行するのは大変です。
50. 50. Engine $ docker-compose up これをDockerComposeというクライア ントを使えば、複数コンテナの同時起 動・停止が可能になります。scaleコマ ンドを使えば、コンテナを一斉に増やし たり減らしたりも可能です。
51. 51. $ docker run … $ docker run … $ docker run … そして、もう１つ。複数のサーバ上で Dockerを分散して実行したい場合が 考えられます。例えばウェブとデータベー スを分けたい場合です。その時に都度 SSHログインしたり、環境を切り替えた りするのではなく
52. 52. $ docker run … $ docker run … $ docker-compose up … リクエスト先をDockerSwarmマネー ジャに向けることで、複数のDocker環 境を１つのリソース・プールとみなせます。 Dockerクライアントの接続先を変更し なくても、ルールに従ってコンテナの起動 や管理を可能とします。また、Swarm とComposeは組み合わせ可能です。
53. 53. version: '2' services: zabbix-db: image: zabbix/zabbix-db-mariadb volumes: - zabbix-db-storage:/var/lib/mysql - backups:/backups - /etc/localtime:/etc/localtime:ro environment: - MARIADB_USER=zabbix - MARIADB_PASS=my_password zabbix-server: image: zabbix/zabbix-3.0:latest depends_on: - zabbix-db ports: - "80:80" - "10051:10051" volumes: - /etc/localtime:/etc/localtime:ro links: - zabbix-db:zabbix.db environment: - ZS_DBHost=zabbix.db - ZS_DBUser=zabbix - ZS_DBPassword=my_password volumes: zabbix-db-storage: driver: local backups: driver: local Composeの具体例をみていきましょう。 こちらはZabbixという監視ツールの実 行に、２つのコンテナ、２つのボリューム と呼ばれるデータ領域を作ります。
54. 54. Demo https://youtu.be/uhwrRj-vNzc Zabbix 3 コンテナの起動デモです。 Zabbix 3 は RHEL7 以上の OS に慣れる必要があります。 Docker があれば、環境の差違を気にしなくても構いません。 Zabbix 3 の操作にのみ集中できます。
55. 55. 課題
56. 56. Docker と課題 セキュリティ対策は従来と同じ べースの OS は通常の Linux ないし Windows なので、セキュリティ対応は欠かせない 従来の手法に比べ、更新しやすい（イメージの自動構築機能） Content Trust や Notary といった技術を利用しセキュリティを高める 運用や監視も特に変わらない Docker Engine の管理が必要になるが、その他は通常のサーバ管理と同じ Docker 導入が目的化すると方向を見失いがち リソース削減や集約が、そのまま開発・運用コストの削減にはつながらない とはいえ、Dockerは、物理→仮想化・ クラウドの延長線上には無いため、多く の場合で業務フローの変更を伴います。 逆に変更を伴わず、加速する可能性 があればDockerは適していると言える でしょう。
57. 57. Dockerに不向きと思われる場面 リソース集約やコスト削減の目的 確かにリソースは集約できるかもしれないが、仮想化技術とは手法が違う 結果として業務フローの変更や Docker コンテナ変換作業が発生して、コストは増える 既存のシステムをそのまま移行 Docker は開発・テスト・運用のサイクルを加速する場合には有用 単純に Docker に対応しても速さや利便性を求めないのなら、結果として仮想化やクラウドと同じ そもそものシステム要件にあわない環境 厳密なセキュリティの確保や長期の安定性を求めるのであれば、別の適切なシステム検討を 全ての要件を満たす完璧なシステムは存在しない。トレードオフを考慮 ※ Dockerはインフラ（システム基盤）ではなく、あくまでアプリケーションのプラットフォーム 時に挑戦が必要なシーンもありますが、 必要な理由がないのに導入してしまう と、大変になりがちと思います。
58. 58. • Dockerはプラットフォームであり、全てを解決しない • Dockerコンテナのライフサイクルに対する理解が必要 • 検討要素 • 最終的な利用者は誰なのか • 業務範囲や用途は何なのか
59. 59. •詳細は別資料をご覧ください コンテナ技術と普及がシステム・インテグレータに与える影響 http://www.slideshare.net/zembutsu/docker-impact-to-system-integrations
60. 60. 事例
61. 61. Dockerの導入目的 引用：The State of Containers and the Docker Ecosystem 2015 (Anna Gerber) http://offers.ruxit.com/rs/987-BEQ-874/images/State_of_Containers_Ruxit_compressed_V2.pdf システム基盤として単に導入しましたで はなく、何らかの課題があり、それを解 決する手段としてのDockerです。以 降で具体的な事例をみていきます。 なぜコンテナ技術を選択したか？ 現時点でどの環境でコンテナを使用中か？ 速い/簡単なデプロイ デプロイの柔軟性 優れたアイソレーション アーキテクチャ的な理由(マイクロサービス) コスト節約 その他 開発 テスト インテグレーション (CIビルド・ターゲット) ステージング/準プロダクション プロダクション
62. 62. ING社 (オランダの銀行) 課題 プロダクションへのデプロイに９か月以上 評価の低いアプリケーション 冗長な手続きやアプリケーション 解決策 Dockerで継続的インテグレーションと、DevOpsを導入 結果 デプロイまで15分、週に1,500デプロイ 180の DevOps チーム、継続的デリバリに4か月で移行
63. 63. GILT - 100デプロイ/日 課題 開発からデプロイまで1週間 ７つのモノリシックなアプリケーション IaaSやPaaS上でモノリシックな実装に時間がかかる 解決策 Dockerで継続的インテグレーション 結果 開発からデプロイまで数分 400以上のマイクロサービス、毎日100以上の改善 ショッピングのピーク時は、クラウド上で簡単に拡張
64. 64. BBC – CIの時間を60%カット 課題 CIの処理に最低でも30分 ジョブ処理に失敗すると、待たなくてはいけない 回避策がない 解決策 Docker、Jenkins、AWS で継続的インテグレーション 結果 スケジュールの待ち時間を解消、ジョブの時間を10分に短縮 ジョブ処理を並列化、標準化と柔軟さ
65. 65. Capital One – 迅速なサービス・デリバリ 課題 特定ベンダー・ロックイン 様々なツール間の軋轢 ローカル・テストの欠乏やツールのガバナンス 解決策 Docker サブスクリプション 結果 素早いプロトタイピングと、迅速なサービス・デリバリ 安定性の向上と、リソースの分離 新しいツールの評価と導入までの時間短縮 より小さく機能的なチームを構成
66. 66. NECソリューション・イノベータ株式会社 http://microsoftdevops.github.io/devops/2016/05/27/NEC.html
67. 67. まとめ
68. 68. まとめ アプリケーションを開発・移動・実行するプラットフォーム 始まりは「開発者が簡単にアプリケーションを動かす環境を作る」設計思想 ソフトウェア実行に必要なすべてを１つのパッケージにまとめ、どこでも開発、移動、実行できる 現時点ではLinuxカーネル技術を使用 名前空間とコントロール・グループを使うので、独自仕様・規格ではない Docker イメージを使い、プロセスを隔離し、リソースを限定して Docker コンテナを起動する 実運用を支えるオーケストレーション・ツール群がある Docker導入が目的化しては意味がない これまでのサーバ管理や運用における課題を、改めて注目する必要がある Dockerは従来のインフラ面の課題を全て解決するものではない（いわゆる、銀の弾丸ではない）
69. 69. 質疑応答 • 何か気になる所はありますか？ • Docker日本語ドキュメント http://docs.docker.jp • @zembutsu or m.zembutsu@gmail.com 私としては、まずDockerのドキュメント をお読みいただければと思っています。 これは私の個人プロジェクトで、できるだ け最新バージョンの日本語版ドキュメン トを共有したいです。GitHubでリポジト リを公開していますので、お気づきの点 等ありましたら、ご指摘いただけますと 幸いです。