Sitecoreソリューションを構築

Version:
日本語翻訳に関する免責事項

このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。

このトピックでは、DockerfileとDockerイメージビルドのプロセス、そしてそれを使ってSitecoreソリューションを構築する方法について説明します。

まだ行っていなければ、Docker Examplesリポジトリ をマシン上の場所にクローンしてください。このトピックではcustom-imagesフォルダを使用します。このトピックでは、標準のSitecoreインスタンスの実行 方法に関するドキュメントを読み、Sitecoreインスタンスを正常に起動できることを前提としています。

このトピックでは、ソリューションコードを使ってコンテナイメージを構築する方法を紹介します。開発中の効率的なフィードバックループを確保するために、実行中のコンテナにファイルをデプロイするための開発環境も設定する必要があります。

Dockerfilesについて

アプリケーションをコンテナ化する最初のステップとしてDockerfileを書きます。Dockerfileには、DockerがDockerイメージを組み立てて実行するための指示が含まれています。Dockerfileコマンドはイメージを構築するためのステップバイステップのレシピです。

以下は、単純な(非Sitecore)ASP.NET MVCアプリのDockerfile例です。

FROM mcr.microsoft.com/dotnet/framework/sdk

.8 AS build WORKDIR /app

COPY *.sln . COPY aspnetmvcapp/*.csproj ./aspnetmvcapp/ RUN nuget restore

COPY aspnetmvcapp/. ./aspnetmvcapp/ WORKDIR /app/aspnetmvcapp RUN msbuild /p

=Release

FROM mcr.microsoft.com/dotnet/framework/aspnet

.8 AS runtime WORKDIR /inetpub/wwwroot COPY --from=build /app/aspnetmvcapp/. ./

この例では マルチステージビルドが用いられています。まずコードはmcr.microsoft.com/dotnet/framework/sdkイメージ( buildステージ)で作成され、その後出力がmcr.microsoft.com/dotnet/framework/aspnetイメージ( runtimeステージ)にコピーされます。

その後、DockerfileはDocker buildコマンド で使用され、このコマンドがビルドとイメージを作成します。

オプションの .dockerignore(https://docs.docker.com/engine/reference/builder/#dockerignore-file) を使えば、ビルドコンテキストからファイルやフォルダを除外し、COPYやADDコマンドで機密データを縮小したりスキップしたりできます。

この例は、コードのコンパイルとビルドがDockerfileの指示の一部であることを示しています。.NETでは、NuGetの復元を行い、その後MSBuildを呼び出すことが含まれます。このようなDockerfileで直接アプリケーションを構築することには、従来のビルドに比べて以下のような利点があります:

  • 移植性 - ビルドプロセス全体がコンテナ化されています。ビルドエージェントやローカル環境はDocker以外をインストールする必要はありません。
  • ビルド環境の制御 - ソリューションはどのビルド依存関係(およびどのバージョンを使うか)を所有します。
  • 効率 - ビルドステップが非常に冗長でも、Dockerのビルドキャッシュを活用することで再構築を最適化できます。
  • Dockerエコシステムで快適に機能します。ビルドはDockerコマンドでトリガーでき、他の画像に使うビルドアーティファクトの取得もDockerfile FROM 命令で簡単にできます。

!注このトピックはDockerfileの使用に焦点を当てています。Dockerfileでビルドすることが望ましいですが、従来の 方法に頼 らざるを得ない場合もあります(例えば、レガシーコードベースやビルドプロセスの制限があるため)。

ソリューションビルドDockerfileとイメージ

典型的なSitecore実装では、単一のVisual Studioソリューションで複数の役割用のビルドアーティファクト(例えばWebsiteやXConnectアセンブリ)が作成され、一部のアーティファクトは複数のロール(例

/CD)に展開する必要があります。コンテナの場合、同じビルド出力を 複数のベースSitecoreランタイムイメージの上に重ねて重ねる必要があります。代わりに各Sitecoreイメージのビルド命令を複製することもできますが、それは非常に非効率的です。

必要なのは、ソリューションの構築に特化し、その結果のイメージ上に構造化ビルドのアーティファクトとして出力を保存するDockerfileです。

ビルドDockerfile

例のルートDockerfileはまさにそのようなDockerfileです。DockerコミュニティではこのタイプのビルドをしばしばDockerfile Dockerfile.buildと呼びます。

custom-imagesフォルダに移動し、そこにあるDockerfileを確認してください。簡単さのために、BASE_IMAGEとBUILD_IMAGE ARGが拡張されています。

  1. ファイルは、デフォルトのバックスラッシュではなく、エスケープ文字をバックティック(')に設定するエ スケープ指令 から始まります。

    # escape=`

  2. prepステージは、NuGet復元に必要なアーティファクトのみを集めるために使われます。これは.NETビルドでよく行われる最適化です(詳細はベストプラクティスDockerfile参照)。

    FROM mcr.microsoft.com/dotnet/framework/sdk

    .8 AS prep

    COPY *.sln nuget.config Directory.Build.targets Packages.props \nuget\ COPY src\ \temp\ RUN Invoke-Expression 'robocopy C:\temp C:\nuget\src /s /ndl /njh /njs *.csproj *.scproj packages.config'

  3. 新しいbuilder段階が、.NET Framework SDKイメージに基づいてコードのコンパイルおよびビルドプロセスを開始し、BUILD_CONFIGURATION ARGが宣言されます(これはdebugまたはrelease、Docker Composeで設定されています):

    FROM mcr.microsoft.com/dotnet/framework/sdk

    .8 AS builder ARG BUILD_CONFIGURATION

  4. SHELL命令は、すべての命令に対してデフォルトのシェルをPowerShell(デフォルトcmdから)に切り替わります。これはWindowsのDockerファイルでよく使われる命令です:

    SHELL "powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';"

  5. 次にワーキングディレクトリが作成され、以前に収集されたNuGetアーティファクトをコピーし、(最適化された) nuget restoreを実行します。

    WORKDIR C:\build COPY --from=prep .\nuget .\ RUN nuget restore

  6. 復元後、残りのソースコードがコピーされ、変換ファイルはC:\out\transformsで収集されます:

    COPY src\ .\src\ RUN Invoke-Expression 'robocopy C:\build\src C:\out\transforms /s /ndl /njh /njs *.xdt'

    例には.dockerignore (Dockerfileの横に配置されています)。これによりCOPYコマンドのサイズが小さくなり、binやobjフォルダなどは除外されます。これはビルドDockerfileのベストプラクティスです。設定変換の詳細については、「設定変換の適用」を参照してください。

  7. 次に、msbuildを用いて設定されたBUILD_CONFIGURATIONのビルドが実行されます。この例には、ウェブサイト/プラットフォーム(DockerExamples.Website.csproj)とxConnect(DockerExamples.XConnect.csproj)環境の両方を対象としたプロジェクトが含まれています。シンプルなファイルシステムのパブリッシュが使用され、出力はそれぞれC:\out\websiteとC:\out\xconnectに着地します。

    RUN msbuild .\src\DockerExamples.Website\DockerExamples.Website.csproj /p

    =$env
    _CONFIGURATION /p
    =True /p
    =WebPublish /p
    =FileSystem /p
    =C:\out\website RUN msbuild .\src\DockerExamples.XConnect\DockerExamples.XConnect.csproj /p
    =$env
    _CONFIGURATION /p
    =True /p
    =WebPublish /p
    =FileSystem /p
    =C:\out\xconnect

  8. ビルド完了後、最終イメージのビルド出力が収集されます。この段階ではMicrosoft Nano Serverイメージ が使用されます。このイメージはファイルのみを配信し実行されないため、ベースイメージは最適化されたサイズで選択されます。これは他のランタイムイメージよりも はるかに 小さいものです:

    FROM mcr.microsoft.com/windows/nanoserver

  9. 出力ファイルはbuilder段階から最終画像に以下の構造でコピーされます。

    • \artifacts\website
    • \artifacts\transforms
    • \artifacts\xconnect

    WORKDIR C:\artifacts COPY --from=builder C:\out\website .\website\ COPY --from=builder C:\out\transforms .\transforms\ COPY --from=builder C:\out\xconnect .\xconnect\

!注この例ではSitecoreのアイテムシリアライズは行われていません。シリアライゼーションフレームワークや戦略によっては、ソリューションビルドのDockerfileに追加の指示が含まれることがあります。詳細は 「アイテムのデプロイ」を参照してください。

解像

ソリューションビルドDockerfileはビルドアーティファクトのみで構成されたイメージを生成します。得られた ソリューションイメージ は決してDockerコンテナ上で実行されることを意図していません。このようなイメージは時に アセットイメージと呼ばれます。

Docker Composeで設定

画像を生成するにはDockerビルドコマンド でDockerfileを送る必要があります。コマンドbuild直接使うことも可能ですが、主にDocker Composeで設定されています。

custom-imagesフォルダには以下のファイルが含まれています:

  • .env
  • docker-compose.yml
  • docker-compose.override.yml

これらはすべてDocker Composeファイルの種類です。

理解してくださいdocker-compose.override.yml

docker-compose up -dなどのDocker Composeコマンドでは、特に指定がない限り、docker-compose.override.ymlファイルはメインのdocker-compose.ymlファイルと自動的に含まれています。Docker Composeに2つ以上のコンポジションファイルが渡されると、それらを統合し、すべてのリソースと設定を一つのマージ定義にまとめます。

この例では、docker-compose.ymlファイルはデフォルトのSitecore Experience Platform - Single(XP0) Docker Composeファイルで、Sitecoreから提供されます。 docker-compose.override.ymlはメインファイルを拡張し、カスタムSitecoreイメージ構築や開発に必要なオーバーライドや拡張子を付けます。

ソリューションサービスの設定

docker-compose.override.ymlファイルはソリューションイメージビルドを定義する場所です。

ファイルを開いて、solutionサービスがどのように構成されているかを確認してください:

solution: image: ${REGISTRY}${COMPOSE_PROJECT_NAME}-solution:${VERSION:-latest} build: context: . args: BASE_IMAGE: ${SOLUTION_BASE_IMAGE} BUILD_IMAGE: ${SOLUTION_BUILD_IMAGE} BUILD_CONFIGURATION: ${BUILD_CONFIGURATION} scale: 0

以下の点に注目してください。

  • 変数の数値(例: ${SOLUTION_BASE_IMAGE})はこの例の 環境ファイル (.env)に定義されていますが、ローカル開発マシンのシステム環境変数やビルドサーバー上のシークレットからも取得可能です。
  • 画像名には -solution の接尾辞が使われます。デフォルトの変数値を使うと、タグ付けされたバージョンは docker-examples-solution
  • build contextは.に設定されていて、同じ場所でビルドDockerfileを使うように指示Docker Compose。
  • build argsはビルドDockerfileに見られたものと相関しています。
  • scale は0に設定されており、 solution サービスのコンテナが docker-compose up中に起動されないようにしています。

解イメージを構築する

解イメージを構築するには:

  1. PowerShellプロンプトを開き、Composeファイルと同じフォルダから以下のコマンドを実行してください。

    docker-compose build solution

    これによりソリューションイメージのビルドプロセスが開始され、イメージが作成されます:

    Building solution Step 1/21 : ARG BASE_IMAGE Step 2/21 : ARG BUILD_IMAGE Step 3/21 : FROM ${BUILD_IMAGE} AS prep ... Successfully built 9bb20b2ab6db Successfully tagged docker-examples-solution

  2. すべてのDockerイメージをリストアップして画像が作成されたか確認してください:

    docker images docker-examples*

    REPOSITORY TAG IMAGE ID CREATED SIZE docker-examples-solution latest 9bb20b2ab6db 2 minutes ago 259MB

トラブルシューティング ソリューション イメージビルド

まずトラブルシューティング ガイドを見てください。

ソリューションイメージ(または他の アセットイメージ)に特有の一般的なトラブルシューティングの問題の一つは、コンテナとして実行されないため、結果のファイルシステムをどう探索すればよいかが分かりにくいことです。これはインタラクティブシェルでイメージを実行することで可能です。

例えば、前述のソリューションイメージの例に対してインタラクティブなコマンドプロンプトを開く場合(Nano ServerにはPowerShellはありません):

docker run -it --rm docker-examples-solution

exitと入力すると一時的な容器を取り除き、前のPowerShellセッションに戻ります。

さらなる参考文献

この記事を改善するための提案がある場合は、 お知らせください!