‫さて､ こんにちは､ いや､ Dockerとコンテナ・ツールのあるソフトウェア管理の未来にホエールカムと言うべきでしょうか｡
‫このビデオは､ 特にDockerについてです｡
‫長年にわたってたくさんのツールがありましたが､ このビデオは2013年にDocker全体のソフトウェアの進化を始めた3つの大きな革新､
‫つまり主に3つのことを紹介しています｡
‫Dockerイメージ､ そのDockerレジストリ､ そしてDockerコンテナ｡
‫Dockerといえばコンテナを思い浮かべる人が多いと思いますが､
‫この3つのイノベーションはパンとバターのように一緒になり､ Docker build
‫ship runと呼ばれるようになりました｡
‫それが3つのステップです｡
‫コンテナ化されていないソフトウェアをDockerイメージに変換し､ レジストリに置き､
‫必要な場所に持っていって実行します｡
‫そして､ 最後にそこからコンテナを作成します｡
‫実際､ CNCF（Cloud Native Computing Foundation）には､
‫私のビデオでお話しする多くのツールがあります｡
‫これらの製品､ ツール､ ワークフローは､ ほとんどの場合､ ビルド・シップ・ランというコンテナ・ワークフローを使用していることを前提としています｡
‫では､ これらを分解して､ 具体的にどのような3つなのかを説明します｡
‫まずはコンテナイメージ｡
‫私はこれをユニバーサル・アプリ・パッケージャーと呼んでいるのですが､ これまでにもたくさんのパッケージマネージャーがありました｡
‫実際､ 私はパッケージ・マネージャーを数え切れないほど持っています｡
‫しかし､ OSやプラットフォーム､ アプリケーション言語にとらわれない､
‫つまり､ LinuxやWindowsであれば､ どこでも､ どんなものでも動作するものは､
‫私の記憶ではこれまで存在しませんでした｡
‫Dockerfileとは､ コンテナ・イメージを作成するためのレシピや指示のセットで､
‫Dockerイメージとコンテナ・イメージは同じものを指す言葉です｡
‫実際､ Dockerのイメージ仕様は非常に好評で､ 今ではOCIイメージ規格と呼ばれる標準規格になっています｡
‫つまり､ 一連の指示が表示され､ すべてのDockerfileはFROMを必要とします｡ そもそも､
‫他人のイメージから始めることができるのです｡
‫多くのFROMから多くの画像を得ることができるので､ その複雑さについては後で説明しますが､
‫ここではPythonから始めて､ 下に向かって作業していきます｡
‫実際には､ Dockerfile（スタンザと呼ばれることもある）の中で､ これらのコマンドをひとつひとつ大文字で重ねていくところから始めます｡
‫FROM､ RUNと上から下に向かって処理するので､
‫レイヤーを作ることができるのです｡
‫これらのレイヤーの中には､ ファイル､ ディレクトリ､
‫ファイルのパーミッション､ そして後で説明するメタデータが含まれています｡
‫このイメージのビルドを開始すると､ 最初の行が始まり､ Docker Hubや私がイメージを取得するように指示したところからPythonイメージを見つけに行きます｡
‫Pythonのバイナリやライブラリも含まれます｡
‫ホストドライバやLinuxカーネルなど､ Pythonが動作するために必要なもの以外のものは含まれていません｡
‫もしPythonがOpenSSLを必要とするなら､ それは画像のそのレイヤーに含まれています｡
‫そして､ Dockerfileの次の行に進みます｡
‫これはPythonの依存関係インストーラのPIPコマンドで､ flaskをインストールしているところです｡
‫これで､ 通常のPIPインストールコマンドと同じように､ flaskを追加する新しいレイヤーを開始することができます｡
‫実際､ バックグラウンドで起きているのは､ それぞれのレイヤーに対して小さなコンテナを素早く実行し､
‫レイヤー内で必要なコマンドや処理を実行し､ それらをそれぞれ別の場所に保存しているのです｡
‫Linuxのホストでは､ これを構築しています｡
‫つまり､ ここでレイヤーを重ねているわけです｡
‫そして､ 次の行のCOPYコマンドに進みます｡
‫WORKDIRはメタデータの変更であり､ ファイルシステム上の場所を変更するだけです｡
‫大したことはない｡
‫COPYコマンドは､ ビルドしているホストからソースコードをコピーして､ 他のレイヤーの上に積み重ねた独自のレイヤーにします｡
‫これらをまとめて､ Docker buildというコマンドでイメージを作成します｡
‫これはDockerの使い勝手の良さの一つで､ Dockerfileの中で起こっている複雑なことを､
‫このシンプルなDocker buildコマンドだけで､ アプリケーションと必要な依存関係だけの単一イメージに変えてしまうことができるからです｡
‫それが､ ビルドシップランの最初の部分です｡
‫Dockerビルドであること｡
‫次は､ レジストリについてです｡
‫Dockerレジストリは､ アプリケーションの配布用です｡
‫どのアプリケーションのパッケージングシステムにも､ それらのパッケージを取り回す方法があり､ Dockerレジストリも同じです｡
‫現在は､ OCIディストリビューション仕様やOCIレジストリ仕様と呼ばれるだけです｡
‫つまり､ コンテナ・イメージを移動させる方法については､ 業界全体で再び標準となったのです｡
‫と､ どこにでもあります｡
‫どのクラウドにもある｡
‫Docker Hubはデフォルトで､ おそらく最も一般的なものです｡
‫GitHubにもあります｡
‫BitbucketやGitLabは､ それぞれ独自のイメージレジストリを持っていて､ 自分で運用することも可能です｡
‫Dockerイメージを格納することができる無料のオープンソースや有料のソフトウェアは､
‫少なくとも10以上のプロジェクトがあると思います｡
‫ということで､ その仕組みを分解してみましょう｡
‫最初に
‫先ほど作成した画像には､ すべてのレイヤーを識別するための一意のSHAハッシュが設定されており､
‫2つの異なるシステムでハッシュを見た場合､ まったく同じファイル､
‫まったく同じメタデータが作成されていることが保証されます｡
‫それらの画像レイヤーは一緒になって分散しています｡
‫Docker pushのようなものを使って､ これらのイメージレイヤーをレジストリにプッシュすることができるのです｡
‫しかし､ 一度登録すれば､ 他のマシンに行ってDocker
‫Pullを行い､ そのマシンにそのイメージの同一コピーを置くことができます｡
‫1号機で作ったのと同じようにね｡
‫Dockerの基本原則の1つは､ あるマシンで作ったソフトウェアを､
‫その依存関係も含めて､ まったく同じように別のシステム（LinuxやWindowsのまったく異なるディストリビューション）で実行できる､
‫ということです｡
‫Linuxで､ Linuxのバイナリを実行しているのでLinux上で動作しなければならないLinuxのイメージを構築した場合､
‫CentOSで構築してUbuntuで実行した場合､ そのdistrobutionにかかわらず､
‫全く同じアプリケーションと依存関係になります｡
‫最後に､ Dockerコンテナそのものを紹介します｡ 画像を構築し､ その場所に置き､
‫サーバーからアクセスし､ サーバーにダウンロードする､
‫そういった手順をすべて行った後です｡
‫走らせることができます｡
‫例えば､ Linuxが動作するサーバーがあるとします｡
‫Windowsが動作している場合もありますが､ 今回はLinuxに絞って説明します｡
‫バックグラウンドでDockerが動くようになるんです｡
‫Docker Engineと呼ばれるこのエンジンは､ イメージをダウンロードし､
‫ダウンロードされる予定のものであるかどうかを確認し､ 最終的にイメージを実行するために必要なすべての異なる事柄を指揮または管理します｡
‫そして､ Docker pullでダウンロードしたイメージで､
‫コマンドを実行します｡
‫まだコマンドを覚える必要はないのですが､
‫Dockerの実行コマンドです｡
‫build ship runのrunの部分です｡
‫そして今回は､ そのPythonアプリを独自のコンテナで動かしています｡
‫その入れ物が名前空間と呼ばれるものです｡
‫それは､ このコンテナで動いているアプリケーションが､ 他のOSを見ることができないようにする､
‫あのLinuxの機能です｡
‫このファイルシステムには､ 先ほど構築したイメージの中にあったファイルだけが含まれます｡
‫独自のIPアドレス､ 独自の仮想NIC､ 独自のプロセスリストを取得することができます｡
‫そして､ 基本的にその内部は独自のシステムになっているようです｡
‫そして､ イメージ名やイメージハッシュを指定してDocker, runコマンドを再度実行すると､
‫同じコンテナが隣り合わせで動作するようになります｡
‫これで､ この2つの工程は互いに分離された｡
‫そのため､ コンテナ1のPythonアプリはコンテナ2のPythonアプリを見ることができない｡
‫また､ コンテナ2でファイルを変更しても､ コンテナ1にはそのファイルはデフォルトで表示されません｡
‫もし､ Docker Engineの2番目のインスタンスが動作している2番目のサーバを追加して同じことを行えば､
‫冗長性やパフォーマンスの向上など､ 何らかの理由で複数回アプリケーションを実行する高可用性セットアップを実現することができます｡
‫ファイルシステム､ パーミッション､ メタデータの観点からは同一となります｡
‫今､ 私たちが学べることはもっとたくさんあります｡ だから､ 私が持っているコースはとても長くなっているのです｡
‫しかし､ この3つはDockerが最初にコンセプトを決めてから､ 今も変わっていないことです｡
‫build ship runの考え方は､ コンテナ､ そしてKubernetesであるHelmの中核的な原則の1つです｡
‫クラウド ネイティブ エコシステムでプロジェクト名を付けると､ おそらく開発者の手からテストシステムへ､
‫そして最終的に本番サーバーへ､ この典型的なワークフローを想定していることでしょう｡
‫この3つのステップと同じです｡
‫ですから､ なぜこの3つが重要な要素なのか､
‫この発明から何年も経った今日でも､ 少しは理解できるようになったのではないでしょうか｡
‫次を探そう｡