ASP.NET Coreアプリケーションは真にクロスプラットフォームであり、nixで実行できます。したがって、Dockerでも実行できます。 Linuxにデプロイするためにパッケージ化し、Nginxと組み合わせて使用​​する方法を見てみましょう。 カットの下の詳細！

注：Hacker誌の記事の完全版の出版物シリーズを継続します。 著者のスペルと句読点が保存されました。

Dockerについて

ほとんどの人がマイクロサービスアーキテクチャについて聞いています。 アプリケーションをパーツに分割するという概念は、それが新しいものであると言うことではありません。 しかし、新しいものは忘れられてリサイクルされた古いものです。

アーキテクチャについて簡単に説明しようとすると、Webアプリケーションはサービスという別個の単一部分に分割されます。 サービスは互いに直接対話せず、共通のデータベースもありません。 これは、他のサービスに影響を与えることなく各サービスを変更できるようにするために行われます。 サービスはコンテナにパッケージ化されています。 コンテナの中では、Dockerがボールを支配します。

Dockerとは何かを説明するために、彼らはしばしば「仮想マシン」という用語を簡単な方法で使用します。 間違いなく類似性はありますが、そう言うのは間違っています。 この違いを理解する最も簡単な方法は、公式のdockerドキュメンテーションから以下の画像を見ることです。

コンテナは、現在のオペレーティングシステムのコアを使用し、コンテナをそれ自体に分割します。 一方、ハイパーバイザーを使用する仮想マシンはハードウェアリソースを使用します。
画像/画像ドッキングウィンドウは読み取り専用オブジェクトであり、実際には、コンテナを構築するためのテンプレートを保存します。 コンテナは、コードが実行される環境です。 画像はリポジトリに保存されます。 たとえば、公式のDocker Hubリポジトリでは、1つのイメージのみをプライベートに保存できます。 ただし、無料なので、この場合でも彼らに感謝する必要があります。

情報

コンテナ化の代表はDockerだけではありません。 それに加えて、他の技術があります。 例：

CoreOSによるrkt （「ロケット」と発音）

UbuntuによるLXD （lexdiと発音）

Windowsコンテナー-誰からも推測されることはありません。

理論に慣れてきたので、実践に移りましょう。

Dockerは多くのオペレーティングシステムにインストールできるため、Dockerインストールを分解する意味はありません。 プラットフォーム用にDocker Storeからダウンロードできることのみを示します。 WindowsでDockerをインストールする場合は、BIOSおよびOSで仮想化を有効にする必要があります。 10-keで有効にする方法については、次の記事をご覧ください：Windows 10でのHyper-Vのインストール

Docker対応プロジェクトの作成

DockerはもちろんLinux製品ですが、必要に応じてMacまたはWindows用に開発するときに使用できます。 Visual Studioでプロジェクトを作成するときに、Dockerサポートを追加するには、[Dockerサポートを有効にする]チェックボックスをオンにします。

Dockerサポートは、既存のプロジェクトに追加できます。 さまざまな新しいコンポーネントが追加されるのと同じ方法で、プロジェクトに追加されます。 コンテキストメニューの追加-Dockerサポート。

マシンにdockerがインストールされて実行されている場合、コンソールが自動的に開き、コマンドが実行されます

docker pull microsoft/aspnetcore:2.0 

これにより、イメージのダウンロードプロセスが開始されます。 この画像は、実際には画像の作成元となる空白です。 ASP.NET Core 2.1は異なるイメージを使用します- マイクロソフト/ドットネット：SDK

ソリューションのあるディレクトリに、次のファイルが自動的に作成されます。
.dockerignore（Dockerイメージからファイルとディレクトリを除外）、docker-compose.yml（このファイルを使用していくつかのサービスの実行を構成できます）、docker-compose.override.yml（補助構成docker-compose）、docker-compose.dcproj（ Visual Studioのプロジェクトファイル）。

Dockerfileファイルがプロジェクトディレクトリに作成されます。 実際、このファイルを使用して、画像を作成します。 デフォルトでは（プロジェクトの名前がDockerServiceDemoの場合）、次のようになります。

 FROM microsoft/aspnetcore:2.0 AS base WORKDIR /app EXPOSE 80 FROM microsoft/aspnetcore-build:2.0 AS build WORKDIR /src COPY DockerServiceDemo/DockerServiceDemo.csproj DockerServiceDemo/ RUN dotnet restore DockerServiceDemo/DockerServiceDemo.csproj COPY . . WORKDIR /src/DockerServiceDemo RUN dotnet build DockerServiceDemo.csproj -c Release -o /app FROM build AS publish RUN dotnet publish DockerServiceDemo.csproj -c Release -o /app FROM base AS final WORKDIR /app COPY --from=publish /app . ENTRYPOINT ["dotnet", "DockerServiceDemo.dll"] 

.NET Core 2.0の初期構成では、docker buildコマンドを使用してすぐにイメージをビルドすることはできません。 1レベル上のディレクトリからdocker-composeファイルを起動するように構成されています。 構築を正常に進めるために、Dockerfileを同様の外観にすることができます。

 FROM microsoft/aspnetcore:2.0 AS base WORKDIR /app EXPOSE 80 FROM microsoft/aspnetcore-build:2.0 AS build WORKDIR /src COPY DockerServiceDemo.csproj DockerServiceDemo.csproj RUN dotnet restore DockerServiceDemo.csproj COPY . . WORKDIR /src RUN dotnet build DockerServiceDemo.csproj -c Release -o /app FROM build AS publish RUN dotnet publish DockerServiceDemo.csproj -c Release -o /app FROM base AS final WORKDIR /app COPY --from=publish /app . ENTRYPOINT ["dotnet", "DockerServiceDemo.dll"] 

余分なDockerServiceDemoディレクトリを削除するだけでした。

Visual Studio Codeを使用する場合、ファイルを手動で生成する必要があります。 VS CodeにはDocker拡張機能の形式の補助機能がありますが、VS Code- Dockerの操作からdockerを操作する方法に関するマニュアルへのリンクを追加します。 はい、記事は英語ですが、写真付きです

Three Chords Docker

港湾労働者との毎日の仕事のために、ほんのいくつかのコマンドを覚えておくだけで十分です。

最も重要なチームは、もちろん、イメージを構築することです。 これを行うには、bash / CMD / PowerShellを使用してDockerfileがあるディレクトリに移動し、コマンドを実行します。

 docker build -t your_image_name . 

ここで、-tオプションの後に、イメージの名前が設定されます。 注意-コマンドの最後で、スペースの後のスペース。 このドットは、現在のディレクトリが使用されていることを意味します。 画像にはタグ（番号または名前）でタグを付けることができます。 これを行うには、名前の後にコロンを入れてタグを指定します。 タグが指定されていない場合、デフォルトでlatestという名前で設定されます。 イメージをリポジトリに送信するには、イメージ名にリポジトリの名前が含まれている必要があります。 このようなもの：

 docker build -t docker_account_name/image_name:your_tag . 

ここで、your_docker_account_nameは、Dockerハブアカウントの名前です。

リポジトリを含まないローカル名のみでイメージを作成した場合は、次のコマンドを使用して、構築後に別の名前でイメージをマークできます。

 docker tag image_name docker_account_name/image_name:your_tag 

ハブに変更を送信するには、次のコマンドを実行する必要があります。

 docker push docker_account_name/image_name:your_tag 

これの前に、Dockerアカウントにログインする必要があります。 Windowsでは、これはアプリケーションUIから行われますが、* nixでは、次のコマンドで行われます。

 docker login 

実際、3つのチームでは不十分です。 また、コンテナの動作を確認できる必要があります。 コンテナを起動できるコマンドは次のようになります。

 docker run -it -p 5000:80 image_name 

-itオプションは擬似TTYを作成し、コンテナはリクエストに応答します。 コマンドを実行すると、 http：// localhost：5000 /でサービスが利用可能になります

-p 5000：80は、コンテナーのポート5000をホストのポート80に関連付けます。

さらに、そのようなコマンドがあります：

 docker ps –a 

コンテナのリストを表示します。 -aスイッチが追加されたため、現在実行中のコンテナだけでなく、すべてのコンテナが表示されます。

 docker rm container_name 

このコマンドは、container_nameという名前のコンテナーを削除します。 rm-削除の略

 docker logs container_name 

コンテナログの表示

 docker rmi image_name 

image_nameという名前の画像を削除します

リバースプロキシサーバーを介したコンテナーの起動

実際、.NET Coreアプリケーション自体はKestrel Webサーバーを使用しています。 このサーバーは実稼働には推奨されません。 なんで？ いくつかの説明があります。
IPとポートを共有するアプリケーションが複数ある場合、Kestrelはトラフィックを分散できません。 さらに、リバースプロキシサーバーは追加のセキュリティレイヤーを提供し、負荷分散とSSL設定を簡素化し、既存のインフラストラクチャとの統合を改善します。 ほとんどの開発者にとって、リバースプロキシが必要な最も重要な理由は、追加のセキュリティです。

最初に、元のDockerfile構成を復元します。 その後、docker-compose.ymlファイルを処理し、サービスを単独で実行しようとします。 ymlファイル形式は「yaml」として読み取られ、「Yet Another Markup Language」または「YAML Ai n't Markup Language」からの略語です。 別のマークアップ言語、またはマークアップ言語ではありません。 どういうわけか、すべてが確実ではありません。

デフォルトのdocker-composeファイルは次のようになります。

 version: '3.4' services: dockerservicedemo: image: ${DOCKER_REGISTRY}dockerservicedemo build: context: . dockerfile: DockerServiceDemo/Dockerfile 

docker-compose.override.ymlファイルは、構成にいくつかの設定を追加します。
バージョン： '3.4'

 services: dockerservicedemo: environment: - ASPNETCORE_ENVIRONMENT=Development ports: - "80" 

docker-compose buildを使用して作成されたソリューションをビルドできます。docker-composeupコマンドを呼び出して、コンテナーを起動します。 すべてが機能しますか？ その後、次の手順に進みます。 nginx.infoファイルを作成します。 構成はおよそ次のようになります。

 worker_processes 4; events { worker_connections 1024; } http { sendfile on; upstream app_servers { server dockerservicedemo:80; } server { listen 80; location / { proxy_pass http://app_servers; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection keep-alive; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } } 

ここでは、nginxがポート80（リッスン80;）でリッスンすることを示します。 そして、受信したリクエストは、dockerservicedemoコンテナ内のホストの80番目のポートにリダイレクトされます。 さらに、nginxに渡すヘッダーを伝えます。

nginxでhttpを使用し、httpsを介してWebサイトにアクセスできます。 httpsリクエストがhttpプロキシを通過するとき、httpsからの多くの情報はhttpに渡されません。 また、プロキシを使用すると、外部IPアドレスが失われます。 この情報をヘッダーで送信するには、ASP.NETプロジェクトのコードを変更し、Startup.csファイルのConfigureメソッドの先頭に次のコードを追加する必要があります。

  app.UseForwardedHeaders(new ForwardedHeadersOptions { ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto }); 

ほとんどのプロキシサーバーは、X-Forwarded-ForおよびX-Forwarded-Protoヘッダーを使用します。 これらのヘッダーは、nginx設定で示されるようになりました。

doker-compose構成にnginxイメージとnginx.confファイルを含めます。 YAMLスペースの注意事項：

 version: '3.4' services: dockerservicedemo: image: ${DOCKER_REGISTRY}dockerservicedemo build: context: . dockerfile: DockerServiceDemo/Dockerfile ports: - 5000:80 proxy: image: nginx:latest volumes: - ./DockerServiceDemo/nginx.conf:/etc/nginx/nginx.conf ports: - 80:80 

ここで、nginxイメージとして構成にプロキシを追加します。 この画像に外部設定ファイルを添付します。 ボリュームと呼ばれるメカニズムを使用して、コンテナファイルシステムにマウントします。 最後にroを追加すると、オブジェクトは読み取り専用でマウントされます。

プロキシは、コンテナが実行されているマシンの外部80番目のポートをリッスンし、リクエストをコンテナの内部80番目のポートに渡します。

doker-compose upコマンドを実行することにより、リポジトリからnginxイメージを抽出し、プロキシコンテナとともにコンテナを起動します。 これでhttp：// localhost：80 / nginx経由でアクセスできるようになります。 5000番目のポートでは、アプリケーションはケストレルの下でも「スピン」します。

Webアプリケーションへのリクエストがリバースプロキシを通過することを確認するために、これを行うことができます。 Chromeブラウザで開発者ツールを開き、[ネットワーク]タブに移動します。 ここでlocalhostをクリックして、[ヘッダー]タブを選択します。

プロキシとHTTPSを介してコンテナを起動します

ASP.NET Core 2.1では、HTTPSサポートが改善されました。
次のミドルウェアを使用すると、セキュリティで保護されていない接続からセキュリティで保護された接続にリダイレクトできるとします。

 app.UseHttpsRedirection(); 

次に、HTTP Strict Transport Security Protocol-HSTSを使用できます。

 app.UseHsts(); 

HSTSはHTTP / 2プロトコルの機能であり、その仕様は2015年にリリースされました。 この機能は最新のブラウザーでサポートされており、Webサイトがhttpsのみを使用していることを通知します。 したがって、ダウングレード攻撃に対する保護が発生し、その間に攻撃者は安全でないhttpプロトコルへの移行を使用することで状況を利用できます。 たとえば、TLSをダウングレードしたり、証明書を置き換えたりします。

通常、このタイプの攻撃は、中間者攻撃と組み合わせて使用​​されます。 HSTSは、ユーザーがhttpプロトコルを使用してサイトにアクセスし、httpsにリダイレクトする状況からあなたを救いません。 httpsをサポートするサイトへのリンクを含む、いわゆるChromeプリロードリストがあります。 他のブラウザ（Firefox、Opera、Safari、Edge）も、Chromeリストに基づいて作成されたhttpsサイトのリストをサポートしています。 しかし、すべてのサイトがこれらのリストのすべてに含まれているわけではありません。

WindowsでCoreアプリケーションを初めて実行すると、開発者証明書が作成およびインストールされたことを示すメッセージが表示されます。 ボタンをクリックして証明書をインストールすることにより、信頼できるようになります。 macOSのコマンドラインから、次のコマンドを使用して証明書に信頼を追加できます。
dotnet dev-certs https –trust

dev-certsユーティリティがインストールされていない場合、次のコマンドでインストールできます。

 dotnet tool install --global dotnet-dev-certs 

Linuxで信頼できる証明書を追加する方法は、ディストリビューションによって異なります。
テスト目的で、開発者の証明書を使用します。 CAによって署名された証明書を使用したアクションも同様です。 オプションで、無料のLetsEncrypt証明書を使用できます。

次のコマンドを使用して、開発者証明書をファイルにエクスポートできます

 dotnet dev-certs https -ep ___.pfx 

ファイルは、Windowsでは％APPDATA％/ ASP.NET / Https /ディレクトリに、またはmacOS / Linuxでは/root/.aspnet/https/にコピーする必要があります。

コンテナが証明書へのパスとそのパスワードを取得するには、次の内容のユーザーシークレットを作成します。

 { "Kestrel":{ "Certificates":{ "Default":{ "Path": "/root/.aspnet/https/__.pfx", "Password": "___" } } } } 

このファイルは暗号化されていないデータを保存するため、開発中にのみ使用されます。 ファイルは、プロジェクトアイコンのコンテキストメニューを呼び出すか、Linuxのユーザーシークレットユーティリティを使用して、Visual Studioで作成されます。

Windowsでは、ファイルは％APPDATA％\ Microsoft \ UserSecrets \ <user_secrets_id> \ secrets.jsonディレクトリに保存され、macOSおよびLinuxでは〜/ .microsoft / usersecrets / <user_secrets_id> /secrets.jsonに保存されます

本番用の設定を保存するために、一部のLinuxディストリビューションはsystemdを使用する場合があります。 たとえば、次のように：

 [Service] Environment="Kestrel _ Certificates _ Default _Path=/root/.aspnet/https/__.pfx" Environment="Kestrel _ Certificates _ Default _Password=___" 

次に、プロキシとコンテナーのドッカー構成の作業バージョンをhttps経由ですぐに提供および分析します。

Docker-composeファイル：

 version: '3.4' services: dockerservicedemo21: image: ${DOCKER_REGISTRY}dockerservicedemo build: context: . dockerfile: DockerServiceDemo/Dockerfile  override: version: '3.4' services: dockerservicedemo: environment: - ASPNETCORE_ENVIRONMENT=Development - ASPNETCORE_URLS=https://+:44392;http://+:80 - ASPNETCORE_HTTPS_PORT=44392 ports: - "59404:80" - "44392:44392" volumes: - ${APPDATA}/ASP.NET/Https:/root/.aspnet/https:ro - ${APPDATA}/Microsoft/UserSecrets:/root/.microsoft/usersecrets:ro proxy: image: nginx:latest volumes: - ./DockerServiceDemo/nginx.conf:/etc/nginx/nginx.conf - ./DockerServiceDemo/cert.crt:/etc/nginx/cert.crt - ./DockerServiceDemo/cert.rsa:/etc/nginx/cert.rsa ports: - "5001:44392" 

ここで、理解できない瞬間について説明します。 ASPNETCORE_URLSを使用すると、app.UseUrlを使用して、アプリケーションコードでアプリケーションがリッスンするポートを指定できなくなります。

ASPNETCORE_HTTPS_PORTは、次のコードが行うことと同様のリダイレクトを行います。
services.AddHttpsRedirection（options => options.HttpsPort = 44392）

つまり、httpリクエストからのトラフィックはhttpsリクエストの特定のポートにリダイレクトされます。
ポートを使用すると、外部の59404番目のポートからの要求が80番目のコンテナーにリダイレクトされ、44392番目の外部ポートから44392番目にリダイレクトされることが示されます。 理論的には、リバースプロキシサーバーを構成しているため、これらのリダイレクトでポートを削除できます。
ボリュームを使用すると、pfx証明書とUserSecretsアプリケーションを含むディレクトリが、パスワードと証明書へのリンクとともにマウントされます。

プロキシセクションは、5001番目の外部ポートからの要求が44392番目のnginxポートにリダイレクトされることを示します。 さらに、nginx構成ファイルと、証明書と証明書キーがマウントされます。

彼らが単一のpfx証明書を作成するために（すでに持っている）crtおよびrsaファイルを作成するには、OpenSSLを使用できます。 まず、証明書を抽出する必要があります。

 openssl pkcs12 -in ./_.pfx -clcerts -nokeys -out domain.crt 

そして、秘密鍵：

 openssl pkcs12 -in ./_.pfx -nocerts -nodes -out domain.rsa 

nginxの構成は次のとおりです。

 worker_processes 4; events { worker_connections 1024; } http { sendfile on; upstream app_servers { server dockerservicedemo:44392; } server { listen 44392 ssl; ssl_certificate /etc/nginx/cert.crt; ssl_certificate_key /etc/nginx/cert.rsa; location / { proxy_pass https://app_servers; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection keep-alive; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } } 

プロキシサーバーはポート44392でリッスンしています。 このポートは、5001番目のホストポートからリクエストを受信します。 次に、プロキシはリクエストをdockerdemoserviceコンテナの44392番目のポートにリダイレクトします。

これらの例を理解すれば、Docker、マイクロサービス、nginxを操作するための良い背景が得られます。

これはハッカー誌の記事の完全バージョンであることを思い出します。 著者はAlexey Sommerです。