‫Dockerfileに飛び込んでみましょう｡ これは､ 実はイメージを作成するためのレシピなのです｡
‫これまで使ってきたDockerイメージはすべてDockerfilesから作成したもので､ Docker Hubから見に行くことができます｡
‫最初のセクションで紹介したリソースから私のリポジトリをクローンした場合､ docker sample file 1 ディレクトリが表示され､
‫その中に1つのファイルだけがあるはずです｡ Dockerfileのことです｡
‫これから一行ずつ､ さまざまなスタンザについて話していきます｡ Dockerfileは一見シェルスクリプトのように見えますが､
‫そうではありません｡
‫バッチファイルでもなく､ シェルスクリプトでもない｡ これはDocker独自の全く異なる言語のファイルで､
‫デフォルトの名前はDockerfileで大文字のDが付きます｡
‫しかし､ コマンドラインから､ dockerコマンドを使ってDockerfileを扱う必要があるときは､
‫実はダッシュfを使うことができるのです｡ Dockerの多くのツールに共通することですが､ dash
‫fでデフォルトとは異なるファイルを指定することができます｡
‫では､ まずfromコマンドです｡ fromコマンドはすべてのDockerfileに含まれています｡ そこに必要なのは
‫通常は最小限の配布となります｡
‫この場合､ Debianです｡
‫でも､ 最近はアルパインになることが多いですね｡
‫そして､ 本当にこれらを使う理由は､ 自分の時間と痛みを節約するためです｡ なぜなら､ これらの最小限のディストリビューションは､ 実際には､
‫そこから仮想マシンをインストールするために使うCDよりもずっと小さいからです｡
‫例えば､ UbuntuのものにはcURLも入っていませんが､ VMにUbuntuをフルインストールすれば､
‫cURLやその他多くのコマンドが既にインストールされていることは明らかです｡
‫これらのディストリビューションはすべて公式イメージであるため､ 常に最新のセキュリティパッチを適用しており､
‫信頼できるディストリビューションであることを意味します｡
‫そして､ コンテナで使用するための主な利点の1つは､ そのパッケージ配布システムを使用して､ パッケージに必要なソフトウェアをインストールできることです｡
‫この場合､ 実際にはコロンの後にあるJessieのリリースを使用しています｡
‫そして､ Docker Hubでの会話で思い出したように､ ここでDebianリポジトリに指定できるオプションはたくさんあります｡
‫次に､ ENVスタンザですが､ ENVは環境変数のことです｡
‫環境変数を設定する方法です｡ 環境変数は､ コンテナ構築やコンテナ実行のためのキーや値を設定する主な方法なので､
‫実はコンテナでは非常に重要なものなのです｡
‫この場合､ 実際にはインストールするNginxのバージョンを設定しており､ この環境変数を設定することで､
‫それ以降の行はこの環境変数を使用できるようになります｡
‫さて､ 前回の講義を思い出していただきたいのですが､ これらのスタンザはそれぞれ､ Dockerイメージの実際のレイヤーです｡
‫つまり､ トップダウンで動くので､ その順番は実は重要なのです｡
‫この比較的長い実行コマンドでおわかりのように､ 次回のためにここに｡ 1つの長いコマンドのように見えることがわかると思います｡
‫このコンテナの中でシェルコマンドを実行しながら構築しているのです｡
‫通常､ パッケージリポジトリでソフトウェアをインストールする必要があるときや､ 解凍を行う必要があるとき､ コンテナ自体の中でファイルを編集する必要があるときに､
‫runコマンドを目にすることが多いでしょう｡
‫Runコマンドは､ ファイル内で先にコピーしておいたシェルスクリプトや､ ファイル内のその時点でコンテナ内からアクセスできるコマンドも実行できる｡
‫Debianから来たのですから､ このrunコマンドはそのリリースでインストールされたであろうすべてのコマンドとバイナリにアクセスできます｡
‫そして､ このNginx用のものでは､ このコマンドのリストは､ 多かれ少なかれ､ Nginxの公式リポジトリから最新のNginxをインストールするためのパッケージを取得できるリポジトリへのキーを追加しています｡
‫ここでは､ 良いDockerfileを作るために本当に重要なことがいくつかあります｡ これについては､
‫後のセクションでベストプラクティスについて詳しく説明します｡
‫しかし､ 注意すべき点が2つあります｡
‫このように､ すべてのコマンドをダブルアンパサンドで追加し､ 次々と連鎖させているのは､
‫各スタンザが独立したレイヤーであることを覚えておいてください｡
‫これは､ これらのコマンドをすべて1つのレイヤーに収めることを保証するものです｡
‫少しは時間の節約になりますね｡
‫省スペースにもなるし｡ そして､ Docker HubにあるすべてのDockerfileで目にすることができるほど､ 一般的なものなのです｡
‫さて､ 27行目には､ もう一つの実行コマンドがあります｡
‫これは､ ログファイルを標準出力と標準エラーに向けるためのものです｡
‫後ほど説明しますが､ コンテナ内のロギングの正しい方法は､ ログファイルにログを記録しないことです｡ また､ コンテナ内にはsyslogdなどのsyslogサービスもありません｡
‫Dockerは､ 実際にすべてのログを処理してくれます｡ コンテナの中でやるべきことは､
‫ログに残したいものをすべて stdout と stderr に吐き出すようにすることだけで､ あとは docker が処理してくれます｡
‫実は､ Docker Engine自体に､ ホスト上の全コンテナのログを制御するためのロギングドライバがあるんです｡
‫そして､ それが本当にやりたいことなのか｡
‫アプリが実際にロギングを行う場合､ アプリはより複雑になります｡
‫さらに､ すべてのコンテナでファイルを扱わなければならない場合､ それらのファイルをどのようにして取り出し､
‫検索し､ アクセスできるようにするかという問題が発生します｡ ここでは､ デフォルトのNginxのログを取得し､ 実際に標準出力にリンクしています｡
‫Dockerがそれらを捕捉できるように｡
‫また､ exposeコマンドも用意しています｡
‫デフォルトでは､ コンテナ内部でTCPやUDPのポートは開いていない｡
‫ここに記載しない限り､
‫コンテナから仮想ネットワークに何かを公開することはない｡
‫そしてもちろん､ これはWebとプロキシサーバーであるため､ 80と443を公開することになる｡
‫さて､ このexposeコマンドは､ これらのポートが我々のホスト上で自動的に開かれることを意味するものではありません｡
‫docker runを使うときのダッシュPコマンドがそれです｡
‫最後に､ こちらのCMDです｡ CMDは必須パラメータで､ イメージから新しいコンテナを起動するたびに､
‫または停止しているコンテナを再起動するたびに実行される最終的なコマンドです｡
‫Dockerのドキュメントサイトdocsには､ これらすべてのスタンザと､ 後で説明するその他の多くのスタンザについて､ 実に優れたドキュメントがあります｡
‫ドッカーです｡ comを使用することで､
‫この講義のリソースで見つけることができます｡
‫なるほど､ これが基本なんですね｡ この5種類のスタンザは､ どのDockerfileにもあるごく普通のものです｡
‫一部必須
‫runやENV､ exposeといった項目はオプションですが､ イメージを作成するほとんどのコンテナで典型的なものです｡