![[DB tech showcase Tokyo 2015] B37 ：オンプレミスからAWS上のSAP HANAまで高信頼DBシステム構築にHAクラスタリ...](https://cdn.slidesharecdn.com/ss_thumbnails/b37dbtechshowcasetokyo2015haclusteringsoftware20150612-150611165311-lva1-app6891-thumbnail.jpg?width=560&fit=bounds)
More Related Content
What's hot (15)
Similar to DOO-013_Docker 最新動向と Azure Container Service 入門 (20)
More from decode2016 (20)
DOO-013_Docker 最新動向と Azure Container Service 入門
- 8. Docker が誕生した背景 • 出自は PaaS ビジネス • アプリごとの分断が肝 • 仮想化では大鉈過ぎる • PaaS の課題はあなたの システムの課題か？ モノリシックな PaaS構成? 理想的な PaaS構成
- 9. サービス開発運用の課題、要求が変化 • 開発速度低下 • システム肥大化 • 技術の変化対応 • 市場要求の変化にどう 追従するかが課題 モノリシックな サーバ構成 アプリを 小さい単位に
- 10. Microservices Architecture • 各機能を分割/独立 • 変化への迅速な追従 • リソースの有効活用 • PaaS ビジネスと同じよ うな課題が現れる 出典: http://martinfowler.com/articles/microservices.html
- 11. 課題例：コンテナの配備(オーケストレーション) 仮想マシン1 コンテナA コンテナA コンテナB 仮想マシン2 コンテナA コンテナA コンテナB Orchestration Engine 2ホスト コンテナAを4インスタンス コンテナBを2インスタンス
- 12. App1 App2 Mesos / Swarm によるオーケストレーションイメージ
- 14. Dockerコンテナとオーケストレーションの理解 なぜDockerなのか？何ができるのか？ クリエーションライン株式会社 前佛雅人 @zembutsu Authorized Docker Trainer
- 15. Dockerとは？
- 16. “Docker allows you to package an application with all of its dependencies into a standardized unit for software development.” アプリケーションがソフトウェア開発で依存するすべてを、 Dockerは標準化したユニットにパッケージ化できます。 www.docker.com
- 18. Docker, Inc. 商用Dockerソリューションの提供 開発・移動・実行を統合するソリューションと製品群 商用技術サポート 前身はPaaS 事業者 アプリケーション・プラットフォーム dotCloud、事業売却 Dockerプロジェクトのスポンサー オープンソース版 Docker のプライマリ・コントリビュータ＆メンテナ 10億以上の Docker イメージのダウンロード 1,500 人以上の貢献者 20万以上の Docker 対応アプリケーション
- 20. 進化する環境 暗黒^H^H物理時代 仮想化・クラウド時代 コンテナ時代 機 材 発 注 機 材 納 品 設 置 機 器 設 定 事 前 設 計 ク リ ッ ク 見 積 も り O S 設 定 環 境 構 築 試 験 利 用 開 始 試 験 開 発 試 験 運 用 利 用 開 始 … … 事 前 設 計 ク リ ッ ク 試 験 利 用 開 始 … 事 前 設 計 ク リ ッ ク 試 験 利 用 開 始 … 開 発 段 階 検 証 段 階 本 番 段 階 すべてを迅速に、一貫した環境で行いやすい← New
- 21. Docker が実現したこと ソフトウェアが必要な全てをファイルシステムに包む コード、ランタイム、システム・ツール、シスラム・ライブラリなど サーバにインストールする全てをイメージ化 どのような環境でも実行を保証 Docker イメージは、Docker エンジンの動く環境上であればどこでも実行可能 ソフトウェアを動かすのに環境構築やセットアップ作業は不要 軽量・オープン・安全 ホスト OS を必要としないためメモリはより少なく、イメージにはファイルだけなのでサイズが小さい 様々なインフラで動く Linux ディストリビューションや Microsoft Windowsをベースにする インフラとアプリケーションを分離
- 22. 仮想マシン vs Docker
- 24. どのような環境に向いているのか 開発速度を加速 Docker コンテナ化は直ちに起動するので、セットアップや環境構築に時間を浪費しない 本来のアプリケーション開発、バグ修正、新機能追加に集中 開発者の想像力を強化 適切な言語環境の選定と構築が可能 ホスト環境上の OS やライブラリの整合性を考慮しなくてよい 環境の矛盾や依存の問題を撲滅 アプリケーションの依存関係や設定を、コンテナ（イメージ）に包み込める 「私の環境では動くけど、別の環境では動かない」問題は、もう起こらない
- 26. コンテナ標準規格 OCI : オープン・コンテナ・イニシアティブ 共通のコンテナ規格を策定する業界標準化団体が 2015 年夏に発足 Amazon、Microsoft、IBM 等のクラウド・ベンダをはじめ、Red Hat や Docker も参画 Dockerの独自仕様ではない Docker コンテナも OCI に準拠した規格に対応 (v1.11～) コンテナ利用はベンダ・ロックインにつながらない Docker を中心としたエコシステムも拡がりつつある
- 27. Dockerを動かす技術
- 28. Docker と Linux カーネル Docker Engineはコンテナを移動・実行するプログラム Engine はデーモン（サーバ）であり、Linux カーネルとクライアントとの処理を仲介 Dockerコンテナ ホスト OS のカーネル機能を使い、複数のルート・ファイルシステムを実行 各ルート・ファイルシステムをコンテナと呼ぶ コンテナは個々のリソース（CPU、メモリ、デバイス、ネットワーク）を持つ Linuxカーネルの技術 名前空間（namespace）は、プロセス間を分離、独立（isolation） コントロール・グループ（cgroup）は、CPU、メモリ、I/Oなどのリソース管理と制限
- 29. Docker に影響を与えた技術 chrootシステム・コール 1979年 Version 7 Unix で実装が計画 特定のプロセスとその子プロセスに対して、見かけ上のルート・ディレクトリを指定 jail 2000年 FreeBSD 4.0 のリリース Linux Containers (LXC) 2008年 Linux kernel 2.6.24 で実装
- 30. Dockerコンテナとイメージ
- 31. Docker の操作 OS ( Linux ) 物理/仮想サーバ Docker エンジン ( docker デーモン ) Linux kernel コンテナ コンテナ コンテナ リモート APIdocker クライアント ・docker コマンド Linux, Mac OS X, Windows ・Kitematic (GUI) Mac OS X, Windows ・Docker Compose ・Docker Swarm TCP あるいは Unix ソケットドメイン
- 32. httpd PID 1 コンテナA コンテナB ruby PID 1 chris.rb PID 2 コンテナのプロセス
- 33. コンテナのプロセス httpd PID 1 コンテナA コンテナB ruby PID 1 chris.rb PID 2 /sbin/init PID 1 docker 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
- 35. コンテナのファイルシステム コンテナ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
- 36. Docker イメージ コンテナ実行時に必要なファイルシステム イメージ・レイヤ（層）の集合体。実体は tar アーカイブ 読み込み専用で変更できない イメージはレイヤを共有できる レイヤには親子関係があり、イメージ構築時は差分を記録 無駄なディスク両々の増加を防ぎ、移動しやすく コンテナ起動時、イメージを使う コンテナ内のファイルを隔離した状態で実行する 読み書き可能なレイヤをイメージの上に追加する
- 37. $ 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/
- 38. $ 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
- 39. Demo
- 41. オーケストレーション
- 43. Engine $ docker run … $ docker run … $ docker run … $ docker run …
- 45. $ docker run … $ docker run … $ docker run …
- 46. $ docker run … $ docker run … $ docker run …
- 47. 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
- 48. Demo
- 50. 課題
- 51. Docker と課題 セキュリティ対策は従来と同じ べースの OS は通常の Linux ないし Windows なので、セキュリティ対応は欠かせない 従来の手法に比べ、更新しやすい（イメージの自動構築機能） コンテナト・トラストやノーチラスといった技術を利用しセキュリティを高める 運用や監視も特に変わらない Docker Engine の管理が必要になるが、その他は通常のサーバ管理と同じ Docker 導入が目的化すると方向を見失いがち リソース削減や集約が、そのまま開発・運用コストの削減にはつながらない
- 52. まとめ
- 53. まとめ アプリケーションを開発・移動・実行するプラットフォーム 始まりは「開発者が簡単にアプリケーションを動かす環境を作る」設計思想 ソフトウェア実行に必要なすべてを１つのパッケージにまとめ、どこでも移動、実行できる 現時点ではLinuxカーネル技術を使用 名前空間とコントロール・グループを使う Docker イメージを使い、プロセスを隔離し、リソースを限定して Docker コンテナを起動する 実運用を支えるオーケストレーション・ツール群がある Docker固有の課題は少ない これまでのサーバ管理や運用における課題を、改めて注目する必要がある Dockerは従来のインフラ面の課題を全て解決するものではない（銀の弾丸ではない）
- 55. App1 App2 (復習)Mesos / Swarm によるオーケストレーション
- 66. 障害ドメイン 障害ドメイン障害ドメイン FC ・ ・ ・ ・ ・ ・ スイッチ FC ・ ・ ・ ・ ・ ・ スイッチ FC ・ ・ ・ ・ ・ ・ スイッチ 可用性セット • 障害ドメインで分散 • 配置が分かれることを保証 • SLA 対象 • ドメインごとの障害影響が ほかに及ばない
- 67. Subnet
- 68. ・・・・・
- 71. Docker / Azure Container Service とは アプリケーションを開発・移動・実行するプラットフォーム - クラウド/オンプレに限らず様々な環境における相互運用性 Apache Mesos/Docker Swarm による基盤構築の利点 - プロプライエタリではないオープンなプロダクトベースによるノウハウの活用 Docker + Azure Container Service - オープンな規格 + OSSベースの運用基盤を容易に活用できる
- 72. コンテナ技術をより活用するための関連セッション 全般 - “de:code の歩き方” の DevOps 全般 Microservices 等アーキテクチャの話 - DEV-016 マイクロサービスプラットフォームAzure Service Fabricによる次世代のサービス開発/運用 - CHK-009 マイクロサービスアーキテクチャのすゝめ - エンタープライズシステムを分割リリースせよ!! - INF-011 驚愕! Azure リソースマネージャを利用した Infrastructure as Code 実践 - ARC-001 5年後のアプリケーション アーキテクチャを考える