‫この講義では､ バインドマウントと､ そのマウントにおける永続的なデータについて説明します｡ 要件としては､ コンテナ管理やコンテナの動かし方について知っていればよいということです｡
‫飛び込んでみよう｡ バインドマウントについて説明します｡ 実は､ かなりイケてるんです｡
‫初めて知ったとき､ ローカル開発で簡単にDockerを使えるんだ､ とハッとさせられたような気がします｡
‫本当に､ バインドマウントは､ ホストのファイル､ またはディレクトリをコンテナのファイル､ またはディレクトリにマッピングしているだけです｡
‫それができるのは､ あなただけです｡
‫ディレクトリを指定することも､ 1つのファイルだけを指定することも可能です｡ バックグラウンドでは､ 基本的に2つのロケーションがディスク上の同じ物理的なロケーションを指すようにするだけです｡
‫繰り返しますが､ これは他のボリュームと同様にUFSをスキップしているので､ コンテナを削除してもホストの場所が消去されることはありません｡
‫コンテナ内にホストファイルをマッピングしたファイルがある場合は､ ホストファイルが優先されます｡ コンテナ内のファイルを上書きしているわけではないので､
‫実際に削除されることはありません｡
‫バインドマウントが存在する間､ そこにあるだけです｡
‫バインドマウントが不要になり､ バインドマウントなしでコンテナを再実行すると､ 実は以前からあった基礎データが表示されることになります｡
‫バインドマウントは通常ホストに依存するため､
‫動作させるためにはホストのハードディスクに特定のデータが必要です｡
‫Dockerfileで指定することはできません｡
‫docker container run コマンドを使用する際に､ 実行時に使用する必要があります｡ フォーマットはこちらで確認できます｡
‫これは､ 前に使った-vと同じですが､ コロンの左側に､
‫名前だけでなくフルパスも入れています｡
‫そして､ Dockerが名前付きボリュームとバインドマウントの違いを見分ける方法は､
‫バインドマウントはフォワードスラッシュで始まるということです｡
‫Windowsの場合､ フォワードスラッシュ2つ､ そしてドライブレター､ そしてパスとなります｡
‫左コロンと右サイドさえあれば､ ホストからコンテナに本当に何でもマッピングできますし､
‫読み取り専用などの指定も可能です｡
‫この機能が真価を発揮するのは､ 開発時や､ ホスト上で使用しているファイルにアクセスするサービスをコンテナ内で実行したり､
‫変更したりするときです｡
‫それをNginxでやってみましょう｡
‫このコースのリポジトリのルートに移動して､ Dockerfileのサンプル2ディレクトリに移動します｡
‫今､ 私たちはさっきまでここにいたんですよ｡
‫思い起こせば､ 2つのファイルがありますね｡ これってNginx用ですよね？
‫Dockerfileをざっと見てみると､ とてもシンプルです｡ 作業ディレクトリを指定し､ そのディレクトリにインデックスファイルをコピーしているだけなのです｡
‫ここにはボリュームがない｡
‫バインドマウントはボリュームを必要としませんが､ ボリュームがあることは間違いないでしょう｡
‫ホストは常に勝つんだ､ 覚えてるか？ つまり､ Dockerコンテナの実行時に､ -d...を実行します｡
‫nginxと名付けましょう｡
‫先程と同じように8080番ポートを与えてみましょう｡
‫そして､ 今度はボリュームを出します｡ そして､ 現在の作業ディレクトリをコンテナ内の作業ディレクトリに実際にマウントするように指示する必要があります｡
‫インデックスファイルはこのフォルダの中にあるので､
‫コンテナの中に入れて､ ここで編集できるようにしたいのですが､ コンテナの中でライブで見られています｡
‫だから､ すぐに理解できる｡
‫ここで､ ちょっとしたコツをお教えしましょう｡ 私が自分のパスを全部把握して入力する代わりに､
‫ここでpwdをこんな風に使うことができるのです｡
‫これは､ 「作業ディレクトリを出力して､ このコマンドをそのパスに置き換える」というシェルショートカットです｡
‫'
‫それから､ そこのDockerfileから同じ作業ディレクトリを使うだけで､ Nginxのイメージを指定することになります｡
‫これから､ もう一つのターミナルウィンドウを開いて､ 二つのことを同時に行うことができます｡
‫本当に必要ないんですね｡
‫基本的には､ ホスト上でファイルを編集し､ 私がコンテナに入り､ 何が起こっているかを見るだけです｡
‫では､ 念のため､ localhostにアクセスしてみましょう｡
‫OK､ これはNginxのデフォルトのHTMLファイルではないんですね｡
‫そして､ 通常のNginxのイメージを使用しました｡
‫このディレクトリにあるカスタムのものは､ 実は使っていないんです｡
‫ストックイメージを使っただけです｡ この点を証明するために､ もう一度同じコマンドを実行しますが､
‫-vを削除して､ 代わりに8080番ポートで実行してみます｡ そして､ これをnginx2と呼ぶことにします｡
‫ブラウザでlocalhost 8080にアクセスすると､ そこがデフォルトのnginxのインデックスになっています｡ htmlファイルです｡
‫こちらは､ このディレクトリに住んでいる方のカスタムです｡
‫だから､ すでに正しくマッピングされていることがわかる｡
‫ここで別のタブを開いて､ コンテナ内にコマンドラインを表示させると｡
‫そして､ そのディレクトリに移動してください｡
‫ディレクトリ全体をマップしているため､ 実際にDockerfileを見ることができることに気づくはずです｡
‫左側で､ 実際に新しいファイルを作ったら､ このLinuxのtouchコマンドで新しいファイルを作ることができます｡
‫そして､ 右手には... 然うは を忘れてしまうのです｡ ls
‫-al とすると､ ファイルに表示されます｡
‫この2つの場所が同じ場所であることを､ ご理解いただけると幸いです｡
‫そして､ そのtestmeファイルに何かをechoすると､
‫...
‫そうこなくっちゃ
‫コンテナ内の通常のファイルパスであり､ それらのファイルはホスト上にあるため､ 私たちのnginxは変更を確認することができるのです｡
‫コンテナ内で削除するとしたら､ 同じファイルなので､ ホスト上でも削除されるでしょう｡
‫このとき､ 私は通常､ 開発者に､ このように複雑なセットアップをしている開発環境のすべてについて考えてもらうことにしています｡
‫Vagrantやその他の手作業で完璧な環境を構築している人たちは､
‫これを使えばもっとシンプルになることを実感できるはずです｡
‫Macで面倒な設定をする必要がないため､ コンテナを走らせるだけでした｡
‫マウントで-vコマンドを使い､ 私のホスト上のコードを私のホストで編集できるようになりました｡
‫そして､ 本当に容器の殻に入る必要がないんです｡
‫通常は､ コンテナを実行し､ そのログを見て､ コーディング中にエラーが発生していないかどうかを確認すればよいのです｡
‫もちろん､ これはNginxを使った簡単な例です｡ 後ほど､ 実際にローカル開発とコンテナで異なる開発環境の具体例をご紹介します｡