~更新~
6月15日に投稿しましたが、今日一番大切なステップを書いてなかったことに気づきました。すみません。「ホストのフォルダーをコンテナにマウントする」で、docker runを実行する際に-v C:\dev\mysite:C:\mysiteと指定してやる部分です。
#目的
Docker for Windowsを使ってごく初歩的なIISのウェブサイトを実行して、ホスト側のファイルをコンテナ上のウェブサイトに反映できるまでの手順を解説します。
#IISレポジトリをダウンロードする
DockerハブにあるMicrosoftの公式IISレジストリをDocker pullします。
私の場合はすでにホストマシーンにイメージがありましたが、そうでない場合はダウングレードとエクストラクトにしばらく時間がかかるかもしれません。
#コンテナをスタートする
以下のコマンドでIISイメージをコンテナとして実行します。
-
-entrypointオプションでPowerShellを指定します。これでコンテナが実行開始したら最初にPowerShellのコンソールがスタートします。 -
-itオプションを指定するとホストのCMDコマンドラインと、コンテナで実行するPowerShellがインターアクティブに接続されます。 -
-pオプションでホストのポート8080とコンテナのコンピュータのポート80（これは言うまでもなくHTTPサービスのデフォルトポートですね）をつなぎます。（今回はコンテナのIPに直接アクセスするのでホストのは適当でいいです）
コンテナがスタートしたらPowerShellのコマンドラインがコンソールに表示されます。このPowerShellはコンテナで実行してるんですよね～、すごい！
例えばdirコマンドでドライブの内容を表示してみましょう。やたらスッキリしているのが分かりますね。コンテナのドライブなので最小限のものしかありません。
ちなみに、コンピュータの名前を調べてみます。
ED9E6FA67BF9という名前になってました。
面白いことに、このコンピュータ名は実はコンテナのIDそのまんまだったりします。
#ブラウザでIISを確認する
せっかくIISのコンテナを実行したので、IIS（Webサービス）にアクセスできることを検証しましょう。
まずはコンテナのコンピュータのIPアドレスを調べます。IPアドレスはdocker inspectコマンドで出力されるJSONデータの中にあります。とりあえずJSONデータを全部ローカルのファイルにコピーします。docker inspectコマンドにはコンテナIDを指定します。
IPアドレスを見つけました。
このIPアドレス、ネットワーク上の他のIPアドレスと同じようにpingしたりできます。こういう雰囲気が「コンテナ技術」と「仮想マシン技術」との混乱の原因のようです。「仮想化」されているのではなく「隔離」されているだけなんです。
さてブラウザで確認してみましょう。ちなみにポートはデフォルトの80なので指定する必要はないですね。
おなじみのIISのデフォルト画面が表示されました。
このページはコンテナではC:\inetpub\wwwrootにあるiisstart.htmに対応してます。
実験として簡単な別のテキストファイルを置いてみましょう。
test.txtというファイルが出来ました。
このファイルもブラウザで確認してみます。
ちゃんとアクセスできました。こんな感じでコンテナ内のファイルシステムを自由に変えらることが確認できました。
では、いったんコンテナを止めます。PowerShellをentrypointとして指定したので、PowerShellを終了させることがすなわちコンテナを終了させる、ということになります。
無事、ホストのCDMプロンプトに帰ってきました～。
#Dockerで作業用のボリュームを設定する
Dockerコンテナを利用してなんらかの作業（たとえば開発中のウェブアプリケーションのテスト）を行う場合、簡単にアプリケーションの内容を変更できる環境が必要になります。
そのためにはDockerのボリューム機能を利用します。
Dockerで簡単にボリュームを設定するやり方のうち、二つを紹介します。
#[方法その１] ホスト側のディレクトリをマウントする
ホストにあるフォルダーをコンテナのドライブの一部として接続します。
ホスト側にはごく簡単なウェブサイトを用意します。
次にDockerコンテナを実行する際に、ホスト側のフォルダーをコンテナ側のフォルダー（存在していなくてもよい）として指定します。-v オプションがその部分です。
コンテナがスタートして、PowerShellコマンドが出てきたら、とりあえずコンテナ側でIISのDefault Web Siteがマップされているディレクトリを表示してみましょう。（下のPowerShellコマンドを上から順に実行してください）
予想通りデフォルトのC:\inetpub\wwwrootにマップされてますね。おなじみのIISのページはここにありますね。
では、これを変更して、マウントしたホストのフォルダーを指し示すようにします。この操作はWebAdministrationPowerShellモジュールに含まれるSet-ItemPropertyを使います。この操作はDockerとは関係ありません。あくまでも単なるPowerShell操作です。
変更完了。ブラウザでチェックしてみましょう。
ちゃんとマウントされたホスト側のフォルダーにマップされました。
#ホストからウェブサイトを編集してみる
せっかくですから、ホスト側からサイトの内容をちょと変更してみます。
こんな感じでパラグラフを加えました。
ブラウザで確認してみましょう。
ちゃんと反映されてますね～。
#[方法その２]コンテナ側のディレクトリにアクセスする
次に、コンテナの方に新にボリュームを作成するようにDockerに指定し、その新規ボリュームにホストからアクセスする手順を解説します。
イメージにはもともとないボリューム（Windowsの場合はトップレベルのディレクトリと考えましょう）が無い場合でも、コンテナを実行する際に新たにボリュームを作成するように指定できます。下の-v C:\mywebappオプションではコンテナ側にC:\mywebappを作成します。
C:\mywebappが作成されたのが確認できます。
なにか適当にファイル操作をしてみましょう。
test.txtというファイルを作成してみました（単なるPowerShellの操作です。Dockerとは関係ありません）
ただ、PowerShell使ってファイルやディレクトリを操作するのは面倒くさいです。ホスト側からコンテナ内のこのボリュームの内容を操作したいですよね。やってみましょう。
#ホスト側からコンテナ内の作業用ボリュームの内容を変更する
まずはコンテナのメタデータを調べたいので、docker inspectを実行します。
つぎにボリュームに関する設定を探します。以下のようにsourceとして指定されているDockerが管理しているディレクトリ情報を探し出します。
このディレクトリをWindowsエクスプローラーで表示してみましょう。例のtest.txtというファイルがあるのが確認できます。
ファイルに変更を加えます。
あれあれ、保存しようとするとアクセス権限に関連したエラーが出ます。
ここでファイルのセキュリティ設定を変更し、ホストのユーザーに書き込み・変更権限を与えてます。
するとエラーにならずに保存が出来ました。
注意：私が調べた限りではホスト側からアクセス権限を変更した場合、Dockerエンジンへ何らかの影響があるのかどうか、分かりませんでした。得にDockerがボリュームを管理しているという点を考えるとこのハックが悪影響を及ぼす可能性を排除できません。自己責任でよろしく！
最後にコンテナ側から内容が変更されたかチェックしてみます。
ホスト側からの変更が反映されているのが確認できます。
#まとめ
IISのDockerイメージを使ってごく簡単なウェブサイトの開発環境っぽいものを作ってみました。ASP.NETやらASP.NETCoreやらもだいたい同じようなパターンでDockerコンテナを利用できるでしょう。