--- title: "Sitecore画像参照" slug: "sitecore-image-reference" abstract: "Sitecoreが提供するDockerイメージに関する追加情報。" --- # Sitecore画像参照 このトピックでは、Sitecoreコンテナレジストリ(SCR)、*scr.sitecore.com*、で見つかる画像と、それらをカスタムソリューションでどのように活用するかについての追加情報を提供します。 ## Sitecoreコンテナレジストリの閲覧 利用可能な画像リポジトリやタグのリストは [、GitHubのSitecore Docker Imagesリポジトリ](https://github.com/Sitecore/docker-images/tree/master/tags)で見つけることができます。 ## リポジトリ名前空間 Sitecoreのイメージリポジトリは、名前空間とともに[Sitecoreコンテナレジスト](https://github.com/Sitecore/docker-images/blob/master/tags/sitecore-tags.md) リ内で整理されています。 ## 命名戦略 Sitecoreは画像を区別するためにいくつかの命名規則を利用しています: - アセット画像 モジュールのような特定のイメージは、カスタムSitecoreイメージビルド時のソースとしてのみ意図されており、実行時には使用しません。これらの *アセットイメージ* には、それに応じて名前が付けられ、接尾辞は \-assets付けられています。以下は例の画像です: - *特殊資産* - *sitecore-management-services-XM1-assets* - *SXA-XP1-資産* - *sitecore-docker-tools-assets* - 位相 特定の画像は位相に特有のものです。この場合、位相(\-xp0、\-xp1、または \-xm1)が名前に含まれます。画像に位相が名前になければ、その画像は位相に依存しません。以下は例の画像です。 - *サイトコア-XP0-CM* - *サイトコア-XP1-Cortexreporting(本音の* - jss-xm1-assets ## タグ付け戦略 すべてのSitecoreイメージは、*完全なタグ*、*3桁のタグ*、*2桁のタグ*からなるタグ付けシステムを使用しています。一般的に、タグの最初の部分はSitecoreまたはモジュールのバージョンを表し、残りは構築されているベースのMicrosoftイメージの詳細を提供します。 Sitecoreは *最新の* タグを使いません。なぜなら、それらは曖昧すぎて、Microsoftや他のOSベースのイメージでは一般的に従われていないからです。 ### プラットフォーム画像 プラットフォーム画像にはSitecore Experience Platformのベース画像が含まれています(*scr.sitecore.com/sxp*)。Sitecoreプラットフォームバージョンがタグの最初の部分を構成します。 **フルタグ:** ..-.- 以下は例タグの後に内訳を示します。 10.4.0.004346.337-10.4.17763.1339-ltsc2022 ..-.- \\\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_/ \\\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_/ \\\_\_\_\_\_\_\_\_\_\_\_\_\_\_/ \\\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_/ \\\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_/ \\\_\_\_\_\_\_\_/ | | | | | | 10.4.0 004346 337 10.4.17763 1339 ltsc2019 **3桁のタグ:** - 以下は例タグです: 10.4.0-ltsc2022 **2桁のタグ:** - 以下は例タグです: 10.4-ltsc2022 ### モジュールとツール これには、Sitecore Experience Platform用のモジュール(scr.sitecore.com/sxp/modules)や一般的なツール(scr.sitecore.com/tools)などのイメージが含まれます。 モジュールやツールはプラットフォームに適合しないバージョンを持っている場合があります。モジュールやツールがプラットフォームのバージョンに適合 *しない場合は* 、[Sitecoreナレッジベースに](https://kb.sitecore.net/articles/541788)互換性マトリックスを提供します。 **フルタグ:** ..-.- 以下は例タグの後に内訳を示します。 14.4.0.00368.71-10.4.17763.1339-1809 ..-.- \\\_\_\_\_\_\_\_\_\_\_\_\_\_\_/ \\\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_/ \\\_\_\_\_\_\_\_\_\_\_\_\_/ \\\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_/ \\\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_/ \\\_\_\_\_\_\_\_/ | | | | | | 14.4.0 00368 71 10.4.17763 1339 1809 **3桁のタグ:** - 以下は例タグです: 14.4.0-1809 **2桁のタグ:** - 14.4-1809 ## タグの選択 ### OSバージョン 異なるOSタグ(例えば10.0.0-ltsc2019と10.0.0-1909)を選ぶ際は、Microsoftイメージを選ぶ際に使われるルールに従ってください。WindowsはホストOSのバージョンがコンテナOSのバージョンと一致することを求めます。新しいWindowsビルドをベースにしたコンテナを実行したい場合は、同等のホストビルドを持っていることを確認してください。そうでなければ、Hyper-Vアイソレーションを使って古いコンテナを新しいホストビルドに実行できます。 Windowsコンテナのバージョン互換性についての詳細は [、Microsoftのドキュメント](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility)をご覧ください。 アセットイメージの場合は問題ありません。なぜならこれらのイメージは実行されないからです。通常、利用可能なOSタグは1つだけです。 ### フルタグと短いタグの比較 フルタグは正確な画像バージョンにロックします。 3桁と2桁のタグは、より動的で最新の画像バージョンを引き出せます。メインバージョン(例: )だけをロックし、残り(例: 、、)は最新のバージョンを使えます。 フルタグを使うか短いタグを使うかは、ビルドやリリースのプロセス、そしてイメージバージョンのコントロール度によって決まります。例えば、開発時にはショートタグを使い、デプロイ時にはフルタグに移行するかもしれません。常に最新のイメージを使いたいなら、ショートタグを使い続けましょう。 Sitecoreがコンテナとその不変画像を管理する方法の性質上、コンテナ画像を作成する際には2桁のタグを利用するのが最善の方法です。これにより、最新のSitecoreコンテナが確保され、最新のアップデートも自動的に受け取れます。 10.X-ltsc2019のような2桁のタグを使うと、次にプルやビルド時に画像が自動的に最新のフルリリースリビジョン(例:10.X.Y)にリリーブされます。 /sxp-pre/名前空間からのプレリリース・デルタイメージは、前のフルリリースの上に適用されるように設計されています。例えば、10.X.Y PREデルタは10.X.0リリースの上に使用されることを想定しています。Sitecoreが後に対応するフルリリース(10.X.Yリリース)を公開すると、2桁タグは自動的にそれに解決されます。DockerfileからPREデルタを削除していなければ、コンテナには新しいリリースのSitecore.configが表示され、新しいプロセッサタイプを参照されます。しかし、その場合はPREデルタの古いSitecore.Kernel.dllを参照し、そのタイプは含まれていません。これにより起動失敗が発生します: System.InvalidOperationException: Could not find type 'Sitecore.Pipelines.FilterItem.ResolveModeFromContext, Sitecore.Kernel' 正式リリースにはすでにPREデルタのすべての修正が含まれているため、正式リリースが利用可能になった時点でデルタは不要になります。 これを解決するために、以下のいずれかの選択肢を選びます。 - *フルリリースにアップグレードしてください* — .envファイルからDELTA\_ASSET\_IMAGE\_VERSIONエントリとPREデルタイメージに対応するDockerfile命令を削除してください。その後、キャッシュされたアセンブリが持ち込まれていないことを確認するためにdocker-compose build --no-cacheを使って再構築します。下の表で目標リリースに適した正しいSitecore.Kernel.dllバージョンを確認してください。 - *前のリリースに留* まり、3桁のタグ(例: 10.X.0-ltsc2019)を使って前のフルリリースにピン留めてください。PREデルタはこのバージョンと互換性があり、削除の必要はありません。 もし10.X.Yにアップグレードするなら、Sitecore Experience Platform[ダウンロードページ](https://developers.sitecore.com/downloads/Sitecore_Experience_Platform)から更新されたSitecoreContainerDeployment.10.X.Y.\*ファイルもダウンロードしてください。古いデプロイファイルを使用すると、イメージが見つからないエラー(例:sitecore-idX:10.X.Y-ltsc2019 not found)が発生します。 ## 最新の画像を引き出す Sitecoreのイメージショートタグを使うと、Dockerは画像ダイジェスト(不変のSHA256ベースの識別子)をプル時にキャッシュし、画像を削除するか明示的にプルするまで使用し続けます。必要なときに最新のイメージを取得するようにしてください(例えばローカル開発やCI環境など)。 [推奨されるDocker Compose設定](https://doc.sitecore.com/xp/ja/developers/103/developer-tools/build-sitecore-solutions.html "Build Sitecore solutions")では、オーバーライドを除き、ほとんどのことはdocker-compose pullコマンドで行えます。 docker-compose -f docker-compose.yml pull このコマンドは最新のベースSitecoreとTraefik画像を自動取得します。ただし、ビルド目的で使う画像(モジュールやツール用のアセットイメージなど)はプルされません。残念ながら、[Docker Composeの問題や制限](https://github.com/docker/compose/issues/6668)によりdocker-compose build --pullは現在できません。そのため、これらの画像は個別に(docker pull付き)を取得するか、タグを全て使う必要があります。 最新の画像を引っ張り忘れがちなため、通常はこれらのコマンドを自動化します。これはCIビルドスクリプトやローカル開発用のカスタム *アップ* スクリプトに追加することで可能です。