Windows コンテナーとして既存の .NET アプリを展開する

  • [アーティクル]

Windows コンテナーに基づく展開は、クラウド向けに最適化されたアプリケーションやクラウドネイティブ アプリケーションに適用できます。

ただし、このガイド (特に以降のセクション) では、主として、アプリケーションを再設計する必要のない "クラウド向けに最適化されたアプリケーション" での Windows コンテナーの使用に重点を置いています。

コンテナーとは (Linux または Windows)

コンテナーとは、アプリケーションをそれ独自の分離パッケージにラップする方法です。 コンテナー内のアプリケーションは、コンテナーの外部に存在するアプリケーションやプロセスの影響を受けません。 アプリケーションがプロセスとして正常に実行するために依存するすべてのものは、コンテナー内にあります。 コンテナーが移動する場所がどこであっても、アプリケーションの要件は、直接的な依存関係の観点から常に満たされます。これは、実行に必要なすべてのもの (ライブラリの依存関係やランタイムなど) がアプリケーションにバンドルされているためです。

コンテナーの主な特徴は、コンテナー自体に必要なすべての依存関係が付属しているために、さまざまな展開にわたり同じ環境が確保されるということです。 ご利用のコンピューター上でアプリケーションをデバッグしてから、同じ環境が保証されている別のコンピューターに展開することができます。

コンテナーは、コンテナー イメージのインスタンスです。 コンテナー イメージとは、(スナップショットのように) アプリやサービスをパッケージ化してから、信頼性が高く、再現可能な方法で展開する方法です。 Docker はテクノロジであるだけでなく、哲学やプロセスでもあると言うことができます。

コンテナーが日常的に使用されるようになるにつれて、コンテナーは業界全体の "展開の単位" になりつつあります。

コンテナーの利点 (Linux または Windows 上の Docker エンジン)

コンテナー (軽量な構成要素として定義されている場合もあります) を使用してアプリケーションをビルドすると、インフラストラクチャ全体で任意のアプリケーションをビルド、配布、実行するための機敏性が大幅に向上します。

コンテナーを使用すると、Microsoft 開発者ツール、オペレーティング システム、およびクラウド全体にわたる Docker 統合により、コードをほとんどまたはまったく変更せずに、開発から運用まで任意のアプリを利用できます。

プレーン VM に展開する場合、ご利用の VM に ASP.NET アプリを展開するための所定の方法が既に用意されているはずです。 ただし、その方法には、Puppet などの展開ツールまたは同様のツールを使用して、手動による複数の手順または複雑な自動化プロセスが必要である可能性があります。 場合によっては、構成項目の変更、サーバー間でのアプリケーション コンテンツのコピー、.msi セットアップに基づく対話型セットアップ プログラムの実行などのタスクを行い、その後でテストを実行する必要があります。 展開でのそのようなすべての手順を行うと、展開にかかる時間が長くなりリスクが増えます。 ターゲット環境に依存関係が存在しない場合は必ずエラーが発生します。

Windows コンテナーでは、アプリケーションをパッケージ化するプロセスが完全に自動化されています。 Windows コンテナーは、コンテナーの展開に対して自動更新およびロールバックを行うことができる Docker プラットフォームに基づいています。 Docker エンジンを使用することで得られる主な改善点は、ご利用のアプリケーションとその依存関係をすべて含むスナップショットのようなイメージを作成できることです。 このイメージは Docker イメージです (この場合は Windows コンテナー イメージ)。 イメージでは、ソース コードに戻ることなく、コンテナー内で ASP.NET アプリが実行されます。 コンテナーのスナップショットが展開の単位となります。

組織の多くは、次の理由により、既存のモノリシック アプリケーションをコンテナー化しています。

  • 改善された展開によるリリースの機敏性。 コンテナーにより、開発と運用の間で一貫した展開コントラクトが得られます。 コンテナーを使用すると、"自分のマシンでは動作するのに運用環境で動作しないのはなぜだ" と言う開発者の言葉を聞くことはありません。 彼らは "コンテナーとして実行されているので、運用環境でも実行される" と言うことができます。 パッケージ化されたアプリケーションは、そのすべての依存関係と共に、サポートされている任意のコンテナーベースの環境で実行することができます。 すべての展開ターゲット (開発、QA、ステージング、運用) での実行を意図した方法で実行されます。 コンテナーでは、あるステージから次のステージに移行するときにほとんどの摩擦が排除されるため、展開が大幅に改善され、より迅速に配布できるようになります。

  • コスト削減。 コンテナーでは、既存のハードウェアの統合と削除によって、またはハードウェア単位ごとのより高い密度でのアプリケーションの実行により、コスト削減がもたらされます。

  • 移植性。 コンテナーはモジュール式で移植可能です。 Docker コンテナーは、任意のサーバー オペレーティング システム (Linux および Windows)、任意のメジャー パブリック クラウド (Microsoft Azure、Amazon AWS、Google、IBM)、およびオンプレミス環境とプライベートまたはハイブリッドのクラウド環境でサポートされています。

  • 制御。 コンテナーでは、コンテナー レベルで制御される柔軟で安全な環境が実現されます。 コンテナーに対して実行制約ポリシーを設定することで、コンテナーをセキュリティで保護し、分離し、さらに制限することができます。 Windows コンテナーに関するセクションで詳述したように、Windows Server 2016 と Hyper-V コンテナーには、追加のエンタープライズ サポート オプションが用意されています。

コンテナーを使用してアプリケーションを開発および管理すると、機敏性、移植性、および制御が大幅に改善され、最終的には大幅なコスト削減につながります。

Docker について

Docker とは、クラウドまたはオンプレミスで実行できる移植可能な自己完結型のコンテナーとしてアプリケーションの展開を自動化するオープン ソース プロジェクトです。 Docker は、このテクノロジを促進および進化させる会社でもあります。 この会社は、Microsoft を含む、クラウド、Linux、Windows の各ベンダーとの共同作業を行っています。

Docker によってハイブリッド クラウドにコンテナーが展開される方法を示す図。

図 4-6 Docker は、ハイブリッド クラウドのすべてのレイヤーでコンテナーを展開します。

仮想マシンを使い慣れているユーザーにとって、コンテナーは非常に似ているように見えるかもしれません。 物理または仮想コンピューター システムと同様に、コンテナーではオペレーティング システムが実行され、ファイル システムが用意されており、コンテナーにはネットワーク経由でアクセスできます。 ただし、コンテナーの背後にあるテクノロジおよび概念は仮想マシンとは大きく異なります。 開発者の観点から見ると、コンテナーはむしろ 1 つのプロセスのように扱う必要があります。 実際、コンテナーには 1 つのプロセス用の単一のエントリ ポイントがあります。

Docker コンテナー (簡単にする場合は、"コンテナー") は、Linux と Windows 上でネイティブに実行できます。 通常のコンテナーを実行する場合、Windows コンテナーは Windows ホスト (ホスト サーバーまたは VM) 上でのみ実行でき、Linux コンテナーは Linux ホスト上でのみ実行できます。 ただし、最新バージョンの Windows Server コンテナーおよび Hyper-V コンテナーでは、現在 Windows Server コンテナーでしか使用できない Hyper-V による分離テクノロジを使用することで、Linux コンテナーを Windows Server 上でネイティブに実行することもできます。

近い将来、Linux コンテナーと Windows コンテナーの両方が混在する環境が可能になり、さらには一般的になります。

既存の .NET アプリケーションに対する Windows コンテナーの利点

Windows コンテナーを使用することの利点は、一般にコンテナーから得られる利点と基本的に同じです。 Windows コンテナーを使用すれば、機敏性、移植性、および制御が大幅に向上します。

既存の .NET アプリケーションは、.NET Framework を使用して作成されたアプリケーションを参照します。 たとえば、それらが従来の ASP.NET Web アプリケーションである場合、より新しく、Linux、Windows、MacOS でクロスプラットフォームで実行される .NET Core や .NET 5 以降は使用されません。

.NET Framework 内の主な依存関係は Windows です。 また、IIS や、従来の ASP.NET の System.Web などの、セカンダリの依存関係もあります。

.NET Framework アプリケーションは、Windows 上で実行する必要があります。 既存の .NET Framework アプリケーションをコンテナー化したいが、.NET Core 以上への移行には投資できない、あるいはしたくない場合 ("正常に動作している場合は移行しないでください")、コンテナーに対する唯一の選択肢は Windows コンテナーを使用することです。

したがって、Windows コンテナーの主な利点の 1 つは、Windows 上で実行されている既存の .NET Framework アプリケーションをコンテナー化を使用して最新化する方法を得られるということです。 最終的に、Windows コンテナーでは、コンテナーを使用することで、期待している利点 (機敏性、移植性、およびより優れた制御) が得られます。

NET ベースのコンテナーでターゲットとする OS を選択する

Docker でサポートされているオペレーティング システムの多様性に加えて、.NET Framework と .NET Core の違いを考慮し、使用しているフレームワークに基づいて特定の OS と特定のバージョンをターゲットにする必要があります。

Windows の場合、Windows Server Core または Windows Nano Server を使用できます。 これらの Windows バージョンは、.NET Framework または .NET アプリケーションで必要とされる可能性があるさまざまな特性を備えています (IIS と、Kestrel のような自己ホスト型 Web サーバーのように)。

Linux の場合、複数のディストリビューションを利用できます。また、Linux は公式の .NET Docker イメージ (Debian など) でサポートされています。

図 4-7 に、.NET Framework のアプリのバージョンに応じてターゲットにすることができる OS バージョンを示します。

.NET Framework のバージョンに基づいてターゲットにする OS を示す図。

図 4-7 .NET Framework のバージョンに基づいてターゲットにするオペレーティング システム

.NET Framework アプリケーションに基づいた既存のアプリケーションまたはレガシ アプリケーションの移行シナリオでは、主な依存関係は Windows と IIS にあります。 唯一のオプションは、Windows Server Core と .NET Framework に基づいた Docker イメージを使用することです。

ご利用の Dockerfile ファイルにイメージ名を追加すると、.NET Framework ベースの Windows コンテナー イメージに関する次の例のように、タグを使用してオペレーティング システムとバージョンを選択できます。

Tag システムとバージョン
mcr.microsoft.com/dotnet/framework/runtime:4.x-windowsservercore-20H2 Windows Server Core での .NET Framework 4.x
mcr.microsoft.com/dotnet/framework/aspnet:4.x-windowsservercore-20H2 Windows Server Core 上での、追加の ASP.NET カスタマイズを含む .NET Framework 4.x

.NET (Linux と Windows のクロスプラットフォーム) の場合、タグは次のようになります。

Tag システムとバージョン
mcr.microsoft.com/dotnet/runtime:5.0 Linux 上の .NET ランタイムのみ
mcr.microsoft.com/dotnet/runtime:5.0-nanoserver-20H2 Windows Nano Server 上の .NET ランタイムのみ

マルチアーキテクチャ イメージ

2017 年から、Docker にはマルチアーキテクチャ イメージと呼ばれる機能がありました。 .NET Docker イメージにはマルチアーキテクチャ タグを使用できます。 ご利用の Dockerfile ファイルでは、ターゲットとするオペレーティング システムを定義する必要がなくなりました。 マルチアーキテクチャ機能では、1 つのタグを、複数のコンピューター構成にわたって使用できます。 たとえば、マルチアーキテクチャでは、mcr.microsoft.com/dotnet/runtime:5.0 という 1 つの一般的なタグを使用できます。 Linux コンテナー環境からそのタグをプルすると、Debian ベースのイメージが得られます。 Windows コンテナー環境からそのタグをプルすると、Nano Server ベースのイメージが得られます。

.NET Framework イメージの場合、従来の .NET Framework では Windows しかサポートされていないため、マルチアーキテクチャ機能は使用できません。

Windows コンテナーの種類

Linux コンテナーと同様に、Windows Server コンテナーは Docker エンジンを使用して管理されます。 Linux コンテナーとは異なり、Windows コンテナーには 2 つの異なるコンテナー タイプ、つまり実行時 Windows Server コンテナーと Hyper-V による分離が含まれます。

Windows Server コンテナー: プロセスと名前空間の分離テクノロジを使用してアプリケーションの分離を実現します。 Windows Server コンテナーは、コンテナー ホスト、およびホスト上で実行されているすべてのコンテナーとカーネルを共有します。 これらのコンテナーは敵対的なセキュリティ境界を提供しないため、信頼されていないコードを分離するために使用しないでください。 共有されたカーネル空間があるため、これらのコンテナーには同じカーネル バージョンおよび構成が必要です。

Hyper-V による分離: 高度に最適化された VM で各コンテナーを実行することで、Windows Server コンテナーによって実現される分離を拡張します。 この構成では、コンテナー ホストのカーネルは、同じホスト上にある他のコンテナーと共有されません。 これらのコンテナーは、VM と同じセキュリティ保証を使用して、敵対的なマルチテナント ホスティング向けに設計されています。 これらのコンテナーは、ホスト、またはホスト上のその他のコンテナーとカーネルを共有しないため、さまざまなバージョンおよび構成のカーネルを実行することができます (バージョンがサポートされている場合)。 たとえば、Windows 10 上のすべての Windows コンテナーでは、Hyper-V による分離を使用して、Windows Server カーネルのバージョンと構成が利用されます。

Windows 上でコンテナーの実行を、Hyper-V による分離を使用して行うか、使用しないで行うかの決定は、実行時に行います。 最初は Hyper-V による分離を使用してコンテナーを作成し、実行時に Windows Server コンテナーとして実行するように選択することもできます。

その他の技術情報

Azure でのコンテナー エコシステム

前のセクションでは、Docker コンテナーの利点と、.NET アプリケーション用の特定のコンテナー イメージの詳細について説明しました。 その一般的な情報はすべて、アプリケーションを開発またはコンテナー化するための基本となります。 ただし、運用展開環境または QA および開発/テスト環境について考えた場合、Microsoft Azure では、オープンで多岐にわたる選択肢が用意され、クラウドでの完全なコンテナー エコシステムが実現されます (以下の図を参照)。 特定のアプリケーションのニーズに応じて、いずれかの Azure 製品を選択する必要があります。

Azure のコンテナーエコシステムの図。

図 4-7.5 Azure でのコンテナー エコシステム

Azure でのコンテナー エコシステムから、次の製品によって、インフラストラクチャと見なされるコンテナーがサポートされています。

  • Azure Container Instances (ACI)
  • Azure Virtual Machines (コンテナーをサポート)
  • Azure Virtual Machine Scale Sets (コンテナーをサポート)

これら 3 つのうち、ACI には大きな利点があります。それは基礎となる OS を維持する必要がなく、アップグレードやパッチなどを行う必要がないという事実です。しかし、このブックの後のセクションで詳しく説明するように、ACI は引き続きインフラストラクチャ レベルに配置されます。

同時に PaaS (サービスとしてのプラットフォーム) レベルにも配置される Azure サポート コンテナーの製品は次のとおりです。

  • Azure App Service
  • Azure Kubernetes Service (AKS および ACS)
  • Azure Batch

次に、Azure Container Registry は、Azure でホストされる拡張性の高いコンテナー レジストリであり、カスタム コンテナー イメージを登録してデプロイするときに、前述のすべての製品から使用することができます。

さらに、ご利用のコンテナーからは、Azure SQL Database、Azure Redis Cache、Azure Cosmos DB など、Azure 内の他のマネージド サービスを利用することもできます。 また、Azure Marketplace には、Cloud Foundry や OpenShift などのサードパーティ製ソリューション/プラットフォームも用意されており、Azure 内でコンテナーを使用することもできます。

次のセクションでは、特に Windows コンテナーをターゲットとする場合に、それらの Azure 製品とソリューションの各々を使用するタイミングに関する Microsoft の推奨事項について説明します。

前へ 次へ