Dockerの期待と現実～Docker都市伝説はなぜ生まれるのか～
•
188 recomendaciones•61,070 vistas
「企業のためのDocker実戦ガイド」発表資料 2017年2月27日(月) https://itmedia.smartseminar.jp/public/seminar/view/981
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Dockerの期待と現実～Docker都市伝説はなぜ生まれるのか～
Similar a Dockerの期待と現実～Docker都市伝説はなぜ生まれるのか～ (20)
Más de Masahito Zembutsu
Más de Masahito Zembutsu (20)
Último
Último (9)
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に触 れてきた一人という、中立的な立場で 皆さんと議論したいと思っています。
- 9. 9 仮想化 事 前 設 計 ク リ ッ ク 試 験 利 用 開 始 しかしそれでは、ウェブを中心とした インターネットの普及スピードに追 いつけません。ですので、速さと効 率化を求めて、仮想化技術や、
- 16. 16 仮想化 Docker / コンテナクラウド 事 前 設 計 ク リ ッ ク 試 験 利 用 開 始 事 前 設 計 ク リ ッ ク 試 験 利 用 開 始 事 前 設 計 ク リ ッ ク 試 験 利 用 開 始 サーバ統合・リソース有効活用 設置スペース・消費電力削減 運用自動化・効率化 システム可用性向上 これまでの延長上の技術と思われ てしまい、その視点で「使える」か 「使えない」かが論じられています。 ですが、それは正しいのでしょうか。
- 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を提供する会社の方。 利用者はインフラの面倒をみたい のではなく、アプリを動かしたいの だと利用者との対話で気づきます。
- 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イメージさえあれば、イン フラを意識せずに動かせるように。
- 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の 宣伝するつもりはないので、詳しい 解説は避けさせてください。
- 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 などアーキテクチャを選択できる 自由度の高いハードウェア・エミュレーションや 管理性を提供する。
- 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 ・ディスク・クォータ さらにプロセスにはリソースを制限 可能な状態と言えます。
- 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イメージの配布や自 動構築を行う仕組みも提供されて います。これも仮想化との違いです。
- 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
- 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とはアプリ ケーションを迅速に構築・移動・実 行するための役割を担います。
- 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とい う言葉も生まれています。
- 66. Dockerと課題 セキュリティ対策は従来と同じ べースの OS は通常の Linux ないし Windows なので、セキュリティ対応は欠かせない 従来の手法に比べ、更新しやすい（イメージの自動構築機能） Content Trust や Notary といった技術を利用しセキュリティを高める 運用や監視も特に変わらない Docker Engine の管理が必要になるが、その他は通常のサーバ管理と同じ Docker 導入が目的化すると方向を見失いがち リソース削減や集約が、そのまま開発・運用コストの削減にはつながらない
- 67. Dockerに不向きと思われる場面 リソース集約やコスト削減の目的 確かにリソースは集約できるかもしれないが、仮想化技術とは手法が違う 結果として業務フローの変更や Docker コンテナ変換作業が発生して、コストは増える 既存のシステムをそのまま移行 Docker は開発・テスト・運用のサイクルを加速する場合には有用 単純に Docker に対応しても速さや利便性を求めないのなら、結果として仮想化やクラウドと同じ そもそものシステム要件にあわない環境 厳密なセキュリティの確保や長期の安定性を求めるのであれば、別の適切なシステム検討を 全ての要件を満たす完璧なシステムは存在しない。トレードオフを考慮 ※ Dockerはインフラ（システム基盤）ではなく、あくまでアプリケーションのプラットフォーム
- 69. 69 物理サーバだけの時代 とある物理サーバ 故障すると大変 CPU メモリ ディスク 調達・管理コストの課題 基本、ハードウェア固定 オペレーティングシステム ミドルウェアやライブラリA B C アプリ 1 リソース有効活用のしづらさ たとえばリソースを有効活用したい のが目的であればMesosという選 択肢もあります。
- 70. 70 仮想化技術の時代 とある仮想サーバA とある仮想サーバB とある仮想サーバC OS ミドルウェア アプリケーション OS ミドルウェア アプリケーション OS ミドルウェア アプリケーション 時間 リ ソ ー ス 使 用 率 時間 時間 サーバが増減できるよ、やったね！ アプリケーション アプリケーション アプリケーション 仮想化によって物理に比べればリ ソースを有効活用できますが、やっ ぱり勿体ないところがあります。
- 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 タスクを処理（実行）
- 77. 振り返り
- 82. まだ時間あります？ 82
- 83. 83 Dockerの役割を再定義 導入コスト 高い 導入コスト 低い 運用コスト 低い 運用コスト 高い Public Cloud 基盤 Private Cloud 基盤 chef Ansible Docker 開発用 OpenShift Docker 運用系 kubernetes
- 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には恨み辛みがある 運用面での疑問や課題