Managed Cloudへのデプロイ
このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。
Managed Cloudは、クラウド ネイティブ アプリケーションの継続的デプロイを実装する方法であるGitOpsの使用をサポートしています。GitOpsでは、デプロイを制御するGitリポジトリを通じてすべてのデプロイを管理する必要があります。各リポジトリにはリポジトリの構成要素が含まれており、デプロイメントへの変更は、リポジトリ内の適切な構成ファイルを変更して行う必要があります。Gitリポジトリを使用すると、信頼性が向上し、さらにGitの機能を利用して、pull requestを通じてチームのレビューと承認のメカニズムをサポートし、デプロイの履歴内の以前の状態に変更をロールバックする機能を利用できます。
Azure portalを使用して非運用デプロイを手動で再構成することもできますが、次回ソリューションを再デプロイすると、変更は失われます。手動による変更は、設定ファイルに取り込まれません。
本番環境のデプロイメントは、次の2つのリポジトリ の設定を変更することによってのみカスタマイズ できます。
リポジトリとパイプラインはどちらも、Sitecoreによるデプロイメントの初期プロビジョニングで日常的に使用されます。
次の図は、インフラストラクチャ リポジトリ、アプリケーション リポジトリ、および一般的なマネージド クラウド デプロイの主要な要素の多くとの主な関係を示しています。
インフラ
インフラ
Infrastructureリポジトリには、デプロイ用のインフラストラクチャ要素(Frontdoorを含む)の構成が、Terraform構成ファイルのセットとして含まれています。
インフラストラクチャパイプライン
Infrastructureパイプラインは、Terraformを使用して構成を読み取り、デプロイメントのすべての要素を同期して、構成ファイルの設定に一致させます。パイプラインが正常に実行されると、Terraform状態ファイルがAzure Storageアカウントに格納されます。
ストレージ ファイルまたはストレージ アカウントは削除しないでください。 Terraform stateファイルは、Infrastructureパイプラインの実行中にデプロイメントをロックするために使用され、Terraformデプロイメントに必要です。
リポジトリの既存のインフラストラクチャ要素のカスタマイズ、スケーリング、またはチューニングの詳細については、Managed Cloudの構成 のトピックを参照してください。
Frontdoorパイプライン
Frontdoorパイプラインは、Terraformスクリプトをデプロイして構成を読み取り、デプロイメントのすべての要素を構成ファイルの設定と一致するように同期します。パイプラインが正常に実行されると、Frontdoor Terraform状態ファイルがAzure Storageアカウントに格納されます。Frontdoor構成を更新したら、Frontdoorパイプラインを手動でトリガーする必要があります。
アプリケーション
アプリケーション
Applicationリポジトリには、デプロイメントで使用されるすべてのコンテナの設定が含まれています。Applicationパイプラインでは、Ansibleスクリプトを使用して、実行中の各コンテナーを含むAKSポッドを設定します。
Applicationリポジトリを使用して、SitecoreソリューションとManaged Cloudインスタンスをカスタマイズする必要があります。アプリケーション要素を使用してカスタマイズされたコンテナをビルドし、それらをACRにアップロードし、新しいカスタマイズしたイメージを使用するように参照を変更する必要があります。
各コンテナを実行する既存のKubernetesポッドのカスタマイズ、スケーリング、またはチューニングの詳細については、Managed Cloudの設定 のトピックを参照してください。
カスタム ソリューションの構築とカスタム イメージの作成の詳細については、DevEx Containers Documentationの「 Sitecoreソリューションの構築 」のトピックを参照してください。
カスタム ソリューションとイメージをビルドしてデプロイするためのCI/CDパイプラインの構築の詳細については、Dockerと継続的インテグレーションのトピックを参照してください。