しばやん雑記

Azure とメイドさんが大好きなフリーランスのプログラマーのブログ

HoloLens を使ってゲームが出来るのか試してみた

2017 年だし、ホログラフィック(自称)と名乗ってるし、このゲームは遊んでおかないといけないと思ったので、蛎殻町に放置されていた HoloLens を整備して試しました。

UWP 版の Remote Desktop アプリケーションを使って、ゲームをインストール済みのマシンに接続しました。Clicker が見つからなかったので、全ての操作をエアタップで行ったので腕がつりそうでした。

画面サイズはドラッグで自由に大きく出来るので、下の画像は 100 インチは超えてる気がします。

ちゃんと Remote Desktop でも音が出ます。少し帯域が足りない感じがしますが、Device Portal から Live Preview などを使わなければ割と頑張れました。

右クリックはゲームによっては出来ない場合がありそうなので、少し不便です。

App-V とかでアプリの画面だけを表示できれば、結構いい感じに遊べると思いました。キャラクターの声が耳元から聞こえてくるのは、やばさがあったと思います。HoloLens ネイティブのゲームを体験したい。

蛎殻町の若者やぶちぞう RD から Xbox One のゲームストリーミングが使えるのでは、と指摘を受けたので HoloLens を借りて自宅の Xbox One に接続してみました。

f:id:shiba-yan:20170215215832j:plain

スペック不足とか言われるのかと思いましたが、すんなりと本体が見つかってストリーミング接続できました。折角なので Forza Horizon 3 をプレイしてみました。

自宅の Wi-Fi は 11ac に対応しているので、思ったより遅延なくプレイできました。

アプリケーションは UWP にしか対応していないのが、正直もったいなく感じます。Unity は使える気がしないですが、UWP を使って HoloLens 向けのアプリケーションを作ってみたい気持ちになりました。

あと、やっぱり視野角が狭すぎると思うので、次のバージョンではもっと広くなって欲しいです。

AMI 向けに Sysprep 応答ファイルを使ってタイムゾーンとシステムロケールの設定を行う

Windows Server の AMI を作成する時に必要な sysprep を実行すると、デフォルトではタイムゾーンが UTC でシステムロケールが en-US になってしまうので、sysprep の応答ファイルを用意して変更してみます。

AWS のドキュメントに sysprep と応答ファイルについて記載があります。

SystemLocale と TimeZone を変更して、sysprep を実行すれば上手くいきそうな感じです。

EC2 の Windows Server AMI を使うと、デフォルトの応答ファイルが予め用意されているので、それに対して変更を行ってから sysprep をすることにします。User Data で実行したいので PowerShell で書きます。

PowerShell で名前空間付きの XML を扱う場合の方法は、以下のページを参考にしました。

Sysprep の応答ファイルは 2012 R2 と 2016 で特に変わっていないので、関数として切り出しておきました。実際に書いたコードは以下のような感じです。

function Update-SysprepAnswerFile($answerFile)
{
    [xml] $document = Get-Content $answerFile -Encoding UTF8

    $ns = New-Object System.Xml.XmlNamespaceManager($document.NameTable)
    $ns.AddNamespace("u", $document.DocumentElement.NamespaceURI)

    $settings = $document.SelectSingleNode("//u:settings[@pass='oobeSystem']", $ns)

    $international = $settings.SelectSingleNode("u:component[@name='Microsoft-Windows-International-Core']", $ns)
    $shell = $settings.SelectSingleNode("u:component[@name='Microsoft-Windows-Shell-Setup']", $ns)

    $international.SystemLocale = "ja-JP"
    $international.UserLocale = "ja-JP"

    $shell.TimeZone = "Tokyo Standard Time"

    $document.Save($answerFile)
}

XPath で応答ファイルの要素を引っ張ってきて、要素の値を書き換えて保存するだけのコードです。なんとなく SystemLocale だけではなく UserLocale も ja-JP に変更しておきました。

TimeZone の値は tzutil で指定するものと同じなので、少し書き方に注意したいです。

Windows Server 2012 R2 までは EC2Config を使って sysprep を実行しますが、Windows Server 2016 では EC2Launch を使う形に変更されたので、それぞれの OS 向けにスクリプトを変更して記載しておきます。

Windows Server 2012 R2

EC2ConfigService の中に存在する sysprep2008.xml が応答ファイルです。sysprep 自体も ec2config.exe にパラメータを渡して実行します。

function Update-SysprepAnswerFile
{
   # 省略
}

Update-SysprepAnswerFile "$env:ProgramFiles\Amazon\Ec2ConfigService\sysprep2008.xml"

# Execute sysprep
& "$env:ProgramFiles\Amazon\Ec2ConfigService\ec2config.exe" -sysprep

割とシンプルなスクリプトになりました。このスクリプトを実行して作成した AMI を使ってインスタンスを起動すると、システムログに設定した言語やタイムゾーンの情報が表示されています。

f:id:shiba-yan:20170202000804p:plain

ちゃんと ja-JP Tokyo Standard Time になっています。

リモートデスクトップで接続して確認しても、設定が変更されていることが確認できました。

f:id:shiba-yan:20170202003910p:plain

日本語言語パックをインストールしてから UILanguage を設定すると日本語にも出来る気がします。

Windows Server 2016

EC2Launch では PowerShell ベースになっているので、手順が少し変わっています。公式ドキュメントに sysprep の手順が書いてあるので、まずは熟読しておきました。

応答ファイルのパスも変わっているので、少し注意したいです。特に InitializeInstance.ps1 の Schedule パラメータを忘れないようにしたいです。ダメなイメージが完成します。

function Update-SysprepAnswerFile
{
   # 省略
}

Update-SysprepAnswerFile "$env:ProgramData\Amazon\EC2-Windows\Launch\Sysprep\Unattend.xml"

# Execute sysprep
cd "$env:ProgramData\Amazon\EC2-Windows\Launch\Scripts"
.\InitializeInstance.ps1 -Schedule
.\SysprepInstance.ps1

2012 R2 の時と同じようにイメージを作成して、新しくインスタンスを作成するとシステムログに設定した言語とタイムゾーンが表示されているので、変更されてるのが分かります。

f:id:shiba-yan:20170202000705p:plain

そしてリモートデスクトップで接続して、システムロケールが変わっていることを確認しました。

f:id:shiba-yan:20170202003836p:plain

システムロケールの設定は再起動が必要になるので自動化がいまいちやりにくい部分でしたが、sysprep を使って AMI を作成する場合では User Data を使って自動化が行えます。

以前書いた Elastic Beanstalk 向けの Custom AMI と同じように CI で作れそうです。

特に Elastic Beanstalk はベースとなる AMI を変更できないので、User Data を使って Custom AMI を作成しないと辛い部分が出てきそうです。ebextensions は割とすぐに限界が来ました。

Surface Pro 4 が価格改定で安くなっていたので買ってみた

今日、突然の価格改定で Surface Pro 4 がかなり安くなりました。SKU によって異なってますが 1.3 万から 7.8 万の値引きはかなりインパクトのあるものでした。

型落ち寸前とはいえ Skylake で NVMe な SSD なので、普段使いには十分のはずです。

https://www.microsoft.com/ja-jp/atlife/campaign/surface/

運悪くツイートを見てしまったので、蛎殻町を抜け出してアキヨドに実物を見に行きました。

15 分後、蛎殻町に戻った時には Surface Pro 4 の Core i5 / 256GB / 8GB *1のモデルを手にしていました。このモデルは 3 万ほど値下げされていたので 14 万ちょいです。

f:id:shiba-yan:20170116164124j:plain

とりあえずセットアップを終わらせて、Windows Hello がやはり最高と思ったりしてました。手持ちの MacBook Pro も全て Windows Hello 対応にしてあります。

f:id:shiba-yan:20170116234434p:plain:w600

ふと、流石に 1 年前とは異なるハードにアップデートされているのでは、と思ったので SSD のパフォーマンスだけ調べました。これまでの SSD の速度はいろんなメディアに上がっていました。

Write が遅いのが特徴のようですが、今日買ったモデルは明らかに Write のパフォーマンスが向上していました。メーカはこれまでとは異なり東芝製が使われていました。

f:id:shiba-yan:20170116175201p:plain:w450

後期型になるとちょいちょいとアップデートされているみたいなので、少し得した気分です。Surface Pro 5 が出たとしても、あまり変化は無いと思うので良い買い物をしたと思ってます。

この Surface Pro 4 には主にゲームを入れていく予定です。ピンボールとか。

*1:一般的には 1 かずあきと呼ばれる容量

Windows Containers の挙動について気になった部分だけ調べてみた

タイトルの通り、個人的に Windows Containers を弄ってみて、気になった部分だけを少し調べました。調べ始めるきっかけは Cloud Services で Docker デプロイしたいってことだった気がします。

結局それはダメだったの、Azure Container Service の Windows 対応に期待してます。

Windows Server Containers は C: に Windows が必要

この制約は知りませんでした。Twitter でぶちぞう RD に教えてもらいました。

カーネルをホストと共有する関係上、決め打ちにならざるを得なかったのかしれません。当たり前という感じですが、Hyper-V Containers の場合はこの影響を受けません。

Windows Server Container hosts must have Windows installed to c:. This restriction does not apply if only Hyper-V Containers will be deployed.

Windows Container Requirements

Azure VM などに Windows Server 2016 をデプロイすると、デフォルトで C: にインストールされるので問題ないですが、この制約の影響を全力で受けそうなのが Cloud Services ですね。

Cloud Services では Windows が D: にインストールされているので、そこに依存している App Service の Windows Containers 対応は難しそうです。

コンテナのカルチャとロケール

既にパブリッククラウド向けにアプリケーションを開発している場合には影響しないと思いますが、地味に気になるのがシステムのカルチャとロケールです。それぞれで簡単に確認しておきました。

まずは Windows Server Containers を使って確認します。いつも通り docker run を使います。

docker run -it microsoft/windowsservercore powershell

f:id:shiba-yan:20161203004030p:plain

Windows Server Containers を使って起動したコンテナの場合は、ロケールがホストと同じになるようです。つまり、開発環境では Japanese だけども、クラウドに持っていくと English に変わるということです。

次に Hyper-V Containers を使って確認します。--isolation=hyperv を付けるだけの違いです。

docker run -it --isolation=hyperv microsoft/windowsservercore powershell

f:id:shiba-yan:20161203004332p:plain

Hyper-V Containers を使って起動したコンテナでは、ロケールはホストとは異なり英語になりました。名前の通り Hyper-V を使っているだけあって、通常の VM に近い挙動ですね。

ロケールは変更が出来ないようなので、アプリケーション側で依存しないように作る必要があります。

コンテナのタイムゾーン

いい加減に UTC と JST で失敗する人は少なくなってると思いますが、一応確認しておきます。一般的なクラウドサービスのタイムゾーンは UTC となっているので、依存するのはそもそも NG です。

f:id:shiba-yan:20161203010240p:plain

f:id:shiba-yan:20161203010350p:plain

文字化けしてますが Windows Server Containers と Hyper-V Containers 共にホストのタイムゾーンが反映されていました。開発環境では問題なくても、本番に持っていくと失敗するタイプなので注意しましょう。

要するに Azure App Service などの、ロケールやタイムゾーンが変更できない系 PaaS を使っているアプリケーションは、あっさりと Windows Containers でも動作しそうです。

Windows Containers 上で動かしている IIS に URL Rewrite や ARR をインストールする

Microsoft が Docker Hub に公開している IIS や ASP.NET のイメージは必要最低限のコンポーネントしかインストールされていないので、このままだといろんなものが足りません。

何がインストールされているかは Dockerfile を見ると書いてあります。

イメージ間の依存関係としては Windows Server Core => IIS => ASP.NET となっています。当然ながら Server Core なのでデスクトップエクスペリエンスがインストールされていません。

Server Core なので、これまで必要なパッケージのインストールで便利に使ってきた Web PI が残念ながら使えません。Server Core を考慮した作りになっていないようです。

Occasionally, though, you might find yourself in a situation where you still prefer to avoid using the WebPI installation option. For example, one such scenario is when installing ARR on the Server Core edition of Windows, where WebPI cannot be used.

Installing ARR manually without WebPI – Erez's IIS Blog

仕方がないので MSI をダウンロードして手動でインストールしてやります。

Dockerfile 内で MSI をダウンロードして、サイレントインストールを行うようにします。IIS モジュールはどれが最新なのかわかりにくいのが欠点ですね。

FROM microsoft/aspnet:4.6.2

ADD https://download.microsoft.com/download/C/9/E/C9E8180D-4E51-40A6-A9BF-776990D8BCA9/rewrite_amd64.msi /install/rewrite_amd64.msi

RUN msiexec.exe /i c:\install\rewrite_amd64.msi /passive & \
    rd /s /q c:\install

この Dockerfile を使ってビルドすると、URL Rewrite Module がインストールされたイメージが完成します。ADD でダウンロード URL を指定できるのは、Invoke-WebRequest の必要がないので便利です。

f:id:shiba-yan:20161125223427p:plain

大体の場合では URL Rewrite があれば足りる気がします。

リバースプロキシを使いたい場合などで、ARR 3 が必要な場合は URL Rewrite Module のインストール後に処理を追加します。Dockerfile は変わらずシンプルなままです。

FROM microsoft/aspnet:4.6.2

ADD https://download.microsoft.com/download/C/9/E/C9E8180D-4E51-40A6-A9BF-776990D8BCA9/rewrite_amd64.msi /install/rewrite_amd64.msi
ADD https://download.microsoft.com/download/E/5/4/E5460BC3-3D6E-42BB-84AF-91EFF1EB14D4/requestRouter_amd64.msi /install/requestRouter_amd64.msi

RUN msiexec.exe /i c:\install\rewrite_amd64.msi /passive & \
    msiexec.exe /i c:\install\requestRouter_amd64.msi /passive & \
    rd /s /q c:\install

RUN %windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/proxy /enabled:"True" /commit:apphost

原因はよくわかりませんが、MSI でインストールしただけでは proxy が有効にならなかったので appcmd を使って有効化するようにしました。

作成したイメージを起動して、アタッチすると ARR がインストールされているのが確認できます。

f:id:shiba-yan:20161125223259p:plain

最後に作成したイメージを使ってリバースプロキシを立ち上げてみます。動作確認なので、リバースプロキシルールだけを定義した Web.config と Dockerfile を用意しました。

FROM arr3

COPY Web.config /inetpub/wwwroot
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="ReverseProxyInboundRule1" stopProcessing="true">
          <match url="(.*)" />
          <conditions>
            <add input="{CACHE_URL}" pattern="^(https?)://" />
          </conditions>
          <action type="Rewrite" url="{C:1}://buchizo.wordpress.com/{R:1}" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

これまでと同じように docker build を使ってイメージを作成し、コンテナを起動します。

f:id:shiba-yan:20161125233310p:plain

docker inspect で取得した IP アドレスをブラウザで開いてみると、ちゃんとリバースプロキシとして動作していることが確認できます。イメージを作ってしまえば、後はとても簡単でした。

f:id:shiba-yan:20161125233340p:plain

基本となる ARR 3 がインストールされたイメージは共通で使えるので、同じように必要なコンポーネントをインストールしたイメージを作成しておくと楽ができそうです。

環境を丸ごとイメージとしてポータブルな形で保持できるのは、想像以上に快適な世界でした。

Xbox One S を買ったので 4K HDR の設定と UHD-BD の再生を試してみた

f:id:shiba-yan:20161124205110j:plain

今のところゲームをする予定はないのですが、4K と UHD-BD に対応しているという点に惹かれたので Xbox One S を買いました。一応 UWP の開発にも使えるのでアンロックはします。

折角 4K HDR に対応したテレビを持っていても、コンテンツがストリーミングの 4K しかない状態でしたが、これでやっと UHD-BD で 4K HDR を楽しめそうです。

ということで、シアトルの Best Buy で The Martian の UHD-BD を買っておきました。

日本語字幕は入っていませんが、日本で買う場合の半額ぐらいで買えました。

Xbox One S とテレビを接続して電源を入れたら、4K テレビだと認識されて解像度は切り替わりましたが、HDR は有効にならなかったので少し悩みましたが、テレビの設定が必要だったようです。

HDMI入力端子に接続した機器の映像を高精彩なHDMI 4Kフォーマット*で表示するには、[外部入力設定]の[HDMI信号フォーマット]を設定します。
HDR機能に対応しているかどうかは、お使いのテレビによって異なります。

http://helpguide.sony.net/tv/cjp1/v1/ja/contents/TP0000909440.html

接続した HDMI の設定を変更することで、Xbox One S から 4K HDR フル対応と認識されました。

f:id:shiba-yan:20161124230101p:plain

スクリーンショットの撮り方が分からなかったので、Windows 10 でストリーミングしました。

UHD-BD のディスクを入れると BD プレイヤーアプリのダウンロードが行われて、そこから再生が始まりました。少しドライブの回転音がうるさい気がしましたが、再生中は静かになりました。

f:id:shiba-yan:20161124215936j:plain

買ってまだ 1 年も経っていないサウンドバーは HDR のパススルーに対応していないということだったので、仕方なく ARC で繋ぐだけという形にしておきました。

途中で Xbox One S からの音声が全く再生されないという謎現象に見舞われましたが、テレビを再起動すると問題なく再生されるようになりました。いい加減に Android TV は安定してほしいです。

シアトルで MADOSMA Q601 を T-Mobile LTE で使ってみた

iPhone 7 Plus に機種変しましたが、docomo 版なので SIM ロックフリーになっていないので MADOSMA Q601 に T-Mobile の SIM を刺して使うことにしました。

T-Mobile の LTE バンドは 2,4,12 らしいですが、メインはバンド 4 ということなのでこれに非対応だと辛いです。AWS バンドは国内端末だと期待できないですが、Q601 は対応しています。

実際に SIM を刺して使ってみましたが、デフォルトで入っている APN だと LTE に繋がらない気がしたので、手動で入力してみました。

パスワードなど必要なく fast.t-mobile.com を入力するだけです。

f:id:shiba-yan:20161114095436p:plain:w450

後はよくわかっていないですが、地域を念のため米国にしておきました。

f:id:shiba-yan:20161114111533p:plain:w450

この二つの設定を行った後、端末を再起動すると LTE で繋がるようになりました。Q601 が海外での W-CDMA に対応していないみたいなので、LTE で繋がらないと 2G になるので死活問題です。

f:id:shiba-yan:20161114111544p:plain:w450

ちなみに MADOSMA Q601 は 5GHz 帯の Wi-Fi テザリングに対応しているので、結構快適に使えます。バッテリーも多いのでテザリングで 1 日中使えます。

SeaTac で速度を試してみたところ、下りで 30Mbps ぐらい出たので結構満足出来ます。下手なホテルの Wi-Fi より速いかもしれないです。

f:id:shiba-yan:20161114095302p:plain:w450

速度は速いですが、T-Mobile の LTE は容量制限があるので注意が必要です。今回は 2 週間近く滞在する予定だったので、LTE で 10GB まで使えるプランを契約しました。

$60 で少し高いですが、docomo の海外プランより圧倒的に安いので払いました。

f:id:shiba-yan:20161114095322p:plain:w450

10GB を使い切ってしまうと LTE での通信が出来なくなるみたいなので、Q601 だと強制的に 2G になります。出来ることなら W-CDMA にも対応してほしかったですね。

Surface Dial を発売日に並んで買ってみた話

偶然にも Surface Dial の発売日にシアトルに滞在していたので、Microsoft Store に開店時間前から並んで買ってきました。公式ブログでは今日から発売と書いてあるのに、何故か入荷してないとか言われましたが、何とか 1 個だけ買うことが出来ました。

$99 に税金がかかって大体 $108 ぐらいになりました。カードの PIN 忘れて通らなかった時は焦りました。

英語ペラペラのぼんぷろ先生曰く、入荷が結構少なかったとか何とか。

f:id:shiba-yan:20161110150224j:plain

気を取り直して、早速 Surface Dial を持って行っていた MacBook Pro 上の Windows 10 とペアリングしてみました。自動的にドライバがインストールされて使えるようになります。

f:id:shiba-yan:20161111040512p:plain:w450

ペアリングが完了すると、設定画面にホイールという項目が増えます。ここで Surface Dial の設定が行えるようになってますが、そこまで項目は多くなかったです。

f:id:shiba-yan:20161111040338p:plain

このメニューは Surface Dial を長押しすると表示されます。アクションが発生した時にはブルブルと震えるようになっていて、分かりやすい感じです。

スクロールだけでもかなり快適な感じでしたので、長い文章読む時などに使いたい感じです。

f:id:shiba-yan:20161111081247p:plain:w450

まだ対応アプリは少ないみたいですが、Surface Dial に対応しているアプリはストアのアイコンが変化してわかるようになっているみたいです。違うっぽいです。

Surface Studio のデモでよく使われている Sketchable は Surface Dial 対応になっていました。

f:id:shiba-yan:20161111050149p:plain:w450

Surface Studio ではないので画面に置いたりできないですが、普通に利き腕の反対側に置いておくとくるくる回して使うのが楽だったので、アプリが増えると楽しくなりそうです。

Surface Dial interactions

ちゃんと API のドキュメントが用意されているので、動画を見ている時にシークバーを動かすアプリとかを作ってみたいですね。マウスやトラックパッドで操作するのは難しすぎるので。

Docker で Windows Containers を使った時にコンテナホストから localhost でコンテナが見えない件

前に Windows Containers を使って IIS を立ち上げた時、コンテナホストから localhost でコンテナで動作しているはずの IIS を確認しようとしても出来なかったのですが、理由が分かったので書きます。

ちなみに Docker と Windows Containers については前のエントリを見てください。

世界の RD ことぶちぞうさんからは「お前の設定が悪い」みたいなことを Twitter で言われましたが、実際のところ内部で使われている WinNAT の制限で見れないだけでした。

あとから追記された感はありますが、ちゃんと IIS の Docker Hub に書いてありました。

With the current release, you can't use http://localhost to browse your site from the container host. This is because of a known behavior in WinNAT, and will be resolved in future. Until that is addressed, you need to use the IP address of the container.

https://hub.docker.com/r/microsoft/iis/

WinNAT については以下の記事にまとまっていました。コンテナ対応のために色々と追加されてますね。

Windows NAT (WinNAT) — Capabilities and limitations | Virtualization Blog

結局のところ、今は localhost を使ってアクセスは出来ないので、代わりにコンテナに割り当てられている IP アドレスを直接指定する必要があるみたいです。実際に Docker を使って試してみました。

まずは Docker を使って IIS を起動します。本来なら localhost:80 がコンテナにフォワーディングされるはずですが、今は対応していないということです。

docker run -d -p 80:80 microsoft/iis

念のためアクセスしておくと、コンテナホストにそのまま繋がっているような感じです。

f:id:shiba-yan:20161031193012p:plain

ここで docker inspect を使ってコンテナの IP アドレスを取得するコマンドを実行します。

docker inspect -f "{{ .NetworkSettings.Networks.nat.IPAddress }}" CONTAINER_ID

実行すると IP アドレスが返ってきます。割り当てられる IP アドレスの範囲は docker network inspect コマンドを叩くことで確認することが出来ます。

f:id:shiba-yan:20161031192917p:plain

取得した IP アドレスを使うと、ちゃんと IIS のいつものページが表示されました。

ちゃんとコンテナホストからアクセスできることが確認できましたが、正直めんどくさいですね。

f:id:shiba-yan:20161031193045p:plain

起動ごとに IP アドレスは新しく振り直されるようなので、そのままだと毎回変わってしまって非常に扱いにくいですが、--ip オプションで IP アドレスを渡すことで一応固定は出来るみたいです。

docker run -d -p 80:80 --ip=172.29.72.198 microsoft/iis

指定できる IP アドレスはサブネット内じゃないとエラーになるので、予め docker network inspect を叩いて、サブネットを確認しておきましょう。

f:id:shiba-yan:20161031200537p:plain

デフォルトで nat というネットワークが作成されているので、このネットワークのサブネットを確認するだけです。どっちにしろめんどくさいので、早く WinNAT が対応されるように祈り続けたいと思います。

Windows Server 2016 の Docker から Hyper-V Containers を利用する

前のエントリでは Windows Containers を使いましたが、Hyper-V Containers も Docker から使えるらしいので実際に試しました。Docker と Windows Containers を試した環境をそのまま使ってます。

検索してみると Cmdlet を使って Hyper-V Containers を管理する方法ばかり出てきますが、ちゃんと Docker を使った管理にも対応していました。

Windows Containers と Hyper-V Containers には互換性があるみたいなので、docker pull で取ってきたイメージを起動する時に引数を追加するだけで、Hyper-V Containers で起動できました。

docker run -d -p 80:80 ––isolation=hyperv microsoft/iis

具体的には --isolation=hyperv を付けるだけです。これだけで切り替え可能です。

実際に前回 docker pull してきた IIS イメージを Hyper-V Containers を使って実行してみました。Windows Containers を使う場合より数秒は起動が遅い気がしますが、仮想マシンを立ち上げるより十分高速です。

f:id:shiba-yan:20161016205614p:plain

タスクマネージャーを見ると Hyper-V 絡みのプロセスが立ち上がっています。ユーザー名には GUID が振られていますが、docker コマンドから確認することは出来ないようでした。

IIS が起動しているのにワーカープロセスが居ないので、Hyper-V で動いていることが分かります。

f:id:shiba-yan:20161016205854p:plain

ブラウザでアクセスすると IIS のデフォルトページが表示されているので、IIS がちゃんと動作していることも確認できました。Hyper-V Containers を使うのはとても簡単ですね。

f:id:shiba-yan:20161016205919p:plain

あまりにも簡単に動作してしまったので、ついでに最近公開された SQL Server 2016 Express の Docker イメージを試しました。とはいえ docker pull して起動するだけです。

パスワードを渡すだけで SQL Server 2016 Express の環境が数秒で整うのはかなり便利です。

f:id:shiba-yan:20161016212508p:plain

当然ながら SSMS で接続して自由に操作できます。Hyper-V Containers は Windows 10 でも使えるらしいので、Hyper-V に対応したマシンなら環境構築が楽になりそうですね。

手持ちの MacBook Pro が Hyper-V に対応していないので、試せていないのが残念ですが。