1. Managed Cloud Standard

Managed Cloudの設定

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

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

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

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

Azure Kubernetesサービス(AKS)クラスターサイズ、SQLデータベース、Azureコンテナレジストリ(ACR)の階層サイズをカスタマイズしたいかもしれません。

Azureコンポーネントのサイズ管理:

  1. インフラストラクチャリポジトリでは、以下へ行きます: .\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仮想マシンにデプロイします。

    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コマンドを追加します:

    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制限です。

非本番環境には通常の仮想マシンを使用してください

デフォルトでは、非本番環境ではAzure KubernetesサービスはRegularインスタンスタイプの仮想マシンを使用します。通常のインスタンスが非本番環境に適さないと判断した場合は、WindowsノードタイプをSpotに切り替える必要があります。通常の仮想マシンよりも安価で、いつでも追放可能です。これにより、スポットインスタンスは非本番環境のテスト環境には理想的ですが、本番環境にはあまり適していません。

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

  • config/resources/resources.jsonに行き、windows_node_priorityをSpotに変更してください。

    Windows node priority in resources.json

カスタム画像を追加してください

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

Private ACRに画像を追加するには:

  1. 既存のSitecoreイメージを基に新しいバージョンの画像を作成します。

  2. イメージをPrivate ACRにプッシュしてください。

  3. docker-images.jsonファイルを新しいイメージで更新してください。

    !重要docker-images.jsonを変更するには、メインにプルリクエストを作成する 必要があります。

外部画像の更新

外部画像の更新:

  • 新しい画像バージョンで更新 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ファイルの構造は以下の通りです:

{ ... "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モジュールを作成する必要があります。これは単一のディレクトリ内のTerraform設定ファイルのセットです。

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

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

  1. インフラストラクチャリポジトリにアクセスし、モジュール用の新しいフォルダを作成します。例えば: .\modules\log-analytics-workspace。

  2. 新しいフォルダで、リソースの説明とモジュール名を記載したmain.tfを作成します:

    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を作成します:

    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を編集し、新しいモジュールを追加し、目的の変数値を渡します:

    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

位相サイズを変更するには:

  • インフラストラクチャリポジトリで .\sku\resources.{size}.json コピーし、ファイル名を resources.jsonに変更します。

Sitecore管理者の認証情報を変更する

Sitecoreのインストールを展開する前に、管理者パスワードを強力なパスワードに変更する必要があります。これらの認証情報を変更した後は、Azure Key Vault内の以下の秘密を更新する必要があります。

  • Sitecore管理者ユーザー名: sitecore-admin-username
  • Sitecore 管理者パスワード: sitecore-admin-password
この記事を改善するための提案がある場合は、 お知らせください!