しばやん雑記

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

Windows Server 2019 時代の Windows Containers を使ったアプリケーション移行

Kubernetes が 1.14 から Windows Server 2019 をサポートするようになり、周辺ツールやサービスも整ってきた現状、今年こそ Windows Containers がぼちぼち使われるようになるのではないかと思っています。と言っても新規開発は ASP.NET Core を推奨しているので、基本は既存のアプリケーションの移行目的です。

まだ AKS で Windows Node を作ることは出来ないですが、例によって AKS-Engine を使うと作れるようです。最近は k8s への興味が薄れつつあるので AKS が対応するまでは試さないです。

今回 k8s でサポートされたのは Windows Server 2019 だけっぽいので、2016 は捨てていく方向で良いと思います。2016 では Docker Image サイズ削減の恩恵も受けられないですし、リビジョンが違うとサポートを受けられないのは致命傷です。

毎年言ってる気がしますが、今度こそ一通り必要な環境やサービスが整ったと思うのでまとめます。

Docker Image

去年から徐々に MCR に移行が進んできましたが、今月になって .NET Framework / .NET Core の Docker Image が MCR に移行されたので、これで移行はほぼ完了となります。

Docker Hub を指している方は今後更新されなくなるはずなので、早めに差し替えておきましょう。移行先の情報は Docker Hub か以下の記事を確認してください。

具体的な例を挙げると .NET Framework を使っている場合は、以下の 2 つだけ覚えておけば良いです。

  • mcr.microsoft.com/dotnet/framework/sdk:4.7.2-windowsservercore-ltsc2019
  • mcr.microsoft.com/dotnet/framework/aspnet:4.7.2-windowsservercore-ltsc2019

Windows Containers を使う場合には、今後は ltsc2019 を指定しておけば良いです。.NET Core の場合も同じような命名なので覚えやすいはずです。

開発環境

Visual Studio 2017 では ASP.NET アプリケーションを Docker 化する場合には、何故か Docker Compose が必須になっていました。専用のプロジェクトも追加されて使い勝手が悪かったです。

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

来月リリースされる Visual Studio 2019 では、ASP.NET Core と同じように Dockerfile だけが追加されるシンプルな形式に変わります。

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

Visual Studio を使ったデバッグはこれまで通り行えるので、別に Docker になったからといって使い勝手が変わることは特にありません。しいて言えば初回の Docker Image の pull に時間がかかるぐらいです。

現実問題として Windows Containers を使いたいケースは実行環境のカスタマイズ系だと思うので、ベースとなるイメージを CI などで作っておくことで、ある程度のタイミングは制御可能でしょう。

CI / CD

必ず必要になってくるのが CI / CD です。単純に Dockerfile から Image を作って ACR にプッシュするだけなら ACR Tasks を使って簡単に用意できます。

ACR Tasks は既に Windows Server 2019 にアップデートされているので安心です。

もう少し複雑なリリースを行いたい場合は Azure Pipelines を使います。こっちも少し前に Windows Server 2019 と Visual Studio 2019 に対応した Hosted Agent が追加されています。

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

残念なことに Windows Server 2019 の Docker Image がキャッシュされていないのでビルド毎に無駄な時間が発生しますが、今後の Agent アップデートで直ると思います。

地味に嫌な問題としては公開されている .NET Framework SDK の Docker Image をそのまま使うと、ASP.NET アプリケーションのプリコンパイルに失敗するというのがありましたが、回避策があるのと Visual Studio 2019 の SDK によって解決しそうです。

Visual Studio 2017 の MSBuild が .NET 4.6.2 SDK をデフォルトで見るようになっているので、4.7.2 SDK しか入っていない Docker Image で失敗するという話でした。

実行環境

先述したように Kubernetes が Windows Server 2019 をサポートしたことで、近いうちには AKS でも簡単に Windows Server 2019 の Node が作成可能になるのではと思っています。*1

Web App for Containers (Windows) も順調にアップデートを重ね、まあまあ使えるようになってきた印象です。少し前に Windows Server 2019 へのアップデートも行われています。

GitHub ではちょっとマニアックなサンプル Dockerfile も公開されています。

この辺りの作業は VM 向けの Image を作るのとあまり変わらないので、Dockerfile を書いて環境をカスタマイズしていく形です。Server Core なので少し注意が必要ですが。

まとめ

実際のところ 98% は通常の App Service に移行が行えると思っているので、ソフトウェアのインストールが必要だったり、サンドボックスで制限されている機能を使っている 2% を VM や k8s を使って動かすのではなく、マネージド環境で動かしたいときに使うものだという認識です。

Docker Image が大きくて扱いにくいという問題は抱えつつも、環境自体は Linux と同じような構成を取れるようになったので、主にエンプラ向けで活躍できるのではないかと思います。

*1:ARM Template を使えばこれまでもデプロイは出来ていたけど

Windows 10 で Process Isolation を使う時の注意点など

Docker Engine 18.09.1 と Windows 10 Version 1809 の組み合わせ時に Process Isolation *1 が使えるようになっています。Windows Server Containers は Hyper-V Containers より軽量なので助かります。

早速弄っていましたが、クライアント OS で使う場合にありがちな問題に当たったので、調べてメモとして残します。Windows Server で使う場合には問題になりにくいです。

Process と Hyper-V で ACL が異なる

例えば Nano Server を Process Isolation かつ Volume をマウントして起動してみます。

docker run --rm --isolation=process -v "C:\Users\shibayan\source\repos\AspNetCore:C:\AspNetCore" \
           -it mcr.microsoft.com/windows/nanoserver:1809 cmd

この時にマウントしたディレクトリを確認しようとすると、アクセスが拒否されます。

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

Hyper-V を使った場合は問題なくアクセス出来るのに、Process の場合は拒否されるので割と悩んでいましたが、以下のドキュメントに答えが載っていました。

Hyper-V の場合は単純に RO / RW という制御しかされないみたいですが、Process の場合は NTFS の ACL が使われるので、コンテナ内の実行ユーザー次第でアクセスが出来ないという話でした。

特に Nano Server は 1709 から実行ユーザーが ContainerAdministrator から ContainerUser に変更されているため、マウントするファイルに権限を付けるか、実行ユーザーを変更する必要があります。*2

ドキュメントには Authenticated Users が載っていたので、とりあえず付けて試します。

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

これでコンテナから再度アクセスしてみると、問題なくディレクトリを確認出来ました。

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

通常はサーバー OS でこういった使い方はしないので、Windows 10 で使えるようになると似たような問題が他にも出てきそうな気がします。

ちなみに Server Core の場合は ContainerAdministrator で動いているのと、ACL に大体は Administrators が入っているので問題ないみたいです。

Visual Studio からは一部利用不可

Process Isolation で Nano Server を使った場合に ACL 周りで問題が発生するため、Visual Studio のコンテナサポートを使った ASP.NET Core アプリケーションの開発は行えなくなります。

イメージのビルドまでは問題なく行えますが、デバッグ実行では Visual Studio が User Profile 以下にあるファイルをマウントしようとするため、リモートデバッガのプロセスを起動できずに失敗します。

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

ASP.NET アプリケーションの場合は Server Core を使うので、問題なく Process Isolation でもデバッグ実行が行えます。Docker Compose を使おうとしたり、ベースイメージが古かったりと罠が多いですが、Hyper-V よりは素早く起動してくれます。

Default Isolation を Process に変更する

今のところ Visual Studio には Isolation を設定する機能などはないので、Process Isolation を使う場合には Default 自体を変更しておく必要があります。

Docker Deamon の設定に exec-opts を追加するだけなので簡単です。

{
  "exec-opts": [
    "isolation=process"
  ]
}

Docker の設定から Advanced を選べば JSON を書けるようになっているので、以下のように追記します。

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

これで設定を保存すると Default Isolation が hyperv から process に変わります。

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

Default Isolation を Process にしていても LCOW は問題なく Hyper-V で動くので、Volume 周りの影響を受けない場合は Process を使うと素早くコンテナを実行出来るので便利です。

*1:Windows Server Containers と呼ばれているやつ

*2:Nano Server の ContainerAdministrator は将来的に削除される予定なので注意

Windows Server 2019 の Docker Image と MCR への移行

停止されていた Windows Server 2019 の公開がようやく再開されました。同時に Windows Server 2019 ベースの Server Core / Nano Server イメージも公開が再開されています。

これでようやく LTSC なバージョン上でサイズが縮小された Docker Image を使う準備が出来ました。

既にこれまで Windows Server 2016 を使っていたイメージに 2019 版が追加され始めています。主に .NET Framework 周りは対応が早く、既に ltsc2019 で各種イメージが選べます。

サイズが ltsc2016 と比べて 1/3 近くになっていることも確認できます。やっと実用が可能なサイズに。

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

ASP.NET や ASP.NET Core (Nano Server) や IIS 向けには 2019 はまだ提供されていないですが、既に PR は作成されているので、近日中にリリースされると思われます。

それはそうと今回の 2019 リリースに合わせて、これまで Docker Hub で公開されていたイメージが Microsoft Container Registry からの公開に切り替わっています。

2019 年から latest タグを使わないようにしていくみたいなので、既に latest を使っている場合には注意。

Docker Hub で新しいイメージ名が確認出来るので迷わないと思いますが、MCR は公開されているイメージやタグをブラウズする機能がないので、正直使いにくいなと思います。

一応タグ名は同じでイメージ名だけが変わっているみたいなので、単純な置き換えで済みます。

# これまで
docker pull microsoft/windowsservercore:ltsc2016

# これから
docker pull mcr.microsoft.com/windows/servercore:ltsc2016

命名のルールは MCR の方が分かりやすいです。現実的にはタグは ltsc2016 か ltsc2019 しか使わないと思うので、この二つだけ覚えておけばよいと思います。

今のところは Server Core / Nano Server などの OS ベースとなるイメージや、PowerShell Core / Azure Functions Runtime / SQL Server 2019 Preview などが MCR に移行済みのようです。

https://hub.docker.com/u/microsoft/

.NET Framework や .NET Core 周りのイメージも順次 MCR への移行を進めていく予定のようです。GitHub の Issue にイメージ名のプロポーザルが載っています。

まだリリースされていないし、確定でもないようですが Server Core のように階層化された形で管理されるようです。既に .NET Core のイメージは結構使われているので、バッサリと移行は行わないみたいです。

MCR は当然ながら Azure 上に構築されていて、さらに Traffic Manager を使って各地に分散されているので、Azure Pipelines や Web App for Containers などで使うとネットワーク的に有利な予感です。

Multi-arch 時代の Windows Containers 関連イメージの扱い

Windows Containers を使っていて非常に悩ましいのが OS バージョンですが、最近は Multi-arch が使われているのでホスト OS のバージョンから適切なものを自動で利用してくれます。

Multi-arch の詳細は Docker 公式ブログを読めば大体理解できるはずです。

最近はちょいちょい Server Core や Nano Server に対応したイメージを見かけますね。

イメージに含まれているプラットフォームを確認する方法も用意されているので、例えば .NET Framework 4.7.2 の SDK イメージの情報を確認したい場合には以下のコマンドを使います。

docker run --rm mplatform/mquery microsoft/dotnet-framework

実行すると、含まれているプラットフォームの一覧が出力されます。

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

Windows Server の LTSC 2016 / Version 1709 / Version 1803 それぞれに対応していることがすぐにわかります。1709 からはリビジョンの制約がなくなっているので、気にせず使えるのはメリットです。

ビルド済みのイメージに対して docker history を実行すると、ベース OS のバージョンが確認出来ます。

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

バージョンを気にすることなくイメージを取得して実行できるのは便利なのですが、同じイメージ名なのに落ちてくるものは環境依存となるので、開発やビルド、実行時の OS が異なると簡単に事故ります。

特に実際にイメージを作成する CI 部分と実行環境のバージョン違いは致命的なので、よく使われそうなサービスに関して情報を軽くまとめておきます。

CI SaaS

サービスの大半は LTSC 2016 が使われているので、開発環境が Windows 10 の場合はビルド番号が大きく異なっているはずです。

  • ACR Build
    • Version 1803 (Hyper-V)
  • AppVeyor
    • LTSC 2016
  • AWS CodeBuild
    • LTSC 2016
  • Visual Studio Team Services
    • LTSC 2016

ACR Build に関してはホスト OS が 1803 ですが、Hyper-V Containers が使われているので LTSC 2016 と Version 1709 のイメージも問題なく扱えるようになっています。

実行環境

数少ない実行環境ですが、こっちも大半が LTSC 2016 が使われています。2019 リリース待ちですね。

  • Web App for Containers (Windows)
    • LTSC 2016
  • Azure Container Instances
    • LTSC 2016
  • Azure Kubernetes Service
    • Version 1709 or 1803

AKS に関しては前に試した時は 1709 が使われていましたが、最近の ACS Engine を見ると 1803 にも対応しているようだったので、両方とも記載しています。Hyper-V Containers ではないので非常に厄介です。

(現時点での)最適なイメージ

現時点での結論としては、使用するイメージは全て LTSC 2016 に統一し、Dockerfile でも明示的に OS バージョンを指定することをお勧めします。

指定していない場合はホスト OS からイメージのバージョンが決定されるので、例えば ACR Build を使うと自動的に 1803 が使われることになります。

# .NET Framework の場合
FROM microsoft/dotnet-framework:4.7.2-sdk-windowsservercore-ltsc2016

# ASP.NET の場合
FROM microsoft/aspnet:4.7.2-windowsservercore-ltsc2016

例外として AKS で Windows Containers を使う場合には、既存の CI SaaS の大半が未対応となってしまうので、ACR Build しか組み合わせる選択肢が存在しないことになります。

2019 リリース後には LTSC 2016 からの移行が発生するであろうこともお忘れなく。

Windows Server Version 1709 から Windows Server Containers のバージョン要件が変更されていた

これまで何回か Windows Containers を触ってきましたが、大体は Windows Server Containers の場合はバージョンを合わせるのが面倒なので、Hyper-V Containers を使おうという方向に落ち着いてました。

ビルド番号が異なる場合には起動がブロックされますが、リビジョン違いは起動はするものの本番環境でサポートは行わないという鬼のような要件です。

なので、使うには Hyper-V Containers を使って完全に分離してあげないと、と思ってました。

最近、何となくドキュメントを眺めていたら Windows Server Version 1709 からはバージョン周りの要件が変更されていて、リビジョンは一致していなくても本番環境でサポートされるようになったみたいです。

正直なところカーネルを共有してるので、この制限は撤廃されないだろうなと考えてました。

ドキュメントによると 1709 からはコンテナホストとリビジョンまで合わせる必要はないが、最新のアップデートを適用しておくのをお勧めしますということのようです。

For Windows Server 2016 based hosts/images – the container image’s revision must match the host to be in a supported configuration. Starting with Windows Server version 1709, this is no longer applicable, and the host and container image need not have matching revisions. It is as always recommended to keep your systems up-to-date with the latest patches and updates.

Windows Container Version Compatibility | Microsoft Docs

LTSC での運用はほぼ不可能じゃないかと思ってましたが、アップデートを重ねることで何だかんだで実用的になってきているなと感じました。

運用ではコンテナホストのアップデートを考える必要がありますが、上のドキュメントには Kubernetes の nodeSelector を使って一致するバージョン上で Pod を実行させるための方法も載っています。しかし、肝心のノードを追加する方法が今の AKS には用意されていないので、単純にクラスタを作ると詰みます。

一応は対応予定ではあるらしいので、追加できるようになると新しい Windows Server のビルドをノードとして追加して、nodeSelector を使って切り替えるだけでアップデートが完了するわけです。

CI 周りも VSTS / AppVeyor / CodeBuild 以外にも、Codefresh という Kubernetes 向けサービスが Windows Containers にベータですが対応を始めているので、去年から割と整ってきた感じがあります。

Codefresh は結構面白そうなので、Windows Containers のサポートを試して見ようかと思います。

AWS CodeBuild が Windows に対応したらしいので試した

Twitter を眺めていたら AWS CodeBuild が一部のリージョンで Windows に対応したとあったので、早速オレゴンで試して見ることにしました。

Windows が使えるビルドサービスは VSTS か AppVeyor ぐらいしか選択肢がなかったので貴重です。

AWS CodeBuild Adds Support for Windows Builds

Microsoft Windows Samples for AWS CodeBuild - AWS CodeBuild

buildspec.yml は特に Windows だから変わっている部分はないみたいです。新しいビルドプロジェクトを作成する時に OS や利用するランタイムを選べるようになっています。

AWS 管理のイメージも用意されていますが、Docker Hub で公開されている任意のイメージも利用できるようになっているみたいです。これは地味に良さそう。

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

ビルドした結果は S3 に保存できるので、結構扱いやすいです。実際に ASP.NET アプリケーションをビルドして、WebDeploy パッケージを作成してみましたが、すんなりと S3 に保存されてました。

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

試した感じでは、まだコンテナを利用した Windows アプリのビルド環境が未成熟という印象を持ちましたが、AppVeyor の地位危うしという感じがします。

やはり毎回 init で必要なパッケージをインストールしたりするのは時間の無駄ですからね。

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

CodeBuild の場合は利用するコンピューティングタイプを選択できるのも良いです。Windows Containers 自体が重いのもありますが、選択肢があるというのは重要です。

CodeBuild 提供の Windows イメージ

CodeBuild で提供されているイメージは msbuild へのパスが通っていないので、そのままだとビルドが通らないので地味に厄介です。フルパスで msbuild を指定しないとエラーになります。

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

ライセンス情報を見る感じでは .NET 4.6.2 までしか Targeting Pack が入っていないみたいなので、4.7 以降をターゲットにしたアプリケーションはビルド出来ないかも知れません。

AWS CodeBuild for Windows—Third Party Notices - AWS CodeBuild

.NET Core についても、パッと見た感じでは 2.0 しか SDK が入っていないように見えます。

それ以外のバージョンをビルドする場合には専用の Docker Image を用意するか、Microsoft から公式リリースされているものを使った方が良さそうです。

.NET Command Line Tools (2.1.103)

Product Information:
 Version:            2.1.103
 Commit SHA-1 hash:  60218cecb5

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.103\

Microsoft .NET Core Shared Framework Host
  Version  : 2.0.6
  Build    : 74b1c703813c8910df5b96f304b0f2b78cdf194d

.NET Core の場合は Nano Server ベースのイメージを使えるのでプロビジョニングの短縮が図れます。

カスタムイメージを作成する

Microsoft から提供されているイメージは何故か WebBuildTools がインストールされていないので、ASP.NET アプリケーションのビルドには微妙に問題が出ます。

予めパッケージをインストールしておきたいという要望もあるはずなので、AWS Blog に書いてあるようにカスタムなイメージを作成して対応しましょう。

Extending AWS CodeBuild with Custom Build Environments for the .NET Framework | AWS DevOps Blog

こっちはちゃんと WebBuildTools をインストールするコマンドになっているので、ASP.NET アプリケーションのビルドも問題ありません。

pull されたイメージはキャッシュされる

条件はよくわかっていませんが、同じイメージを使っている場合にはキャッシュが効いて素早くビルドまで実行できるようになっていました。

単純に同じホストに割り当てられた場合のみなんでしょうが、Server Core のイメージは重いので重要です。

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

欲を言えば、予めよく使われそうなイメージは pull 済みになっておいて欲しいですね。

LTSC 2016 のみ実行可能

.NET Framework SDK の Docker Image は LTSC 2016 以外に 1709 / 1803 が提供されているので、そのイメージを利用してビルドを実行してみましたが、コンテナが立ち上がることなく失敗しました。

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

なので Hyper-V Containers ではなくて Windows Server Containers を利用していることが分かります。

軽量化された Docker Image は CodeBuild では暫く使えそうにないですね。残念ながら Windows Server 2019 のリリースを待つしかなさそうです。

ConoHa が Windows Server に対応したので契約してみた

前から Linux の VPS は主に Docker 用として契約して使ってましたが、Windows Server にも対応したと聞いたので早速契約してみることにしました。

10% オフになっても 2GB プランはまあまあのお値段という感じがします。

どうやら Windows Server 2016 Datacenter だけのイメージと SQL Server が入ったイメージが選べるようになっているみたいです。SQL Server 入りを選ぶとライセンス分が上乗せされるので高くなります。

ConoHa の Windows Server は珍しく 3 コアのマシンが選べます。

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

人生で 3 コアのマシンを使ったことがなかったので、試してみることにしました。

リモートデスクトップ用のパスワードを入力して、追加ボタンを押せば VM が作成されます。プロビジョニングは結構早いです。そしてブラウザからデスクトップが確認出来るのはかなり良いですね。

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

最初は「どうせ Windows Server では動作しないんだろ」とか思ってました。ごめんなさい。

デフォルトの Windows Server 2016 のバージョンは少し古いものでした。デフォルトで日本語 OS が起動するのが、地味に便利な気がしますね。

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

この状態で Windows Update を実行すると、累積アップデートが落ちてきます。Azure や AWS は少し遅れて新しいイメージが提供されてますが、ConoHa ではどうなるのか気になります。

そしてタスクマネージャーの表示です。3 コアだと微妙に収まりが悪いですね。

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

当然ですが、Windows Server 2016 の VM を作成しても、そのままでは何も出来ません。最低限 Web サーバーとして運用するためには IIS を入れる必要があります。

ConoHa のデフォルトではファイアウォールが全ポート許可になっているので、実際に使う際にはちゃんと必要なポートだけ開けるようにして使ってください。

Web Deploy を使ってデプロイ

IIS を入れてもアプリケーションのデプロイは必要になるので、Web Deploy をインストールして Visual Studio や MSDeploy を使ってリモートでデプロイ出来るようにしないと、使い道が無さそうです。

Web Deploy のインストールは癖があるので、いい感じに記事を参考にしてください。

適当に Web Deploy をインストールして、発行用のユーザーを作成し、publishsettings ファイルを作成して Visual Studio にインポートします。この辺りは App Service を使っている場合と同じです。

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

証明書周りの警告が出ますが、オレオレ証明書なのでスルーします。

デプロイが完了すると、見慣れた ASP.NET アプリケーションが表示されました。問題なく動いてますね。

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

MSDeploy を使ってデプロイが出来るので、AppVeyor や VSTS から簡単に扱えるはずです。

Docker を使う

ちなみに ConoHa でも Docker EE をインストールして Windows Server Containers を使うことが出来ます。Nested Virtualization には対応していないので Hyper-V Containers は無理です。 ごめんなさい、Hyper-V Containers 使えました。

インストールは Docker 公式のドキュメントを読んでください。このブログでも何回か書きました。

Server Core のイメージはサイズが大きすぎるので Nano Server を pull してきました。

動作確認を簡単にするために、IIS がインストールされたものを使います。8080 を 80 にフォワーディングするように指定して、Nano Server なコンテナーを起動します。

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

コンテナーホストの外から 8080 にアクセスすると IIS のスタートページが表示されます。

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

簡単な Windows Server Containers の検証としても良い感じですね。メモリが 2GB では心許ないですが、お遊びでは十分という感じもします。

最後に気が付いたのですが、何故か起動した Windows Server は時計が 1 時間遅れていました。タイムゾーンは合ってたので、NTP を使うと日本時間に戻りましたが謎です。

追記 : Hyper-V Containers も使えました

書いたときは Hyper-V を微妙に見落としていたのか、Install-WindowsFeature Hyper-V であっさりとインストールした後に、docker run で isolation を hyperv にすると Hyper-V Containers として起動できました。

タスクマネージャーを見ると wmwp や vmmem が動いてることが確認できます。

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

大きめのインスタンスを契約すれば Azure Functions Runtime などのインストールも出来そうな気がします。

Windows Server Insider Preview Build 17079 で Server Core Container のサイズが更に削減

Windows Containers を使って ASP.NET アプリケーションの Dockernize を行う上で最大の問題となる、Server Core な Docker Image のサイズが 17079 で更に削減されました。

ブログでは 30% 削減されたと書いてありますが、実際のサイズはダウンロード時が 1.58GB で展開後のディスク上では 3.61GB にまで小さくなったらしいです。

初期の Docker Image は展開後 10GB あったことを考えると 1/3 近くになってます。

他にも MSMQ がプリインストールされたとか、アプリケーションの互換性が向上したとありますが、具体的にどう変わったかは公開されてないので分からないです。

Virtualization のブログではもっと詳細な内容が公開されているので面白いです。

今回のイメージサイズ削減は Nano Server と同じ方法を使って削減したとか、利用者から送信されるテレメトリーから使われていない機能を削除したとか、非常に興味深い話です。テレメトリーを使っているので、今後も使っていくほどにサイズが小さくなっていく可能性がありますね。*1

まだ WOW64 が残っているらしいので、今後削除が行われると更に小さくなる可能性がありそうです。

今回のビルドでは In-place Upgrade がやっと行えるようになったらしいですが、例によって Semi-Annual な Windows Server は Server Core しか提供されておらず使いにくいので、検証には Windows 10 Insider Preview を使いました。

カーネルのバージョンが異なっていますが、Hyper-V Containers なら問題なく扱えるようになってます。とりあえずメジャーな Docker Image を pull してきてサイズを比較してみました。

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

windowsservercore-insider と windowsservercore:1709 の差が大きいですね。Nano Server も小さくなっているように見えますが、Windows Update でレイヤーが増えた結果かもしれないので確証はありません。

Server とは関係ないですが、最新の Windows 10 Insider Preview Build 17083 でもループバックアドレスで、実行中のコンテナにアクセス出来るようになっていました。これはやっぱり地味に嬉しい。

Insider Preview な Server Core には IIS が入ったものがないので 1709 で試してますが、問題なく localhost でアクセスが出来ています。RS4 からは inspect する必要が無くなります。

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

慣例的に Insider Preview な Server Core 向けには ASP.NET 向けのイメージも公開されないので、試して見たい場合には公開されている Dockerfile を使って自前でビルドする形になります。

ちなみに ASP.NET 4.7 のイメージを作ってもサイズは結構小さいままでした。

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

とりあえず ASP.NET MVC 5 アプリケーションを動かすイメージをビルドして実行してみました。当然ですが、何の問題もなく普通に動きます。

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

Server Core のサイズが小さくならないと ASP.NET アプリケーションの Dockernize は現実的ではないスタンスでいましたが、現実的なサイズになってきたので嬉しいですね。後は CI SaaS で使えるようになれば準備が整いそうです。

RS4 でやっと Windows Containers が現実的な時間で扱えるようになりそうです。

*1:ちなみに削除された機能の一覧はこれ https://gist.github.com/weijuans/19a04903a24487c296effa3f88b603e6

Windows Server Insider Preview Build 17035 で Windows Containers 周りが改善

ちょっと前に次の Semi-Annual Channel 向けの Windows Server Inside Preview がリリースされてました。ぶちぞう RD が空リプしてましたが、6 時とか完全に寝てるので気が付きません。

S2D とか個人的にはどうでもよくて、やっぱり注目はずっと WinNAT 周りの制約と言い続けてきた、ループバックアドレスでコンテナにアクセスできない点が解消されたことです。

  • Developers can now use localhost or loopback (127.0.0.1) to access services running in containers on the host
Announcing Windows Server Insider Preview Build 17035 - Windows Experience BlogWindows Experience Blog

Windows Containers では docker run 時に指定したポートフォワーディングの指定が実質的には動作しておらず、docker inspect を叩いてコンテナの IP アドレスを取得して、直接見に行くことしか出来ませんでした。

それが次の Semi-Annual Channel では解消されて、他のプラットフォーム上の Docker と同じように、簡単にループバックアドレスを使ってアクセス出来るようになります。多分 Windows 10 でも同じでしょう。

ちゃんと Azure 上に Nested VM を作成して、ループバックアドレスで見れるか確認しました。

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

見ての通り、問題なくループバックアドレスでポートフォワーディングが動いてることが分かりました。

Visual Studio の Docker 拡張は docker inspect を内部的に叩いているので、将来的にはループバックアドレスを使うように挙動が変更されるかも知れません。

そしてブログには書いていませんでしたが、Insider Preview の Docker Image をダウンロードしてくると、Version 1709 と比べて Server Core は 1GB ほどサイズが削減されていました。

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

Insider Preview の段階では IIS / ASP.NET / .NET Framework などの Insider 向けイメージが提供されていないので、今回は IIS だけ GitHub から Dockerfile などを落としてきて、自分でイメージをビルドしました。

初期の Server Core が展開後 10GB ほどあったことを考えると、半分以下になったことになります。

今の Version 1709 でも初回にかかる時間が半分ぐらいになっていて、割と我慢できるぐらいの時間になってますが、さらに短縮される可能性がありそうです。そろそろプロダクションで使ってみたい。

Windows Server Version 1709 で Docker と Windows Containers を使ってみる

自宅の検証用 Windows Server 2016 を Version 1709 にアップグレードしたので、例によって Docker 周りで気になる部分だけまとめておくことにします。Tech Summit は Version 1709 ベースで話したいですし。

Windows Server Blog や Azure Blog では Azure Marketplace から使えると書いてますが、最近になってようやく Marketplace に 1709 が出てくるようになりました。

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

例によって Azure の場合は Dv3 / Ev3 を選ぶことで Nested Virtualization を使って Hyper-V Containers が利用可能になります。それにしても対応リージョン増えないですね。

自宅に NUC で作ったマシンがあったので、MSDN から Version 1709 の ISO をダウンロードしてきて、インストールしてみることにしました。気軽にインストールしたら少しはまったので軽くそこから書きます。

ちなみに Linux Containers についてはムッシュが既に書いているので、そっちを参照してください。

流石ムッシュ、SQL Server だけじゃなくて Docker も Linux Container も出来る。

Version 1709 は Server Core / Nano Server のみ

Insider Preview の時は Server Core しか提供されてなかったのは知っていたのですが、GA になればデスクトップ付きもリリースされるだろ、と甘く思って自宅 Windows Server 2016 のアップグレードを行ったところ、Server Core になっていて焦りました。

思わずぶちぞう RD に相談するぐらい焦りました。ちゃんとドキュメント読んでなかったです。

ドキュメントには Semi Annual Channel では Server Core と Nano Server のみとしっかりと書いてあります。そろそろサーバーでデスクトップとか言う現状を、捨てる必要があるのかも知れませんね。

Long-term Servicing は今後どのようにアップデートされていくのかもよくわかりませんが、基本的には Semi Annual Channel に乗っかっていくのが現実的な選択肢なのかと思いました。

特に Windows Containers を使う場合には追従は必須だと思われます。

Docker のインストール

Microsoft のドキュメントだと DockerMsftProvider を使うように書いてますが、微妙にバージョンが古いのが落ちてくるようになってます。この現状に Docker の人がしびれを切らしたのか、fork されて DockerProvider というのが配布されています。

なので Docker 側のドキュメントでは DockerProvider を使うようにと書いてあります。

といっても使い方はほぼ変わらず、DockerMsftProvider から DockerProvider に変えるだけです。

Install-Module DockerProvider -Force
Install-Package Docker -ProviderName DockerProvider -Force

これでインストールが完了しますが、Hyper-V Containers を使う場合には別途 Hyper-V をインストールする必要があります。

Install-WindowsFeature Hyper-V

自分の環境では何故かコンテナからインターネットへの通信が出来ない事象が発生しました。ぶちぞう RD と話しながら解決策を探しましたが、結局わからなかったので Azure に構築しました。

Version 1709 向け Docker Image

Version 1709 では Server Core / Nano Server のイメージサイズが大幅に削減されています。Nano Server は Debian と同じぐらいにまで小さくなってますし、Server Core もまあまあ小さくなりました。

今のところ Docker Hub で公開されている Version 1709 向けイメージは以下の通りです。

# Server Core 1709
docker pull microsoft/windowsservercore:1709
docker pull microsoft/dotnet-framework:4.7.1-windowsservercore-1709
docker pull microsoft/iis:windowsservercore-1709
docker pull microsoft/aspnet:4.7.1-windowsservercore-1709

# Nano Server 1709
docker pull microsoft/nanoserver:1709
docker pull microsoft/aspnetcore:2.0.0-nanoserver-1709

タグ名の付け方は大体見たらわかるような感じですね。

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

新しい Version 1709 向け Docker Image を使うには当然ながらホストが Version 1709 である必要があるので、今のところは自前で環境を用意する必要があるのが少し辛いところです。

VSTS や AppVeyor も Server Core のみ提供の 1709 に対応してくるかわからないので、下手したら CI サービス全滅という可能性もありそうです。