コンテナ技術と普及がシステム・インテグレータに与える影響
47 likes7,734 views
コンテナ技術と普及がシステム・インテグレータに与える影響 2016年3月4日(金) IDFフロンティア セミナールーム NCWC第35回会合 発表資料 【テーマ】『Dockerのクラウドビジネス利用の勘所』
コンテナ技術と普及がシステム・インテグレータに与える影響
- 1. Docker概要：コンテナ技術と普及が システム・インテグレータに与える影響 2016年3月4日(金) @zembutsu Technology Evangelist; Creationline, Inc.
- 4. 2016年3月4日(金) 第35回NCWG発表資料 @zembutsu Technology Evangelist; Creationline, Inc. コンテナ時代にシステムインテグレータが この先生きのこるには？
- 7. 本資料の想定読者 • 営業）お客さまが「Docker」を使いたいと言われたら？ • 上長）部下が「Docker」を使いたいと言ってきたら？ • 現場）上長・役員に「Docker」を使うべきと伝えるには？ ・
- 8. 本資料における主張 • 「Docker」を導入するだけでは価値を生まない。 • 「Docker」は技術選択要素の１つにすぎないので、 業務フローに一致するならば、積極的に導入すべきだ。 • 継続的な技術評価を行うべきだ。 ・
- 14. 本スライドの内容 • 10分で分かる「Docker」の世界 • なぜDockerが必要なのか、業務に何をもたらすのか？ • 導入時の技術選択要素と誤解（都市伝説） • 質疑応答
- 16. 10分で分かるDockerの世界 1■□□□ What is the "Docker" ?
- 18. docker ※Docker Glossary https://docs.docker.com/engine/reference/glossary/ Docker プロジェクト Docker デーモン • 開発者やシステム管理者が、 アプリを開発・移動・実行する プラットフォーム • Docker, inc. はスポンサー primary contributor, maintainer • イメージとコンテナを管理 • ホスト上で動くプロセス • Linuxコンテナ技術を使う namespaces, cgroups
- 19. Docker, Inc. Docker • • (Docker, IBM) Docker • Docker • 10 • 1500 • 200,000 Docker Gerber, Anna. “The State of Containers and the Docker Ecosystem: 2015” O’Reilly, September 2015 40%
- 22. BUILD SHIP RUN Docker Hub or Trusted Registry Cloud or Private Infrastructure Plugins: Network, Volume, Clustering Management UIDocker Toolbox 「Docker」とは、アプリケーションを動かすための仕組みを提供 プラットフォーム
- 24. サーバ OS のカーネル空間 Docker サーバ ユ ー ザ プ ロ セ ス ユ ー ザ プ ロ セ ス ユーザ空間 ユ ー ザ プ ロ セ ス ユーザ空間 • Cgroups • Namespaces mount UTS IPC PID Network User コンテナ https://hub.docker.com/ Docker Hub (レジストリ) Docker クライアント "docker" デーモン TCP:2375,TCP:2376(TSL),UnixSocket Ubuntu レポジトリ MySQL レポジトリ tag:latest tag:14.04 … tag:latest tag:5.7 …docker run … Docker Engine
- 25. docker
- 26. Engine $ docker run … $ docker run … $ docker run … $ docker run …
- 28. $ docker run … $ docker run … $ docker run …
- 29. $ docker run … $ docker run … $ docker run …
- 30. tutum https://www.tutum.co/ Docker社が買収(2015年10月) AWS, Digital Ocean, Azure, SoftLayer, Packet と連携 コンテナのデプロイと管理 Docker Hub を補完する役割
- 32. DTR Docker Trusted Registry Orca (beta) + UCP Universal Control Plane より安全にコンテナを実行 https://www.docker.com/universal-control-plane
- 33. Amazon Web Services Google Cloud Platform Windows Azure SoftLayer Niftyクラウド さくらのクラウド Salesforce Heroku DigitalOcean LinodeさくらのVPS VMware Circle CI Jenkins GitHub Slack NewRelic Datadog IaaS パブリック・クラウド PagerDuty Atlas Cloud n クラウドを取り巻く業界俯瞰図 Mackerel OpenStack CloudStack
- 34. OpenStack CloudStack Mackerel Amazon Web Services Google Cloud Platform Windows Azure SoftLayer Niftyクラウド さくらのクラウド Salesforce Heroku DigitalOcean LinodeさくらのVPS VMware Circle CI Jenkins GitHub Slack NewRelic Datadog IaaS パブリック・クラウド 日本国内 パブリック クラウド VPS PagerDuty Operations CI PaaS Atlas プライベート クラウド 開発環境 SaaS Cloud n クラウドを取り巻く業界俯瞰図 Monitoring
- 35. OpenStack CloudStack Mackerel Amazon Web Services Google Cloud Platform Windows Azure SoftLayer Niftyクラウド さくらのクラウド Salesforce Heroku DigitalOcean LinodeさくらのVPS VMware Circle CI Jenkins GitHub Slack NewRelic Datadog IaaS パブリック・クラウド 日本国内 パブリック クラウド VPS Monitoring PagerDuty Operations CI PaaS Atlas プライベート クラウド 開発環境 SaaS Cloud n Docker ( Linux Containers) クラウドを取り巻く業界俯瞰図
- 36. OpenStack CloudStack Mackerel Amazon Web Services Google Cloud Platform Windows Azure SoftLayer Niftyクラウド さくらのクラウド Salesforce Heroku DigitalOcean LinodeさくらのVPS VMware Circle CI Jenkins GitHub Slack NewRelic Datadog IaaS パブリック・クラウド 日本国内 パブリック クラウド VPS Monitoring PagerDuty Operations CI PaaS Atlas プライベート クラウド 開発環境 SaaS Cloud n Docker ( Linux Containers) クラウドを取り巻く業界俯瞰図
- 37. APCERA Cloud Foundry shippable Google Container Engine Amazon EC2 Container Service IBM Containers on Bluemix コンテナを取り巻く業界俯瞰図 開発環境 Build / Deploy 運用自動化 Orchestration kitematic Etcd SkyDNS Service Discovery Docker fleet flannel rkt CoreOS Tectonic Mesosphere Apache Auora Marathon Cluster Management Kubernetes 構成管理 Docker Swarm Docker Machine Docker Compose Docker特化OS PaaS Networking コンテナ管理用プラットフォーム
- 38. パブリック・クラウド陣営 Google Container Engine Amazon EC2 Container Service IBM Containers on Bluemix Google Kubernetes Tectonic CoreOS 商用サポート／エンタープライズ 管理・効率化 Docker ネイティブサポート 最小環境 Docker 競合 オープンソース コミュニティ
- 39. 39 DockerCon 2015 から流れが変わる ‣ Docker, Inc.主催 サンフランシスコ 6月22日・23日の2日間 セッション、ハンズオン、 トレーニング、ブース出展 http://www.dockercon.com/
- 40. Google Kubernetes CoreOS× libcontainer 廃止 The Open Container Project (OCP) runC Orchestration PROJECT ORCA appcは独自に継続 Linux Foundation 事務局として協力 Google Container Engine IBM Containers on Bluemix Amazon ECS
- 42. ここまでのまとめ • Dockerは組織でもあり、技術でもある • 簡単にアプリケーションを開発・移動・実行するための プラットフォームを提供する（≠インフラ） • Dockerには用途に応じた様々なツールが存在する • Dockerを中心としたエコシステムが形成されつつある
- 43. なぜDockerが必要になったのか？ 2■■□□ Why we need "Docker" ?
- 44. ご注文はコンテナですか？ Is the order a container?
- 45. ご注文はコンテナですか？ Is the order a container?
- 46. 物理サーバ・ネットワーク環境の全盛時代 開 発 用 端 末 社 内 サ ー バ デ ー タ セ ン タ ftp, rsync, scp
- 48. 突然の死
- 49. 仮想化・クラウド時代 開 発 用 端 末 社 内 サ ー バ ク ラ ウ ド 環 境 VirtualBox VirtualBox VirtualBox Virtual Machine Virtual Machine Virtual Machine Virtual Machine Machine Image Virtual Machine Machine Image 開 発 用 C I ス テ ー ジ ン グ 本 番 Virtual Machine Virtual Machine Virtual Machine 構成管理ツール (Chef, Puppet, Ansible, Itamae… etc.) デプロイ支援ツール (Capistrano, Vagrant, Packer, Terraform, AWS CLI … etc.) ftp, rsync, scp
- 52. 暗黒^H^H物理時代 仮想化・クラウド時代 コンテナ時代 機 材 発 注 機 材 納 品 設 置 機 器 設 定 事 前 設 計 ク リ ッ ク 見 積 も り O S 設 定 環 境 構 築 試 験 利 用 開 始 試 験 開 発 試 験 運 用 利 用 開 始 … … 事 前 設 計 ク リ ッ ク 試 験 利 用 開 始 … 事 前 設 計 ク リ ッ ク 試 験 利 用 開 始 … 開 発 段 階 検 証 段 階 本 番 段 階 すべてを迅速に、一貫した環境で行いやすい← New
- 53. 社外開発環境 本番環境ステージング環境 社内共有開発環境 個人開発環境 社内テスト環境 社外開発環境 本番環境ステージング環境 CI/CD Docker レジストリ Docker動作環境(docker machine)
- 54. ここまでのまとめ • 迅速な業務フローが求められている • ハードウェア視点：インフラを迅速かつ継続的に使いたい • ソフトウェア視点：継続的な開発・運用を続けたい
- 56. ？？？「すべてがコンテナになる」
- 58. 58 Dockerコンテナのライフサイクル ※ Docker Docs より引用：https://docs.docker.com/engine/reference/api/docker_remote_api/ まずは、ライフサイクルの 理解です。バッチ的なコマ ンド処理もサービスとしての 常駐も可能です。
- 59. 59 ‣ 開発環境のみ ‣ 開発環境 ～ CI / テスト環境 ‣ 開発環境 ～ 本番環境 利用シーンの範囲を検討 Dockerの基本的ライフサイクル やコマンドの使い方などの理解 は前提として、次に、どのような 場面でDockerを使うのかで視点 が変わってきます。
- 63. 63 検討項目 1. 利用者は誰で、用途は何か？ 2. インフラをどうするのか？ 3. OSを何にするのか？ 4. ディストリビューションを何にするのか？ 5. ストレージ・ドライバを何にするのか？ 6. ベースイメージは何にするのか？ 7. セキュリティをどのように考慮すべきか？ 8. 性能をどのように担保するのか？ ★重要な警告★ 本章に含まれる以降の検討要素 は私個人の見解であり頻繁にい ただく質問に対する一般的見解 をまとめたものです。所属会社 およびDocker, Inc. の意見を代 表するものではありませ。また、 Docker 1.10 現在の情報です。 今後の Docker のバージョンに よっては判断材料として適切では ない場合が有り得ます。常に、 最新情報をご確認願います。
- 64. 64 ‣コンテナを誰が使うのか？ 開発チーム？ 運用チーム？ テスト？ 検証？ コミュニティ？ 自社内？ お客さま？ ‣何のために使うのか？ システム開発？ 運用？ 商用サービス？ 検証？ 技術選択にあたっての基本ポイント まず始めに誰が何のために使う のか？という視点が必須です。
- 65. たとえばピザで考えてみます！
- 69. 利用者や目的が定まれば、インフラに何を使うべきか は自ずと決まると思われます。利用シーンであったり、 環境によって異なるでしょう。どれが優れているか優 れていないかは、個々のユースケースに依存します。
- 70. 70 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 ‣ ベンダーによる保守サポート有無 ‣ コミュニティによるサポートの有無
- 71. 71 ‣ 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-maintenance ストレージ・ドライバ ストレージ・ドライバを何にする かはDocker独特の判断ポイント です。こちらもどのような用途に 使うのか、あるい経験を持ってい るかによって異なります。
- 73. 73 コピー・オン・ライト方式 ‣ CoW; Copy on Write • 効率的にイメージを使う仕組み 1. ファイル更新が発生する（初回） 2. イメージからコンテナ用領域に ファイルをコピーする 3. コピーしたファイルを編集 CoW処理がパフォーマンスに影響 デバイス・ドライバの選択により 挙動が異なるので注意が必要 なぜならDockerはイメージ管理 に独特の処理を行っているため。 詳細：イメージ、コンテナ、ストレージ・ドライバの理解 — Docker-docs-ja 1.10.0b ドキュメント http://docs.docker.jp/engine/userguide/storagedriver/imagesandcontainers.html
- 74. こちらはレイヤを抽象化したもの。
- 75. AUFS AUFS ストレージ・ドライバを使う — Docker-docs-ja 1.10.0b ドキュメント http://docs.docker.jp/engine/userguide/storagedriver/aufs-driver.html AUFSはコンテナに書き込みを行 う時、初回にコピーが発生します。 1GBのファイルに追記する場合、 1GBのファイルをコピー後に処理 が進行します。
- 76. devicemapper Device Mapper ストレージ・ドライバを使う — Docker-docs-ja 1.10.0b ドキュメント http://docs.docker.jp/engine/userguide/storagedriver/device-mapper-driver.html 一方、RHEL系の場合はコピーは 発生しません。64KB単位で処理 が行われます。
- 77. コンテナのボリューム ボリュームはCoW処理を行わず、 ホスト上のI/O性能が直接反映。 コンテナでデータを管理する — Docker-docs-ja 1.10.0b ドキュメント http://docs.docker.jp/engine/userguide/containers/dockervolumes.html
- 78. 78 ‣ ベース・イメージ • 誰がセキュリティのメンテナスを行っているのか。コミュニティ 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 通信が推奨 主なセキュリティ考慮点
- 79. 79 検討項目まとめ 1. 利用者は誰で、用途は何か？ 2. インフラをどうするのか？ 3. OSを何にするのか？ 4. ディストリビューションを何にするのか？ 5. ストレージ・ドライバを何にするのか？ 6. ベースイメージは何にするのか？ 7. セキュリティをどのように考慮すべきか？ 8. 性能をどのように担保するのか？
- 81. 81 ‣ ユーザガイド • http://docs.docker.jp/engine/userguide/index.html • Dockerfile ベスト・プラクティス – http://docs.docker.jp/engine/userguide/eng-image/dockerfile_best-practice.html • ストレージ・ドライバ – http://docs.docker.jp/engine/userguide/storagedriver/index.html • Docker ネットワーク機能の概要 – 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 Docker Engine オススメのドキュメント
- 82. ここまでのまとめ • Dockerはプラットフォームであり、全てを解決しない • Dockerコンテナのライフサイクルに対する理解が必要 • 検討要素 • 最終的な利用者は誰なのか • 業務範囲や用途は何なのか
- 83. 技術選択のポイント 1. 利用者は誰で、用途は何か？ 2. インフラをどうするのか？ 3. OSを何にするのか？ 4. ディストリビューションを何にするのか？ 5. ストレージ・ドライバを何にするのか？ 6. ベースイメージは何にするのか？ 7. セキュリティをどのように考慮すべきか？ 8. 性能をどのように担保するのか？ Dockerは全てを解決するインフラ ではない。Dockerの管理領域と、 それ以外を区別して組み合わせを 考える必要がある。
- 86. 本資料における主張 • 「Docker」を導入するだけでは価値を生まない。 • 「Docker」は技術選択要素の１つにすぎないので、 業務フローに一致するならば、積極的に導入すべきだ。 • 継続的な技術評価を行うべきだ。 ・
- 88. 誰が？ 何のために？
- 89. 技術選択のポイント 1. 利用者は誰で、用途は何か？ 2. インフラをどうするのか？ 3. OSを何にするのか？ 4. ディストリビューションを何にするのか？ 5. ストレージ・ドライバを何にするのか？ 6. ベースイメージは何にするのか？ 7. セキュリティをどのように考慮すべきか？ 8. 性能をどのように担保するのか？
- 91. 質疑応答 • 何か気になる所はありますか？ • 日本語ドキュメント http://docs.docker.jp • @zembutsu
- 92. 92 私は誰なのか？ ‣ @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/log3 Why am I here? +MasahitoZembutsu