Sitecore イメージリファレンス

このページでは、Sitecore Container Registry (SCR)、scr.sitecore.comで利用可能なイメージの詳細情報と、カスタムソリューションでの使用方法について説明します。

注意: このページの原文は https://containers.doc.sitecore.com/docs/image-reference です

Sitecore Container Registry をブラウズする

利用可能なイメージリポジトリとタグの一覧は、GitHubのSitecore Docker Imagesリポジトリ に掲載されています。

リポジトリの名前空間

Sitecoreのイメージリポジトリは、Sitecore Container Registryの中にネームスペースを使って整理されています。以下にその内容を示します。

  • sxp - すべての Sitecore Experience Platform (SXP) イメージリポジトリが含まれています。プライマリプラットフォームリポジトリはルートにあります。
  • sxp/modules - SXP 固有のモジュールのイメージリポジトリがあります。
  • sxp/nonproduction - SXP用の非生産イメージリポジトリが含まれています。
  • tools - プラットフォームに依存しないツールのイメージリポジトリがあります。

ネーミング戦略

Sitecoreでは、画像を区別するためにいくつかの命名規則を使用しています。

アセット画像

モジュールのような特定のイメージは、カスタムSitecoreイメージのビルド時にのみソースとして使用され、実行時には決して使用されません。これらの "アセットイメージ "には、-assetsという接尾辞を付けて名前を付けます。

イメージの例をいくつか挙げます。

  • spe-assets
  • sitecore-management-services-xm1-assets
  • sxa-xp1-assets
  • sitecore-docker-tools-assets

トポロジー

特定のイメージはトポロジーに固有のものです。この場合、名前にはトポロジー(-xp0, -xp1, -xm1)が含まれます。イメージが名前にトポロジーを含まない場合は、トポロジーに依存しません。

イメージの例をいくつか挙げます。

  • sitecore-xp0-cm
  • sitecore-xp1-cortexreporting
  • jss-xm1-assets

タギングのルール

すべてのSitecoreイメージは、ロングタグとショートタグの2つのタグシステムを使用しています。一般的に、タグの最初の部分はSitecoreまたはモジュールのバージョンを表し、残りの部分はその上に構築されたベースとなるMicrosoftイメージの詳細を提供します。タグのフォーマットについては、以下を参照してください。

Sitecoreでは、"latest "タグを使用していません。これはあまりにも曖昧で、Microsoftや他のOSベースのイメージでは一般的に使用されていません。

プラットフォーム

プラットフォームイメージには、Sitecore Experience Platform (scr.sitecore.com/sxp)のベースイメージが含まれます。Sitecoreプラットフォームのバージョンがタグの最初の部分を構成しています。

長いタグ:

<Sitecoreバージョン>.<Sitecoreリビジョン>.<Sitecoreビルド>-<Windowsバージョン>.<Windowsリビジョン>-<OS名>

内訳に続くサンプルのタグです。

10.0.0.004346.337-10.0.17763.1339-ltsc2019

<Sitecore version>.<Sitecore revision>.<Sitecore build>-<Windows version>.<Windows revision>-<OS name>
\________________/ \_________________/ \______________/ \_______________/ \________________/ \_______/
         |                  |                 |               |                 |              |
       10.0.0             004346             337          10.0.17763           1339         ltsc2019

短いタグ:

<Sitecoreバージョン>-<OS名>

サンプルのタグです。

10.0.0-ltsc2019

モジュールとツール

これらには、Sitecore Experience Platform のモジュール (scr.sitecore.com/sxp/modules) や一般的なツール (scr.sitecore.com/tools) などのイメージが含まれます。

モジュールやツールのバージョンは、プラットフォームと一致している場合としていない場合があります。モジュールやツールがプラットフォームのバージョンに対応していない場合は、Sitecore Knowledgebaseに互換性のマトリックスが表示されます。

長いタグ:

<モジュールのバージョン>. <モジュールのリビジョン>. <モジュールのビルド>-<Windowsのバージョン>. <Windowsのリビジョン>-<OS名>

タグの例で、内訳が続いています。

14.0.0.00368.71-10.0.17763.1339-1809

<module version>.<module revision>.<module build>-<Windows version>.<Windows revision>-<OS name>
\______________/ \_______________/ \____________/ \_______________/ \________________/ \_______/
       |                 |               |               |                  |              |
     14.0.0            00368             71          10.0.17763            1339           1809

短いタグ:

<モジュールのバージョン>-<OS名>

タグの例。

14.0.0-1809

どのタグを使えばいいの？

OSのバージョン

異なる OS タグ (例えば 10.0.0-ltsc2019 と 10.0.0-1909) を選択する際には、Microsoft イメージを選択する際に使用されるのと同じルールに従います。つまり、Windows はホスト OS のバージョンがコンテナ OS のバージョンと一致することを要求します。新しい Windows ビルドに基づいてコンテナを実行したい場合は、同等のホストビルドがあることを確認してください。それ以外の場合は、Hyper-V 分離を使用して、新しいホストビルドで古いコンテナを実行することができます。

Windows コンテナのバージョンの互換性についての詳細は、Microsoft のドキュメントを参照してください。

アセットイメージは決して実行されないので、これは実際には考慮されません（実際には、通常、利用可能な OS タグは 1 つしかありません）。

長いタグ vs 短いタグ

長いタグは、正確なイメージバージョンに固定されます。

一方、短いタグは、最新のイメージバージョンを取得することで、よりダイナミックになります。メインのバージョン（例：<Sitecore バージョン>）のみをロックし、残りのバージョン（例：<Sitecore リビジョン>、<Sitecore ビルド>、<Windows リビジョン>）は最新のものを使用できるようにします。

しかし、短いタグを使用する場合、最新のイメージを使用するためには、明示的なプルが必要です。これは、Microsoftの.NET FrameworkなどのDockerイメージや、イメージの "latest "タグを使用している場合の通常の動作です。最新のイメージの更新をプルする方法については、次のセクションを参照してください。

longタグを使うかshortタグを使うかは、ビルドやリリースのプロセスや、イメージのバージョンをどの程度コントロールする必要があるかに依存します。例えば、開発目的で short タグを使用し、アップストリーム環境では long タグに移行することができます。あるいは、常に最新のイメージを使用したいので、短いタグを使用することもできます。

最新のイメージを取得する

Sitecoreのイメージショートタグ（例：10.0.0-ltsc2019）を使用している場合、Dockerはイメージのダイジェスト（不変のSHA256ベースの識別子）をプルされた時点でキャッシュし、次のいずれかを実行するまで使用し続けます。

  1. イメージを削除する。
  2. 明示的にイメージをプルします。

短いタグを使用している場合は、必要に応じて最新のものをプルする必要があります（ローカルの開発環境やCI環境など）。

推奨されているDocker Composeの設定では、オーバーライドを除いて、docker-compose pullコマンドを使ってほとんどのことができるはずです。

docker-compose -f docker-compose.yml pull

これは、最新のベースとなる Sitecore と Traefik のイメージを取得します。ただし、ビルド目的で使用されているイメージ（モジュールやツールのアセットイメージなど）は除外されます。残念ながら、Docker-composeのビルド --pullはDocker Composeの問題/制限のため、現在はできません。

最新のイメージをプルするのを忘れがちなので、これらのコマンドは通常自動化されています。これはCIビルドスクリプトやローカル開発用のカスタム "up "スクリプトに追加することで実現できます。

← Sitecore モジュールリファレンストラブルシューティング →