コンテナを使用したSitecoreのローカル開発

実行中のコンテナへのファイルのデプロイ

Version:

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

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

このトピックでは、Visual Studioからローカルで実行されているコンテナーにファイルを直接デプロイできるように、Sitecoreソリューションを設定する方法について説明します。開発中にこれを使用して、毎回カスタムSitecoreイメージを再構築するのではなく、効率的なフィードバックループを確保します。

次の図は、デプロイメント・プロセスの概要を示しています。

A diagram that shows the deployment process.

Docker Examplesリポジトリをクローンする

Docker Examplesリポジトリをマシン上の場所 (C:\sitecore\docker-examples\など) にクローンしていない場合は、クローンを作成します。このトピックでは、例としてcustom-imagesフォルダーを使用します。

サンプルの準備

custom-images例を実行するには、いくつかの準備が必要です。まだ行っていない場合は、準備手順に従うか、付属のcompose-init.ps1スクリプトを実行して、次の準備手順を自動的に実行します。

PowerShell管理者プロンプトを開き、custom-imagesフォルダー ( C:\sitecore\docker-examples\custom-imagesなど) に移動します。次のコマンドを実行し、Sitecoreライセンスファイルの場所を -LicenseXmlPathパラメーターに指定します。
.\compose-init.ps1 -LicenseXmlPath C:\License\license.xml

開発用ENTRYPOINTスクリプトとは?

ENTRYPOINTは、コンテナが最初に実行されるときに実行するコマンドを提供します。すべてのSitecoreランタイムイメージには、Dockerfile命令の一部としてデフォルトのENTRYPOINTが設定されているため、イメージを実行する準備ができています。docker inspectコマンドを使用すると、任意のイメージのデフォルトENTRYPOINTを見つけることができます。

なぜ開発に異なるスクリプトが必要なのですか?

一般的なSitecore開発ワークフローには、複数のイテレーションでコードを変更することや、実行中のSitecoreインスタンスのWebルートに対するソリューションの構築が含まれます。 Docker for Windowsの現在の制限により、コンテナ内のボリュームの宛先は、存在しないディレクトリまたは空のディレクトリである必要があります。現在、ボリュームがマウントされたDockerコンテナでは実現できません。

回避策は、マウントされた別のhotフォルダーで変更を監視し、これらの変更をSitecore Webルートにコピーすることです。このウォッチプロセスが起動時に開始されるようにするには、デフォルトのSitecoreプロダクションENTRYPOINTをオーバーライドできます。

このウォッチプロセスとコンパニオンENTRYPOINTの組み合わせが、sitecore-docker-tools-assetsイメージに含まれています。

sitecore-docker-tools-assetsイメージ開発ENTRYPOINT

イメージのビルドプロセスに役立つ他のスクリプトに加えて、sitecore-docker-tools-assetsイメージには次のスクリプトが含まれています。

脚本を見る:

C:\tools\scripts\Watch-Directory.ps1: ファイルの変更のソースパスを監視し、それに応じて宛先パスを更新します。
ENTRYPOINTスクリプト:
- C:\tools\entrypoints\iis\Development.ps1 : IISベースのロールに使用する開発ENTRYPOINTスクリプト ( cm、cd、xconnectなど)。
- C:\tools\entrypoints\worker\Development.ps1: .NET Coreベースのワーカーロール (xdbsearchworker、xdbautomationworker、cortexprocessingworkerなど) に使用する開発ENTRYPOINTスクリプト。

Development.ps1各スクリプトは、同じように機能します。

ディレクトリがC:\deployにマウントされている場合、監視プロセス (Watch-Directory.ps1) をバックグラウンドジョブとして開始します。
デフォルトのSitecore ENTRYPOINTを呼び出します。

メモ

C:\deployはデフォルトのソースディレクトリですが、これを上書きできます。ウォッチスクリプトのパラメーターをカスタマイズして、異なるソースパスと宛先パスを使用したり、追加のファイルやフォルダーを除外したりできます。

ソリューションの構造を理解する

Dockerを使用したSitecore開発では、一般的なソリューションであるdockerフォルダーに新しいフォルダーが導入されます。 dockerフォルダには、Docker開発をサポートするためのファイルとフォルダが含まれています。

custom-images\dockerフォルダの構造は次のとおりです。

deploy
    [environment]
    [...]

environment各フォルダは、次の役割を果たします。

コードのデプロイのdestination 。
開発ENTRYPOINTウォッチスクリプトのsourceです。

この場合、websiteフォルダーはSitecore Webサイト/プラットフォームコンテナー (cm、cdなど) を提供し、xconnectフォルダーはSitecore xConnectコンテナー ( xconnectなど) を提供します。

Docker Examples環境プロジェクト

Docker Examplesリポジトリには、ファイルのデプロイシナリオを示す2つのプロジェクトがあります。 custom-imagesフォルダーに移動し、Visual StudioでソリューションDockerExamples.slnを開きます。

DockerExamples.Website: Webサイト/プラットフォーム成果物のビルドと公開を容易にし、デフォルトのSample Inner Sublayout.ascxサブレイアウトに簡単な変更を加えます。
DockerExamples.XConnect: xConnectアーティファクトのビルドと公開を容易にします。

Helixソリューションでは、DockerExamples.WebsiteプロジェクトとDockerExamples.XConnectプロジェクトは、多くの場合、別々の環境モジュールと1つ以上のプロジェクト/機能モジュールに分割されますが、ここではシンプルさを売りにするために組み合わせられています。

これらの各プロジェクトには、DockerDeploy公開プロファイルがあります。

各プロファイルのDockerDeploy.pubxmlファイルを開くと、対応するdocker\deploy環境サブフォルダー ( DockerExamples.Websiteからdocker\deploy\website Uに、DockerExamples.XConnectからdocker\deploy\xconnectに発行するように設定されていることがわかります。

ファイル展開オプション

Docker Examplesソリューションは、基本的なVisual Studioファイル発行を使用する簡単な例です。実際のソリューションでは、Team Development for Sitecore (TDS)、Helix Publishing Pipeline (HPP) に含まれるもの、または独自のカスタムアプローチなど、より堅牢なデプロイメカニズムを使用できます。

ただし、最終的な目標は同じで、ファイルを適切なdocker\deploy環境サブフォルダーに格納することです。

これは、WebルートにデプロイするSitecore開発のベストプラクティスに従うのと似ていますが、ファイルをWebルートに直接送信する代わりに、ファイルをWebルートに送信しますdocker\deploy。

Sitecoreランタイムイメージに適用

Sitecoreイメージでランタイムファイルのデプロイを有効にするには:

cmサービスのSitecoreランタイムDockerfileを開きます。TOOLING_IMAGEは、最初にARG(Docker Composeで設定)で取り込まれ、次に名前付きビルドステージとして開始されることがわかりますtooling
ARG TOOLING_IMAGE [...] FROM ${TOOLING_IMAGE} as tooling
toolsフォルダ(ENTRYPOINTスクリプトを含む)は、toolingイメージから(C:\toolsに)コピーされます。
COPY --from=tooling \tools\ \tools\
xconnectサービスのSitecoreランタイムDockerfileを開くと、ここでも同じ手順が表示されます。これらは、XP1およびXM1トポロジで使用するためのcd SitecoreランタイムDockerfileにも含まれています。

SitecoreランタイムのDockerfileに必要なのはこれだけです。

大事な

ENTRYPOINTスクリプトとウォッチスクリプトがイメージにコピーされ、実行時に使用可能になることが重要です。

Docker Composeで設定するには:

custom-imagesフォルダのルートにあるdocker-compose.override.ymlファイルを開きます (例: C:\sitecore\docker-examples\custom-images\docker-compose.override.yml)。

次の例は、cmサービスの設定方法を示しています。

cm:
  image: ${REGISTRY}${COMPOSE_PROJECT_NAME}-xp0-cm:${VERSION:-latest}
  build:
    context: ./docker/build/cm
    args:
      BASE_IMAGE: ${SITECORE_DOCKER_REGISTRY}sitecore-xp0-cm:${SITECORE_VERSION}
      SPE_IMAGE: ${SITECORE_MODULE_REGISTRY}spe-assets:${SPE_VERSION}
      SXA_IMAGE: ${SITECORE_MODULE_REGISTRY}sxa-xp1-assets:${SXA_VERSION}
      TOOLING_IMAGE: ${SITECORE_TOOLS_REGISTRY}sitecore-docker-tools-assets:${TOOLS_VERSION}
      SOLUTION_IMAGE: ${REGISTRY}${COMPOSE_PROJECT_NAME}-solution:${VERSION:-latest}
  [...]
  volumes:
    - ${LOCAL_DEPLOY_PATH}\website:C:\deploy
    [...]
  entrypoint: powershell -Command "& C:\tools\entrypoints\iis\Development.ps1"

次に、設定について説明します。

TOOLING_IMAGE build argは、sitecore-docker-tools-assetsイメージリポジトリを使用するように構成されています。特定のイメージタグまたはバージョンは、環境ファイル (.env) で定義されているTOOLS_VERSION変数によって決定されます。
また、.envファイルでは、LOCAL_DEPLOY_PATHはdocker\deployフォルダの相対パスに設定されています。
この変数は、docker\deploy website環境サブフォルダー (.\docker\deploy\website) を、Dockerボリュームを持つデフォルトの監視スクリプトソースフォルダー (C:\deploy) の実行中のコンテナに公開するために使用されます。
デフォルトのエントリポイントは上書きされ、開発ENTRYPOINTスクリプトに設定されます。

xconnectサービスも同様の方法で構成されます。ただし、C:\deployボリュームのマウントは、代わりにdocker\deploy xconnect environmentサブフォルダーにマップされます。
xconnect: [...] volumes: - ${LOCAL_DEPLOY_PATH}\xconnect:C:\deploy [...]
この設定が完了すると、実行中のSitecore Dockerインスタンス内のWebサイト/プラットフォームまたはxConnectコンテナにソリューションアセットを個別に公開できるようになりました。

Dockerの例を実行する

Dockerサンプルを実行するには、次のようにします。

PowerShellプロンプトを開き、custom-imagesフォルダーに移動し、Docker Compose upコマンドを使用してDocker Examplesを実行します。
docker-compose up -d
インスタンスが稼働している状態になったら、https://cm.dockerexamples.localhostを参照します。おなじみのSitecoreのデフォルトページにDockerロゴが追加されました。

ロゴは、DockerExamples.WebsiteプロジェクトのSample Inner Sublayout.ascxサブレイアウトに追加されます。

Visual StudioでSample Inner Sublayout.ascxファイルを開き、変更を加えます。たとえば、Dockerロゴの下に新しい段落を追加します。

<%@ Control Language="c#" AutoEventWireup="true" TargetSchema="http://schemas.microsoft.com/intellisense/ie5" %>
<div id="InnerCenter">
    <div id="Header">
        <img src="-/media/Default Website/sc_logo.ashx" alt="Sitecore" id="scLogo" />
        <p style="margin: 0 16px; font-size: 30px;">+</p>
        <img src="/images/docker-logo.png" alt="Docker" />
        <p><strong>= Awesome!</strong></p>
    </div>
    <div id="Content">
        <div id="LeftContent">
            <sc:placeholder runat="server" key="content" />
        </div>                
    </div>
    <div id="Footer"><hr class="divider"/>© <%= Sitecore.DateUtil.ToServerTime(DateTime.UtcNow).Year.ToString()%> Sitecore</div>
</div>

DockerDeploy公開プロファイルを使用してDockerExamples.Websiteプロジェクトを公開します (Solution ExplorerでDockerExamples.Websiteプロジェクトを右クリックし、Publishをクリックします)。

手記

これにより、ファイルがdocker\deploy websiteフォルダに公開されます。これにより、ウォッチスクリプトがトリガーされ、cmコンテナのWebルートにコピーされます。
公開が完了したら、ブラウザーでhttps://cm.dockerexamples.localhostページを更新すると、変更を確認できます。
コンテナを停止し、downコマンドを使用して削除します。
docker-compose down

デプロイフォルダをクリーンアップする

mssqlやsolrのデータフォルダと同様に、docker/deployフォルダ内のファイルはdocker-compose down後も残ります。これらのフォルダ内のファイルを削除するには、付属のclean.ps1スクリプトを使用します。

デプロイフォルダをクリーンアップするには:

custom-imagesフォルダーに移動し、PowerShell管理者プロンプトでスクリプトを実行します。
.\docker\clean.ps1

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

実行中のコンテナへのファイルのデプロイ

Docker Examplesリポジトリをクローンする

サンプルの準備

開発用ENTRYPOINTスクリプトとは?

なぜ開発に異なるスクリプトが必要なのですか?

sitecore-docker-tools-assetsイメージ開発ENTRYPOINT

ソリューションの構造を理解する

Docker Examples環境プロジェクト

ファイル展開オプション

Sitecoreランタイム イメージに適用

Dockerの例を実行する

デプロイフォルダをクリーンアップする

Sitecoreランタイムイメージに適用