初見Microsoft は、おそらく最も興味深い新機能である Windows Server コンテナーの最初のパブリック リリースを含む、Windows Server 2016 の Technical Preview 3 をリリースしました。
コンテナは、従来の VM よりも多くのリソースを共有する仮想マシン (VM) の一種です。
「効率性を高めるため、多くの OS ファイル、ディレクトリ、実行中のサービスはコンテナー間で共有され、各コンテナーの名前空間に投影されます」と Azure CTO の Mark Russinovich 氏は述べています。
コンテナは軽量であるため、ホストサーバー上でVMよりも多くのコンテナを実行できます。ただし、柔軟性は低くなります。Windows上で動作するVMでLinuxを実行することは可能ですが、コンテナはホストとオペレーティングシステムファイルを共有するため、このアイデアは意味がありません。
コンテナは Unix 系オペレーティング システムでは長い間存在していましたが、2013 年初頭に Docker がオープン ソース プロジェクトとしてリリースされて以来、アプリケーションの展開での使用が増加しました。
Docker は、Linux コンテナ イメージを管理およびデプロイするための高レベル API とツールを提供し、Docker Hub はコンテナ イメージのパブリック リポジトリです。
Docker の人気により、開発者が複数回デプロイできるコンテナ イメージの作成に重点を置く、アプリケーション デプロイに対する独特のアプローチが促進されました。
ライブインスタンスは使い捨てであり、アプリケーションを更新するにはイメージを更新して再デプロイします。各イメージは比較的小規模な機能を実装しており、これはマイクロサービスと呼ばれるソフトウェアアーキテクチャのスタイルに適しています。
コンテナはWindows Serverの機能になりました
Windows開発者はコンテナの恩恵を享受する機会を逃してきましたが、MicrosoftはServer 2016とAzureクラウドプラットフォームでその恩恵を享受しています。コンテナのサポートは現在Windowsに組み込まれており、2種類のコンテナが提供されています。
- Windows Server コンテナ: コンテナ VM は共有 OS ファイルとメモリを使用します
- Hyper-Vコンテナ: VMは独自のOSカーネルファイルとメモリを持ちます
現在のテクニカルプレビューではHyper-Vコンテナはサポートされていません。Hyper-Vコンテナと従来のHyper-V CMの違いは何でしょうか？
「OS が物理マシンではなくコンテナ内にあることを完全に認識することで得られる最適化に加え、Hyper-V コンテナは Docker の魔法を使って展開され、Windows Server コンテナで実行されるものとまったく同じパッケージを使用することができます」と Russinovich 氏は詳細を明かさずに述べた。
Microsoft は今回のリリースで Hyper-V にネストされた仮想化を追加したため、ホスト自体が VM であっても Hyper-V コンテナーを使用できるようになります。
Hyper-Vコンテナを使用する主な理由はセキュリティです。Hyper-Vコンテナはより分離されており、Microsoftはこれを「信頼境界」と見なしていますが、Windows Serverコンテナはそうではありません。しかし、Hyper-Vコンテナがなくても、分離は必要です。「もし誰かがコンテナから抜け出す方法を見つけたら、それは大問題です」と、シニアプログラムマネージャーのテイラー・ブラウンはトレーニングビデオで述べています。
さらに、MicrosoftはDockerをWindowsに移植しました。これは、Docker APIとツールをWindowsコンテナで使用できることを意味します。ただし、既存のLinuxベースのDockerイメージが、従来のようにLinux VM経由でのみWindows上で実行できるという意味ではありません。
Server 2016 TP3 のコンテナー
先日リリースされたプレビューを見る限り、Windows Serverコンテナはまだ初期段階のようです。Microsoftは、DockerまたはPowerShellといったコマンドラインツールを用いて、簡単なコンテナの作成と実行方法を示すチュートリアル形式の、大まかなドキュメントを公開しています。
Visual Studio ツールが開発者を Azure へ誘導
Visual Studio Tools for Docker を使用して Azure 上の Docker コンテナーにデプロイするチュートリアルもあります。これらのツールは Azure 以外のホストにも対応していますが、このチュートリアルではそれらのシナリオは取り上げていません。ツールは Azure へのデプロイを推奨しているため、Azure がデフォルトの選択肢となっており、「カスタム Docker ホスト」のチェックボックスをオンにした場合にのみ代替手段が利用可能です。
この技術を試用する人々は、混乱を招く可能性のある問題に直面するでしょう。その一つは、DockerコンテナとWindows Serverコンテナは一見同じ基盤技術を使用しているように見えますが、実際には異なるものであるということです。Windows Serverコンテナ用のPowerShellライブラリを使用してDockerコンテナを管理することはできませんし、その逆も同様です。Microsoftは、これは長期的な計画ではないと述べています。
第二に、Windowsコンテナイメージは現在、GUIのないWindows ServerであるServer Coreをベースにしています。おそらく、さらに機能制限の少ないNano Serverもサポートされるでしょう。
3つ目に、Microsoftはまだやるべきことが山積みで、何が機能し、何が機能しないのかを説明する「作業中」のFAQを公開しています。これには、「コマンドが時々失敗する場合は、もう一度お試しください」といったアドバイスも含まれています。
コンテナVMは現在、Windows Server Coreで動作するすべての機能をサポートしているわけではありません。例えば、ASP.NET 4.5は動作しないため、同じくプレビュー版である新しいASP.NET 5.0を使用する必要があります。PHPはApacheでは動作しますが、MicrosoftのIIS（Internet Information Server）では動作しません。Microsoftはインストール可能なWindows機能のリストを公開していますが、「インストール後、多くの機能は動作しなくなります」と付け加えています。
ドキュメントには、Windowsコンテナイメージ内のシステムファイルは、ビルドレベルとパッチレベルに関して、ホストOS内のシステムファイルと完全に一致する必要があるとも記載されています。「不一致は、不安定性や予期せぬ動作につながる可能性があります。」
この要件は、依存関係の問題を回避することを目的としたコンテナの価値を一部損ないます。これはMicrosoftにとって対処が難しい問題ですが、OSにパッチを適用するとホストされているコンテナが破損する可能性があるため、対処が不可欠です。
Dockerに関しては、いくつかの主要コマンドがまだサポートされていません。失敗するコマンドには、Docker commit、Docker load、Docker pause、Docker pull、Docker restartなどがあります。
このような問題はパブリック プレビューでは驚くことではありませんが、多くの制限があるため、テクノロジをテストする前に、より完全なリリースを待つことを好む人が多いため、言及する価値はあります。
