Docker Compose のビルド プロパティ
「コンテナー ツールのビルド プロパティ」で説明している、個々の Docker プロジェクトを制御するプロパティに加え、ソリューション構築のために MSBuild で使用される Docker Compose プロパティを設定することで、Visual Studio による Docker Compose プロジェクトのビルド方法をカスタマイズすることもできます。 Docker Compose 構成ファイルでファイル ラベルを設定することで、Visual Studio デバッガーによる Docker Compose アプリの実行方法を制御することもできます。
MSBuild プロパティの設定方法
プロパティの値を設定するには、プロジェクト ファイルを編集します。 Docker Compose プロパティの場合、このプロジェクトファイルは、次のセクションの表で特に指定されていない限り、拡張子が .dcproj のプロジェクト ファイルです。 たとえば、デバッグを開始するときにブラウザーを起動するように指定するとします。 次のように、.dcproj プロジェクト ファイル内で DockerLaunchAction プロパティを設定できます。
<PropertyGroup>
<DockerLaunchAction>LaunchBrowser</DockerLaunchAction>
</PropertyGroup>
プロパティ設定を既存の PropertyGroup 要素に追加できます。存在しない場合は、新しい PropertyGroup 要素を作成できます。
Docker Compose MSBuild のプロパティ
次の表は、Docker Compose プロジェクトで使用できる MSBuild プロパティを示しています。
| プロパティ名 | 場所 | 説明 | 既定値 |
|---|---|---|---|
| AdditionalComposeFilePaths | dcproj | すべてのコマンドで docker-compose.exe に追加の Compose ファイルがセミコロンで区切られたリストで送信されるように指定します。 Docker Compose プロジェクト ファイル (dcproj) からの相対パスが許可されます。 | - |
| DockerComposeBaseFilePath | dcproj | 拡張子を付けずに、Docker Compose ファイルのファイル名の最初の部分を .yml 指定します。 例: 1. DockerComposeBaseFilePath = null/undefined: 基本ファイル パス docker-composeを使用します。ファイルはdocker-compose.ymlおよびdocker-compose.override.ymlという名前になります。2. DockerComposeBaseFilePath = mydockercompose: ファイル名は mydockercompose.yml と mydockercompose.override.yml になります。 3. DockerComposeBaseFilePath = ..\mydockercompose: ファイルは 1 レベル上になります。 |
docker-compose |
| DockerComposeBuildArguments | dcproj | docker-compose build コマンドに渡す追加のパラメーターを指定します。 たとえば、--parallel --pull のようにします。 |
|
| DockerComposeDownArguments | dcproj | docker-compose down コマンドに渡す追加のパラメーターを指定します。 たとえば、--timeout 500 のようにします。 |
- |
| DockerComposeEnvFilePath | dcproj | --env-file を介して docker compose コマンドに渡される .env ファイルへの 相対パス。 「.env ファイルに置き換える」を参照してください。 |
空 |
| DockerComposeProjectName | dcproj | 指定した場合は、Docker Compose プロジェクトのプロジェクト名をオーバーライドします。 | "dockercompose" + 自動生成されたハッシュ |
| DockerComposeProjectPath | csproj または vbproj | Docker Compose プロジェクト (dcproj) ファイルへの相対パス。 docker-compose.yml ファイルに格納されている関連イメージ ビルド設定を見つける目的で、サービス プロジェクトの公開時にこのプロパティを設定します。 | - |
| DockerComposeProjectsToIgnore | dcproj | デバッグ中に Docker Compose ツールによって無視されるプロジェクトを指定します。 このプロパティは、任意のプロジェクトに使用できます。 ファイル パスは、次の 2 つの方法のどちらかで指定できます。 1. dcproj を基準として。 たとえば、 <DockerComposeProjectsToIgnore>path\to\AngularProject1.csproj</DockerComposeProjectsToIgnore> のようにします。 2. 絶対パス。 注: これらのパスは、区切り文字 ; で区切る必要があります。 |
- |
| DockerComposeUpArguments | dcproj | docker-compose up コマンドに渡す追加のパラメーターを指定します。 たとえば、--timeout 500 のようにします。 |
- |
| DockerDevelopmentMode | dcproj | ユーザー プロジェクトをコンテナーにビルドするかどうかを制御します。 Fast または Regular の許可される値によって、Dockerfile でどのステージがビルドされるかが制御されます。 デバッグ構成は、既定では Fast モードであり、それ以外の場合は Regular モードです。 | Fast |
| DockerLaunchAction | dcproj | F5 または Ctrl + F5 キーで実行する起動アクションを指定します。 指定できる値には、None、LaunchBrowser、LaunchWCFTestClient があります。 | None |
| DockerLaunchBrowser | dcproj | ブラウザーを起動するかどうかを示します。 DockerLaunchAction が指定されている場合は無視されます。 | False |
| DockerServiceName | dcproj | DockerLaunchAction または DockerLaunchBrowser が指定されている場合、DockerServiceName は、ファイル内で docker-compose 参照されているサービスが起動されるように指定します。 |
- |
| DockerServiceUrl | dcproj | ブラウザーを起動するときに使用される URL。 有効な置換トークンには、"{ServiceIPAddress}"、"{ServicePort}"、"{Scheme}" があります。 例: {Scheme}://{ServiceIPAddress}:{ServicePort} | - |
| DockerTargetOS | dcproj | Docker イメージをビルドするときに使用されるターゲット OS。 | - |
例
相対パスに設定DockerComposeBaseFilePathしてファイルのdocker-compose場所を変更する場合は、ソリューション フォルダーを参照するようにビルド コンテキストが変更されていることを確認する必要もあります。 たとえば、ファイルが DockerComposeFiles という名前のフォルダーである場合docker-compose、Docker Compose ファイルはビルド コンテキストを ".." または ".に設定する必要があります。/.."。ソリューション フォルダーに対する相対位置に応じて異なります。
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" Sdk="Microsoft.Docker.Sdk">
<PropertyGroup Label="Globals">
<ProjectVersion>2.1</ProjectVersion>
<DockerTargetOS>Windows</DockerTargetOS>
<ProjectGuid>154022c1-8014-4e9d-bd78-6ff46670ffa4</ProjectGuid>
<DockerLaunchAction>LaunchBrowser</DockerLaunchAction>
<DockerServiceUrl>{Scheme}://{ServiceIPAddress}{ServicePort}</DockerServiceUrl>
<DockerServiceName>webapplication1</DockerServiceName>
<DockerComposeBaseFilePath>DockerComposeFiles\mydockercompose</DockerComposeBaseFilePath>
<AdditionalComposeFilePaths>AdditionalComposeFiles\myadditionalcompose.yml</AdditionalComposeFilePaths>
</PropertyGroup>
<ItemGroup>
<None Include="DockerComposeFiles\mydockercompose.override.yml">
<DependentUpon>DockerComposeFiles\mydockercompose.yml</DependentUpon>
</None>
<None Include="DockerComposeFiles\mydockercompose.yml" />
<None Include=".dockerignore" />
</ItemGroup>
</Project>
ビルド コンテキストがソリューション フォルダーの相対パスに設定された状態 (この場合は ..) では、mydockercompose ファイルは次のようになります。
version: '3.4'
services:
webapplication1:
image: ${DOCKER_REGISTRY-}webapplication1
build:
context: ..
dockerfile: WebApplication1\Dockerfile
メモ
Visual Studio 2019 バージョン 16.3 では、DockerComposeBuildArguments、DockerComposeDownArguments、DockerComposeUpArguments が新しく追加されています。
Visual Studio の Docker Compose 構成のオーバーライド
通常、docker-compose.override.yml は docker-compose.yml の特定の設定をオーバーライドするために使用されます。 さらに、Visual Studio では、Visual Studio 内でのアプリケーションの実行に固有の設定を使用して、docker-compose.vs.debug.g.yml (高速モードの場合) ファイルと docker-compose.vs.release.g.yml (標準モードの場合) ファイルのオーバーライド ファイルが生成されます。 docker-compose.yml ファイルと同じディレクトリ内に docker-compose.vs.debug.yml (Fast モードの場合) または docker-compose.vs.release.yml (Regular モードの場合) という名前のファイルを置くことによって、このような Visual Studio の設定をオーバーライドできます。 Docker Compose プロジェクトを右クリックし、エクスプローラーで [フォルダーを開く] を選択し、[既存の項目の追加]>を使用して Docker Compose プロジェクトにファイルを追加します。
ヒント
任意の Visual Studio 設定の既定値を確認するには、docker-compose.vs.debug.g.yml または docker-compose.vs.release.g.yml の中間出力ディレクトリを調べます (例: obj/Docker)。 これらのファイルは Visual Studio によって生成されるため、変更しないでください。
Docker Compose ファイル ラベル
docker-compose.vs.debug.yml または docker-compose.vs.release.yml で、オーバーライド固有のラベルを次のように定義できます。
services:
webapplication1:
labels:
com.microsoft.visualstudio.debuggee.workingdirectory: "C:\\my_app_folder"
前の例のように値を二重引用符で囲み、パスでバックスラッシュのエスケープ文字としてバックスラッシュを使用します。
| ラベル名 | 説明 |
|---|---|
| com.microsoft.visualstudio.debuggee.program | デバッグの開始時に起動するプログラム。 .NET Core アプリの場合、この設定は通常、dotnet です。 |
| com.microsoft.visualstudio.debuggee.arguments | デバッグの開始時にプログラムに渡される引数。 .NET Core アプリの場合、通常、これらの引数は NuGet パッケージの追加検索パスであり、これにプロジェクトの出力アセンブリのパスが続きます。 |
| com.microsoft.visualstudio.debuggee.workingdirectory | デバッグの開始時に開始ディレクトリとして使用されるディレクトリ。 この設定は通常、Linux コンテナーの場合は /app、Windows コンテナーの場合は C:\app になります。 |
| com.microsoft.visualstudio.debuggee.killprogram | このコマンドは、(必要なときに) コンテナー内で実行されているデバッグ対象プログラムを停止する目的で使用されます。 |
| ラベル名 | 説明 |
|---|---|
| com.microsoft.visualstudio.debuggee.program | デバッグの開始時に起動するプログラム。 .NET Core アプリの場合、この設定は通常、dotnet です。 |
| com.microsoft.visualstudio.debuggee.arguments | デバッグの開始時にプログラムに渡される引数。 .NET Core アプリの場合、通常、これらの引数は NuGet パッケージの追加検索パスであり、これにプロジェクトの出力アセンブリのパスが続きます。 |
| com.microsoft.visualstudio.debuggee.workingdirectory | デバッグの開始時に開始ディレクトリとして使用されるディレクトリ。 この設定は通常、Linux コンテナーの場合は /app、Windows コンテナーの場合は C:\app になります。 |
| com.microsoft.visualstudio.debuggee.killprogram | このコマンドは、(必要なときに) コンテナー内で実行されているデバッグ対象プログラムを停止する目的で使用されます。 |
| com.microsoft.visualstudio.debuggee.noattach.program | 分離プロセスで実行される Azure Functions プロジェクトで [デバッグなしで開始] (Ctrl+F5 キー) を使用するときに起動されるプログラム。 通常、F5 キーと Ctrl+F5 キーの両方で同じプログラムが使用されますが、分離プロセスの Azure Functions のようなプロジェクトの種類で F5 キーとは異なるプログラムが必要な場合は、これが使用されます。 |
| com.microsoft.visualstudio.debuggee.noattach.arguments | 分離プロセスで実行される Azure Functions プロジェクトで [デバッグなしで開始] (Ctrl+F5 キー) を使用するときにプログラムに渡される引数。 |
Docker ビルド プロセスをカスタマイズする
build プロパティの target 設定を使用して、Dockerfile でどのステージをビルドするかを宣言できます。 このオーバーライドは、docker-compose.vs.debug.yml または docker-compose.vs.release.yml でのみ使用できます。
services:
webapplication1:
build:
target: customStage
labels:
...
アプリのスタートアップ プロセスをカスタマイズする
entrypoint 設定を使用し、それを DockerDevelopmentMode に依存させることによって、アプリの起動前にコマンドまたはカスタム スクリプトを実行できます。 たとえば、 を実行することによって (Regularupdate-ca-certificates モードではなく) Fast モードでのみ証明書を設定する必要がある場合は、次のコードをdocker-compose.vs.debug.yml にのみ追加することができます。
services:
webapplication1:
entrypoint: "sh -c 'update-ca-certificates && tail -f /dev/null'"
labels:
...
次の手順
MSBuild プロパティの一般情報については、MSBuild プロパティを参照してください。
関連項目
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示