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ライセンス環境変数が必要です。

この例は Helixで見ることができます。GitHubの例リポジトリ。