Sitecoreソリューションの構築
このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。
このトピックでは、DockerfileとDockerイメージのビルド プロセスと、それを使用してSitecoreソリューションをビルドする方法について説明します。
Docker Examplesリポジトリをマシン上の場所にまだクローンしていない場合は、クローンします。このトピックでは、custom-imagesフォルダーを使用します。このトピックは、すぐに使用できるSitecoreインスタンスの実行方法に関するドキュメントを確認し、Sitecoreインスタンスを正常に開始できることを前提としています。
このトピックでは、ソリューション コードを使用してコンテナー イメージをビルドする方法を示します。開発中に効率的なフィードバック ループを確保するには、実行中のコンテナーにファイルをデプロイするための開発環境も構成する必要があります。
Dockerfileについて
Dockerfileについて
Dockerfileは、アプリケーションをコンテナ化するための最初のステップとして記述します。Dockerfileには、DockerがDockerイメージをアセンブルして実行するために使用する命令が含まれています。Dockerfileコマンドは、イメージを構築する方法のステップバイステップのレシピです。
以下は、単純な (Sitecore以外の) ASP.NET MVCアプリのDockerfileの例です。
この例では、マルチステージ ビルドを使用します: 最初にコードがmcr.microsoft.com/dotnet/framework/sdkイメージ ( buildステージ) でビルドされ、次に出力がmcr.microsoft.com/dotnet/framework/aspnetイメージ ( runtimeステージ) にコピーされます。
その後、DockerfileはDockerビルド コマンド によって使用され、このコマンドはイメージをビルドして作成します。
オプションの .dockerignoreを使用すると、ビルド コンテキストからファイルとフォルダーを除外し、COPYコマンドとADDコマンドでサイズを縮小したり、機密データをスキップしたりできます。
この例では、コードのコンパイルとビルドがDockerfileの命令の一部であることを示しています。.NETでは、これにはNuGetの復元と、それに続くMSBuildの呼び出しが含まれる場合があります。このようにDockerfileでアプリケーションを直接ビルドすると、従来のビルドに比べて次のような利点があります。
-
Portability - ビルドプロセス全体がコンテナ化されます。ビルド エージェントとローカル環境には、Docker以外のものをインストールする必要はありません。
-
ビルド環境の制御 - ソリューションは、使用されるビルドの依存関係 (およびバージョン) を所有します。
-
Efficiency - ビルド手順が非常に冗長な場合でも、Dockerビルドキャッシュを使用すると、リビルドが最適化されます。
-
Dockerエコシステムでうまく機能します - ビルドはDockerコマンドを使用してトリガーでき、他のイメージで使用するためのビルドアーティファクトの取得は、Dockerfile FROM手順を使用して簡単に行うことができます。
このトピックでは、Dockerfileの使用に焦点を当てています。Dockerfileでのビルドが推奨されますが、ソリューションをビルドするには従来の手段に頼 らざるを得ない場合があります (たとえば、従来のコードベースやビルド プロセスの制限のため)。
ソリューションのビルドDockerfileとイメージ
ソリューションのビルドDockerfileとイメージ
一般的なSitecore実装では、通常、1つのVisual Studioソリューションで複数のロール (WebサイトやXConnectアセンブリなど) のビルド アーティファクトが作成され、一部のアーティファクトを複数のロール (CM/CDなど) にデプロイする必要があります。コンテナの場合、これは、同じビルド出力をmultiple base Sitecore runtime imagesの上に階層化する必要があることを意味します。代わりに、各Sitecoreイメージのビルド手順を複製することもできますが、これは非常に非効率的です。
必要なのは、ソリューションのビルドのみに焦点を当てたDockerfileと、出力を構造化されたビルド成果物として結果のイメージに格納することです。
Dockerfileのビルド
この例のルートDockerfileは、このようなDockerfileです。Dockerコミュニティでは、このタイプのビルドにDockerfileという名前が付けられることがよくありますDockerfile.build
custom-imagesフォルダに移動し、そこにあるDockerfileを確認します。わかりやすくするために、BASE_IMAGEとBUILD_IMAGE ARGが拡張されていることに注意してください。
-
このファイルは、エスケープ文字をデフォルトのバックスラッシュではなくバックティック (') に設定するescapeディレクティブ で始まります。
-
prepステージは、NuGetの復元に必要な成果物のみを収集するために使用されます。これは、.NETビルドで行われる一般的な最適化です (説明については、Dockerfileのベスト プラクティスを参照してください)。
-
新しいbuilderステージでは、.NET Framework SDKイメージに基づいてコードのコンパイルとビルドのプロセスが開始され、BUILD_CONFIGURATION ARGが宣言されます (これはdebugまたはreleaseでDocker Composeで構成されます)。
-
SHELL命令は、後続のすべての命令で既定のシェルをPowerShellに切り替えます (既定の1からcmd)。これは、Windows Dockerfileの一般的な手順です。
-
次に、作業ディレクトリが作成され、前に収集されたNuGet成果物がコピーされ、(最適化された) nuget restoreが実行されます。
-
復元後、残りのソース コードがコピーされ、変換ファイルが次の場所に収集されますC:\out\transforms
この例には、.dockerignore (Dockerfileと共に配置) が含まれています。これにより、COPYコマンドのサイズが小さくなり、binフォルダーやobjフォルダーなどが除外されます。これは、Dockerfileをビルドするためのベスト プラクティスです。構成変換の詳細については、構成変換の適用を参照してください。
-
次に、構成されたBUILD_CONFIGURATIONに対して、msbuildを使用してビルドが実行されます。この例には、Webサイト/プラットフォーム (DockerExamples.Website.csproj) 環境とxConnect (DockerExamples.XConnect.csproj) 環境の両方を対象とするプロジェクトが含まれています。単純なファイルシステムのパブリッシュが使用され、出力はそれぞれC:\out\websiteとC:\out\xconnectにランディングされます。
-
ビルドが完了すると、最終イメージのビルド出力が収集されます。この段階では、Microsoft Nano Serverイメージ が使用されます。このイメージはファイルを配信するだけで実行されないため、基本イメージは最適化されたサイズ (他のランタイム イメージよりもmuch小さい) で選択されます。
-
出力ファイルは、builder段階から次の構造で最終画像にコピーされます。
-
\artifacts\website
-
\artifacts\transforms
-
\artifacts\xconnect
-
この例では、Sitecoreアイテムのシリアル化は行いません。シリアル化のフレームワークと戦略によっては、ソリューション ビルドDockerfileに追加の指示が含まれる場合があります。詳細については、Deploying itemsを参照してください。
ソリューションイメージ
ソリューション ビルドDockerfileは、ビルド成果物のみで構成されるイメージを生成します。結果として得られるsolution imageは、Dockerコンテナで実行することを意図したものではありません。このような画像は、asset imagesと呼ばれることもあります。
Docker Composeでの構成
Docker Composeでの構成
イメージを生成するには、Docker buildコマンドを使用してDockerfileを送信する必要があります。 buildコマンドを直接使用することもできますが、ほとんどの場合、DockerComposeで構成されます。
custom-imagesフォルダには、次のファイルが含まれています。
-
.env
-
docker-compose.yml
-
docker-compose.override.yml
これらはすべてDocker Composeファイルの種類です。
docker-compose.override.ymlを理解する
Docker Composeコマンド ( docker-compose up -dなど) の場合、特に指定しない限り、docker-compose.override.ymlファイルはメインのdocker-compose.ymlファイルと共に自動的に含まれます。Docker Composeに2つ以上のcomposeファイルが渡されると、それらをマージし、すべてのリソースと構成を1つのマージされた定義にまとめます。
この例では、docker-compose.ymlファイルはSitecoreからのデフォルトのSitecore Experience Platform - Single (XP0) Docker Composeファイルです。このdocker-compose.override.ymlは、カスタムSitecoreイメージのビルドと開発の目的で必要なオーバーライドと拡張子を使用してメイン ファイルを拡張します。
ソリューション サービスを構成する
docker-compose.override.ymlファイルは、ソリューション イメージのビルドを定義する場所です。
ファイルを開き、solutionサービスを見て、どのように構成されているかを確認します。
次の点に注意してください。
-
変数値( ${SOLUTION_BASE_IMAGE}など)は 、環境ファイル (この例では.env)で定義されていますが、ローカル開発マシンのシステム環境変数やビルドサーバー上のシークレットから取得することもできます。
-
イメージ名には -solutionサフィックスが付きます。デフォルトの変数値では、タグ付けされたバージョンは docker-examples-solution:latest
-
build contextは . に設定され、同じ場所にあるビルドDockerfileを使用するようにDocker Composeに指示します。
-
build argsは、ビルドDockerfileで見つかったものと相関しています。
-
scaleは0に設定されているため、solutionサービスのコンテナはdocker-compose up中に開始されません。
ソリューション イメージをビルドする
ソリューション イメージをビルドする
ソリューション イメージをビルドするには、次のようにします。
-
PowerShellプロンプトを開き、Composeファイルと同じフォルダーから次のコマンドを実行します。
これにより、ソリューション イメージのビルド プロセスが開始され、イメージが作成されます。
-
すべてのDockerイメージを一覧表示して、イメージが作成されたことを確認します。
ソリューション イメージのビルドのトラブルシューティング
ソリューション イメージのビルドのトラブルシューティング
まず、トラブルシューティングガイドをご覧ください。
ソリューション イメージ (または任意のasset image) に固有の一般的なトラブルシューティングの問題の1つは、コンテナとして実行されないため、結果のファイル システムを探索する方法が明確でない可能性があることです。これを行うには、対話型シェルでイメージを実行します。
たとえば、対話型コマンド プロンプト (Nano ServerにはPowerShellがありません) を開くには、前に示したソリューション イメージの例を表示します。
「 exit 」と入力して一時コンテナーを削除し、前のPowerShellセッションに戻ります。