Sitecore 開発におけるコンテナー

Version: 10.2

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

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

このトピックでは、コンテナーと Docker についての概要と、Sitecore での開発に Docker を使用する方法について説明します。

コンテナーとは

コンテナーは実行可能なソフトウェアの単位で、コードはライブラリや依存関係とともにパッケージ化されており、開発者のワークステーション、オンプレミスのサーバー、クラウドなど、どこでも実行でき、ターゲット環境に関係なく簡単かつ一貫してデプロイできるようになっています。

アプリケーションをコンテナー化することで、開発者はアプリケーションロジックと依存関係に集中し、デプロイメントチームはデプロイと管理に集中することができ、懸念事項を明確に分離することができます。

コンテナー化の主な利点は次のとおりです。

軽量 - ディスク上のサイズが小さく、オーバーヘッドが非常に少ない。
分離 - コンテナーは、アプリケーションを互いに分離するだけでなく、基盤となるシステムからも分離します。固有の制約は、コンテナーがデフォルトで安全であることを意味します。
移植性 - コンテナーは、コンテナーのランタイム環境をサポートする任意のマシンで実行されます。ローカルで構築してから、オンプレミスまたはクラウド環境に簡単に移行できます。
緩い結合 - コンテナーは高度に自己充足的でカプセル化されているため、他のコンテナーに影響を与えることなく、あるコンテナーを交換したりアップグレードできます。
スケーラビリティ - コンテナーは軽量で疎結合であるため、新しいコンテナーを作成することで迅速にスケーリングできます。

コンテナーと仮想マシンの違い

ハードウェアスタックを仮想化する代わりに、コンテナーはオペレーティングシステムレベルで仮想化され、複数のコンテナーがオペレーティングシステムカーネル上で直接実行されます。これは、コンテナーがはるかに軽量であることを意味します。オペレーティングシステム全体を起動する場合と比較して、コンテナーはカーネルを共有し、起動が速く、メモリの使用量はごくわずかです。

The difference between containers and virtual machines.

より詳細な比較については、「コンテナーと仮想マシン」を参照してください。

Docker とは?

コンテナーが最初に登場したのは数年前ですが、最新のコンテナー開発は 2013 年の Docker の導入により加速しました。

Docker は、コンテナー上にアプリケーションを構築するためのオープンソースプロジェクトであると同時に、その技術を推進し、進化させる企業でもあります。また、Docker の公式レジストリである Docker Hub を所有しています。Docker がコンテナーの代名詞となったのは、コンテナーの普及に大成功したからです。Docker はもともと Linux 用に作られたものですが、今では Windows や MacOS でも動作するようになっています。

Sitecore では、コンテナー技術は常に Docker です。

用語

Docker とコンテナーは特定の用語を使用します。使用される用語の一部を次に示します。

イメージ - コンテナーを作成するための設計図として機能するすべてのコードと依存関係を含むパッケージ。多くの場合、画像は別の画像に基づいており、追加のカスタマイズが行われています。一度作成されたイメージは変更できません。
Dockerfile - Docker イメージを組み立てるための指示を含んだテキストドキュメント形式です。このファイルは、Docker CLI ビルドコマンドでイメージを構築する際に使用します。
レジストリ - イメージを保存する場所。これは、パブリック (Docker Hub) またはプライベート (Azure コンテナーレジストリ) のいずれかです。レジストリには 1 つ以上のリポジトリが含まれます。
リポジトリ - 同じ名前の画像を集めたもので、バージョンやバリアントを示すタグが付いています。イメージリファレンスでは、リポジトリは最後のコロンの前の部分で、たとえば、mcr.microsoft.com/windows/servercore:ltsc2019 の mcr.microsoft.com/windows/servercore のようになります。
タグ - リポジトリ内の特定のイメージへの参照。イメージの参照では、これは最後のコロンの後の部分であり、バージョン番号やアーキテクチャのバリアントによく使用されます。たとえば、mcr.microsoft.com/windows/servercore:ltsc2019 の ltsc2019 です。タグを指定しない場合、Docker はデフォルトでタグ名 latest となります。
コンテナー - イメージのインスタンス。これは、Docker イメージのコンテンツ、実行環境、および標準の命令セットで構成されています。
Compose - Docker 社が開発した CLI ツールと (YAML ベースの) テキストドキュメント形式です。これを使って、マルチコンテナーアプリケーションの実行方法を定義します。定義を作成した後、1 つのコマンド (docker-compose up) でマルチコンテナーアプリケーション全体をデプロイすることができます。このコマンドは、イメージごとのコンテナーです。
Orchestrator - コンテナーの管理ツール。本番環境でコンテナーをデプロイおよび管理するのに役立ちます。Kubernetes が最もよく使用されており、Microsoft でも Azure Kubernetes サービス (AKS) を通じて十分にサポートされています。

コンテナーを使った Sitecore の開発

コンテナーの使用が Sitecore 開発にとって魅力的な理由はいくつかあります。Sitecore がマイクロサービスベースのアーキテクチャに移行するにつれて、コンテナーの使用はさらに魅力的になります。コンテナーは、このアーキテクチャに非常に適しています (実際、コンテナーを推奨しています)。

その他の理由は次のとおりです。

インストールなし - SIF (Sitecore Install Framework)、SIM (Sitecore Instance Manager) などを使用したインストールなし。Sitecore は、すぐに使用できるコンテナーイメージを提供します。docker-compose up でインスタンスを起動して実行でき、コンテナーイメージが自動的にダウンロードされます。
マルチプロジェクトの効率性 - SQL と Solr のバージョンの競合などを心配することなく、複数の Sitecore インスタンスを同時に実行できます。プロジェクト間をジャンプするときに、インスタンス全体をすばやく開始および停止できます。
簡素化されたオンボーディング - 前提条件をインストールし、コードリポジトリのクローンを作成して docker-compose up を実行するだけで簡単にオンボーディングできます。
環境の一貫性 - 環境の不一致による問題を排除します。ビルドをコンテナー化すると、ビルド環境を完全に制御できます。
環境の安定性 - コンテナーは変更できないため、ローカルの Sitecore インスタンスを台無しにする心配はありません。docker-compose down と docker-compose up を使用して、再起動することができます。

Sitecore の開発者には多くのメリットがあります。しかし、組織にとっては別の考慮事項があります。コンテナーや Docker が自分のチームに適しているかどうかを判断するために、Sitecore Knowledge Center のこの記事を参照してください。

Sitecore のイメージ

Sitecore バージョン 10.0 以降、すべてのロールとトポロジのコンテナーイメージは「Sitecore Container Registry (SCR) scr.sitecore.com」で入手できます。

Sitecore の以前のバージョンでは、docker-images コミュニティリポジトリを利用することができます。最初にイメージを構築する必要があるため、これにはより多くの作業が必要ですが、プロセスはスクリプト化されており、十分に文書化されています。バージョン 10.0 より前のコンテナーのサポートについては、このナレッジベース記事を参照してください。

Sitecore Docker リソース

コンテナーのドキュメントでは、次のリソースを参照および使用します。

Docker Examples - コンテナー開発に推奨される構造の Visual Studio ソリューションの例と、さまざまなトポロジで Sitecore インスタンスを構築するための Docker 構成ファイルを含むリポジトリ。
Helix.Examples - 同じ Sitecore Helix に特化したサンプルリポジトリを、Docker コンテナーを使って Sitecore 10 用に更新したものです。