Managed Cloudの構成

チュートリアル: Managed Cloudの更新

Version:

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

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

Managed Cloud Containersでは、最新の更新プログラムが適用されたMCCパッケージをインストールできます。これは、Managed Cloud Containersの最新の進歩に合わせて実装を最新の状態に保つための重要なプロセスです。これらの更新は、定期的なメンテナンス計画の一部として計画し、たとえば、MCCの更新時間を毎月スケジュールすることをお勧めします。

更新プログラムパッケージの内容の詳細については、リリースノートを参照してください。すべてのパッケージのリリースノートは、アップグレードパッケージ (release_notes.<mcc package version>.md) と同じ場所から入手できます。

大事な

Sitecore Managed Cloud Containersソリューションは、モジュール化されたリポジトリ構造をサポートしている場合にのみ更新できます。モジュール化された構造は、バージョン10.1.0-r.182868および10.1.1-r.182925からサポートされています。バージョンを確認するには、アプリケーションリポジトリに移動し、version.txtファイルのバージョンを確認します。以前のバージョンをお持ちの場合は、移行プロセスに従う必要があります。 solution.jsonファイルがある場合、環境は既にモジュール化された構造を使用しており、このトピックで説明するアップグレードプロセスを続行できます。

Managed Cloudソリューションを更新するには、まず更新を準備し、インフラストラクチャを更新してから、アプリケーションを更新する必要があります。

このトピックでは、次の方法について説明します。

アップデートを準備します。
インフラストラクチャを更新します。
アプリケーションを更新します。
更新を元に戻します。

更新プログラムを準備する

アップデートを準備するには:

mccsharedupgradestorageストレージアカウントに移動し、mcc-upgradesコンテナーを開いて、トポロジとSitecoreバージョンの最新のリビジョンを見つけます。

- mcc.{topology}.upgrade.{sitecore_version}-r.{revision}.nupkg

メモ

ストレージアカウントにアクセスできない場合は、DevOps Engineerアクセスのサービスリクエストを開きます。
パッケージをダウンロードして一時フォルダに解凍します。
リポジトリを見直し、カスタマイズを行ったかどうかを確認します。
- 新しいAzureリソースを追加する場合は、Add a new infrastructure moduleセクションのConfigure Managed Cloudトピックで説明されている手順に従います。
- アプリケーションリポジトリ内のカスタマイズされたファイルの場合: カスタムファイルを個別のAnsibleロールに移動します。たとえば、パブリック・サービスを追加した場合は、「パブリック・サービスの追加」トピックで説明されているプロセスに従います。監視拡張機能を追加した場合は、「カスタムPrometheusアラートの追加」トピックと「 Grafanaダッシュボードのインポートとエクスポート」トピックをお読みください。

インフラストラクチャを更新する

インフラストラクチャの更新方法は、環境にディザスターリカバリー (DR) があるかどうか、およびディザスターリカバリーの種類によって異なります。

手記

ファイルをカスタマイズした場合は、すべてのカスタム変更が異なるモジュールに分割されていることを確認してください。

DRがない環境のインフラストラクチャを更新する

DRがない環境のインフラストラクチャを更新するには:

機能ブランチを作成し、InfrastructureフォルダーのすべてのコンテンツをInfrastructureリポジトリにコピーします (次のフォルダーを除く)。
- config\resources
メインブランチに対してプル要求を作成します。競合を確認し、解決します。
config\resources\resources.jsonファイルとsku\resources.{topology-size}.jsonファイルを比較します。構造に違いがある場合は、config\resources\resources.jsonを更新します。
pipelinesフォルダーに他の新しいファイルが追加されている場合は、Azure DevOpsで新しいパイプラインを作成し、pipelinesフォルダーから新しいパイプライン .yamlファイルにリンクしてください。詳細については、パイプラインのドキュメントを参照してください。

DRベーシックコールドスタンバイがある環境のインフラストラクチャを更新する

DRベーシックコールドスタンバイがある環境のインフラストラクチャを更新するには、次のようにします。

機能ブランチを作成し、InfrastructureフォルダーのすべてのコンテンツをInfrastructureリポジトリにコピーします (次のフォルダーを除く)。
- config\resources
メインブランチに対してプル要求を作成します。競合を確認し、解決します。
config\resources\resources.jsonファイルとsku\resources.{topology-size}.jsonファイルを比較します。構造に違いがある場合は、config\resources\resources.jsonを更新します。
次のファイルに強調表示されたコードが含まれていることを確認します。
- /config/remote-mcc-modules/modules.jsonファイル:
- /pipelines/templates/infrastructure.yamlファイル:
- /main.tfファイル:
- /pipelines/scripts/enable-tls-1dot2.ps1ファイル:
- /pipelines/scripts/update-tags.ps1ファイル:
- /pipelines/update-resource-group-tags.yamlファイル:
- /pipelines/scripts/managed-identity-access.ps1ファイル:
/pipelines/infrastructure.yamlファイルに次の強調表示されたコードが含まれていることを確認します。

警告

デプロイしたディザスタリカバリタイプのタイプを確認します。DRベーシックコールドスタンバイとDRマネージドホットスタンバイの /pipelines/infrastructure.yamlファイルが異なります。デプロイしたディザスタリカバリのタイプに基づく以下の例に従っていることを確認してください。

次のスニペットをmain_override.tfファイルの下部に追加します (スニペットがまだファイル内にない場合)。

resource "azurerm_key_vault_secret" "vmss_identity_client_id" {
  count = local.is_dr_run_state ? local.hadr_config.aks.secret_count : 1
}

resource "azurerm_key_vault_secret" "redis_password" {
  count = local.is_dr_run_state ? local.hadr_config.redis.secret_count : 1
}

新しいシークレットdr-sc-typeを追加し、値はexternalです。
プルリクエストを完了します。インフラストラクチャパイプラインが実行され、変更が自動的に適用されます。
インフラストラクチャパイプラインの実行が正常に完了したことを確認します。
pipelinesフォルダーに他の新しいファイルが追加されている場合は、Azure DevOpsで新しいパイプラインを作成し、pipelinesフォルダーから新しいパイプライン .yamlファイルにリンクしてください。詳細については、パイプラインのドキュメントを参照してください。

DR管理ホットスタンバイがある環境のインフラストラクチャを更新する

DR管理ホットスタンバイがある環境のインフラストラクチャを更新するには、次のようにします。

機能ブランチを作成し、InfrastructureフォルダーのすべてのコンテンツをInfrastructureリポジトリにコピーします (次のフォルダーを除く)。
- config\resources
メインブランチに対してプル要求を作成します。競合を確認し、解決します。
config\resources\resources.jsonファイルとsku\resources.{topology-size}.jsonファイルを比較します。構造に違いがある場合は、config\resources\resources.jsonを更新します。
次のファイルに強調表示されたコードが含まれていることを確認します。
- /config/remote-mcc-modules/modules.jsonファイル:
- /pipelines/templates/infrastructure.yamlファイル:
- /main.tfファイル:
- /pipelines/scripts/enable-tls-1dot2.ps1ファイル:
- /pipelines/scripts/update-tags.ps1ファイル:
- /pipelines/update-resource-group-tags.yamlファイル:
- /pipelines/scripts/managed-identity-access.ps1ファイル:
/pipelines/infrastructure.yamlファイルに次の強調表示されたコードが含まれていることを確認します。

警告

デプロイしたディザスタリカバリタイプのタイプを確認します。DRベーシックコールドスタンバイとDRマネージドホットスタンバイの /pipelines/infrastructure.yamlファイルが異なります。デプロイしたディザスタリカバリのタイプに基づく以下の例に従っていることを確認してください。

次のスニペットをmain_override.tfファイルの下部に追加します (スニペットがまだファイル内にない場合)。

resource "azurerm_key_vault_secret" "vmss_identity_client_id" {
  count = local.is_dr_run_state ? local.hadr_config.aks.secret_count : 1
}

resource "azurerm_key_vault_secret" "redis_password" {
  count = local.is_dr_run_state ? local.hadr_config.redis.secret_count : 1
}

新しいディザスタリカバリクラスタバージョンのアップグレード .yamlファイルを作成します。

新しいDRクラスターバージョンのアップグレードyamlファイルを作成するには、次のコードスニペットをテキストエディターにコピーし、ファイルをdr-cluster-version-upgrade.yamlとして保存します。次に、yamlファイルをインフラストラクチャリポジトリのpipelinesフォルダーに追加します。

次の構造を参照してください。

trigger:
none

parameters:
- name: kubernetes_version
  type: string

variables:
  - group: azure-auth-variables
  - group: azure-keyvault-variables

pool:
  vmImage: "ubuntu-latest"

jobs:
  - job: Cluster_Upgrade
    displayName: Upgrade Secondary AKS
    timeoutInMinutes: 360
    steps:
      - task: AzureKeyVault@1
        inputs:
          azureSubscription: $(azure_subscription_id)
          KeyVaultName: $(azure_key_vault_name)
          SecretsFilter: '*'
          RunAsPreJob: true
      - task: AzureCLI@2
        inputs:
          azureSubscription: $(azure_subscription_id)
          scriptType: 'pscore'
          scriptLocation: 'scriptPath'
          scriptPath: 'pipelines/scripts/cluster-version-upgrade.ps1'
          arguments: |
            -InfrastructureId $(dr-infrastructure-id) `
            -KubernetesVersion ${{ parameters.kubernetes_version }}
        displayName: Upgrade Secondary AKS cluster

  - job: Reset_Nodepools
    displayName: Reset Secondary Nodepools
    dependsOn: Cluster_Upgrade
    timeoutInMinutes: 360
    steps:
      - task: AzureKeyVault@1
        inputs:
          azureSubscription: $(azure_subscription_id)
          KeyVaultName: $(azure_key_vault_name)
          SecretsFilter: '*'
          RunAsPreJob: true
      - task: AzureCLI@2
        inputs:
          azureSubscription: $(azure_subscription_id)
          scriptType: 'pscore'
          scriptLocation: 'scriptPath'
          scriptPath: 'pipelines/scripts/reset-nodepools-to-default.ps1'
          arguments: |
            -InfrastructureId $(dr-infrastructure-id)
        displayName: Reset Secondary Nodepools to Default State

  - job: Upgrade_Nodepools_Linux
    displayName: Upgrade Secondary Linux Nodepools
    dependsOn: Reset_Nodepools
    variables:
      osType: "Linux"
    timeoutInMinutes: 360
    steps:
      - task: AzureKeyVault@1
        inputs:
          azureSubscription: $(azure_subscription_id)
          KeyVaultName: $(azure_key_vault_name)
          SecretsFilter: '*'
          RunAsPreJob: true
      - task: AzureCLI@2
        inputs:
          azureSubscription: $(azure_subscription_id)
          scriptType: 'pscore'
          scriptLocation: 'scriptPath'
          scriptPath: 'pipelines/scripts/upgrade-nodepools.ps1'
          arguments: |
            -InfrastructureId $(dr-infrastructure-id) `
            -OsType $(osType) `
            -KubernetesVersion ${{ parameters.kubernetes_version }}
        displayName: Upgrade Secondary Linux Nodepools

  - job: Upgrade_Nodepools_Windows
    displayName: Upgrade Secondary Windows Nodepools
    dependsOn: Upgrade_Nodepools_Linux
    variables:
      osType: "Windows"
    timeoutInMinutes: 360
    steps:
      - task: AzureKeyVault@1
        inputs:
          azureSubscription: $(azure_subscription_id)
          KeyVaultName: $(azure_key_vault_name)
          SecretsFilter: '*'
          RunAsPreJob: true
      - task: AzureCLI@2
        inputs:
          azureSubscription: $(azure_subscription_id)
          scriptType: 'pscore'
          scriptLocation: 'scriptPath'
          scriptPath: 'pipelines/scripts/upgrade-nodepools.ps1'
          arguments: |
            -InfrastructureId $(dr-infrastructure-id) `
            -OsType $(osType) `
            -KubernetesVersion ${{ parameters.kubernetes_version }}
        displayName: Upgrade Secondary Windows Nodepools

   - job: Update_Keyvault
    displayName: Update Keyvault
    dependsOn: Upgrade_Nodepools_Windows
    timeoutInMinutes: 360
    steps:
      - task: AzureCLI@2
        inputs:
          azureSubscription: $(azure_subscription_id)
          scriptType: 'pscore'
          scriptLocation: inlineScript
          inlineScript: |
            $keyvaultName = '$(azure_key_vault_name)'
            $kubernetesVersion = "${{ parameters.kubernetes_version }}"
            Write-Host "Update [dr-kubernetes-cluster-version] secret in keyvault [$keyvaultName] to [$kubernetesVersion]"
            az keyvault secret set --name "dr-kubernetes-cluster-version" --vault-name $keyvaultName --value $kubernetesVersion | Out-Null
            Write-Host " Secret has been updated"
        displayName: Update Keyvault Secrets

手記

コードが削除された場合は、これらのファイルをmainにしてコミットに戻り、強調表示されたコードを機能ブランチのファイルにコピーします。

新しいシークレットdr-sc-typeを追加し、値はexternalです。
プルリクエストを完了します。インフラストラクチャパイプラインが実行され、変更が自動的に適用されます。
インフラストラクチャパイプラインの実行が正常に完了したことを確認します。
dr cluster version upgradeという名前の新しいパイプラインを作成し、手順7で作成した .yamlファイルにリンクして、継続的インテグレーションを無効にします。詳細については、パイプラインのドキュメントを参照してください。
pipelinesフォルダーに他の新しいファイルが追加されている場合は、Azure DevOpsで新しいパイプラインを作成し、pipelinesフォルダーから新しいパイプライン .yamlファイルにリンクしてください。詳細については、パイプラインのドキュメントを参照してください。

アプリケーションを更新する

アプリケーションの更新方法は、環境に災害復旧があるかどうか、および災害復旧の種類によって異なります。

手記

ファイルをカスタマイズした場合は、すべてのカスタム変更が異なるモジュールに分割されていることを確認してください。

DRがない環境のアプリケーションを更新する

DRがない環境のアプリケーションを更新するには、次のようにします。

機能ブランチを作成し、次のフォルダーを除くApplicationフォルダーのすべてのコンテンツをApplicationリポジトリにコピーします。
- config\resources
config\resources\resources.jsonファイルとsku\resources.{topology-size}.jsonファイルを比較します。構造に違いがある場合は、config\resources\resources.jsonを更新します。
メインブランチに対してプル要求を作成します。競合を確認し、解決します。
pipelinesフォルダーに新しいファイルを追加した場合は、Azure DevOpsで新しいパイプラインを作成し、新しいパイプライン (pipelinesフォルダーのyamlファイル) にリンクしてください。詳細については、パイプラインのドキュメントを参照してください。

手記

パッチを適用する場合は、パッチスクリプトがリポジトリから削除されていないことを確認してください。

DRがある環境のアプリケーションを更新する

DRがある環境のアプリケーションを更新するには、次のようにします。

機能ブランチを作成し、次のフォルダーを除くApplicationフォルダーのすべてのコンテンツをApplicationリポジトリにコピーします。
- config\resources
config\resources\resources.jsonファイルとsku\resources.{topology-size}.jsonファイルを比較します。構造に違いがある場合は、config\resources\resources.jsonを更新します。
次のファイルに強調表示されたコードが含まれていることを確認します。
- /pipelines/templates/application.yamlファイル:
- /main.yamlファイル:
手記

コードが削除された場合は、これらのファイルをmainにしてコミットに戻り、強調表示されたコードを機能ブランチのファイルにコピーします。
/pipelines/application.yamlファイルに次の強調表示されたコードが含まれていることを確認します。

警告

デプロイしたディザスタリカバリタイプのタイプを確認します。DRベーシックコールドスタンバイとDRマネージドホットスタンバイの /pipelines/application.yamlファイルが異なります。デプロイした災害復旧のタイプに基づく以下の例に従っていることを確認してください。
- DRベーシックコールドスタンバイの場合のみ:
- DR管理ホットスタンバイの場合のみ:
メインブランチに対してプル要求を作成します。競合を確認し、解決します。
アプリケーションパイプラインの実行が正常に完了したことを確認します。アプリケーションパイプラインが実行され、変更が自動的に適用されます。
pipelinesフォルダーに新しいファイルを追加した場合は、Azure DevOpsで新しいパイプラインを作成し、新しいパイプライン (pipelinesフォルダーのyamlファイル) にリンクしてください。詳細については、パイプラインのドキュメントを参照してください。

手記

パッチを適用する場合は、パッチスクリプトがリポジトリから削除されていないことを確認してください。