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

  • [アーティクル]

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

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

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

はじめに

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 コンテナーには、2 種類のランタイム分離モードがあります。プロセスによる分離と Hyper-V による分離です。 どちらのモードのコンテナーも、同様に作成、管理され、同様に機能します。 では、違いは何ですか、違いを気に掛ける必要がある理由は何ですか? プロセスによる分離では、名前空間、リソース管理、およびその他の機能を使用して実現する分離により、複数のコンテナーを 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 つのモードのどちらかを選択する必要があります。 幸いなことに、後で一方のモードから他方のモードに非常に簡単に変更できます。これは、アプリケーションまたはコンテナーに変更を加える必要がないためです。 ただし、アプリをコンテナー化する場合は、2 つのモードのいずれかを選択することが、最初に行う必要がある作業の 1 つであることに注意してください。

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

OS 管理を気にせずに 1 つまたは複数のホストで複数のコンテナーを実行できると、柔軟性が向上し、マイクロサービス ベースのアーキテクチャに移行するのに役立ちます。 ただし、その柔軟性のトレードオフの 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 コンテナーのサポート ポリシーを確認してください。 詳細については、下記を参照してください

これらの各制限を検討してみましょう。

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

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

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

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

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

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

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

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

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

状態の例として、画像や音楽ファイルをローカル フォルダーに格納する 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 Apps Web アプリケーションは本質的に、特定のポートでリッスンするバックグラウンド サービスであり、コンテナーによって提供されるスケーラビリティを活用できるので、コンテナー化に最適な候補です アプリケーションのニーズに応じて、適切な基本コンテナー イメージを使用します。

注: コンテナー化に最適なこれらの候補であっても、Windows コンテナーで異なる処理が必要な Windows のコア機能やコンポーネントを利用する場合があります。 このような実用的な考慮事項について詳しく説明する次のセクションでは、Windows コンテナーの機能の利用に十分に備えることができます。

コンテナー化可能なアプリケーションに関する実用上の考慮事項

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

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

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

特別な処理が必要な Windows 機能/コンポーネント 理由
Microsoft Messaging Queueing (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 には、複数のデプロイ オプションが含まれています。 プライベート キューとパブリック キューの対比、トランザクションであるかどうか、認証の種類といった要素により、MSMQ が当初サポートするように設計されたシナリオのマトリックスが作成されます。 これらのすべてが Windows コンテナーに簡単に移行できるわけではありません。 次の表に、サポートされているシナリオを示します。

Scope トランザクションかどうか キューの場所 認証の種類 送受信かどうか
プライベート はい 同じコンテナー (単一コンテナー) 匿名 はい
プライベート はい 永続ボリューム 匿名 はい
プライベート はい ドメイン コントローラー 匿名 はい
プライベート はい 単一ホスト (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 コンテナーで再現できない特定のシナリオがあります。

  • コンテナーを作成するときは、docker run コマンドに必ず -name パラメーターを渡してください。 この name パラメーターは、コンテナーが Docker ネットワーク経由で通信できるようにするためのものです。 gMSA を使用する場合、この名前は gMSA アカウント名と一致する必要があるホスト名と一致する必要があります。
    • gMSA を使用した run コマンドの例を次に示します。
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 Function などのイベント ドリブン PaaS (サービスとしてのプラットフォーム) を使用して、コードを格納し、そのアプリのトリガーを定義します。 Azure Functions では、トリガーが満たされたときに実行される Windows コンテナー イメージさえもサポートされます。
  • Windows コンテナーをコンテナー オーケストレーターと組み合わせて使用します。 コンテナーは、トリガーが満たされ、アプリケーションの他の部分から呼び出された場合にのみ実行できます。 この場合、コンテナー オーケストレーターはアプリケーションのスケジュールとトリガーを処理します。
  • 最後に、スケジュールされたタスクを実行するために Windows コンテナーを実行したままにします。 コンテナーを実行し続けるには、フォアグラウンド サービス (サービス モニターなど) が必要です。

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

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

この適切な例は 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 または Server の基本コンテナー イメージの上に独自の .NET Framework または .NET イメージをビルドすることが必要になることがあります。 これが必要になる可能性があるのは、アプリケーションにフレームワークの依存関係だけでなく、OS の依存関係もある場合です。 特定の基本コンテナー イメージを使用してアプリケーションをテストすることで、このような依存関係を検出できます。

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

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

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

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

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

イベント ログ

Windows と Linux では、ログとイベントを格納し、ユーザーに提示するのに使用する方法が異なります。 従来、Windows では EVT 形式が使用されており、イベント ビューアーで体系的に表示できます。 これに対し、Linux では、Docker などの他のツールが利用する標準出力 (stdout) を使用した合理的な方法が用意されています。

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

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

  • stdout で公開するイベント/ログの種類をフィルター処理できること。 たとえば、"情報" イベントに関心がない場合、アプリケーション ログで "エラー" と "警告" メッセージのみをフィルター処理できます。
  • イベント ログ、カスタム ログ ファイル、または Windows イベント トレーシング (ETW) の中から選択できること。 これは、アプリケーションが別のログ ソースに書き込む場合に特に役立ちます。 この例は、"C:\inetpub" フォルダーにある IIS ログです。
  • ログ モニターによって 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 コンテナー レジストリ (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 のドキュメント ページをご覧ください。