Sitecore開発のコンテナ
このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。
このトピックでは、コンテナ、Docker、およびSitecoreでの開発時にDockerを使用する方法について簡単に説明します。
コンテナとは?
コンテナは、コードがライブラリや依存関係とともにパッケージ化されたソフトウェアの実行可能ユニットであるため、開発者のワークステーション、オンプレミスサーバー、クラウドなど、どこでも実行でき、ターゲット環境に関係なく簡単かつ一貫してデプロイできます。
アプリケーションのコンテナ化により、開発者はアプリケーションロジックと依存関係に集中し、デプロイメントチームはデプロイメントと管理に集中するため、懸念事項が明確に分離されます。
コンテナ化の主な利点は次のとおりです。
-
Lightweight - ディスク上のサイズが小さく、オーバーヘッドが非常に少ない。
-
Isolation - コンテナは、アプリケーションを相互に分離するだけでなく、基盤となるシステムからも分離します。固有の制約は、コンテナがデフォルトで安全であることを意味します。
-
Portability - コンテナは、コンテナのランタイム環境をサポートする任意のマシンで実行されます。ローカルで構築し、オンプレミス環境やクラウド環境に簡単に移行できます。
-
Loose coupling - コンテナは高度に自己完結し、カプセル化されているため、他のコンテナを中断することなく、1つのコンテナを交換またはアップグレードできます。
-
Scalability - コンテナは軽量で疎結合であるため、新しいコンテナを作成することで迅速にスケーリングできます。
コンテナと仮想マシンの違い
ハードウェアスタックを仮想化する代わりに、コンテナはオペレーティングシステムレベルで仮想化され、複数のコンテナがオペレーティングシステムカーネル上で直接実行されます。これは、コンテナがはるかに軽量であることを意味します: カーネルを共有し、より高速に起動し、オペレーティングシステム全体を起動する場合と比較して、メモリのほんの一部しか使用しません。
より詳細な比較については、「 コンテナーと仮想マシン」を参照してください。
Dockerとは何ですか?
コンテナは数年前に初めて登場しましたが、2013年のDockerの導入により、最新のコンテナ開発が加速しました。
Dockerは、コンテナ上にアプリケーションを構築するための オープンソースプロジェクト であると同時に、この技術を推進し進化させる 企業 でもあります。また、Dockerの公式レジストリであるDocker Hubも所有しています。Dockerは、コンテナの普及に非常に成功しているため、コンテナの代名詞となっています。DockerはもともとLinux用に構築されていましたが、現在はWindowsとMacOSでも動作します。
Sitecoreでは、コンテナ テクノロジーは常にDockerです。
用語
Dockerとコンテナは特定の用語を使用します。使用される用語の一部を次に示します。
-
Image - コンテナを作成するための青写真として機能するすべてのコードと依存関係を含むパッケージ。多くの場合、イメージは別のイメージに基づいており、さらにカスタマイズが加えられています。イメージは、一度作成されると不変です。
-
Dockerfile - Dockerイメージをアセンブルするための手順を含む テキスト ドキュメント形式 。このファイルは、Docker CLIビルド コマンド によってイメージをビルドするために使用されます。
-
Registry - 画像を保存する場所。これは、パブリック (Docker Hub) またはプライベート (Azure Container Registry) のいずれかです。レジストリには、1つ以上のリポジトリが含まれています。
-
Repository- 同じ名前の画像のコレクションで、バージョンまたはバリアントを示すタグが付けられています。イメージ参照では、リポジトリは最後のコロンの前の部分です (例: mcr.microsoft.com/windows/servercore:ltsc2019のmcr.microsoft.com/windows/servercore )。
-
Tag- リポジトリ内の特定のイメージへの参照。画像参照では、これは最後のコロンの後の部分であり、バージョン番号やアーキテクチャのバリアント (mcr.microsoft.com/windows/servercore:ltsc2019のltsc2019など) によく使用されます。タグを指定しない場合、Dockerはデフォルトでタグ名latestになります。
-
Container - イメージのインスタンス。これは、Dockerイメージの内容、実行環境、および標準の命令セットで構成されます。
-
Compose - Dockerによって作成されたCLIツールと (YAMLベースの) テキストドキュメント形式 。これを使用して、マルチコンテナアプリケーションの実行方法を定義します。定義を作成したら、1つのコマンド (docker-compose up) でマルチコンテナ・アプリケーション全体をデプロイできます。このコマンドは、イメージごとにコンテナです。
-
Orchestrator - コンテナの管理ツール。これは、本番環境でのコンテナのデプロイと管理に役立ちます。 Kubernetesは最も使用されており、Azure Kubernetes Service (AKS) を通じてMicrosoftによって十分にサポートされています。
コンテナベースのSitecore開発
コンテナの使用がSitecoreの開発にとって魅力的である理由はいくつかありますが、Sitecoreがマイクロサービスベースのアーキテクチャに移行するにつれて、コンテナの使用はさらに魅力的になります。コンテナは、このアーキテクチャに非常に適しています(実際、それを奨励しています)。
その他の理由は次のとおりです。
-
No install - SIF (Sitecore Installation Framework)、SIM (Sitecore Instance Manager) などを使用したインストールは行いません。Sitecoreは、すぐに使用できるコンテナ イメージを提供します。 docker-compose upを使用してインスタンスを稼働させることができ、コンテナイメージは自動的にダウンロードされます。
-
Multi-project efficiencies - SQLとSolrのバージョンが競合するなどを心配することなく、複数のSitecoreインスタンスを同時に実行できます。プロジェクト間をジャンプするときに、インスタンス全体をすばやく開始および停止できます。
-
Simplified onboarding - オンボーディングプロセスは、前提条件のインストール、コードリポジトリのクローン作成、docker-compose upの実行と同じくらい簡単です。
-
Environment consistency - 環境の不整合による問題を排除します。ビルドをコンテナ化すると、ビルド環境を完全に制御できます。
-
Environment stability - コンテナは不変であるため、ローカルのSitecoreインスタンスを台無しにすることを心配する必要はありません。 docker-compose downとdocker-compose upを使用して、再び稼働を再開します。
Sitecoreの開発者には多くのメリットがあります。ただし、組織にとっては、他の考慮事項があります。コンテナとDockerがチームに適しているかどうかを判断するには、Sitecoreナレッジ センターのこの記事を参照してください。
Sitecoreの画像
Sitecoreバージョン10.0以降、すべてのロールとトポロジのコンテナ イメージは、Sitecore Container Registry (SCR) のscr.sitecore.comで利用できます。
以前のバージョンのSitecoreでは、docker-imagesコミュニティ リポジトリを使用できます。これには、最初にイメージをビルドする必要があるため、より多くの作業が必要ですが、プロセスはスクリプト化されており、十分に文書化されています。バージョン10.0より前のコンテナのサポートについては、このナレッジベースの記事 を参照してください。
Sitecore Dockerリソース
コンテナのドキュメントでは、次のリソースを参照および使用しています。
-
Dockerの例 - コンテナ開発に推奨される構造を持つVisual Studioソリューションの例と、さまざまなトポロジでSitecoreインスタンスを構築するためのDocker作成ファイルを含むリポジトリ。
-
Helix Examples - Sitecore 10 with Dockerコンテナ用に更新された、Sitecore Helixに焦点を当てた同じサンプル リポジトリ。
参考資料
Sitecoreナレッジ センター:
Dockerのドキュメント:
Microsoftのドキュメント:
Dockerの詳細なラボ:
Pluralsightには、大量のDockerコンテンツがあります。