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

概要

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

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

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

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

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

  • 軽量 - ディスク上のサイズが小さく、オーバーヘッドが非常に少ない。

  • 分離 - コンテナーは、アプリケーションを互いに分離するだけでなく、基盤となるシステムからも分離します。固有の制約は、コンテナーがデフォルトで安全であることを意味します。

  • 移植性 - コンテナーは、コンテナーのランタイム環境をサポートする任意のマシンで実行されます。ローカルで構築してから、オン プレミスまたはクラウド環境に簡単に移行できます。

  • 緩い結合 - コンテナーは高度に自己充足的でカプセル化されているため、他のコンテナーに影響を与えることなく、あるコンテナーを交換したりアップグレードできます。

  • スケーラビリティ - コンテナーは軽量で疎結合であるため、新しいコンテナーを作成することで迅速にスケーリングできます。

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

The difference between containers and virtual machines.

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

コンテナーが最初に登場したのは数年前ですが、最新のコンテナー開発は 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:ltsc2019mcr.microsoft.com/windows/servercore のようになります。

  • タグ - リポジトリ内の特定の画像への参照。画像参照では、これは最後のコロンの後の部分であり、バージョン番号やアーキテクチャのバリアントによく使用されます。たとえば、mcr.microsoft.com/windows/servercore:ltsc2019ltsc2019 です。タグを指定しない場合、Docker はデフォルトでタグ名 latest となります。

  • コンテナー - イメージのインスタンス。これは、Docker イメージのコンテンツ、実行環境、および標準の命令セットで構成されています。

  • Compose - Docker 社が開発した CLI ツールと (YAML ベースの) テキスト文書形式です。これを使って、マルチ コンテナー アプリケーションの実行方法を定義します。定義を作成した後、1 つのコマンド (docker-compose up) でマルチ コンテナー アプリケーション全体をデプロイすることができます。このコマンドは、イメージごとのコンテナーです。

  • Orchestrator - コンテナーの管理ツール。本番環境でコンテナーをデプロイおよび管理するのに役立ちます。Kubernetes が最もよく使用されており、Microsoft でも Azure Kubernetes サービス (AKS) を通じて十分にサポートされています。

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

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

  • インストールなし - SIF (Sitecore Install Framework)、SIM (Sitecore Instance Manager) などを使用したインストールなし。Sitecore は、すぐに使用できるコンテナー イメージを提供します。docker-compose up でインスタンスを起動して実行でき、コンテナー イメージが自動的にダウンロードされます。

  • マルチ プロジェクトの効率性 - SQL と Solr のバージョンの競合などを心配することなく、複数の Sitecore インスタンスを同時に実行できます。プロジェクト間をジャンプするときに、インスタンス全体をすばやく開始および停止できます。

  • 簡素化されたオンボーディング - 前提条件をインストールし、コード リポジトリのクローンを作成して docker-compose up を実行するだけで簡単にオンボーディングできます。

  • 環境の一貫性 - 環境の不一致による問題を排除します。ビルドをコンテナー化すると、ビルド環境を完全に制御できます。

  • 環境の安定性 - コンテナーは変更できないため、ローカルの Sitecore インスタンスを台無しにする心配はありません。使用するdocker-compose downdocker-compose up を使用して、再起動することができます。

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

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

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

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

  • Docker の例 - コンテナー開発に推奨される構造の Visual Studio ソリューションの例と、さまざまなトポロジで Sitecore インスタンスを構築するための Docker 構成ファイルを含むリポジトリ。

  • Helix.Examples - 同じ Sitecore Helix - に特化したサンプル リポジトリを、Docker コンテナーを使って Sitecore 10 用に更新したものです。