次の方法で共有

December 2017

Volume 32 Number 12

コンテナー - Docker と Windows Server Containers による .NET アプリの近代化

Sean Iannuzzi

おそらくこれまでに Docker、Docker コンテナー、そして Windows Server 2016 のリリースで Windows Server Containers が統合されたことを耳にされたと思います。筆者は、今後数年以内に、仮想マシン (VM) を実行してアプリケーションをサポートするのではなく、Docker コンテナーが Web サイト、アプリケーション、およびその他のシステムを実行する標準の手段になると心から信じています。Docker を使用すると、スケーラビリティ、分離性、セキュリティを確保できるだけではありません。配置の点では、ほとんどサポートなしで、アプリケーションやシステムを適切に構成できます。VM を設定し、必要な機能をすべて構成する複雑さに比べると、Docker の設定は簡単なため、非常に便利です。VM が優先され、物理コンピューターの需要が徐々に少なくなっていったように、すぐにではないとしても今後数年もすれば、VM の需要が下向きになり、Docker が利用されるようになるでしょう。

今回は、Windows Server 2016、ファイル共有、および Windows Server 2016 のソケット通信を使用して、いくつかの .NET アプリケーションを近代化する方法を紹介します。Windows PowerShell を使用して Docker イメージを作成し、ホストである Windows Server 2016 システムと Windows Server Containers 間でファイルとソケットを共有する方法について詳しく説明します。アプリケーションの多くには、.NET アプリケーションを Docker コンテナーに移植するために実現しなければならない共通の機能があると思われます。ここで紹介する機能の多くは、Windows Server Containers 固有のものではなく、同様の機能を持つどのアプリケーションにも利用できるでしょう。  

ビジネスの課題: CPU、メモリ、およびディスクを集中的に使用する .NET アプリ

ビジネスの課題は、大量のデータを処理する既存の .NET および C++ コンソール アプリケーションをいくつか近代化することです。このデータ処理には、CPU、メモリ、およびディスクを集中的に使用する処理が含まれています。これらのコンソール アプリケーションを従来の Web モデルで公開し、シングル ユーザー システムからマルチ ユーザー対応の構成にシステムを移行する必要があります。アプリケーションの設定方法と処理するデータの量を考えると、データや実行可能ファイルの複数のコピーを複数の VM にまたがって管理するのは避けたいと思います。

このビジネス課題への取り組みでは、これらのアプリケーションをスケール アウトする最適な方法と、ネットワーク待ち時間を最小限に抑え、ネットワーク全体のファイル管理も最小限で済む方法を判断することも必要です。アプリケーションのパフォーマンスは非常に重要ですが、ネットワーク共有、ファイル共有などの分散処理を使用すると、アプリケーションのパフォーマンスに大きく影響します。したがって、このビジネス課題が成功したと認められるには、スケーラブルでありながら、(CPU、メモリ、ディスク IO の) パフォーマンスも優れ、また、データの複数のコピーを保持する必要がないモデルを用意する必要があります。ほとんどのプロジェクトと同様、これらのアプリケーションの新しい近代化されたスケーラブルなバージョンを提供するための時間は非常に限られているため、完全に設計し直すことはできません。

重要な機能: Docker でのファイル共有、ソケット接続、および .NET

今回のアプリケーションでは、いくつかのオプションを検討したうえで、Docker を Windows Server Containersで 利用することにしました。評価の一環として、アプリケーションを無事に Docker に移行するために、検証しておかなければならない特定の技術的課題として次の 3 つがありました。 

  • Docker で従来の .NET アプリケーションを実行できること。
  • ホスト システムと Docker コンテナー間でファイル共有を利用できること。
  • ホストと Docker コンテナー間でソケット通信を確立できること。

今回は、これらの技術的課題を克服した方法と、Windows Server 2016 で Docker と Windows Server Containers を利用してこれらのコンセプトを実現した方法を詳しく説明します。これらのコンセプト自体は、Docker または Windows Server Containers に移行される可能性がある .NET アプリケーションの数を考えると、まだまだ手始めに過ぎません。今回紹介する例は、幅広く応用や拡張を行い、さまざまなアプリケーション機能を解決します。その結果、より近代化された配置方法でアプリケーションを提供できるようになります。

アプリケーションのパフォーマンス: 8GB の RAM、10 TB のファイル処理

検討したオプションとコンセプトについての詳しい説明に入る前に、Docker コンテナーに移行するアプリケーションとシステムについてもう少し詳しく触れておきます。何はともあれ、これらのアプリケーションは、実行する作業の種類がかなり独特であり、プロセス、メモリ、ディスクを集中的に使用するアプリケーションです。さらに、アプリケーションの実行速度が、システムの成否を左右するほど重要です。

アプリケーションは、基本的にシングル ユーザー向けの設計で、データ ファイルを処理する非常に複雑な計算を実行するもので、C++ と .NET Framework を組み合わせてビルドされています。システムのパフォーマンスの課題を理解しておきましょう。10 TB 程度のデータ ファイルの計算を実行するために、1 ユーザーにつき約 8 GB の RAM を使用します。また、大量のデータを数秒で処理するために、メモリは事前に確保しておく必要があり、ディスク速度も極めて高速でなければなりません。このシステムでは、要求元からの起動と通知にソケット通信も使用します。アプリケーションとシステムが進化するにつれて、システムのスケールをすばやく調整でき、また、複数ユーザーによる処理をサポートできる手段が必要であることがわかりました。読者の多くも、コンテナーに移行するメリットがある同様のアプリケーションに心当たりがあると思います。

ソリューションのオプション: リエンジニアリング、自動スケール、Docker

今回直面した技術的課題には、目標を達成できそうな複数の方法を評価することも含まれています。今回は 3 つのオプションを検討しました。

  1. リエンジニアリング: オプションの 1 つは、アプリケーション スイート全体をリエンジニアリングすることです。この方法では間違いなく目標を達成できますが、システムの規模と複雑さを考えると、よりリスクが少なく、完成までに時間がかからないソリューションが必要です。システム設計の見直しに 1 年または数か月も待たなくてはならないというのでは、承認される見込みはありません。それでも、これが実は合理的なソリューションであった場合に備えて、このオプションを評価する必要がありました。 
  2. 自動スケール: もう 1 つのオプションは、VM と自動スケールを利用する方法を評価することです。この方法は、アプリケーションを書き直すよりも時間がかからず、全体のリスクも少なくなることは間違いありません。しかし、VM の割り当てにかかる時間を考えるとオーバーヘッドが大きく増えます。10 TB の記憶域がある VM ならなおのことです。スタンバイ インスタンスを使用し、追加のレイヤーやアプリケーションを利用してサーバーのプロビジョニングとプロビジョニング解除を処理するなど、この解決策を見つけられるとしても、最善の方法とは思えません。ただし、このオプションは、アプリケーション全体のリエンジニアリングが不要で、1 つの VM に複数の実行可能ファイルを配置でき、VM を自動スケールアウトできるため、方向性が正しいことは間違いありません。そこで、より新しい技術的アプローチを使用して、これよりもシンプルな実装モデルを引き続き探すことにしました。
  3. Docker コンテナー: 最後に検討したオプションは、ホスト システムと Docker コンテナーの相互運用性に目を付け、Docker を使用する方法です。Docker コンテナーを使用すると、システム全体をリエンジニアリングしなくても、必要に応じてシステムのスケールを調整できます。この方法なら、アプリケーションのリエンジニアリングに伴うリスクが減り、セキュリティを目的としてある程度の分離を実現できます。また、必要なレベルのスケールを確保しつつ、すばやく更新を実装できます。

Docker を利用した .NET アプリの配置

Docker のオプションでの最大の問題は、アプリケーションが .NET と C++ で作成されていることです。Docker で直接アプリケーションを実行できるかどうかが懸念されます。.NET/C++ アプリケーションを Docker に移行する方法を調べ始めてすぐに、アップグレードまたは再設計が必要なことがわかりました。時間をかけることができなかったため、Windows Server 2016 と、これに完全に統合されている Windows Server Containers について詳しく調べ始めました。Windows Server Containers を利用すれば、アプリケーションはそのままで、すべての依存関係とその他の必要な設定をコンテナーに配置できるのではないかと考えました。最初に直面した技術的課題は、アプリケーションは .NET と C++ で作成されていますが、.NET アプリケーション用の従来の Docker コンテナーには .NET Core が必要なことです。もちろん、アプリケーションを .NET Core にアップグレードすることもできますが、かなり手間がかかります。ここでは、最小限のリスクで、できるだけ迅速にソリューションを配置しようと取り組んでいます。また、アプリケーションにはスケーリングを追加し、ある程度の分離とセキュリティも確保しようとしています。

 Windows Server Containers を使用するのは、かなりうまく行きそうに思えますが、まだ、さまざまなコンセプトをテストする必要があります。ファイル共有やソケット通信など、非常に便利だと思えるコンセプトです。ここで説明していることの多くは、今回の特定のセットアップ独自の内容ですが、オプションとコンセプトはそうではありません。アプリケーション設計の見直しや書き直しをしないで、このような移行やスケーリングが必要なその他のシステムでも利用できます。もちろん、この方法はアプリケーションの設計を見直す代わりにはなりませんが、再設計が望ましい場合に、その時間を確保できます。設計見直しの一環として、Docker と互換性があるか、Docker に対応するアプリケーションのリエンジニアリングを実行できます。

ここからは、以下について説明します。

  1. Windows Server Containers をサポートするために Windows Server 2016 VM をセットアップする方法
  2. PowerShell を使用して Docker イメージを作成する方法
  3. Windows Server Core ベースの Docker ファイル
  4. ホストとコンテナー間の高度なファイル共有を実現する方法
  5. ホストのソケット リスナーとコンテナーを実現する方法

Windows Server 2016 と Windows Server Containers

最初に、Windows Server 2016 VM を配置して、.NET Framework、IIS、コンテナーなど、適切な機能を有効にします (図 1 参照)。

.NET Framework とコンテナー サービスの有効化
図 1 .NET Framework とコンテナー サービスの有効化

この種のソリューションをビルドするには、.NET Framework をインストールする必要があります。

今回は必要なすべての機能をインストールしてから、各機能をそれぞれ検証しました。Docker が適切に実行されていることを確認するには、PowerShell コマンド「docker version」を実行します。その後、PowerShell から「(get-service “Docker”).Status」と入力して、Windows Docker エンジン サービスも実行されていることを確認します。最後に、dockr.ly/2i7pDSn (英語) から Windows Server Core Docker イメージを取得するために「docker pull」要求を実行します。このプル要求が完了したら、「docker images」コマンドを実行して、Docker イメージが無事に作成されていることを確認します。

Windows コンテナー サービスをインストールし、基本の Docker イメージで環境をセットアップしたら、.NET コンソール アプリケーションの作業に取り掛かる準備ができます。

.NET アプリケーションのセットアップ

最初に、.NET Framework 4.6.1 を使用して、ごく基本的なコンソール アプリケーションを作成します。このアプリケーションは、引数を受け取り、応答を表示する以外の機能は特にありません。Windows コンテナーへの完全な移行を進める前に、必要な機能が意図したとおりに機能することを確認しておきます。ただし、Windows Server 2016 のコンテナーでアプリケーションを実行できるようにするには、必要な手順がいくつかあります。

最初の手順は、アプリケーションをビルドし、再利用可能な “build” PowerShell スクリプトを作成して、Windows Server 2016 に Docker イメージを作成することです。そのためには、msbuild を実行する関数と、実際の Docker イメージを作成する関数の 2 つの関数を作成します (図 2 参照)。

図 2 アプリケーションをビルドするPowerShell 関数と Docker イメージを作成する PowerShell 関数

Set-StrictMode -Version Latest
$ErrorActionPreference="Stop"
$ProgressPreference="SilentlyContinue"
s
# Docker image name for the application
$ImageName="myconsoleapplication"
function Invoke-MSBuild ([string]$MSBuildPath, [string]$MSBuildParameters) {
  Invoke-Expression "$MSBuildPath $MSBuildParameters"
}
function Invoke-Docker-Build ([string]$ImageName, [string]$ImagePath,
  [string]$DockerBuildArgs = "") {
  echo "docker build -t $ImageName $ImagePath $DockerBuildArgs"
  Invoke-Expression "docker build -t $ImageName $ImagePath $DockerBuildArgs"
}

スクリプトの次の手順は、必要なパラメーターをすべて渡して、これら 2 つの関数を実行することです。

Invoke-MSBuild -MSBuildPath "MSBuild.exe" -MSBuildParameters
  ".\myconsoleapplication.csproj /p:OutputPath=.\publish /p:Configuration=Release"
Invoke-Docker-Build -ImageName $ImageName -ImagePath "."

ビルド スクリプトは用意できているので、後は Docker ファイルを作成すれば、Windows Server 2016 で実行される Windows Server Containers でコンソール アプリケーションが実行されるようになります。開発の観点では、ビルド プロセスのテストに Visual Studio コマンド プロンプトを使用すると便利です。この場合、パスに MSBuild が含まれます。暫定的なセットアップの一環として、Windows Server Core という名前の基本 Docker イメージをインストールします。このイメージには、アプリケーションの実行に必要な基本機能がすべて含まれています。Docker ファイルを作成するときに、Docker にこのイメージを使用し、エントリ ポイントとなる “myconsoleapplication.exe” という名前のアプリケーションを発行するように指示します。 

FROM microsoft/windowsservercore
ADD publish/ /
ENTRYPOINT myconsoleapplication.exe

このエントリ ポイントは、コンソール アプリケーションの Main 関数になります。

最終ビルドと Windows Server 2016 への配置

Windows Server Containers 対応の .NET コンソール アプリケーションが完成したので、このアプリケーションを配置できます。今回見つけたテスト用にアプリケーションを配置する簡単な方法は、VM にアプリケーション フォルダーをコ単純にピーすることです。アプリケーションをサーバーにコピーしたら、PowerShell スクリプトを実行して、アプリケーションをビルドします。ソース ディレクトリに移動して、PowerShell から ./build コマンドを実行します。

ビルド スクリプトの出力は、図 3 に示す結果のようになります。

図 3 ビルド スクリプトの出力

docker build -t myconsoleapplication .
Sending build context to Docker daemon  6.058MB
Step 1/3 : FROM microsoft/windowsservercore
 ---> 2cddde20d95d
Step 2/3 : ADD publish/ /
 ---> 452c4b42caa5
Removing intermediate container cafb387a3634
Step 3/3 : ENTRYPOINT myconsoleapplication.exe
 ---> Running in a128ff044ef3
 ---> 4c7dce888b36
Removing intermediate container a128ff044ef3
Successfully built 4c7dce888b36
Successfully tagged myconsoleapplication:latest

Docker イメージが無事に作成されたことを確認するには、再び「docker images」コマンドを実行します。すると、新しい Docker イメージが表示されます (図 4 参照)。

Docker イメージとしてのコンソール アプリケーション
図 4 Docker イメージとしてのコンソール アプリケーション

Windows Server Containers コンソール アプリケーションのテスト

特定の機能に取り掛かる前に実行する最後の手順は、アプリケーションをテストして、Windows Server Containers 内で実際に実行できることを確かめることです。そのためには、次のコマンドを実行します。

docker run --rm -it myconsoleapplication
  ".NET Framework App Running in Windows Container"

想定どおり、アプリケーションは、渡された引数をコンソール ウィンドウに出力します。

以上で、Windows Server Containers で実行できる .NET アプリケーションの配置、構成、セットアップの基本的な処理は完了です。この時点で、Windows ServerContainers に移行できそうな既存のアプリケーションを多数思い付くでしょう。ただし、ファイル共有やソケット通信など、開発者にとって便利だと思われる重要な機能がまだいくつかあります。ここからは、このような機能と、これらを自身のアプリケーションで利用する方法について、もう少し詳しく説明します。

Docker コンテナー: 高度なファイル共有の実現

多くのコンソール アプリケーションと同様、開発するアプリケーションにも、ログの記録や処理など、目的は何であれ、さまざまな理由で利用される大量のファイルがあり、集中的にファイルを使用する可能性があります。今回の特定のアプリケーションの場合、サイズが非常に大きいファイルを読み取るため、各コンテナーにファイルをコピーすることは避けたいと考えました。また、ディスク I/O の最適化もできる限り行いたいと考えました。ネットワークの共有フォルダー (ファイル サーバー) を使用すると、そのような大きなファイルを読み取る場合に待ち時間が長すぎて、パフォーマンスに影響します。さらに、メンテナンスが大変になるため、構成やポート、ディレクトリを変えてアプリケーションの複数のバージョンを作成するのも避けたいと思います。その結果、Docker サービスを実行しているホスト システムでファイルを共有し、コンテナー内からそれらのファイルにアクセスできる方法を評価することにしました。結局、これは非常に簡単で、Windows Server Containers を使用しているか、Linux で Docker コンテナーを実行しているかどうかは問題ではないことがわかりました。Docker は、この種の機能を完全にサポートします。実際、今回のセットアップで最も役に立ったのは、コンテナーにドライブをマウントして、内部ディレクトリと関連付けている限り、アプリケーションを変更する必要すらなかったことです。唯一変更したのは、Docker コンテナーを実行するときに、パスを構成ファイルから読み取るのではなく、パラメーターを設定したことです。

どれも相対パスを利用していて、メイン ディレクトリ内に置いているため、ファイル処理とパスのすべてをそのまま維持できます。つまり、アプリケーションの中核のロジックを変更する必要がなく、.NET コンソール アプリケーションを変更することで生じるかもしれないリスクの多くを緩和できます。

この機能をテストするには、次のコードを挿入して、コンソール アプリケーションに基本のファイル IO プロセスを追加します。

using (StreamWriter sw = File.AppendText(@"C:\containertmp\testfile.txt"))
{
  sw.WriteLine(DateTime.Now.ToString() + " - " + args[0]);
}

その後、ソリューションを Windows Server 2016 VM に再配置します。これには、「./build」PowerShell スクリプトを実行して、イメージを再構築する必要があります。

この機能を実現する最後の手順として、Docker コンテナーに公開するディレクトリをホスト上に作成します。今回のケースでは、単純に hostcontainershare というフォルダーを作成しました。この作業で重要なのは、このフォルダーを Windows Server ホスト システムから Docker コンテナーにどのようにマウントするかです。驚くことに、次の引数を「docker run」コマンドに渡すだけで、実に簡単にマウントできます。

-v [source directory or path]:[container directory or path]

この引数は、ソースとターゲットを受け取るように設定されています。たとえば、最初に Windows Server ホストのディレクトリを渡し、次に、このディレクトリをコンテナー内にどのようにマウントするかを渡します。以下に「docker run」コマンドの全体を示します。

docker run --rm -it -v c:\hostcontainershare:c:\containertmp myconsoleapplication
  ".NET Framework App Writing to Host Folder" 1

Windows Server Containers と Docker コンテナーのどちらでも、この機能を実現する方法は複数ありますが、今回の .NET コンソール アプリケーションに関しては、この方法が非常にシンプルで、簡単に実装できます。これがどのようにセットアップされているかを 図 5 に図示します。

ホストおよび Windows Server Containers のファイル操作の概要
図 5 ホストおよび Windows Server Containers のファイル操作の概要

「docker run」コマンドの結果は、Docker コンテナー内からホスト ディレクトリにファイルとして書き込まれます (図 6 参照)。

Docker コンテナーから Windows Server 2016 ホストへの書き込みアクセスの例
図 6 Docker コンテナーから Windows Server 2016 ホストへの書き込みアクセスの例

今回のアプリケーションは、非常にサイズの大きいファイルを処理するため、この機能を実現することは大きなメリットになります。すべてのコンテナー間でファイルを複製する必要はありません。ホストに最適なまたは安定した状態のドライバーがある限り、共有フォルダーやネットワーク ドライブ、その他のローカルではないサイトを使用するよりも、格段に速くファイルを処理できます。従来のコンソール アプリケーションの場合、この手法を使用するメリットは、数えきれません。

ファイル共有を無事に実装できたら、ソケット接続を実装するだけです。ここからはこれについて説明します。

Docker コンテナー: 高度なソケット機能の実現

検証が必要だった主要機能の 1 つは、ホスト ソケット接続から内部のコンテナー ソケット接続に通信できるかどうかです。やはり、この機能の多くも、Windows Server Containers と Docker コンテナーのどちらでも利用できます。Docker コンテナーの実行方法と公開するポートを指定するコマンド ライン引数によって、セットアップを制御しているためです。

この機能をサポートするには、Windows Server で実行されるクライアント アプリケーションから、Windows Server Containers として実行されているサーバー側のアプリケーション リスナーへの接続を確立する、クライアント/サーバー ソケット アプリケーションを作成します。また、特定のソケットでリッスンし、受信したデータとバイトをコンソールに出力してから応答するために必要なコードをアプリケーションに追加します。

「非同期クライアント ソケットの例」(/ja-jp/dotnet/framework/network-programming/asynchronous-client-socket-example) と「非同期サーバー ソケットの例」/ja-jp/dotnet/framework/network-programming/asynchronous-server-socket-example の Microsoft のソケット例を基本のコード セグメントとして、アプリケーションに組み込みます。

サーバー側のコードにもいくつか変更を施し、コンテナーの IP アドレスを取得できるようにします。これで、クライアント ソケット アプリケーションを使用するときに、割り当てられた IP アドレスを提供できます。次のコマンドを実行することで、コンテナーの NAT の詳細を取得できます。

docker network inspect nat

また、コンテナーの IP アドレスを取得するさまざまな参照を実行しましたが、デバッグとトラブルシューティングを簡単にするために、すべての IP アドレスを取得して、コンソール ウィンドウに出力するループを追加します。

foreach (var info in ipHostInfo.AddressList)
{
  Console.WriteLine("\nIP: " + info);
}

ソケット接続をテストする特定のポートに、ポートを設定します。接続をテストするには、再び、Windows Server 2016 VM にアプリケーションを配置し、クライアント アプリケーションをサーバーにコピーします。既定では、コンテナーのカスタム ポートは公開されず、コンテナーは TCP ソケット接続を受け付けません。フォルダーの共有に必要だったように、この機能を実現するには、Docker に適切な実行引数を渡す必要があります。

今回のケースでは、ポート 50020 を使って、クライアント アプリケーションを実行するホストから、Windows Server Containers 内で実行される .NET コンソール アプリケーションに接続する必要があります。図 7 に、アプリケーションがどのようにセットアップされるかを示します。

クライアントと Windows Server Containers ホスト間のソケット通信
図 7 クライアントと Windows Server Containers ホスト間のソケット通信

すべてのセットアップと構成が完了したら、コンテナーからホスト マシンに特定のポートを公開するように、Windows Server Containers と Docker コンテナーに指示する必要があります。この動作を実現するために、次の引数を「docker run」コマンドに指定します。

-p [host port]:[container port]

ポートごとにこの引数を繰り返し使用して、複数のポートを公開できます。たとえば、「-p 50020: 50020 –p 50019:50019」のように指定します。コンテナーを実行し、ポートを公開したら、Windows Server Containers のコンソール アプリケーションから Windows Server 2016 VM で実行されているクライアントへの接続が確立できたかどうかをテストできます。

Windows Server Containers の実行に使用した完全なコマンドは次のとおりです。

docker run --rm -it -p 50010:50010 -v c:\hostcontainershare:c:\containertmp myconsoleapplication
  ".NET Framework App Listening on Socket" 2

コンソール アプリケーションを実行する Windows Server Containers を起動したら、クライアント アプリケーションを起動できます。コンテナーのコンソール アプリケーションに、コンテナーの現在の IP アドレスと、指定したソケットでリッスンしていることが表示されます。後は、クライアント アプリケーションを起動して、クライアント アプリケーションの接続先になるコンテナーの現在の IP アドレスを渡せば、テストは完了です。クライアント アプリケーションは、画面に表示されたコンテナーのコンソール アプリケーションの IP アドレスに接続し、ソケットを使って少量のデータを送信します (図 8 参照)。無事にソケット接続が確立されました。

コンテナーのコンソール アプリケーションにデータを送信するクライアント ソケット アプリケーション
図 8 コンテナーのコンソール アプリケーションにデータを送信するクライアント ソケット アプリケーション

まとめ

実行するアプリケーションの性質を考えると、Docker で利用できるいくつかの特定の機能が必要です。Windows Server Containers で .NET コンソール アプリケーションを実行できることがわかると、ホストからファイルにアクセスでき、ホスト システムから Docker コンテナーへのソケット通信を実現できるだろうという思いを強くしました。最も感銘を受けたのは、フォルダーとファイルを共有できるだけでなく、自身のアプリケーションやその他のアプリケーション固有のソケットやポートを公開できることです。Windows Server 2016 の場合、Windows Server Containers との統合は非常にスムーズで、Windows コンテナーの配置に必要な構成やオーケストレーションはごくわずかです。.NET アプリケーションを Docker に移行する予定なら、Windows Server Containers を使用して、アプリケーションが想定どおりに実行されるように、必要に応じて Docker の機能を公開することをお勧めします。ほとんどのアプリケーションや、リソース共有で必要になりますが、必ずセキュリティについて検討し、確認してください。ホスト システムからコンテナー間でデータを共有したり、ソケットを公開する場合も注意が必要です。このような機能を実現するときは、脆弱性が発生しないように、細心の注意が必要です。また、ホスト システムとコンテナー間でファイルを共有したり、ポートを開く場合は、セキュリティ リスクを防ぐために注意して処理する必要があります。今回のアプリケーションでは、高いレベルのスケーラビリティが得られただけでなく、アプリケーション全体で特定のコンポーネントについては近代化もできました。現在は、Docker Swarm やその他のスケーリング モデルを使用して、よりスケーラブルなセットアップにアプリケーションを配置できるようになっています。これにより、アプリケーションは、コストやハードウェアのレベル以外の制約を受けずに実行できます。しかも、このソリューションでは、再設計が必要であるかどうかや、このソリューションは永続的に使用できるソリューションになるかどうかを評価するために、ぜひとも必要な時間も確保できます。今回紹介した機能の多くを利用して、.NET アプリケーションを近代化するための移行と設計を始められることを祈っています。

Sean Iannuzzi は、テクノロジ業界で 20 年以上の経験があり、各種のソーシャル ネットワーク、ビッグ データ、データベース ソリューション、クラウド コンピューティング、電子商取引、および財務アプリケーションに関して、テクノロジとビジネスにおけるビジョンのギャップを埋めるうえできわめて重要な役割を担っています。Iannuzzi には 50 を超える固有テクノロジ プラットフォームの経験があり、10 種類を超える技術表彰や認証を獲得し、テクノロジーの目標やソリューションを実現してビジネスの目的達成を支援することを専門にしています。

この記事のレビューに協力してくれたマイクロソフト技術スタッフの Jesse Squire に心より感謝いたします。

この記事について MSDN マガジン フォーラムで議論する