こんにちは、Habr！ 執筆者Cornell KnulstによるWindows Server ContainersおよびDockerの詳細-パート2-Windows Server Containersの基本的な実装の記事の翻訳を紹介します。

この記事では、WindowsでのDocker実装の機能と、WindowsとLinuxのコンテナー実装の違いについて説明します。

この前に、コンテナとは何か、それらがどのように類似しているか、仮想マシンとどのように異なっているかについての一般的な考え方が与えられます。

エントリー

2015年8月3日にWindows Server 2016 Technical Preview 3が導入され、MicrosoftはWindowsプラットフォームにコンテナーテクノロジーを導入しました。 コンテナテクノロジーは2008年8月にLinuxに登場しましたが、同様の機能は以前はMicrosoftオペレーティングシステムでサポートされていませんでした。 LinuxでのDockerの成功のおかげで、Microsoftはほぼ3年前に決定しました（元の記事は2017年5月6日- およそTranslに公開されました ）。 2016年9月以降、Windows Server 2016およびWindows 10でこの新しいコンテナーテクノロジの公開バージョンを使用できるようになりました。しかし、コンテナーと仮想マシンの違いは何ですか？ また、Windowsコンテナーは内部的にどのように実装されていますか？ この記事では、Windowsでのコンテナーの実装について詳しく説明します。

コンテナと仮想マシン

多くの場合、「コンテナは軽量の仮想マシンです」というフレーズでコンテナに慣れ始めます。 これにより、人々はコンテナとは何かを基本的に理解することができますが、このステートメントは100％間違いであり、非常に混乱を招く可能性があることに注意することが重要です。 コンテナは仮想マシンとは異なるため、私は常にコンテナを「仮想マシンとは異なるもの」または「コンテナは仮想マシンではない」と考えています。 しかし、違いは何ですか？ そして、なぜ彼女はそんなに重要なのでしょうか？

コンテナと仮想マシンの共通点は何ですか？

コンテナは仮想マシンではありませんが、どちらにも3つの重要な特性があります。

（Image Albund | Dreamstime.com ）

コンテナと仮想マシンの共通点：

• 隔離された環境 ：仮想マシンのように、コンテナはファイルシステム、環境変数、レジストリ、およびアプリケーション間のプロセスの隔離を保証します。 これは、仮想マシンのように、各コンテナがそれ自体内のすべてのアプリケーションに対して隔離された環境を作成することを意味します。 移行中、コンテナと仮想マシンの両方は、内部のアプリケーションだけでなく、これらのアプリケーションのコンテキストも保持します。
• ホスト間の移行 ：仮想マシンを使用する大きな利点は、仮想マシンのナゲットスナップショットをハイパーバイザー間で移動でき、その内容を変更する必要がないことです。 これはコンテナにも当てはまります。 仮想マシンを異なるハイパーバイザー間で「移動」できる場合、コンテナーは異なるコンテナーホスト間で「移動」できます。 異なるホスト間で両方のタイプのアーティファクトを「移動」する場合、仮想マシン/コンテナの内容は以前のホストとまったく同じままです。
• リソース管理 ：もう1つの一般的な機能は、コンテナーと仮想マシンの両方の使用可能なリソース（CPU、RAM、ネットワーク帯域幅）を指定された値に制限できることです。 どちらの場合も、このリソース管理はコンテナーまたはハイパーバイザーのホスト側でのみ実行できます。 リソース管理は、同じホストで実行されている他のコンテナのパフォーマンスに影響を与えるリスクを最小限に抑えるために、コンテナが限られたリソースを受け取ることを保証します。 たとえば、コンテナには、CPUの10％を超えて使用できないという制限を与えることができます。

コンテナと仮想マシンの違い

コンテナと仮想マシンの間には類似点がありますが、それらの間にもいくつかの重要な違いがあります。

コンテナと仮想マシンの違い：

• 仮想化レベル ：コンテナは新しいレベルの仮想化です。 仮想化の歴史を見ると、仮想メモリや仮想マシンなどの概念から始まりました。 コンテナは、この仮想化のトレンドの新しいレベルです。 仮想マシンがハードウェア仮想化を提供する場合、コンテナーはOS仮想化を提供します。 これは、ハードウェア仮想化により、仮想マシンがそのハードウェアリソースがそれだけに属すると信じることを許可する場合、OS仮想化により、OS全体がOSのみに属すると容器が信じることができることを意味します。 この仮想化の違いに注意することが重要です。 たとえば、コンテナには独自のカーネルモードはありません。 このため、コンテナーは仮想マシンとして表示されず、オペレーティングシステム内の仮想マシンとしても認識されません（PowerShell Get-VMコマンドを自分で実行してみることができます）。 この違いを説明する良い例えは、自宅（仮想マシン）とアパート（コンテナ）です。 ホーム（仮想マシン）は完全に自己完結型であり、招待されていないゲストに対する保護を提供します。 各家には、給水、暖房、電気などの独自のインフラストラクチャもあります。アパート（コンテナ）も、招かれざる客からの保護を提供しますが、共通のインフラストラクチャに基づいて構築されています。 アパートの建物（Dockerホスト）では、配管、暖房、電気などが共有されます。 これらは両方とも共通の特性を持つ場合がありますが、異なるエンティティです。
• OSとの相互作用 ：コンテナーと仮想マシンのもう1つの重要な違いは、カーネルモードとの相互作用の方法です。 仮想マシンには完全なOS（および専用カーネルモード）がありますが、コンテナは「OS（より正確にはカーネルモード）」を他のコンテナおよびコンテナホストと共有します。 その結果、コンテナはコンテナホストOSに焦点を当てる必要がありますが、仮想マシンは必要なOS（バージョンとタイプ）を選択できます。 仮想マシンがコンテナーテクノロジーを備えたWindowsハイパーバイザーでLinuxを実行できる場合、WindowsコンテナーホストでLinuxコンテナーを実行することはできません。 （LinuxコンテナーはWindows 10で実行できますが、Linux仮想マシン内で実行されます - およそTransl。 ）
• 成長モデル ：コンテナは、コンテナホストのリソースを共有し、アプリケーションを実行するために必要なものを正確に含むイメージに基づいて作成されます。 基本から始めて、必要なものを追加します。 仮想マシンは逆の順序で作成されます。 ほとんどの場合、完全なオペレーティングシステムから開始し、アプリケーションに応じて、不要なものを削除します。

Windowsサーバーコンテナー

仮想マシンとコンテナの違いがわかったので、Windows Serverコンテナアーキテクチャについて詳しく見ていきましょう。 コンテナがWindowsオペレーティングシステムで内部的に実装される方法を説明するには、ユーザーモードとカーネルモードという2つの重要な概念について知る必要があります。 これらは、実行する必要のあるコードのタイプに応じて、プロセッサーが絶えず切り替える2つの異なるモードです。

カーネルモード

オペレーティングシステムのカーネルモードは、ハードウェアへの無制限のアクセスが必要なドライバー向けに作成されました。 通常のプログラム（ユーザーモード）は、オペレーティングシステムAPIを呼び出して、ハードウェアまたはメモリにアクセスする必要があります。 カーネルモードコードはこれらのリソースに直接アクセスし、カーネル内のオペレーティングシステムおよび他のドライバーと同じメモリ領域/仮想アドレススペースを共有します。 したがって、カーネルモードコードが誤って誤った仮想アドレスにデータを書き込むと、オペレーティングシステムまたは別のドライバーに属するデータが破損する可能性があるため、カーネルモードでコードを実行することは非常に危険です。 カーネルモードドライバーがクラッシュすると、オペレーティングシステム全体がクラッシュします。 したがって、カーネルモードでは、実行するコードをできるだけ少なくする必要があります。 このまさに理由で、ユーザーモードが作成されました。

ユーザーモード

ユーザーモードでは、コードは常に別のプロセス（ユーザー空間）で実行されます。このプロセスには、独自のメモリ領域セット（独自の仮想アドレス空間）があります。 各アプリケーションの仮想アドレス空間は独自のものであるため、あるアプリケーションは別のアプリケーションに属するデータを変更できません。 各アプリケーションは独立して実行され、アプリケーションがクラッシュした場合、そのアプリケーションのみにフォールが制限されます。 仮想アドレス空間であることに加えて、ユーザーモードでは制限されています。 ユーザーモードプロセッサは、オペレーティングシステム用に予約された仮想アドレスにアクセスできません。 ユーザーモードでアプリケーションの仮想アドレス空間を制限しても、オペレーティングシステムの重要なデータを変更したり、場合によっては損傷したりすることはできません。

Windowsコンテナーの技術的な実装

しかし、これらのすべてのプロセッサモードはコンテナで何をしますか？ 各コンテナは、名前空間の分離、リソースの管理、カスケード統合ファイルシステムの概念など、いくつかの追加機能を備えたプロセッサの「ユーザーモード」にすぎません。 これは、Microsoftが複数のユーザーモードをサポートできるようにWindowsオペレーティングシステムを適応させる必要があることを意味します。 以前のバージョンのWindowsの両方のモードが高度に統合されていたため、非常に困難でした。

Windows Server 2016のリリース以前は、使用したすべてのWindowsオペレーティングシステムは、単一の「ユーザーモード」と「カーネルモード」で構成されていました。 Windows Server 2016の登場により、同じオペレーティングシステムで複数のユーザーモードを実行できるようになりました。 次の図は、この新しいマルチモードユーザーアーキテクチャの概要を示しています。

Windows Server 2016のユーザーモードを見ると、ホストユーザーモードとコンテナーユーザーモード（図の緑色のブロック）の2つの異なるタイプを識別できます。 ホストユーザーモードは、以前のバージョンのWindowsでよく知られている通常のユーザーモードと同じです。 このユーザーモードの目的は、セッションマネージャー、イベントマネージャー、ネットワークなどの基本的なWindowsサービスとプロセスをホストすることです。 さらに、このユーザーモードは、Windows Server Coreの実装の場合、ユーザーインターフェイスを使用したWindows Server 2016とのユーザー対話を容易にします。

Windows Server 2016の新機能は、コンテナコンポーネントを有効にするとすぐに、このホストユーザーモードに、コンテナがWindowsで動作することを保証する追加のコンテナ管理テクノロジが含まれることです。 このコンテナテクノロジーの基盤は、Compute Services（オレンジブロック）の抽象化です。これにより、パブリックAPIを介して、カーネルが提供する低レベルコンテナ機能にアクセスできます。 実際、これらのサービスには、Windowsコンテナーを実行し、実行中かどうかを追跡し、それらを再起動するために必要な機能を管理するための機能のみが含まれています。 すべてのコンテナの追跡、コンテナイメージ、ボリュームなどの保存など、その他のコンテナ管理機能はDocker Engineに実装されています。 このエンジンは、Compute ServicesコンテナーAPIと直接通信し、Microsoftが提案する「Go言語バインディング」を使用します。

WindowsコンテナとLinuxコンテナの違い

WindowsコンテナとLinuxコンテナで同じDockerユーティリティとコマンド

同じDockerクライアントユーティリティ（Docker Compose、Docker Swarm）はWindowsコンテナとLinuxコンテナの両方を管理できますが、WindowsとLinuxのコンテナ実装にはいくつかの重要な違いがあります。

システムプロセス

Linuxがシステムコールを介してカーネルレベルの機能を提供する場合、MicrosoftはDLLを使用して利用可能なカーネル機能を制御することにしました（これは、Microsoftが実際にシステムコールを文書化しなかった理由でもあります）。 このシステムコールの抽象化の方法には利点がありますが、さまざまなWin32 DLLと多くのDLLの相互依存関係を備えた高度に統合されたWindowsオペレーティングシステムと、それらが明示的に参照する（しない）システムサービスが起動される多くのDLLの期待につながりました。 その結果、Windowsコンテナ内のDockerfileで指定されたアプリケーションプロセスのみを実行することはあまり現実的ではありません。 したがって、Windowsコンテナ内には、起動された追加のシステムプロセスが多数表示されますが、Linuxコンテナは指定されたアプリケーションプロセスのみを実行する必要があります。 必要なシステムプロセスとサービスがWindowsコンテナ内で実行されていることを確認するために、いわゆるsmssプロセスが各コンテナ内で起動されます。 smssプロセスの目的は、必要なシステムプロセスとサービスを開始することです。

SMSSプロセス

OSアーキテクチャ

カーネルレベルの機能が提供される方法だけでなく、アーキテクチャレベルでも、両方のオペレーティングシステムがコンテナ機能をDockerクライアントユーティリティに提供する方法に重要な違いがあります。 Windows Server 2016の現在のコンテナー実装では、Compute Servicesと呼ばれる抽象化レイヤーが導入され、外部からコンテナーの低レベル機能が抽象化されます。 これは、MicrosoftがDocker Engineおよびその他のクライアント側コンテナーユーティリティによって呼び出されるパブリックAPIを変更することなく、低レベルコンテナーAPIを変更できるためです。 このCompute Services APIに加えて、 https：//github.com/Microsoft/dotnet-computevirtualizationおよびhttps://github.com/Microsoft/で入手可能なC＃またはGo言語バインダーを使用して、独自のコンテナー管理ツールキットを作成できます 。 hcsshim

カスケードファイルシステム？

LinuxコンテナとWindowsコンテナの実装の3番目の重要な違いは、両方のオペレーティングシステムがDockerコピーオンライトテクノロジーを使用する方法です。 多くのWindowsアプリケーションはNTFSセマンティクスに依存しているため、MicrosoftチームがWindows上でカスケード統合ファイルシステムの本格的な実装を作成することは困難でした。 たとえば、USNログやトランザクションなどの機能の場合、これには完全に新しい実装が必要です。 したがって、Windows Server 2016のコンテナーの現在のバージョンには、実際のカスケード統合ファイルシステムはありません。 代わりに、現在の実装では、コンテナごとに新しいNTFS仮想ディスクが作成されます。 これらの仮想ディスクを小さく保つために、この仮想NTFSディスク上のさまざまなファイルシステムオブジェクトは、実際には実際のホストファイルシステムファイルへのシンボリックリンクです。 コンテナー内のファイルを変更するとすぐに、これらのファイルは仮想ブロックデバイスに保存されます。この変更のレイヤーをコミットする瞬間に、変更は仮想ブロックデバイスから取得され、コンテナーホストファイルシステムの適切な場所に保存されます。

Hyper-Vコンテナー

LinuxとWindowsのコンテナー実装の最後の違いは、Hyper-Vコンテナーの概念です。 この興味深いタイプのコンテナーについては、このシリーズの次の記事で説明します。 私たちと一緒に...