紹介
昨年、Sitecoreは、コンテナ内での製品の実行に対する限定的なサポートを発表しました。現在のサポートモデルの詳細については、こちらをご覧くださいナレッジベース記事.今後のバージョンごとに、コンテナで製品を実行するためのサポートを増やす予定です。この方法でアプリケーションを実行するのが初めての人のために、この投稿では、いくつかの主要な概念の概要を説明し、それぞれについてさらに学習するためのリンクを提供します。
これらの概念のデモを含む、この記事に付属するビデオをご覧ください。または、で視聴してください Discover Sitecore YouTubeで。
ソフトウェア開発、デプロイ、ホスティングにおける一般的な問題
- 必要なすべての依存関係を持つ新しいプロジェクトをマシンにセットアップするのに問題があったことはありますか?
- それでは、すべてのノンプログラミング環境とプロダクション環境でこれらの依存関係を管理するのはどうですか?
- これらの依存関係の 1 つ以上をアップグレードする必要がある場合はどうなりますか?
- 依存関係の 1 つのバージョンに対して誤って開発を行った後、別のバージョンがプロダクションで稼働していることに気付いたことはありませんか?
- 異なるオペレーティングシステム(OS)を実行したい開発者とチームを組むのはどうですか?
- ここでの問題は、アプリケーションだけを単独でデプロイし、依存関係の提供をホスト環境に依存していることです。実際には、ホストは OS に対して責任を負うべきであり、それ以外はあまり責任を負いません。
これらすべての問題に共通しているのは、一貫性、分離性、再現性の問題です。これらは、Docker、およびコンテナ全般が解決するために作成された問題です。
コンテナが救いの手を差し伸べます!
コンテナーをデプロイすると、実際には、そのアプリケーションを実行するために必要なすべてのものが 1 つの成果物内にデプロイされます。
画像からわかるように、アプリケーションだけでなく、依存関係とライブラリ、構成アセット、および実行する必要があるその他のものもパッケージ化しています。すべてが 1 つのアセットにうまくまとめられており、異なる環境間を移動できます。
コンテナと仮想マシン
よくある質問の 1 つは、コンテナと仮想マシンの違いです。提供する機能には重複する部分がありますが、それを実現する方法は根本的に異なります。
左側の仮想マシン図を見ると、緑色のボックスはそれぞれ OS 全体を表しています。つまり、そのホスト インフラストラクチャには 4 つの完全なオペレーティング システムが存在するため、必要なシステム リソースとディスク領域に大きな負荷がかかる可能性があります。
これを右側のコンテナベースのアプローチと比較してください。ここでは、ホストオペレーティングシステムのカーネルとリソースは、Dockerデーモンを介してコンテナによって直接共有されます。つまり、コンテナは仮想マシンよりもはるかに軽量であり、同じ量のハードウェアではるかに多くのコンテナを実行できます。
画像とレイヤー
これで、前の例で示したコンテナは、イメージから作成されています。イメージは、Docker コンテナを作成するための手順を含む読み取り専用テンプレートです。画像自体はレイヤーの概念に基づいて構築され、各レイヤーはその下のレイヤーに基づいて構築されます。この概念は、既存の画像をカスタマイズしてカスタム機能を構築することを非常に簡単にすることを意味します。
上の画像を見ると、Sitecore® Experience Platform™ (XP) イメージが 4.8-windowsservercore-ltsc2019 イメージの上に構築されていることがわかります。Microsoft がリリースした Windows Server Core イメージを取得し、その上にカスタム レイヤーを追加して Sitecore コードを含めます。これは、コンテンツ管理 (CM) ロールまたはコンテンツ配信 (CD) ロールを構築するためのイメージである可能性がありますが、概念は同じです。
その後、その Sitecore XP イメージをその上に構築して、さらに機能を提供することもできます。上の中央の画像は、XP イメージを取得し、その上に Sitecore PowerShell 拡張機能 (SPE) を重ねたものです。右の図は、これをさらに一歩進めて、作成したばかりの SPE イメージを使用し、その上に Sitecore Experience Accelerator (SXA) のレイヤーを追加しています。
階層化アプローチの強力な概念は、これらのレイヤーが共有されることです。そのため、最初に使用した Windows Server Core イメージは、ディスク上に 1 回だけ存在する必要があり、上記の 3 つのイメージはすべてその上に構築されます。
Docker、そのユースケース、およびアプリケーションアーキテクチャの概要は、次のURLで読むことができます。Dockerのドキュメント.
レジストリ
これらの画像がもともとどこから来たのか疑問に思われるかもしれません。まあ、それらはレジストリに保存されています — 公開または非公開のレジストリを持つことができます。最も人気のあるパブリック レジストリは Docker Hub です。そこには、考えられるほぼすべての最新のソフトウェアの画像を見つけることができます。イメージをローカル マシンに降ろすには、Docker pull コマンドを使用します。
docker pull mcr.microsoft.com/dotnet/samples:dotnetapp
このコマンドは、dotnetapp タグを持つ mcr.microsoft.com/dotnet/core/samples イメージをプルダウンします。プルダウンされたら、ローカルで使用して、それに基づいてコンテナを作成できます。これを行うには、単純なDocker実行コマンドを使用します。
docker run mcr.microsoft.com/dotnet/samples:aspnetapp
レジストリの詳細については、以下をご覧ください。Dockerのドキュメント.
ボリューム
ボリュームは、コンテナを扱う際のもう1つの重要な概念です。ホストとコンテナ間でファイルを共有すると便利な場合が多くあります。これの良い例をいくつか紹介します。
- 静的アセットを操作する場合、イメージを再構築してコンテナを再作成して変更を確認することは望ましくありません。
- イメージに含めたくないシークレットファイル(ライセンスファイルなど)を操作する場合。
この問題を解決するためにボリュームが作成されます — ホストマシン上のフォルダをコンテナ内で共有し、利用可能にするように指定できます。これは強力な機能で、ボリュームの内容に加えた変更は即座にコンテナ内に反映されます。
ボリュームの詳細については、Dockerのドキュメント.
ネットワーキング
ここで取り上げる最後の重要な概念は、ネットワーキングです。Dockerコンテナとサービスが非常に強力である理由の1つは、Dockerデーモンによって作成された内部ネットワークでそれらを接続できることです。この良い例は、SQL Server バックエンドを持つ .NET Core アプリケーションで構成されるシステムです。このシナリオでは、.NET Core アプリケーションと SQL Server を含む 2 つのコンテナーを立ち上げ、Docker で 2 つのコンテナー間にネットワークを作成して、相互に通信できるようにすることができます。
ネットワーキングの詳細については、以下をご覧ください。Dockerのドキュメント.
参考資料
Docker の Web サイトには、アプリケーション開発に Docker を使用して稼働させるための優れたチュートリアルのセットがあります。
- https://docs.docker.com/get-started/
- https://docs.docker.com/get-started/part2/
- https://docs.docker.com/get-started/part3/
読んでくれてありがとう、そして今後のコンテンツのために #LearnSitecore をフォローしてください!
ロブ・アーラム氏、テクニカルエバンジェリスト、Sitecore
https://robearlam.com/