Dockerfileのベスト プラクティスとシナリオ

Dockerfileを作成するときは、Dockerのビルド プロセスへの影響と、結果のイメージの両方を考慮してください。Dockerfileの構造が不十分な場合、ビルド時間が長くなったり、イメージ サイズが大きくなったりする可能性があります。Dockerfileを最適化するには、いくつかの方法があります。最高のガイドは、DockerとMicrosoftからのものです。これらは両方とも研究する価値があります。

主なポイントとベストプラクティスは次のとおりです。

多くの場合、DockerfileでソリューションをビルドするときにNuGetの復元を行いますが、プロセスを最適化しないと、ビルド時間が長くなる可能性があります。

各ビルド ステップは、前のすべてのステップがキャッシュされている場合は結果をキャッシュし、ソース ファイルのハッシュが変更されていない場合はCOPYコマンドで結果をキャッシュします。そのため、NuGetの復元でコピーするファイルを選択して、キャッシュのバストを最小限に抑えることができます。

次に簡単な例を示します。

FROM mcr.microsoft.com/dotnet/framework/sdk:4.8 AS build

# Copy NuGet essentials and restore as distinct layers
COPY *.sln nuget.config .
COPY src\*.csproj .\src\
RUN nuget restore

# Copy everything else, build, etc
COPY src\. .\src\
RUN msbuild /p:Configuration=Release

[...]

この例は、次のように機能します。

これにより、NuGetの復元手順がより頻繁にキャッシュされるため、毎回ダウンロードする必要がなくなります。

これは、単純なフォルダー構造の基本的なソリューションでは便利ですが、COPYコマンドのワイルドカード制限 によりフォルダー構造が失われるため、ほとんどのソリューション (Sitecore Helixなど) では実行できません。

これには回避策があります。これらのほとんどは、フォルダ構造とプロジェクトの命名について仮定しています。Sitecoreの例で一般的に使用される方法には、robocopyに加えて別のprep ビルド ステージがあります (これにより、これらの仮定はすべて削除されます)。

FROM mcr.microsoft.com/dotnet/framework/sdk:4.8 AS prep

# Gather only artifacts necessary for NuGet restore, retaining directory structure
COPY *.sln nuget.config \nuget\
COPY src\ \temp\
RUN Invoke-Expression 'robocopy C:\temp C:\nuget\src /s /ndl /njh /njs *.csproj *.scproj packages.config'

[...]

# New build stage, independent cache
FROM mcr.microsoft.com/dotnet/framework/sdk:4.8 AS build

# Copy prepped NuGet artifacts, and restore as distinct layer
COPY --from=prep .\nuget .\
RUN nuget restore

# Copy everything else, build, etc
COPY src\ .\src\
RUN msbuild /p:Configuration=Release

[...]

ビルドでは、プライベート フィードからNuGetパッケージを取得する必要がある場合があります。Dockerコンテキストでビルドする際には、認証情報が確実に保護されるように、認証情報の管理について特別な考慮を払う必要があります。詳細については、次の記事を参照してください。

Team Development for Sitecore (TDS) を使用したDockerソリューション ビルドには、ここで説明するように、HedgehogDevelopment.TDS NuGetパッケージとTDSライセンス環境変数が必要です。

この例は、GitHubのHelix.Examplesリポジトリで確認できます。