‫さて､ Dockerの主要な機能をいくつか学んだ後でも､ なぜDockerが存在する必要があるのか疑問に思うかもしれません｡
‫もちろん､ 私たちは何十年もの間､ 他の多くのパッケージマネージャと一緒にソフトウェアをパッケージングし､
‫サーバにソフトウェアをデプロイしてきました｡
‫では､ お話を伺いましょう｡
‫このビデオでは､ それに焦点を当てます｡
‫の3つを軸に｡
‫なぜDockerなのか､ なぜ今なのか？
‫そして､ 作られた当時は摩擦がありました｡
‫ソフトウェアライフサイクルのスピードと使いやすさを次のレベルに引き上げるには､ 特に私たちが作っているすべてのソフトウェアのパッケージング､
‫配布､ 運用において､ 邪魔になるものがありました｡
‫そして､ 私は3つのリストが好きなんですね｡
‫そこで､ このメインリストであるアイソレーション､ 環境､ スピード､ この3つの領域が､
‫総合的な3つの理由としてお話したいと思うのです｡
‫容器そのものが存在しなければならないのに､ なぜ今人気があるのか､ という気がします｡
‫まず第一に､ 孤立の問題｡
‫私のキャリアの始まりである90年代に戻ると､ コンテナができる前のサーバーがどうであったかについて話を始めることができます｡
‫ちょうど2013年､ Dockerができる前よりさらにさかのぼると｡
‫90年代にメインフレームからPCに移行したときの典型的な管理者の姿は､
‫このようなものだったでしょう｡
‫1社につき2､ 3台のサーバーを持っていました｡
‫一人当たり100台のサーバーを管理するのは無理でしょう｡
‫繰り返しになりますが､ これは2000年頃の話です｡
‫そのため､ 非常に高価で大規模なサーバーを用意することになります｡
‫1つのアプリですべてのリソースを消費することは稀であると｡
‫そうすると､ 同じサーバー上に､ いろいろなアプリを寄せ集めてしまうことになります｡
‫そして､ サーバーがもろくなってしまったのです｡
‫あるアプリのために何かを変更する必要があっても､ 別のアプリでは別のものが必要になることもあり､
‫管理が大変になったのです｡
‫そして､ 異なるPythonのバージョンやApacheのバージョンを異なるサーバーで管理し､
‫すべてのバランスを取る必要があります｡
‫同時に､ 各サーバーにどんどん物を置きたくなるのですが､
‫何も隔離されていない状態でしたね｡
‫つまり､ これらのアプリはすべて同じファイルシステムを共有していたのです｡
‫通常､ 複雑なハッキングをしなければ､ そのアプリの複数のバージョンを作ることはできません｡
‫そして､ それが大きな問題でした｡
‫そして､ VMが登場した｡
‫そのため､ VMが普及し始めると､ クラウド化する以前から､ すべてのアプリケーションを抽象化し､
‫より少ないアプリケーションを小さなVMに乗せ､ すべて同じ大きなホストに乗せることができるようになったのです｡
‫このように､ 増え続けるサーバーを管理する方法として､
‫ChefやPuppetを使い始めるかもしれません｡
‫実際､ Dockersが誕生する前の2010年代前半には､
‫非常に多くのサーバーがあり､ 一度にすべてのサーバーを管理するのは非常に難しくなっていました｡
‫クラウドでも､ マシンの起動と停止を高速化することができます｡
‫クラウドを導入することで､ より多くの製品を簡単に立ち上げることができるようになったため､
‫管理は大変でしたが､ 同時に悪化もしました｡
‫では､ Dockerはどのようにそれを支援することができるのでしょうか｡
‫どのようにすれば､ 管理すべきインフラの量を減らし､ 同時にワークロードの分離を確保し､
‫物事が脆くなったり､ 管理が難しくなったりしないようにできるのでしょうか？
‫20年前なら､ 不必要な数のOSを搭載したVMを分散させる代わりに､
‫コンテナによってVMのように分離することができたでしょう｡
‫全く同じというわけではありませんが､ とりあえず分離レイヤーとして､ 独自のIPアドレス､
‫独自のファイルシステム､ 独自のプロセス空間を得ることができると主張します｡
‫そのため､ ほぼフルVMのように見えますが､ さまざまなOSを必要としないので､
‫OSの数を減らすことができます｡
‫当社の物理的なホスト数です｡
‫もはやVMを分離のレイヤーとして使用する必要はないのです｡
‫そして､ SSHを使用する代わりに､ Docker CLIを使用するように見えるかもしれません｡
‫あるいは､
‫Kubernetesに移行すれば､ Kubernetes CLIを使って､ アプリケーションはすべて独自のコンテナで隔離されます｡
‫これにより､ 同じシステム上で同じアプリの複数のバージョンを競合することなく実行できるなど､
‫多くの利点があります｡
‫次は環境の問題です｡
‫そして､ 先ほどお話したように､ 大量のOSSをスピンアップしていましたが､
‫さまざまなタイプの環境も増えていきました｡
‫私のマシンでワークスなんて聞いたことある？
‫ジェフ・アトウッドのジョークで有名になったようなものです｡
‫スタックオーバーフローの創設者の一人が､ その昔､ 有名なブログ記事でこう語っています｡
‫しかし､ このアイデアは少し嫌味なものでしたが､ アプリケーションが正しく動作することを確認するのは､
‫しばしば開発者の仕事であるというジョークでした｡
‫しかし､ このアプリを動かすために必要な環境をすべて持っているわけではありません｡
‫だから､ 自分のマシンで動かして､ 自分のマシンでテストして､ 他の場所でうまくいかなかったときに､
‫私のマシンではうまくいったと言うのです｡
‫Dockerは「地獄のマトリックス」という造語を作りましたが､ これは本質的に､
‫アプリのすべての部分について､ 私より上位に位置するものを意味します｡
‫そして､ この上のあらゆるタイプの環境に対してです｡
‫コンフィギュレーションが違うんですね｡
‫もしかしたら､ 別の方法で依存関係をインストールしなければならないかもしれません｡
‫もしかしたら､ 片方ではバージョンが違うので､ 依存関係が微妙に違うのかもしれません｡
‫開発者がMacで使っているアプリをWindowsでは別の方法でインストールする必要があり､
‫Linuxサーバーでは別の方法でインストールする必要があるなど､ さまざまなタイプの環境があり､
‫ドキュメントを読んだり書いたりしなければならないことがあるでしょう｡
‫今､ コンテナイメージとコンテナ自体は､ それが実行される場所とその中で実行されるものの間の基本的な抽象または契約となったのです｡
‫100年近く前のデザインから､ 世界中に商品を発送できるようになった現実世界の物理的なコンテナのようなものです｡
‫そこで目指したのは､ 物理的なコンテナを届ける人は､ その中身を知らなくてもいいということです｡
‫そして､ コンテナの中に荷物を入れた人は､ そのコンテナが物理的にどのように目的地に届くのかを知る必要も､
‫気にする必要もないのです｡
‫このコンテナは､ 今や世界中に何百万個と出荷され､ 家にあるほとんどのものが一生のうちにコンテナに入ったことがあるという､
‫壮大なスケールの抽象的なものだったのです｡
‫今はイメージやDockerコンテナでも同じことが言えます｡
‫これは､ 現在OCI規格として知られている一貫した標準フォーマットです｡
‫これらは､ コンテナをどこで実行しても､ ビルドされたときと同じ正確な依存関係で､
‫同じ一貫した方法で実行されることを保証します｡
‫次は速度の問題です｡
‫今は､ 必ずしもここでというわけではありません｡
‫CPUのスピードや｡
‫そういうものは､ 時間が経てば自然と速くなるものですが､ 私が言っているのは､
‫本当にビジネスのスピードのことなんです｡
‫ITやソフトウェア､ ソフトウェアライフサイクルについて語るとき､ 私たちは企業や組織がアイデアを実行に移し､
‫ソフトウェアのアイデアをできるだけ早く顧客に提供する能力について本当に語っているのであり､
‫それはソフトウェアライフサイクルの一部なのです｡
‫しかし､ コンピュータの黎明期から､ このような理由でインフラやアーキテクチャの転換が行われてきたのです｡
‫私が入社した90年代は､ メインフレームからPCに移行する分散型アーキテクチャが主流でした｡
‫それは､ 変化を展開できるスピードが大きいということでした｡
‫メインフレームが次のUnixのバージョンにアップデートされるのを待つことなく､
‫1台のマシンにDOSをインストールすることができるようになったのです｡
‫一気に動くことができなくなったのです｡
‫私たちは､ 組織のさまざまな部分を､ さまざまな方向に､ さまざまなスピードで動かす必要があったのです｡
‫それゆえ､ 分散コンピューティングの夜明けとなったのです｡
‫ハードウェアの発注やデータセンターへの実装を待つのに疲れたので､
‫ベアメタルから仮想化へ移行しました｡
‫スピードアップを図り､ リソースの有効活用を図りたかったのです｡
‫仮想化､ 仮想マシンが非常に普及したのは､ そういった理由からです｡
‫そして､ データセンターからクラウドへの移行は､ 自社のハードウェアやデータセンターの許容範囲を超えるスピードでアイデアを展開する必要があったため､
‫次のステップとなりました｡
‫現在持っていないサーバーを､ 数日､ 数週間ではなく､ 数分で稼働させたかったのです｡
‫そして､ クラウドによって､ ほぼ瞬時にリソースにアクセスできるようになったのです｡
‫クラウドがこれほどまでに巨大になったのは､ 明らかにそのためです｡
‫そして､ いよいよその次のステップに突入です｡
‫ホストやカーネル､ オペレーティングシステムが多すぎるという､ 大規模なホストの拡張から移行したのです｡
‫そして今､ その数を減らすことができます｡ なぜなら､ その中のワークロードを分離して､
‫同じカーネル上で一緒に安全に実行することができるようになったからです｡
‫ところで､ ここでサーバーレスを含めているのは､ ほとんどのサーバーレスプラットフォームをよく調べてみると､
‫実際にはバックグラウンドでコンテナを動かしているだけだからです｡
‫イメージとして出荷したコンテナかもしれませんし､ ただ単に､ 彼らがあなたの関数を動かしているコンテナかもしれません｡
‫コンテナとDockerは､ より速く開発し､ より速くアプリを構築し､
‫より速くテストし､ より速くサーバーにデプロイする能力を提供します｡
‫さて､ あなたはまだ私と一緒にいますか？
‫まだ､ 気になりますか？
‫簡単におさらいしておきましょう｡
‫では､ なぜコンテナが存在するのかというと､ 大きく分けて3つの理由があります｡
‫私の意見では､ 単一のOS内部でより優れた分離を行うことで､ OSや依存関係の管理の手間を省き､
‫かつアプリケーションを保護するために必要な分離を行うことができます｡
‫そして､ 環境バリアブルの低減です｡
‫そのため､ 動作する各環境の差はごくわずかです｡
‫繰り返しますが､ 通常はデータベースの接続設定､
‫URLのパス､ ポートなどです｡
‫そして､ あとはすべて､ あなたが作ってテストしたのとまったく同じです｡
‫そして最後に､ ソフトウェアそのものだけでなく､ そのソフトウェアを導入しようとする企業の変化への対応速度を高めることです｡
‫より速く開発し､ より速く構築し､ より速くサーバーにデプロイし､ より速くテストすることができるようになったのです｡
‫コンテナイメージとコンテナそのものが､ ビルド､ デプロイ､
‫再デプロイ､ 再実行など､ とても簡単だからです｡
‫ということで､ ご理解いただけたでしょうか｡
‫次の動画でお会いしましょう｡