Managed Cloudの構成

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

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

このトピックでは、Managed Cloudコンテナ ソリューションをスケーリング、サイズ設定、および調整する方法について説明します。インフラストラクチャとアプリケーションのリポジトリで設定ファイルを見つけて操作する方法について説明します。

Azureコンポーネントのサイズを管理する

Azure Kubernetes Service (AKS) クラスター サイズ、SQLデータベース、Azure Container Registry (ACR) レベル サイズをカスタマイズすることができます。

Azureコンポーネントのサイズを管理するには:

  1. Infrastructureリポジトリで、次の場所に移動します。 .\config\resources\resources.json

    resources.json example

  2. AKSクラスター サイズ、SQLデータベース、ACR階層のサイズを管理するには、次のパラメーターを更新します。

    パラメーター

    形容

    windows_vm_size

    Windows VMのAKSサイズ。

    windows_scaled_vm_size

    WindowsスケーリングされたVMサイズ。Content DeliveryポッドとXDBCollectionポッドのより効率的なスケーリングに使用されます。

    windows_node_count

    Windowsノードの量。インプレース ノード アップグレードをサポートするには、少なくとも2つのWindowsノードが必要です。

    windows_scaled_node_count

    スケーリングされたリソースのWindowsノードの量。一部のSKUレベルでは0に設定できます。値が0の場合、スケーリングされたポッド (cdおよびxdbコレクション) は通常のWindows VMにデプロイされます。

    linux_node_count

    Linuxノードの数。

    windows_node_priority

    Windowsのノード優先度。運用シナリオでは、常にregularを使用します。

    size_gb

    SQLプール サイズ (GB)。

    sku_capacity

    SQLプールSKUの容量。

    sku_name

    SQLプールSKU名。

    sku_family

    SQLプールSKUファミリ。

    sku_tier

    SQLプールSKUレベル。

    SKUの

    ACRレベルのサイズ。

AKSのメンテナンス期間をスケジュールする

計画メンテナンスを使用して、AKSクラスターのメンテナンス期間をスケジュールできます。計画メンテナンスを使用すると、毎週のメンテナンスウィンドウをスケジュールし、ワークロードへの影響を最小限に抑えることができます。スケジュールが設定されると、すべてのメンテナンスは選択した期間中に行われます。

メンテナンスウィンドウを追加するには:

  • Azure CLIで、az aks maintenanceconfigurationコマンドを追加します。

    RequestResponse
    az aks maintenanceconfiguration add -g MyResourceGroup --cluster-name myAKSCluster --name default --weekday Monday  --start-hour 1

AKSポッドのチューニング制限

AKSクラスター内のすべてのSitecoreデプロイ ポッドの制限を管理できます。

AKSポッドの制限を調整するには:

  1. アプリケーション リポジトリで、.\config\resources\resources.jsonを開きます。AKSクラスターで実行されているすべてのポッドの一覧を確認できます。例えば：

    Pods in resources.json example

  2. ポッドを調整するには、次のパラメーターを更新します。

    パラメーター

    形容

    レプリカ

    Sitecoreレプリカの数。

    request_memory

    デフォルトのポッドメモリ。

    request_cpu

    デフォルトのポッドCPU。

    limit_memory

    ポッドの最大メモリ制限。

    limit_cpu

    ポッドの最大CPU制限。

非運用環境では、通常のVirtual Machinesを使用します

既定では、非運用環境の場合、Azure Kubernetes ServiceはVirtual MachinesのRegularインスタンスの種類を使用します。通常のインスタンスが非本番環境の設定に適していないと思われる場合は、WindowsノードタイプをSpotに切り替える必要があります。通常の仮想マシンよりも安価で、いつでも削除できます。これにより、スポットインスタンスは非本番環境のテスト環境には理想的ですが、本番環境にはあまり適していません。

Windowsノード タイプをRegularからSpotに切り替えるには:

  • config/resources/resources.jsonに移動し、windows_node_priorityをSpotに変更します。

    Windows node priority in resources.json

カスタム画像を追加する

カスタム イメージを保存するために、SitecoreはプライベートAzure Container Registry (ACR) を使用します。プライベートACRは、Sitecore Managed Cloud Infrastructureの一部として作成されます。

プライベートACRにイメージを追加するには:

  1. 既存のSitecoreイメージに基づいて、イメージの新しいバージョンをビルドします。

  2. 画像をプライベートACRにプッシュします。

  3. docker-images.jsonファイルを新しいイメージで更新します。

    大事な

    docker-images.jsonを変更するには、mainへのプルリクエストを作成する必要があります。

外部イメージの更新

外部イメージを更新するには:

  • 新しいイメージバージョンでdocker-images.jsonを更新します。

アプリケーション パイプラインは自動的に実行され、メイン ブランチが更新されるとすぐにファイルから新しいイメージが適用されます。

アプリケーション パイプラインを実行して新しいイメージをデプロイする

アプリケーション パイプラインは、一連のイメージを使用してSitecore環境をデプロイします。すべてのイメージの名前と場所は、Applicationリポジトリ .\config\docker-images\docker-images.jsonファイルで指定されます。SitecoreはAnsibleを使用してDockerコンテナ イメージをデプロイします。デプロイするために、Ansibleは次の場所にあるdocker-images.jsonファイルからイメージを収集します。

application\config\docker-images.json

このファイルには、Sitecoreアプリケーションのデプロイに必要なイメージのリストが含まれています。

docker-images.jsonファイルの構造は次のとおりです。

RequestResponse
{
  ...
  "sitecore": {
    "sitecore role name": "{image repository}/{role name}:{image tag}"
  }
  ...
  "entity name": {
     "image name": "{image repository}/{role name}:{image tag}"
   } 
  ...
}

Sitecoreイメージを更新するには:

  • application\config\に移動し、docker-images.jsonファイルを開きます。既存のロールを、既存のベースSitecoreイメージに基づくカスタム イメージに置き換えることができます。

新しいインフラストラクチャ モジュールを追加する

Azureで新しいリソースを作成するには、カスタム インフラストラクチャ モジュールを追加します。インフラストラクチャ・モジュールを追加するには、新しいTerraformモジュール(1つのディレクトリにterraform構成ファイルのセット)を作成する必要があります。

新しいインフラストラクチャモジュールを追加するには:

この例では、Azure Log Analyticsワークスペース モジュールをデプロイします。同様の手順を使用して、任意のAzureリソースをデプロイできます。

  1. Infrastructureリポジトリに移動し、モジュール用の新しいフォルダを作成します (例: .\modules\log-analytics-workspace)。

  2. 新しいフォルダーに、リソースの説明とモジュール名を含むmain.tfを作成します。

    RequestResponse
    resource "azurerm_log_analytics_workspace" "alaw" {
  name                = var.alaw_name
  location            = var.location
  resource_group_name = var.resource_group_name
  sku                 = var.sku
  retention_in_days   = var.retention_in_days
}

  3. 新しいフォルダーに、変数リストを使用してvariables.tfを作成します。

    RequestResponse
    variable "location" {
  type = string
}

variable "resource_group_name" {
  type = string
}

variable "alaw_name" {
  type = string
}

variable "sku" {
  type = string
  default = "PerGB2018"
}

variable "retention_in_days" {
  type = string
  default = 30
}

  4. ルート フォルダーで、元の .\main.tfを編集し、新しいモジュールを追加して、目的の変数値を渡します。

    RequestResponse
    Module "alaw" {
  count               = 1
  source              = "./modules/log-analytics-workspace"
  location            = local.location
  resource_group_name = var.resource_group_name
  alaw_name           = "${local.infrastructure_id}alaw"
}

  5. プルリクエストを完了すると、Infrastructureパイプラインが自動的に実行され、変更が適用されます。

    または、ブランチからInfrastructureパイプラインを実行することもできますが、これにより変更は適用されず、計画された変更のみが表示されます。

Sitecoreトポロジ サイズの変更

デフォルトでは、すべてのパラメーターは元のSitecoreトポロジ サイズに基づいて設定されます。 .\sku\ フォルダーには、事前定義されたSitecoreトポロジ サイズのセットがあります。これらの設定ファイルを使用して、トポロジサイズをスケーリングできます。

メイン ブランチに変更をコミットするとすぐに、InfrastructureまたはApplicationパイプラインが自動的にトリガーされ、ファイルからの変更が適用されます。新しいトポロジ サイズを適用する必要がある場合は、まずインフラストラクチャ リポジトリで関連する変更を行います。インフラストラクチャ パイプラインが正常に完了するまで待ってから、必要な変更をアプリケーション リポジトリに適用します。.\config\resources\resources.json

トポロジ・サイズを変更するには、次のようにします。

  • Infrastructureリポジトリで、.\sku\resources.{size}.jsonをコピーし、ファイルの名前をresources.jsonに変更します。

Sitecore管理者の資格情報を変更する

Sitecoreインストールをデプロイする前に、管理者パスワードを強力なパスワードに変更する必要があります。これらの資格情報を変更した後、Azure Key Vaultで次のシークレットを更新する必要があります。

  • Sitecore管理者のユーザー名: sitecore-admin-username

  • Sitecore管理者パスワード: sitecore-admin-password

何かフィードバックはありますか?

この記事を改善するための提案がある場合は、