---
title: "Sitecoreソリューションを構築"
slug: "build-sitecore-solutions"
abstract: "Sitecoreソリューションの構築方法を説明しています。"
---
# Sitecoreソリューションを構築

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

まだ行っていなければ、[Docker Examplesリポジトリ](https://github.com/Sitecore/docker-examples) をマシン上の場所にクローンしてください。このトピックでは*custom-images*フォルダを使用します。このトピックでは、[標準のSitecoreインスタンスの実行](https://doc.sitecore.com/xp/ja/developers/103/developer-tools/run-your-first-sitecore-instance.html "Run your first Sitecore instance") 方法に関するドキュメントを読み、Sitecoreインスタンスを正常に起動できることを前提としています。

このトピックでは、ソリューションコードを使ってコンテナイメージを構築する方法を紹介します。開発中の効率的なフィードバックループを確保するために、[実行中のコンテナにファイルをデプロイ](https://doc.sitecore.com/xp/ja/developers/103/developer-tools/deploying-files-into-running-containers.html "Deploying files into running containers")するための開発環境も設定する必要があります。

## Dockerfilesについて

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

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

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

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

COPY aspnetmvcapp/. ./aspnetmvcapp/
WORKDIR /app/aspnetmvcapp
RUN msbuild /p:Configuration=Release

FROM mcr.microsoft.com/dotnet/framework/aspnet:4.8 AS runtime
WORKDIR /inetpub/wwwroot
COPY --from=build /app/aspnetmvcapp/. ./

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

その後、[DockerfileはDocker buildコマンド](https://docs.docker.com/engine/reference/commandline/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でビルドすることが望ましいですが、従来の [方法に頼](https://doc.sitecore.com/xp/ja/developers/103/developer-tools/building-custom-sitecore-images.html "Building custom Sitecore images") らざるを得ない場合もあります(例えば、レガシーコードベースやビルドプロセスの制限があるため)。

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

典型的なSitecore実装では、単一のVisual Studioソリューションで複数の役割用のビルドアーティファクト(例えばWebsiteやXConnectアセンブリ)が作成され、一部のアーティファクトは複数のロール(例:CM/CD)に展開する必要があります。コンテナの場合、同じビルド出力を *複数のベースSitecoreランタイムイメージ*の上に重ねて重ねる必要があります。代わりに各Sitecoreイメージのビルド命令を複製することもできますが、それは非常に非効率的です。

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

### ビルドDockerfile

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

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

1.  ファイルは、デフォルトのバックスラッシュではなく、エスケープ文字をバックティック(')に設定するエ [スケープ指令](https://docs.docker.com/engine/reference/builder/#escape) から始まります。
    
    \# escape=\`
    
2.  prepステージは、NuGet復元に必要なアーティファクトのみを集めるために使われます。これは.NETビルドでよく行われる最適化です(詳細は[ベストプラクティスDockerfile](https://doc.sitecore.com/xp/ja/developers/103/developer-tools/dockerfile-best-practices-and-scenarios.html "Dockerfile best practices and scenarios")参照)。
    
    FROM mcr.microsoft.com/dotnet/framework/sdk:4.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イメージ](https://hub.docker.com/_/microsoft-dotnet-framework-sdk/)に基づいてコードのコンパイルおよびビルドプロセスを開始し、BUILD\_CONFIGURATION ARGが宣言されます(これはdebugまたはrelease、Docker Composeで設定されています):
    
    FROM mcr.microsoft.com/dotnet/framework/sdk:4.8 AS builder
    ARG BUILD\_CONFIGURATION
    
4.  [SHELL命令](https://docs.docker.com/engine/reference/builder/#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](https://docs.docker.com/engine/reference/builder/#dockerignore-file) (Dockerfileの横に配置されています)。これによりCOPYコマンドのサイズが小さくなり、binやobjフォルダなどは除外されます。これはビルドDockerfileのベストプラクティスです。設定変換の詳細については、「[設定変換の適用](https://doc.sitecore.com/xp/ja/developers/103/developer-tools/applying-configuration-transforms.html "Applying configuration transforms")」を参照してください。
    
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:Configuration=$env:BUILD\_CONFIGURATION /p:DeployOnBuild=True /p:DeployDefaultTarget=WebPublish /p:WebPublishMethod=FileSystem /p:PublishUrl=C:\\out\\website
    RUN msbuild .\\src\\DockerExamples.XConnect\\DockerExamples.XConnect.csproj /p:Configuration=$env:BUILD\_CONFIGURATION /p:DeployOnBuild=True /p:DeployDefaultTarget=WebPublish /p:WebPublishMethod=FileSystem /p:PublishUrl=C:\\out\\xconnect
    
8.  ビルド完了後、最終イメージのビルド出力が収集されます。この段階では[Microsoft Nano Serverイメージ](https://hub.docker.com/_/microsoft-windows-nanoserver) が使用されます。このイメージはファイルのみを配信し実行されないため、ベースイメージは最適化されたサイズで選択されます。これは他のランタイムイメージよりも *はるかに* 小さいものです:
    
    FROM mcr.microsoft.com/windows/nanoserver:1809
    
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に追加の指示が含まれることがあります。詳細は [「アイテムのデプロイ」](https://doc.sitecore.com/xp/ja/developers/103/developer-tools/deploying-items.html "Deploying items")を参照してください。

### 解像

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

## Docker Composeで設定

画像を生成するには[Dockerビルドコマンド](https://docs.docker.com/engine/reference/commandline/build/) でDockerfileを送る必要があります。コマンドbuild直接使うことも可能ですが、主に[Docker Compose](https://docs.docker.com/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})はこの例の [環境ファイル](https://docs.docker.com/compose/env-file/) (.env)に定義されていますが、ローカル開発マシンのシステム環境変数やビルドサーバー上のシークレットからも取得可能です。
-   画像名には \-solution の接尾辞が使われます。デフォルトの変数値を使うと、タグ付けされたバージョンは docker-examples-solution:latest
-   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:latest
    
2.  すべてのDockerイメージをリストアップして画像が作成されたか確認してください:
    
    docker images docker-examples\*
    
    REPOSITORY TAG IMAGE ID CREATED SIZE
    docker-examples-solution latest 9bb20b2ab6db 2 minutes ago 259MB

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

まずトラブルシューティング [ガイド](https://doc.sitecore.com/xp/ja/developers/103/developer-tools/troubleshooting-docker.html "Troubleshooting Docker")を見てください。

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

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

docker run -it --rm docker-examples-solution:latest

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

## さらなる参考文献

-   [Dockerfile参照](https://docs.docker.com/engine/reference/builder/)
-   [Windows上のDockerfile](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-docker/manage-windows-dockerfile)
-   [Dockerfileのベストプラクティスとシナリオ](https://doc.sitecore.com/xp/ja/developers/103/developer-tools/dockerfile-best-practices-and-scenarios.html "Dockerfile best practices and scenarios")