次の方法で共有

Windows コンテナーを使用して既存のアプリケーションを "コンテナー化" する

  • [アーティクル]

適用対象: Windows Server 2025、Windows Server 2022、Windows Server 2019、Windows Server 2016

Windows コンテナーは、従来のアプリケーションまたはレガシ アプリケーションを最新化するための優れたメカニズムを提供します。 "リフト アンド シフトからコンテナーへの移行" と呼ばれるこのアプローチは聞くかもしれませんが、リフト アンド シフトのメタファーは、ワークロードを物理マシンから仮想マシンに移行することから生じ、ワークロードをクラウドに移動する場合に使用されます。 現在、この用語は、仮想マシン (VM) の移行により適切に適用されています。 ただし、コンテナーは VM ではなく、VM と考えると、アプリケーションのコンテナー化方法や、コンテナー化できるかどうか、またはコンテナー化する必要があるかどうかについて混乱を招く可能性があります。

このトピックでは、従来のアプリケーションを Windows コンテナーに移動する方法に関する実用的なガイダンスを提供します。 これは、事前に特別な考慮事項を説明することで、コンテナー化する必要があるアプリケーションの優先順位付けを支援することを目的としています。

紹介

Windows コンテナーとは何か、何ではないか

汎用用語コンテナーとは、オペレーティング システム (OS) を仮想化するテクノロジを指します。 この仮想化により、サーバー/ホスト自体の OS からの分離レベルが提供され、アプリケーション開発者や運用チームの機敏性が向上します。

Windows コンテナーは、コンテナー テクノロジの特定の実装です。 これらは、Windows OS から分離された仮想化オペレーティング システムのインスタンスを提供します。 ただし、コンテナーとホストの間の完全な相互依存関係は不可能です。Windows コンテナーは、リソースと機能に対する需要を Windows OS と調整する必要があります。 これが重要なのはなぜですか? Windows コンテナーは仮想化されたサーバー全体ではなく、アプリケーションで行う必要がある操作の一部は、仮想化された OS だけでは実行できないためです。

このトピックの詳細については、「コンテナーと仮想マシンの」を参照してください。 ただし、コンテナーと VM の区別を覚えるのに役立ついくつかの良い点は次のとおりです。

  • コンテナーは、デスクトップ アプリケーションの仮想化と同等のソリューションではありません。 対話型セッションを必要としないサーバー側アプリケーションのみがサポートされます。 特殊なコンテナー イメージで実行されるため、グラフィカル フロントエンドを必要としないアプリケーションのみがサポートされます。
  • コンテナーは本質的に一時的なものです。 つまり、既定では、コンテナー インスタンスの状態を保存するメカニズムはありません。 インスタンスが失敗した場合、別のインスタンスがその代わりに使用されます。

コンテナー テクノロジは Linux で始まり、Docker が標準として登場しました。 Microsoft は Docker と密接に連携して、コンテナーの機能が可能な限り Windows 上で同じであることを確認しました。 Linux と Windows の固有の違いは、実際には Linux と Windows の違いだけである場合に、Windows コンテナーの制限のように見える方法で表面化する可能性があります。 一方、Windows コンテナーには、分離 Hyper-V など、いくつかの固有の実装が用意されています。これは後で説明します。 このトピックは、それらの違いとそれらに対応する方法を理解するのに役立ちます。

コンテナーを使用する利点

1 つの物理ホストで複数の VM を実行するのと同様に、1 つの物理ホストまたは仮想ホストで複数のコンテナーを実行できます。 ただし、VM とは異なり、コンテナーの OS を管理する必要がないため、アプリケーションの開発と基になるインフラストラクチャに柔軟に集中できます。 また、OS でサポートされている他のプロセスの影響を受けないように、アプリケーションを分離することもできます。

コンテナーは、機能しているアプリケーションに必要なリソースを作成して動的に停止する軽量の方法を提供します。 アプリケーションの需要が増加するにつれて VM を作成してデプロイすることは可能ですが、スケールアウトにコンテナーを使用する方が迅速です。コンテナーを使用すると、クラッシュやハードウェアの中断が発生した場合にすばやく再起動することもできます。 コンテナーを使用すると、環境間で動作するようにアプリケーションの依存関係を "含む" ため、コードの変更がほとんどまたはまったくないアプリを開発から運用環境に移行できます。 Microsoft 開発者ツール間の Docker 統合により、コードの変更を最小限に抑えて既存のアプリケーションをコンテナー化する機能も、アプリケーションの開発とメンテナンスの強力な要素です。

最後に、コンテナーを使用する最も重要な利点の 1 つは、リソースの競合なしで同じホスト上で実行されるアプリのバージョンが異なる可能性があるため、アプリ開発で得られる機敏性です。

既存のアプリケーションにコンテナーを使用する場合の利点の詳細な一覧については、Microsoft .NET のドキュメント ページを参照してください。

分離レベルの重要な概念

Windows コンテナーは、Windows OS からの分離、アプリのビルド、テスト、運用環境への昇格に有利な分離を提供します。 ただし、分離を実現する方法は、アプリケーションのコンテナー化を検討する際に理解することが重要です。

Windows コンテナーには、プロセス と Hyper-V という 2 つの異なるランタイム分離モードが用意されています。 両方のモードのコンテナーは、同じように作成および管理され、同じように機能します。 では、違いは何か、なぜ気にする必要がありますか?

プロセス分離では、名前空間、リソース制御、およびその他の機能によって提供される分離を使用して、複数のコンテナーが 1 つのホスト上で同時に実行されます。 プロセス分離モードのコンテナーは、ホストと互いに同じカーネルを共有します。 これは、Linux コンテナーの実行方法とほぼ同じです。

Hyper-V 分離では、複数のコンテナーも 1 つのホスト上で同時に実行されますが、コンテナーは高度に最適化された仮想マシン内で実行され、それぞれが効果的に独自のカーネルを取得します。 この仮想マシン (実質的には "ユーティリティ" VM) が存在することで、各コンテナーとコンテナー ホストの間にハードウェア レベルの分離が提供されます。

つまり、Hyper-V 分離モードは VM とコンテナーのハイブリッドに似ています。アプリでマルチテナントが必要な場合に特に役立つセキュリティの追加レイヤーが提供されます。 ただし、Hyper-V 分離モードを使用すると、次のようなトレードオフが考えられます。

  • コンテナーの起動時間が長くなり、アプリの全体的なパフォーマンスに影響する可能性があります。
  • すべてのツールが Hyper-V 分離でネイティブに動作するわけではありません。
  • 現時点では、Azure Kubernetes Service (AKS) と AKS on Azure Stack HCI のどちらも Hyper-V 分離をサポートしません。

2 つの分離モードの実装方法の詳細については、「分離モードの 」を参照してください。 最初にアプリをコンテナー化するときは、2 つのモードから選択する必要があります。 幸いなことに、アプリケーションまたはコンテナーに変更を加える必要がないため、後で 1 つのモードから別のモードに変更するのは非常に簡単です。 ただし、アプリをコンテナー化するときは、2 つのモードのいずれかを選択することが最初に行う必要があることに注意してください。

コンテナーのオーケストレーション

OS 管理を気にせずに 1 つまたは複数のホストで複数のコンテナーを実行できるため、柔軟性が高く、マイクロサービス ベースのアーキテクチャに移行できます。 その柔軟性の代償として、コンテナとマイクロサービスに基づく環境は、非常に多くの可動パーツに急激に増えすぎて、追跡が困難になる可能性があります。 さいわい、負荷分散、高可用性、コンテナーのスケジュール設定、リソース管理などを管理することは、コンテナー オーケストレーターの役割です。

オーケストレーターの名前が間違っている可能性があります。彼らは、音楽を再生し続けるために複数のコンテナの活動を調整するという点で、オーケストラの指揮者に似ています。 ある意味では、OS の機能と同様の方法で、コンテナーのスケジュール設定とリソース割り当てを処理します。 そのため、アプリケーションをコンテナー化する場合は、Windows コンテナーをサポートするオーケストレーターの中から選択する必要があります。 最も一般的なものの一部は、Kubernetes と Docker Swarm です。

Windows コンテナーに移動できない内容

アプリをコンテナー化できるかどうかを検討する場合は、Windows コンテナーをオプションとして完全に除外する要因の一覧から始めるのが最も簡単です。

次の表は、Windows コンテナーに移動できないアプリの種類とその理由をまとめたものです。 理由については、表の後のサブセクションで詳しく説明します。 これらの制限の理由を理解すると、VM とどのように異なるかなど、コンテナーが実際に何であるかをより明確に把握できます。 これにより、コンテナー化できる既存のアプリで利用できる Windows コンテナーの機能をより適切に評価できます。

注: 以下のリストは完全なリストではありません。 お客様がコンテナー化しようとしているのを Microsoft が確認したアプリを寄せ集めたものです。

アプリケーション/機能はサポートされていません サポートされない理由 これを回避できますか?
デスクトップを必要とするアプリケーション コンテナーはグラフィック ユーザー インターフェイス (GUI) をサポートしていません アプリケーションでインストールする GUI のみが必要な場合は、サイレント インストールに変更することがソリューションである可能性があります。
リモート デスクトップ プロトコル (RDP) を使用するアプリケーション RDP は対話型セッション用であるため、上記の原則もここに適用されます リモート管理の代替手段として、Windows Admin Center (WAC) またはリモート PowerShell を使用できる場合があります
ステートフル アプリケーション コンテナーはエフェメラル はい。一部のアプリケーションでは最小限の変更が必要な場合があるため、コンテナー内にデータや状態が格納されません
データベース アプリケーション コンテナーはエフェメラル はい。一部のアプリケーションでは最小限の変更が必要な場合があるため、コンテナー内にデータや状態が格納されません
Active Directory Active Directory の設計と目的により、コンテナーで実行されるのが妨げる いいえ。 ただし、Active Directory に依存するアプリでは、グループ管理サービス アカウント (gMSA) を使用できます。 gMSA の詳細については、以下を参照してください。
以前のバージョンの Windows Server Windows Server 2016 以降のみがサポートされています いいえ。 ただし、アプリケーションの互換性はオプションである可能性があります。ほとんどの Windows Server 2008/R2 および古いアプリは、新しいバージョンの Windows Server で実行されます
.NET Framework バージョン 2.0 以前を使用するアプリ .NET Framework をサポートするには特定のコンテナー イメージが必要であり、より新しいバージョンのみがサポートされます 2.0 より前のバージョンはサポートされていませんが、以降のバージョンに必要なコンテナー イメージについては以下を参照してください
他のサード パーティ製フレームワークを使用するアプリ Microsoft は、Windows コンテナーでの Microsoft 以外のフレームワークの使用を明示的に認定またはサポートしていません 特定のフレームワークまたはアプリのベンダーに、Windows コンテナーのサポート ポリシーを確認してください。 詳細については、以下を参照してください。

次に、これらの各制限について考えてみましょう。

デスクトップを必要とするアプリケーション

コンテナーは、ユーザー操作を含む他のアプリケーションから呼び出されるエフェメラル関数に最適です。 ただし、UI 自体を持つアプリケーションには使用できません。 これは、アプリケーション自体に GUI がなくても、GUI に依存するインストーラーがある場合でも当てはまります。 一般に、Windows インストーラーは PowerShell を使用して呼び出すことができますが、アプリケーションで GUI を使用したインストールが必要な場合は、コンテナー化の候補として不要になります。

これは、Windows コンテナーの実装方法に関する問題ではなく、コンテナーのしくみの基本的な概念です。

アプリに GUI API が必要かどうかは別の問題です。 これらの API によって提供される GUI がサポートされていない場合でも、API はサポートされます。 これは、Nano Server x Server Core x Server トピックで詳しく説明されています。適切な基本イメージはどれですか?

RDP を使用するアプリケーション

リモート デスクトップ プロトコル (RDP) の目的全体は対話型のビジュアル セッションを確立するため、前述の GUI の制限も適用されます。 RDP を使用するアプリケーションは、as-isコンテナー化できません。

ただし、代わりに、Windows Admin Center などのリモート管理ツールを使用することをお勧めします。 Windows Admin Center を使用すると、Windows コンテナー ホストとコンテナー自体を管理できます。RDP で接続する必要はありません。 ホストやコンテナーへのリモート PowerShell セッションを開いて管理することもできます。

ステートフル アプリケーション

状態データを保持する必要があるアプリケーションは、必要なデータを 1 つのセッションから次のセッションに分離し、永続ストレージに格納する場合にのみコンテナー化できます。 これにはいくつかの "再設計" が必要になる場合があります。これは簡単な場合もあれば、そうでない場合もありますが、それに進むと、コンテナー化に対するこの障壁はなくなります。

状態の例として、画像や音楽ファイルをローカル フォルダーに格納する Web アプリケーションがあります。 従来の Windows 環境では、書き込み操作が終了した時点でファイルがディスクに保存されるため、インスタンス (この場合は VM) が失敗した場合は、単にバックアップし、ファイルはそのまま残ります。 これに対し、書き込み操作を実行しているコンテナー インスタンスが失敗した場合、新しいコンテナー インスタンスにはそのファイルは含まれません。 このため、すべてのコンテナー インスタンスが状態データまたはファイルを一元化された永続的な場所に格納できるように、永続ストレージの使用を検討する必要があります。 この種類の再設計では、アプリケーションのコードを変更する必要はありません。これは、Windows インスタンスで使用されるストレージの種類だけです。 詳細については、ストレージ に関する Windows コンテナードキュメントを参照してください。

ただし、別の関連トピックが表示されます。...

データベース アプリケーション

一般的に、データベース アプリケーションはコンテナー化に適した候補ではありません。 コンテナー内でデータベースを実行できますが、2 つの理由から、通常、既存のデータベースをコンテナー化することは理想的ではありません。

まず、データベースに必要なパフォーマンスでは、ホストで使用できるハードウェア リソース全体が必要になる場合があります。これは、統合の利点を損ないます。 2 つ目は、1 つのデータベース層の複数のインスタンスで、その書き込み操作を調整する必要があります。 コンテナー オーケストレーションで解決できますが、既存のデータベースの場合、オーケストレーションがオーバーヘッドになる可能性があります。 Microsoft SQL Server などのほとんどのデータベースには、ロード バランスと高可用性メカニズムが組み込まれています。

Windows Server 上のインフラストラクチャ役割

Windows Server インフラストラクチャの役割は、主にオペレーティング システムに近い機能 (AD、DHCP、ファイル サーバーなど) を処理します。 そのため、実行中のコンテナーでは使用できません。 そのため、これらのロールを必要とするアプリケーションは常にコンテナー化が困難になります。

灰色の領域がいくつかあります。 たとえば、DNS などの一部の機能は、実際にはコンテナーで使用することを意図していない場合でも、Windows コンテナーで動作する場合があります。 その他のインフラストラクチャ ロールは、基本コンテナー イメージから単に削除され、Active Directory、DHCP など、インストールできません。

Active Directory (AD)

Active Directory は、20 年以上前に Windows 2000 Server に沿ってリリースされました。 各デバイスまたはユーザーがデータベースに格納されているオブジェクトによって表されるメカニズムを使用します。 この関係は緊密に結合されており、実際のユーザーやデバイスが使用されなくなった場合でも、オブジェクトはデータベースに保持されます。 Active Directory に対するこのアプローチは、コンテナーの一時的な性質と直接矛盾しています。これは、有効期間が短いか、無効にされたときに削除されることが予想されます。 Active Directory とのこの 1 対 1 の関係を維持することは、このようなシナリオには適していません。

そのため、Windows コンテナーをドメインに参加させることはできません。 その結果、Windows コンテナーでインフラストラクチャ ロールとして Active Directory Domain Services を実行することはできません。 Windows コンテナー内でドメイン コントローラーをリモートで管理するための PowerShell モジュールを実行できます。

Active Directory に依存する Windows コンテナーで実行されているアプリケーションの場合は、グループ管理サービス アカウント (gMSA) を使用します。これについては、さらに説明します。

.NET Framework バージョン 2.0 以前を使用するアプリ

アプリケーションで .NET が必要な場合、コンテナー化する機能は、使用する .NET Framework のバージョンによって完全に異なります。 .NET Framework 2.0 より前のバージョンはサポートされていません。より高いバージョンでは、後で説明するように特定のイメージを使用する必要があります。

サードパーティ (Microsoft 以外) フレームワークを使用するアプリ

一般に、Microsoft では、サード パーティのフレームワークやアプリケーションを認定したり、Windows コンテナー(物理マシンや仮想マシン)で実行されているフレームワークやアプリケーションをサポートしたりすることはできません。 ただし、Microsoft は、Apache、Cassandra、Chocolatey、Datadog、Django、Flask、Git、Golang、JBoss、Jenkins、Rust、Nodejs、Pearl、Python、Ruby、Tomcat など、複数のサードパーティのフレームワークとツールの使いやすさに関する独自の内部テストを実行しています。

サード パーティ製のフレームワークまたはソフトウェアについては、Windows コンテナーでのサポートを提供するベンダーと共に検証してください。

コンテナー化に最適な候補

アプリのコンテナー化に関する難しい制限事項を検討したので、Windows コンテナーにどの種類のアプリがより簡単に役立つのかを簡単に確認できるようになりました。 Windows コンテナーの理想的な候補と、コンテナー化に関する特別な考慮事項を次の表に示します。

アプリケーションの種類 これらが適切な候補である理由 特別な考慮事項
コンソール アプリケーション GUI の制限がないため、コンソール アプリはコンテナーに最適な候補です。 アプリケーションのニーズに応じて、適切な基本コンテナー イメージを使用します。
Windows サービス これらはバックグラウンド プロセスであるため、直接のユーザー操作は必要ありません アプリケーションのニーズに応じて、適切な基本コンテナー イメージを使用します。 コンテナー化されたバックグラウンド プロセスを実行し続けるために、フォアグラウンド プロセスを作成する必要があります。 以下のバックグラウンド サービスのセクションを参照してください。
Windows Communication Foundation (WCF) サービス これらは、バックグラウンドでも実行されるサービス指向のアプリであるため アプリケーションのニーズに応じて、適切な基本コンテナー イメージを使用します。 コンテナー化されたバックグラウンド プロセスを実行し続けるために、フォアグラウンド プロセスを作成する必要がある場合があります。 以下のバックグラウンド サービスのセクションを参照してください。
Web アプリ Web アプリケーションは基本的に、特定のポートでリッスンするバックグラウンド サービスであるため、コンテナー化の候補として最適です。コンテナーによって提供されるスケーラビリティを活用するためです。 アプリケーションのニーズに応じて、適切な基本コンテナー イメージを使用します。

注: コンテナー化のこれらの理想的な候補であっても、Windows コンテナーで異なる方法で処理する必要がある主要な Windows の機能とコンポーネントに依存する場合があります。 このような実用的な考慮事項について詳しく説明する次のセクションでは、Windows コンテナーの機能を活用するための準備を強化します。

コンテナー化できるアプリケーションに関する実用的な考慮事項

通常、アプリの改装プロジェクトでは、アプリのビジネス機能の観点から特定のアプリをコンテナー化できるかどうかを考慮します。 しかし、ビジネス機能は、技術的に可能かどうかを決定する要因ではありません。 重要なのは、アプリのアーキテクチャ、つまり、それが依存する技術コンポーネントです。 そのため、"HR アプリケーションをコンテナー化できますか" のような質問に対する簡単な回答はありません。これは、アプリケーションの実行内容ではなく、違いを生み出す方法 (および Windows コンポーネント/サービス) であるためです。

アプリケーションが最初にマイクロサービス アーキテクチャを使用して構築されていない場合、コンテナー化が困難になる可能性があるため、これは重要な違いです。 コンテナー化に進む際に、特定の機能で特別な処理が必要になる場合があります。 一部は、Windows コンテナーでサポートされていない主要な Windows コンポーネントとフレームワークのアプリの使用が原因である可能性があります。 イベント ログや監視などは、アプリをコンテナー化する場合にのみ明らかになる、Linux と Windows の固有の違いによるものです。 スケジュールされたタスクやバックグラウンド サービスなどの他のユーザーは、コンテナーが VM ではなく一時的なものであり、特別な処理が必要であるという観点から理解する必要があります。

次の表は、コンテナー化を検討する際に特別な考慮事項が必要なアプリケーションのコンポーネント/機能の概要を示しています。 以下のサブセクションでは、各シナリオを処理するための手法を示す例など、さらに詳しく説明します。 以下の一覧では、Windows コンテナーでサポートされているシナリオについて説明しますが、これらのシナリオでは前の章のガイダンスを尊重する必要があります。 たとえば、バックグラウンド サービスはサポートされていますが、.NET Framework 1.1 でのバックグラウンド サービスの実行はサポートされていません。

特別な処理を必要とする Windows の機能/コンポーネント 理由
Microsoft メッセージング キュー (MSMQ) MSMQ はコンテナーよりずっと前に発生し、メッセージ キューのすべてのデプロイ モデルがコンテナー アーキテクチャと互換性があるわけではありません。
Microsoft 分散トランザクション コーディネーター (MSDTC) MSDTC とコンテナーの間の名前解決には、特別な考慮事項が必要です。
IIS IIS は VM と同じですが、証明書管理、データベース接続文字列など、コンテナー環境で実行する際には重要な考慮事項があります。
スケジュールされたタスク Windows コンテナーでは、任意の Windows インスタンスと同様に、スケジュールされたタスクを実行できます。 ただし、コンテナー インスタンスを実行し続けるために、フォアグラウンド タスクの実行が必要になる場合があります。 アプリケーションによっては、イベント ドリブンのアプローチを検討する必要がある場合があります。
バックグラウンド サービス コンテナーは一時的なプロセスとして実行されるため、コンテナーを実行し続けるためには追加の処理が必要です。
.NET Framework と .NET (以前の .Net Core) 次のサブセクションで説明するように、互換性を確保するために適切なイメージを使用してください。

その他のサポート コンポーネント

特別な処理を必要とするコンポーネント 理由 代替アプローチ
イベント ログ/監視 Windows がイベントとログを書き込む方法は本質的に Linux stdout とは異なるため 新しいログ モニター ツールを使用してデータを正規化し、Linux と Windows の両方から結合します。
Windows コンテナーのセキュリティ 多くのセキュリティ プラクティスは変わりませんが、コンテナーには追加のセキュリティ対策が必要です。 専用のレジストリとイメージ スキャン ツールを使用します。詳細については後で説明します。
Windows コンテナーのバックアップ コンテナーにデータや状態を含めないようにする コンテナーとコンテナー イメージで使用される永続的なストレージをバックアップします。

Windows コンポーネント/機能

次に、コンテナー化できますが、追加の処理が必要なアプリケーションとコンポーネントの詳細について説明します。

MSMQ

アプリケーションが MSMQ に依存している場合、アプリケーションをコンテナー化できるかどうかは、その MSMQ デプロイ シナリオによって異なります。 MSMQ には、複数のデプロイ オプションが含まれています。 プライベート キューとパブリック キュー、トランザクション キュー、認証の種類の要因は、MSMQ が最初にサポートするように設計されたシナリオのマトリックスを形成します。 これらのすべてが Windows コンテナーに簡単に移動できるわけではありません。 次の表に、サポートされているシナリオを示します。

スコープ トランザクションかどうか キューの場所 認証の種類 送受信かどうか
非公開 はい 同じコンテナー (単一コンテナー) アノニマス はい
プライベート はい 永続ボリューム アノニマス はい
プライベート はい ドメイン コントローラー アノニマス はい
プライベート はい 単一ホスト (2 つのコンテナー) アノニマス はい
パブリック いいえ 2 つのホスト アノニマス はい
パブリック はい 2 つのホスト アノニマス はい

Microsoft の内部開発チームによって検証された、これらのサポートされているシナリオに関するいくつかの注意事項:

  • 分離モード: 分離のためのプロセス モードと Hyper-V モードの両方が、上記のシナリオで動作します。
  • 最小 OS とコンテナー イメージ: MSMQ での使用に推奨される最小 OS バージョンは Windows Server 2019 です。
  • 永続ボリューム: 上記のシナリオでは、永続的ストレージに Azure ファイルを使用して、Azure Kubernetes Service (AKS) で MSMQ を実行している検証が行われました。

これらの考慮事項を上記の表と組み合わせると、サポートされないシナリオは、Active Directory での認証を必要とするキューに対するシナリオだけであることがわかります。 MSMQ には Active Directory への依存関係がまだ存在していないため、gMSA (グループ管理サービス アカウント) と MSMQ の統合は現在サポートされていません。

または、MSMQ の代わりに Azure Service Bus を使用します。 Azure Service Bus は、メッセージ キューと発行/サブスクライブ トピック (名前空間内) を備えたフル マネージドのエンタープライズ メッセージ ブローカーです。 MSMQ から Azure Service Bus への切り替えには、コードの変更とアプリケーションの再アーキテクチャが必要ですが、最新のプラットフォームに移行する機敏性が得られます。

MSDTC

Microsoft 分散トランザクション コーディネーター (MSDTC) は、大企業の間で Windows レガシ アプリケーションで頻繁に使用されています。 MSDTC は Windows コンテナーにインストールできますが、動作せず、Windows コンテナーで再現できない特定のシナリオがあります。

  • コンテナーを作成するときは、必ず --name パラメーターを docker run コマンドに渡してください。 この名前パラメーターは、コンテナーが Docker ネットワーク経由で通信できるようにするためのパラメーターです。 gMSA を使用する場合、名前は gMSA アカウント名と一致する必要があるホスト名と一致する必要があります。
    • gMSA を使用した実行コマンドの例を次に示します。
docker run -d --security-opt "credentialspec=file://contoso_webapp01.json" --hostname webapp01 -- name webapp01 mcr.microsoft.com/windows/servercore:ltsc2022
  • コンテナーは、NETBIOS 名を使用して相互に解決できる必要があります。 これに問題がある場合は、コンテナーの名前と IP を他のホスト ファイルに追加することをお勧めします。
  • 両方のコンテナーの msdtc の uuid は一意である必要があります。 uuid は、コンテナーの PowerShell で "Get-Dtc" を実行することで確認できます。 一意でない場合、解決する 1 つの方法は、いずれかのコンテナーで msdtc をアンインストールして再インストールする方法です。 これらの PowerShell コマンドは、「uninstall-dtc」や「install-dtc」を使用できます。
  • 現在、MSDTC は Azure Kubernetes Services ではサポートされていません。 AKS で MSDTC を実行する必要がある場合は、GitHub で Windows コンテナー リポジトリで問題を開いて、Windows コンテナー チームに通知してください。

コンテナーと VM での IIS のしくみ

IIS は、WINDOWS コンテナー上で VM と同じように動作します。 ただし、コンテナー環境で実行する場合に考慮する必要がある IIS インスタンスの実行には、いくつかの側面があります。

  • ローカル データの永続ストレージ: アプリがファイルの書き込み/読み取りを行うフォルダーは、IIS インスタンスの VM に保持する優れた例です。 コンテナーでは、データをコンテナーに直接書き込む必要はありません。 コンテナーはローカル ストレージに "スクラッチ領域" を使用します。同じアプリケーションに対して新しいコンテナーが起動すると、以前のコンテナーからその領域にアクセスできなくなります。 そのため、任意のコンテナー インスタンスがそのストレージにアクセスできるように、Web アプリケーションからアクセスできる必要があるデータに永続的ストレージを使用します。
  • 証明書: コンテナー インスタンスにローカル証明書を含めることができますが、証明書を更新する必要がある場合はコンテナー イメージを再構築する必要があるため、これを行わないでください。 または、イングレス コントロールでコンテナー オーケストレーターを使用することもできます。 イングレス コントローラーでは、ネットワーク ポリシーを適用したり、その背後でホストされている Web サイトの証明書管理を処理したりすることもできます。 逆に、証明書のライフサイクル管理を Web サイトの管理から切り離します。
  • データベース接続文字列: 従来の IIS デプロイでは、アプリケーションのデプロイの一部として DB 接続文字列を渡すことができます。 Windows コンテナーではそのモデルに従うことができますが、DB 接続文字列をコンテナーから、アプリケーションが読み取ることができるコンテナー オーケストレーターによって提供される一元化された構成に切り離すことを検討できます。 これにより、アプリケーションとは別に DB 接続文字列を管理および更新できます。 DB が変更された場合 (たとえば、クラウドへのリフト アンド シフトの場合) は、コンテナー イメージを再構築せずに接続文字列を簡単に変更できます。 この方法では、シークレット ストアにシークレット (DB に接続するためのユーザー名やパスワードなど) を保持することもできます。
  • 水平自動スケール: 負荷が増加すると、コンピューティング システムは、同時要求を処理しようとしたときに、認識されるパフォーマンスが低下する傾向があります。 パフォーマンスへの影響を回避するには、通常、垂直スケールと水平スケールの 2 つの方法があります。 垂直方向のスケールにより、既存のコンピューティング インスタンスで使用できるリソースが増加します (CPU やメモリなど)。 水平方向のスケールにより、要求をサポートするインスタンスの数が増えます (より多くの物理ホスト、VM、またはコンテナー)。 IIS などの Web 層の場合、水平方向のスケールは垂直方向よりも効率的になる傾向がありますが、オンプレミス環境ではリソースの制限や負荷分散の問題が発生する可能性があります。 クラウド環境では、(追加コストで) リソースを簡単に利用でき、クラウド プロバイダーは通常、水平方向のスケールを考慮して負荷分散メカニズムを設計するため、水平方向のスケールがはるかに簡単になります。 Windows コンテナーは IIS の水平方向のスケールを利用できますが、コンテナーの一時的な側面が重要な役割を果たします。 コンテナーの構成が同じであり、Web アプリケーションをサポートするインスタンスの数をスケールアップまたはスケールダウンできるように状態やデータが格納されていないことが不可欠です。

スケジュールされたタスク

スケジュールされたタスクは、Windows 環境でプログラム、サービス、またはスクリプトをいつでも呼び出すために使用されます。 従来、Windows インスタンスは常に稼働しており、トリガーが満たされるとタスクが実行されます。 これは Windows コンテナーで可能であり、Azure PowerShell を使用してスケジュールされたタスクを構成および管理する必要があることとは別に、まったく同じように動作します。

ただし、マイクロサービスアプローチでは、トリガーを待機するためにコンテナーを実行したままにしておくのを避けるために、いくつかのオプションがあります。

  • Azure 関数などのイベント ドリブン PaaS (サービスとしてのプラットフォーム) を使用して、コードを格納し、そのアプリのトリガーを定義します。 Azure Functions では、トリガーが満たされたときに実行される Windows コンテナー イメージもサポートされています。
  • Windows コンテナーをコンテナー オーケストレーターと組み合わせて使用します。 コンテナーは、トリガーが満たされ、アプリケーションの他の部分から呼び出された場合にのみ実行できます。 この場合、コンテナー オーケストレーターはアプリケーションのスケジューリングとトリガーを処理します。
  • 最後に、スケジュールされたタスクを実行するために Windows コンテナーを実行したままにします。 コンテナーの実行を維持するには、フォアグラウンド サービス (サービス モニターなど) が必要です。

バックグラウンド サービス

コンテナーは一般的に一時的なプロセス用ですが、バックグラウンドで実行時間の長いアプリケーションをコンテナー化できます。ただし、フォアグラウンド プロセスを作成して開始し、実行し続ける場合は、アプリケーションをコンテナー化できます。

この優れた例は ServiceMonitor です。ServiceMonitor は、コンテナーで IIS を実行するときにエントリ ポイント プロセスとして使用されるように設計された Windows 実行可能ファイルです。 IIS 用に構築されていますが、ServiceMonitor ツールには、他のサービスの監視にも使用できるモデルが用意されていますが、いくつかの制限があります。

ServiceMonitor の詳細については、Github のドキュメントを参照してください。

.NET Framework と .NET

Windows コンテナーでは、.NET Framework と .NET (以前の .NET Core) の両方がサポートされています。 .NET チームは、Windows 基本コンテナー イメージの上に両方のフレームワーク用の独自の公式イメージを作成します。 互換性を確保するには、適切なイメージを選択することが重要です。 .NET チームは、Server Core 基本コンテナー イメージの上に .Net Framework イメージを提供し、Server Core と Nano Server の両方の基本コンテナー イメージの上に .NET イメージを提供します。 Server Core には Nano Server よりも大きな API セットがあり、互換性が向上するだけでなく、イメージ サイズも大きくなります。 Nano Server の API サーフェスは大幅に縮小されていますが、画像サイズは大幅に小さくなります。

場合によっては、Windows またはサーバーの基本コンテナー イメージの上に独自の .NET Framework または .NET イメージをビルドすることが必要になる場合があります。 これは、アプリケーションにフレームワークの依存関係だけでなく、OS の依存関係がある場合に必要になる場合があります。 特定の基本コンテナー イメージを使用してアプリケーションをテストすることで、このような依存関係を検出できます。

たとえば、Server Core と Nano Server の基本コンテナー イメージには、イメージ サイズを小さくするためのフォントが 1 つだけ用意されています。 アプリケーションで別のフォントが必要な場合は、そのフォント インストールするか、より大きな API セットを持ち、すべての既定の Windows フォントを含むサーバーイメージまたは Windows イメージを使用する必要があります。 互換性の観点から見ると、これにより、事実上すべてのアプリ (コンテナーの性質 (GUI なしなど) を尊重している限り) をコンテナー化できます。 欠点として、サイズが大幅に大きくなり、パフォーマンスに影響を与える可能性があります。

コンテナー化するアプリケーションが Windows コンテナーで動作するかどうかを検証する場合、Microsoft では次のことをお勧めします。

このフレームワークの場合 最初にこのコンテナー イメージを使用してテストする 最初に機能しない場合は、このコンテナー イメージにフォールバックする 基本イメージ
.NET Framework バージョン 2.X および 3.X .NET Framework 4.x .NET Framework 3.5 Windows Server Core
.NET Framework 4.x バージョン .NET Framework 4.x サーバーまたは Windows イメージを使用して .NET Framework コンテナー イメージをビルドする Windows Server Core
.NET 6 または 7 それぞれ .NET 6 または 7 Windows または Server の基本イメージを使用して .NET コンテナー イメージをビルドする Windows Nano Server または Server Core

その他のサポート コンポーネント

以下のコンポーネントとトピックでは、一緒に行ったり、Windows コンテナーをより明確にしたりするための項目に関する追加のガイダンスを提供します。

イベント ログ

Windows と Linux では、さまざまな方法を使用して、ログとイベントをユーザーに格納して表示します。 従来、Windows では EVT 形式が使用されており、イベント ビューアーで構造化された方法で表示できます。 これに対し、Linux では、Docker などの他のツールが依存する Standard Output (stdout) を使用した合理化されたアプローチが提供されています。

Docker には、Linux コンテナーからログを抽出するメカニズムが常に用意されています。 既定の stdout 構成で "docker logs" コマンドを使用すると、Docker はコンテナーを対話形式で開かずに、アプリケーション ログをコンテナーから取り出します。 ただし、ログ モニター ツールを起動するまでは、同じ手法が Windows では機能しませんでした。

ログ モニター ツールでは、Windows ログが stdout 形式で表示されるため、Docker などの他のツールで、表示に必要な情報を収集できます。 ログ モニターを使用する場合のその他の利点は次のとおりです。

  • stdout で公開するイベント/ログの種類をフィルター処理できること。 たとえば、"情報" イベントに関心がない場合にのみ、アプリケーション ログに "エラー" メッセージと "警告" メッセージをフィルター処理できます。
  • イベント ログ、カスタム ログ ファイル、または Windows イベント トレース (ETW) から選択する機能。 これは、アプリケーションが別のログ ソースに書き込む場合に特に役立ちます。 その例として、"C:\inetpub" フォルダーにある IIS ログがあります。
  • Log Monitor を使用すると、Windows コンテナーは Linux コンテナーとよく似た動作をするため、stdout を検索してコンテナー ランタイム関数と対話するツールが期待どおりに動作します。 たとえば、コンテナー ランタイムとして Docker から ContainerD に移動する場合、ログは (例: "crictl logs" を介して) コンテナー ホストから表示されます。

ログ モニター ツールの詳細については、このブログ記事 参照してください。

Windows コンテナーのセキュリティ

Windows コンテナーは、物理マシンまたは仮想マシンで実行されている Windows インスタンスと同じベース上に構築されます。 コンテナーの実装方法の詳細 (特に共有カーネルの性質) を理解することは、コンテナー化されたアプリケーションをセキュリティで保護するのに役立ちます。

  • 共有コンポーネント。 Windows コンテナーは、セキュリティ目的でホストのコンポーネントの一部を共有します。 これには、Windows ファイアウォール、Windows Defender (ウイルス対策)、その他のリソース アクセス制限が含まれます。 コンテナー ホストはコンテナーのワークロードに基づいて必要な調整を行うため、コンテナーでこれらのコンポーネントを直接構成する必要はありません。 たとえば、コンテナーが Web 要求を行った場合、コンテナー ホストは、コンテナーが Web にアクセスできるように、必要なトラフィックをファイアウォール経由で転送します。
  • 分離モード。 議論したように、Windows コンテナーはプロセスまたは Hyper-V 分離モードで展開でき、Hyper-V が最も安全な分離を提供します。 プロセスの分離では、コンテナーはカーネル、ファイル システム、レジストリをホストと共有します。これにより、管理者特権の (管理者) プロセスがコンテナー のプロセスとサービスと対話できるようになります。 適切なセキュリティ モデルを確保するには、アプリケーションに適した分離モードを選択することが重要です。
  • Windows 更新プログラム。 サービス スタックは Windows コンテナーに存在しないため、Windows コンテナーは一般的な Windows インスタンスなどの更新プログラムを受け取りません。 代わりに、使用可能な最新の基本コンテナー イメージを使用して Windows コンテナーを再構築する必要があります。 お客様は、その目的のために DevOps パイプラインを利用できます。 Microsoft は、Patch Tuesday の周期に続いて、毎月、すべての公式イメージの基本コンテナー イメージを更新します。
  • コンテナー ユーザー アカウント。 既定では、Windows コンテナー内のアプリケーションは、ContainerAdmin ユーザー アカウントの管理者特権で実行されます。 これは、コンテナー イメージ内に必要なコンポーネントをインストールして構成する場合に役立ちます。 ただし、昇格された特権を必要としないアプリケーションを実行するときは、ユーザー アカウントを ContainerUser に変更することを検討する必要があります。 特定のシナリオでは、適切な特権を持つ新しいアカウントを作成することもできます。
  • イメージとランタイムのスキャン。 コンテナーでは、リポジトリとコンテナー インスタンス上のイメージがセキュリティで保護されている必要があります。 Microsoft では、イメージ スキャンとランタイム スキャンに Microsoft Defender for Containers を使用することをお勧めします。 Defender for Containers では、レジストリ スキャンによる脆弱性評価と、脅威検出によるランタイム保護のための Windows コンテナーがサポートされています。

上記のトピックの詳細については、Windows コンテナー ドキュメント ページを参照してください。

Windows コンテナーのバックアップ

コンテナーを使用する場合は、バックアップについて異なる考え方をする必要があります。 前に説明したように、一時的な性質を考えると、コンテナーを使用して状態やデータを格納しないでください。 コンテナー インスタンスから状態とデータを分離する場合、バックアップの問題はコンテナー インスタンスのランタイムの外部にあります。これは、必要なすべての永続ストレージを引き続き使用できる新しいものに置き換えることができます。

ただし、バックアップを担当するコンポーネントは引き続き存在します。には、アプリケーション、コンテナー イメージ、コンテナー イメージをビルドする dockerfile が含まれます。 これらの操作のほとんどは、運用ワークロードと開発ワークロードを実行するプラットフォームによって処理されます。 DevOps アプローチを採用する場合は、最も一般的なケースを考慮してください。

  • アプリケーション: アプリケーションは、GitHub や Azure DevOps などのソース リポジトリに存在する可能性があります。 これらのリポジトリにはバージョン管理が用意されているため、アプリケーションの特定のバージョンに戻すことができます。 ソース リポジトリを所有している場合は、バックアップと管理に関する推奨事項に従ってください。
  • コンテナー イメージ: 運用環境の場合、コンテナー イメージは、Azure Container Registry (ACR) などの一元化されたイメージ リポジトリに格納されている必要があります。 コンテナー イメージを ACR にプッシュして、他のホストがプルできるようにします。 ACR はコンテナー イメージの可用性を処理し、バックアップ オプションとして機能します。ただし、ACR はイメージの可用性を処理する一方で、イメージが削除または上書きされるのを防ぐことはありません。 その他のローカルまたはオンプレミスのイメージ リポジトリについては、既存のレジストリをバックアップするためのベンダーの推奨事項に従ってください。
  • Dockerfile: Dockerfile は新しいコンテナー イメージをビルドし、通常はアプリケーション ソースと共に格納されます。 dockerfile はアプリケーションで作成されていない可能性があるため、特にコンテナー化されている既存のアプリケーションの場合は、dockerfile が安全でバックアップされた場所に格納されていることを確認する必要があります。 また、アプリケーションがコンテナーで動作するために必要なその他の資産もバックアップされるようにする必要があります。たとえば、Kubernetes、Docker Swarm、Azure ARM テンプレートの YAML ファイルと JSON ファイルは、上記と同じガイドラインに従います。

リフトアンドシフトプロセスの計画

コンテナー化のためのアプリケーションの準備状況を評価したら、次の一般的なガイダンスを使用してプロセスを計画します。

  1. Windows オペレーティング システムの基本イメージとして必要なものを決定します: Windows Server Core、Nano Server、Windows、または Server イメージ。
  2. コンテナーの分離モードの種類を決定します。プロセスまたは Hyper-V 分離モードを選択します。 注: 現在、AKS と AKS on Azure Stack HCI では、プロセス分離コンテナーのみがサポートされています。 今後のリリースでは、AKS と AKS on Azure Stack HCI の両方で Hyper-V 分離コンテナーもサポートされます。 詳細については、「分離モードの」を参照してください。
  3. アプリ互換性のために、アプリケーションに適した Windows Server バージョンを選択します。 コンテナーの最小 Windows Server バージョンは Windows Server 2016 ですが、AKS と AKS on Azure Stack HCI でサポートされているコンテナー ホスト オペレーティング システムは Windows Server 2019 と Windows Server 2022 だけです。
  4. コンテナー環境に対して会社のセキュリティ ポリシーが設定されていることを確認します。 これには、レジストリのスキャンや脅威の検出など、コンテナー固有の要件への適応が含まれます。
  5. 負荷分散のニーズを検討してください。 コンテナー自体は移動しません。代わりにオーケストレーターを使用して、クラスター ノードでコンテナーを自動的に開始または停止したり、負荷と可用性の変更を自動水平スケールで管理したりできます。
  6. オーケストレーションのニーズを考慮してください。 コンテナー化されたアプリケーションでは、Kubernetes、AKS、AKS on Azure Stack HCI などのツールを使用して使用できる自動化された管理が必要な場合があります。 ツールの選択に関する詳細な説明とガイドについては、「Windows コンテナーのオーケストレーションの概要」を参照してください。
  7. アプリをコンテナー化します。
  8. アプリをイメージ リポジトリにプッシュします。 これにより、コンテナー ホストは、開発、テスト、運用など、任意の環境でイメージをダウンロードできます。

Azure Migrate では、既存の Windows アプリケーションを検出し、評価し、Azure Kubernetes Service に移行するためのガイド付きプロセスを提供できます。 詳細については、Azure Migrate ドキュメント ページ を参照してください。