.NET SDK コンテナーの作成の概要

Dockerfile を使用して .NET アプリをコンテナー化することは可能ですが、.NET SDK を使用してアプリを直接コンテナー化するべき強力な理由があります。 この記事では、.NET SDK コンテナー作成機能の概要と、テレメトリ、発行に関する考慮事項、ビルド プロパティ、コンテナー レジストリへの認証に関連する詳細について説明します。

プロジェクト出版に関する考慮事項

これで .NET アプリが作成されたので、コンテナーとして発行できます。 その前に、注意すべき重要な考慮事項がいくつかあります。 .NET SDK バージョン 8.0.200 より前のバージョンでは、NuGet パッケージ Microsoft.NET.Build.Containers が必要です。 このパッケージは、.NET SDK バージョン 8.0.200 以降では必要ありません。コンテナーのサポートは既定で含まれています。

.NET アプリをコンテナーとして発行できるようにするには、次のビルド プロパティが必要です。

• IsPublishable: trueに設定します。 このプロパティは、console、webapp、workerなど、実行可能なプロジェクトの種類の true に暗黙的に設定されます。
• EnableSdkContainerSupport: プロジェクトの種類がコンソール アプリの場合に true に設定します。

SDK コンテナーのサポートを明示的に有効にするには、次のプロジェクト ファイル スニペットを検討してください。

<PropertyGroup>
  <IsPublishable>true</IsPublishable>
  <EnableSdkContainerSupport>true</EnableSdkContainerSupport>
</PropertyGroup>

スイッチとビルドのプロパティを公開する

すべての .NET CLI コマンドと同様に、コマンド ラインで MSBuild プロパティ 指定できます。 次のようなプロパティを提供するために使用できる有効な構文フォームは多数あります。

• /p:PropertyName=Value
• -p:PropertyName=Value
• -p PropertyName=Value
• --property PropertyName=Value

任意の構文を自由に使用できますが、ドキュメントには -p 形式の使用例が示されています。

プロファイルとターゲットを発行する

dotnet publishを使用する場合、-p PublishProfile=DefaultContainer でプロファイルを指定すると、SDK が発行プロセスの後に別のターゲットをトリガーするプロパティを設定できます。 これは、目的の結果を達成するための間接的な方法です。 一方、dotnet publish /t:PublishContainer を使用すると、PublishContainer ターゲットが直接呼び出され、同じ結果が得られますが、より簡単な方法で実現されます。

つまり、次の .NET CLI コマンドです。

dotnet publish -p PublishProfile=DefaultContainer

PublishProfile プロパティを DefaultContainerに設定するコマンドは、次のコマンドと同じです。

dotnet publish /t:PublishContainer

2 つのメソッドの違いは、前者がプロファイルを使用してプロパティを設定し、後者がターゲットを直接呼び出す点です。 これが重要な理由は、プロファイルは MSBuild の機能であり、単に直接設定するよりも複雑な方法でプロパティを設定するために使用できることです。

1 つの重要な問題は、すべてのプロジェクトの種類がプロファイルをサポートしているわけではないか、同じプロファイル セットを使用できるわけではないということです。 さらに、Visual Studio や .NET CLI など、さまざまなツール間のプロファイルのサポート レベルに違いがあります。 そのため、ターゲットの使用は、一般に、同じ結果を得るためにより明確で広くサポートされている方法です。

コンテナー レジストリに対する認証

プライベート コンテナー レジストリを操作するには、これらのレジストリを使用して認証する必要があります。

Docker には、docker login コマンドを使用してこれを使用する確立されたパターンがあります。これは、特定のレジストリで認証するための規則を含む Docker 構成ファイルと対話する方法です。 このファイルとエンコードする認証の種類は、レジストリ認証のために Microsoft.Net.Build.Containers でサポートされています。 これにより、このパッケージは、docker pull および docker push が可能なすべてのレジストリでシームレスに動作することが保証されます。 通常、このファイルは ~/.docker/config.jsonに格納されますが、config.json ファイルを含むディレクトリを指す 変数を使用して追加で指定できます。

認証の種類

config.json ファイルには、次の 3 種類の認証が含まれています。

• 明示的なユーザー名/パスワード
• 資格情報ヘルパー
• システム キーチェーン

明示的なユーザー名/パスワード

config.json ファイルの auths セクションは、レジストリ名と Base64 でエンコードされた username:password 文字列の間のキー/値マップです。 一般的な Docker シナリオでは、docker login <registry> -u <username> -p <password> 実行すると、このマップに新しい項目が作成されます。 これらの資格情報は、継続的インテグレーション (CI) システムで一般的であり、ログインは実行の開始時にトークンによって行われます。 ただし、ファイルに資格情報が必要な場合のセキュリティ 上のリスクがあるため、エンド ユーザーの開発マシンではあまり人気が高くはありません。

資格情報ヘルパー

config.json ファイルの credHelpers セクションは、レジストリ名と、そのレジストリの資格情報の作成と取得に使用できる特定のプログラムの名前の間のキー/値マップです。 これは、特定のレジストリに複雑な認証要件がある場合によく使用されます。 この種の認証を機能させるには、システムの PATHに docker-credential-{name} という名前のアプリケーションが必要です。 このような資格情報はセキュリティで保護される傾向がありますが、開発または CI マシンでは設定が困難な場合があります。

システム キーチェーン

credsStore セクションは、システムのパスワード マネージャーとのインターフェイス方法を認識する Docker 資格情報ヘルパー プログラムの名前を値とする単一の文字列プロパティです。 Windows の場合、これは例えば wincred かもしれません。 これらは、macOS および Windows 用の Docker インストーラーで一般的です。

環境変数を使用した認証

一部のシナリオでは、上記で説明した標準的な Docker 認証メカニズムでは不十分です。 このツールには、レジストリに資格情報を提供するための追加のメカニズム (環境変数) があります。 環境変数を使用する場合、資格情報の提供メカニズムはまったく使用されません。 次の環境変数がサポートされています。

• DOTNET_CONTAINER_REGISTRY_UNAME: これはレジストリのユーザー名である必要があります。 レジストリのパスワードがトークンの場合は、ユーザー名を "<token>"する必要があります。
• DOTNET_CONTAINER_REGISTRY_PWORD: これはレジストリのパスワードまたはトークンである必要があります。

このメカニズムは資格情報の漏洩に対して脆弱になる可能性があるため、他のメカニズムが使用できないシナリオでのみ使用する必要があります。 たとえば、Docker コンテナー自体内で SDK コンテナー ツールを使用している場合です。 さらに、このメカニズムは名前空間が設定されていません。これは、ソース レジストリ (基本イメージがある場所) と の移行先 レジストリ (最終的なイメージをプッシュする場所) の両方に同じ資格情報を使用しようとします。

安全でないレジストリの使用

ほとんどのレジストリ アクセスはセキュリティで保護されていると見なされます。つまり、HTTPS はレジストリとの対話に使用されます。 ただし、すべてのレジストリが TLS 証明書を使用して構成されているわけではありません。特に、VPN の背後にあるプライベート企業レジストリのような状況です。 これらのユース ケースをサポートするために、コンテナー ツールは、特定のレジストリが安全でない通信を使用することを宣言する方法を提供します。

.NET 8.0.400 以降、SDK はこれらの構成ファイルと形式を認識し、その構成を自動的に使用して、HTTP と HTTPS のどちらを使用するかを判断します。 セキュリティで保護されていない通信用にレジストリを構成する方法は、選択したコンテナー ツールによって異なります。

Docker

Docker は、そのレジストリ構成を デーモン構成に格納します。 新しい安全でないレジストリを追加するために、新しいホストが "insecure-registries" 配列プロパティに追加されます。

{
  "insecure-registries": [
    "registry.mycorp.net"
  ]
}

Podman

Podman は、registries.conf TOML ファイルを使用してレジストリ接続情報を格納します。 このファイルは通常、/etc/containers/registries.confに存在します。 新しい安全でないレジストリを追加するには、レジストリの設定を保持する TOML セクションが追加され、insecure オプションを trueに設定する必要があります。

[[registry]]
location = "registry.mycorp.net"
insecure = true

環境変数

9.0.100 以降、.NET SDK は、DOTNET_CONTAINER_INSECURE_REGISTRIES 環境変数を介して渡された安全でないレジストリを認識します。 この変数は、上記の Docker および Podman の例と同じ方法で安全でないものとして扱うために、ドメインのコンマ区切りのリストを受け取ります。

$Env:DOTNET_CONTAINER_INSECURE_REGISTRIES=localhost:5000,registry.mycorp.com; dotnet publish -t:PublishContainer -p:ContainerRegistry=registry.mycorp.com -p:ContainerBaseImage=localhost:5000/dotnet/runtime:9.0

DOTNET_CONTAINER_INSECURE_REGISTRIES=localhost:5000,registry.mycorp.com dotnet publish -t:PublishContainer -p:ContainerRegistry=registry.mycorp.com -p:ContainerBaseImage=localhost:5000/dotnet/runtime:9.0

テレメトリー

.NET アプリをコンテナーとして発行すると、.NET SDK コンテナー ツールによって、ツールの使用方法に関する使用状況テレメトリが収集されて送信されます。 収集されたデータは、.NET CLIによって送信される テレメトリに加えて、同じメカニズムを使用し、重要なことに、同じ オプトアウト制御に準拠します。

収集されるテレメトリは、本質的に一般的であり、個人情報が漏えいしないことを目的としています。目的は、次の測定に役立ちます。

• .NET SDK コンテナー化機能の全体的な使用方法。
• 成功率と失敗率と、最も頻繁に発生するエラーの種類に関する一般的な情報。
• さまざまなレジストリの種類への発行や、発行の呼び出し方法など、テクノロジの特定の機能の使用。

テレメトリをオプトアウトするには、DOTNET_CLI_TELEMETRY_OPTOUT 環境変数を trueに設定します。 詳細については、.NET CLI テレメトリを参照してください。

推論テレメトリ

基本イメージ推論プロセスの発生方法に関する次の情報がログに記録されます。

イメージ生成テレメトリ

コンテナーの作成と発行プロセスの発生方法に関する次の情報がログに記録されます。

さらに、プロセス中にさまざまな種類のエラーが発生した場合、そのエラーの種類に関するデータが収集されます。

関連項目

• .NET アプリをコンテナーとして発行
• .NET アプリ参照 をコンテナー化する