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ベースの識別子)をプルされた時点でキャッシュし、次のいずれかを実行するまで使用し続けます。
- イメージを削除する。
- 明示的にイメージをプルします。
短いタグを使用している場合は、必要に応じて最新のものをプルする必要があります(ローカルの開発環境やCI環境など)。
推奨されているDocker Composeの設定では、オーバーライドを除いて、docker-compose pullコマンドを使ってほとんどのことができるはずです。
docker-compose -f docker-compose.yml pull
これは、最新のベースとなる Sitecore と Traefik のイメージを取得します。ただし、ビルド目的で使用されているイメージ(モジュールやツールのアセットイメージなど)は除外されます。残念ながら、Docker-composeのビルド --pullはDocker Composeの問題/制限のため、現在はできません。
最新のイメージをプルするのを忘れがちなので、これらのコマンドは通常自動化されています。これはCIビルドスクリプトやローカル開発用のカスタム "up "スクリプトに追加することで実現できます。