name: overview class: title, smokescreen, shelf, no-footer # 第13回 Docker(1) 概要 <div class=footnote> <small> </small> </div> --- class: compact # 何のために仮想化したい? <div class=footnote> <small> <small> (脚注) [豆知識] 初期の「仮想化技術の商用利用」は(動作検証のため)「同じOSの異なるバージョンを利用したい」から始まりました </small> </small> </div> - <B>一台の強力なPCハードウエアで、たくさんの(仮想)サーバを運用したい</B>(主な理由) - <B>各ユーザが自分専用のOSを使っていると錯覚</B>できればよい - 各ユーザが使いたいOSは異なっていてよい - 同じOSの異なるバージョンを利用してもOK - 異なるOSでもOK - 他のハードウエアを真似したいこともある(動作検証など,レアケース) --- class: compact,img-right # <small>(より軽い仕組みで)自分専用のOSを使っている錯覚を出したい</small> <div class=footnote> <small> <small> </small> </small> </div> ![](../../images/concept-vt-container.png) <small> - 前回の「仮想化技術」は力技,重たい,必要か? - <B>一つのOSを分割</B>して使えば十分では? - [共有]多数のユーザがログインして利用する <br> (これが昔ながらの方式) - 例: AWS Academy (vocareum)が、これを少しモダンにした状態 - 他人の様子も見えてしまうのが欠点 - 共有しながらも、<B>ユーザ同士を分離する技術を開発する(-> 占有の錯覚)</B> - 過去40年くらい、あれこれ開発してきた - いわば分譲マンション? </small> --- class: compact,img-right # Dockerの意義 <div class=footnote> <small> <small> (脚注) コンテナベース=dockerの最重要な特徴ではありません。 「アプリを開発環境ごとパッケージングしろ」という主張が大事。 <br> たまたま2000年代の終わりに開発が始まったから、コンテナベースなんだと思う。 タイミングの問題は大きい </small> </small> </div> ![](../../images/concept-vt-container.png) <small> - ユーザが占有できる<B>アプリ実行環境</B>を提供 - 図の「Linux カーネル以外一式」が「アプリ実行環境」のこと - この環境の利用方法 1. ユーザは自分の<B>アプリを開発環境も含めてアーカイブ</B>(docker <B>コンテナ</B>を作成)し 1. dockerというPaaSへアップロードし実行 - 特徴 - <B>[移転可]</B>別docker環境で同じアプリが実行可 - <B>[再現性]</B>何度でも同じ環境を実行できる - <B>冪等性</B>と呼ぶ </small> --- class: compact,img-right # Dockerエコシステム(生態系) <small>〜 ここが大事 〜</small> <div class=footnote> <small> <small> (脚注) どんな業界でも早い者勝ちだが、他の業界にくらべ、ITビジネスでは圧倒的に早い者勝ち感あり。 それは限界費用が異様に安いため、ヒットさえすれば、一瞬で市場を制覇できるから (限界費用 = もうひとつ生産するために必要な費用; 経済学用語) </small> </small> </div> ![](../../images/docker-ecosystem.png) <small> 1. デファクトスタンダード 1. 単なるPaaSではなく、<B>アプリ実行環境一式を取り扱う仕組み</B>がdocker(前頁を参照) 1. <B>docker hub</B>があること(最重要) - すぐに使えるコンテナ(公式,非公式,同人(?))の提供場所 - githubと同様にハブ、<B>ノウハウのハブ</B>。 githubのようにノウハウの集積場所。 人気がでれば、ここにノウハウが集まり続ける。 <B>この正のスパイラルを構築できたことが勝因</B> </small>