1. Managed Cloudの設定

Update Managed Cloud

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

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

Managed Cloud Containersでは、最新のアップデートでMCCパッケージをインストールできます。これは、Managed Cloudコンテナの最新情報を実装にアップデートさせるための重要なプロセスです。これらのアップデートは定期的なメンテナンス計画の一環として計画し、例えばMCCの更新時間を毎月スケジュールすることをお勧めします。

アップデートパッケージの内容について詳しく知りたい方は、リリースノートを参照してください。すべてのパッケージのリリースノートはアップグレードパッケージと同じ場所から入手可能です(release_notes..md)。

!重要Sitecore Managed Cloudコンテナソリューションは、モジュール化されたリポジトリ構造をサポートしている場合のみ更新可能です。モジュール化された構造はバージョン10.1.0-r.182868および10.1.1-r.182925からサポートされています。バージョンを確認するには、アプリケーションリポジトリにアクセスし、version.txtファイルのバージョンを確認してください。もし古いバージョンをお持ちなら、移行プロセスを踏む必要があります。 solution.jsonファイルを持っている場合、環境はすでにモジュール化された構造を使っており、このトピックで説明したアップグレードプロセスを継続できます。

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

このトピックでは、以下の方法を説明します:

  1. アップデートの準備をしてください
  2. インフラの更新
  3. アプリケーションの更新
  4. アップデートを元に戻す

アップデートの準備をしてください

アップデートの準備として:

  1. mccsharedupgradestorageストレージアカウントにアクセスし、mcc-upgradesコンテナを開き、トポロジーとSitecoreバージョンの最新リビジョンを探してください。

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

    !注ストレージアカウントにアクセスできない場合は、DevOps Engineerアクセスのためのサービスリクエストを開いてください。

  2. パッケージをダウンロードして一時フォルダに解凍してください。

  3. リポジトリを見直し、カスタマイズした点を確認してください:

インフラの更新

インフラの更新方法は、環境に災害復旧(DR)があるかどうかと、その災害復旧の種類によって異なります。

!注カスタマイズファイルがある場合は、すべてのカスタム変更を 異なるモジュールに分けて行うようにしてください。

DRがない環境のインフラを更新してください

DRを持たない環境のインフラを更新するには:

  1. 機能ブランチを作成し、 Infrastructure フォルダの以下のフォルダを除くすべての内容を Infrastructure リポジトリにコピーします。

    • config\resources

  2. メインブランチに対してプルリクエストを作成してください。競合を確認して解決してください。

  3. ファイル config\resources\resources.json と sku\resources.{topology-size}.json ファイルを比較してください。構造に違いがあれば config\resources\resources.json 更新してください。

  4. もしパイプラインフォルダに他に新しいファイルを追加している場合は、Azure DevOpsで新しいパイプラインを作成し、パイプラインフォルダ内の新しいパイプライン .yaml ファイルにリンクしてください。詳細は パイプラインのドキュメント をご覧ください。

DR Basic Cold Standbyがある環境のインフラを更新してください

DR Basicコールドスタンバイがある環境のインフラを更新するには:

  1. 機能ブランチを作成し、Infrastructureフォルダの以下のフォルダを除くすべての内容をInfrastructureリポジトリにコピーします。

    • config\resources

  2. メインブランチに対してプルリクエストを作成してください。競合を確認して解決してください。

  3. config\resources\resources.jsonファイルとsku\resources.{topology-size}.jsonファイルを比較してください。構造に違いがあれば更新してくださいconfig\resources\resources.json。

  4. 以下のファイルにハイライトされたコードが含まれていることを確認してください:

    • /config/remote-mcc-modules/modules.jsonファイル:

      d613fc03-3745-4ee6-bcde-6441f2ee18dc.png

    • /pipelines/templates/infrastructure.yamlファイル:

      DR2.png

    • /main.tfファイル:

      DR4.png

    • /pipelines/scripts/enable-tls-1dot2.ps1ファイル:

      enable-tls-1dot2_ps1_file_Cold.png

    • /pipelines/scripts/update-tags.ps1ファイル:

      image-20240627-031255.png

    • /pipelines/update-resource-group-tags.yamlファイル:

      image-20240627-031132.png

    • /pipelines/scripts/managed-identity-access.ps1ファイル:

      image-20240627-033952.png

      /pipelines/hadr/geosync/geosync.yamlファイル:

      37fc2283-4160-41b6-90da-43e8f6e6454c.png

  5. /pipelines/infrastructure.yamlファイルに以下のハイライトコードが含まれていることを確認してください:

    !警告展開した災害復旧の種類を確認してください。DR

    Cold StandbyとDR Managed Hot Standbyは異なる /pipelines/infrastructure.yamlファイルを持っています。展開した災害復旧の種類に基づく以下の例に従うことを必ず確認してください。

    DR Basic Cold Standby /pipelines/infrastructure.yaml

  6. 以下のスニペットを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 }

    /main_override.tf

  7. もしまだ存在しなければ、externalの値を持つ新しい秘密dr-sc-typeを追加します。

  8. プルリクエストを完成させてください。インフラストラクチャパイプラインが自動的に動作し、変更を適用します。

  9. インフラのパイプラインが無事に完了したことを確認してください。

  10. もしパイプラインフォルダに他に新しいファイルを追加している場合は、Azure DevOpsで新しいパイプラインを作成し、パイプラインフォルダ内の新しいパイプライン .yamlファイルにリンクしてください。詳細は パイプラインのドキュメント をご覧ください。

DRマネージドホットスタンバイがある環境のインフラを更新してください

DRマネージドホットスタンバイがある環境のインフラを更新するには:

  1. 機能ブランチを作成し、Infrastructureフォルダの以下のフォルダを除くすべての内容をInfrastructureリポジトリにコピーします。

    • config\resources

  2. メインブランチに対してプルリクエストを作成してください。競合を確認して解決してください。

  3. config\resources\resources.jsonファイルとsku\resources.{topology-size}.jsonファイルを比較してください。構造に違いがあれば更新してくださいconfig\resources\resources.json。

  4. 以下のファイルにハイライトされたコードが含まれていることを確認してください:

    • /config/remote-mcc-modules/modules.jsonファイル:

      d613fc03-3745-4ee6-bcde-6441f2ee18dc.png

    • /pipelines/templates/infrastructure.yamlファイル:

      DR2.png

    • /main.tfファイル:

      DR4.png

    • /pipelines/scripts/enable-tls-1dot2.ps1ファイル:

      UUID-3d87031a-b541-57a6-88c1-90f5b721580c.png

    • /pipelines/scripts/update-tags.ps1ファイル:

      image-20240627-031255.png

    • /pipelines/update-resource-group-tags.yamlファイル:

      image-20240627-031132.png

    • /pipelines/scripts/managed-identity-access.ps1ファイル:

      image-20240627-033952.png

      /pipelines/hadr/geosync/geosync.yamlファイル:

      37fc2283-4160-41b6-90da-43e8f6e6454c.png

  5. /pipelines/infrastructure.yamlファイルに以下のハイライトコードが含まれていることを確認してください:

    !警告展開した災害復旧の種類を確認してください。DR

    Cold StandbyとDR Managed Hot Standbyは異なる /pipelines/infrastructure.yamlファイルを持っています。展開した災害復旧の種類に基づく以下の例に従うことを必ず確認してください。

    DR Managed Hot Standby /pipelines/infrastructure.yaml

  6. 以下のスニペットを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 }

    /main_override.tf

  7. 新しい災害復旧クラスタのバージョンアップグレードファイル .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

    MCC folder structure

    !注コードが削除されている場合は、これらのファイルをmainに入れた状態でコミットに戻り、ハイライトされたコードをフィーチャーブランチのファイルにコピーしてください。

  8. もしまだ存在しなければ、externalの値を持つ新しい秘密dr-sc-typeを追加します。

  9. プルリクエストを完成させてください。インフラストラクチャパイプラインが自動的に動作し、変更を適用します。

  10. インフラのパイプラインが無事に完了したことを確認してください。

  11. dr cluster version upgradeという名前の新しいパイプラインを作成し、ステップ7で作成した.yamlファイルにリンクし、継続的統合を無効にしてください。詳細はパイプラインのドキュメントをご覧ください。

    New DR cluster version upgrade pipeline

  12. もしパイプラインフォルダに他に新しいファイルを追加している場合は、Azure DevOpsで新しいパイプラインを作成し、パイプラインフォルダ内の新しいパイプライン .yamlファイルにリンクしてください。詳細は パイプラインのドキュメント をご覧ください。

アプリケーションの更新

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

!注カスタマイズファイルがある場合は、すべてのカスタム変更を 異なるモジュールに分けて行うようにしてください。

DRがない環境のアプリケーションを更新してください

DRを持たない環境のアプリケーションを更新するには:

  1. 機能ブランチを作成し、アプリケーションフォルダの以下のフォルダを除くすべてのコンテンツをアプリケーションリポジトリにコピーします。

    • config\resources

  2. config\resources\resources.jsonファイルとsku\resources.{topology-size}.jsonファイルを比較してください。構造に違いがあれば更新してくださいconfig\resources\resources.json。

  3. メインブランチに対してプルリクエストを作成してください。競合を確認して解決してください。

  4. パイプラインフォルダに新しいファイルを追加した場合は、Azure DevOpsで新しいパイプラインを作成し、そのパイプライン(パイプラインフォルダ内のyamlファイル)にリンクしてください。詳細は パイプラインのドキュメント をご覧ください。

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

DRが設定されている環境のアプリケーションを更新してください

DRが設定されている環境向けにアプリケーションを更新するには:

  1. 機能ブランチを作成し、アプリケーションフォルダの以下のフォルダを除くすべてのコンテンツをアプリケーションリポジトリにコピーします。

    • config\resources

  2. config\resources\resources.jsonファイルとsku\resources.{topology-size}.jsonファイルを比較してください。構造に違いがあれば更新してくださいconfig\resources\resources.json。

  3. 以下のファイルにハイライトされたコードが含まれていることを確認してください:

    • /pipelines/templates/application.yamlファイル:

      /pipelines/templates/application.yaml

    • /main.yamlファイル:

      main.yaml

    !注コードが削除されている場合は、これらのファイルをmainに入れた状態でコミットに戻り、ハイライトされたコードをフィーチャーブランチのファイルにコピーしてください。

  4. /pipelines/application.yamlファイルに以下のハイライトコードが含まれていることを確認してください:

    !警告展開した災害復旧の種類を確認してください。DRのBasic Cold StandbyとDR Managed Hot Standbyは異なる /pipelines/application.yamlファイルを持っています。展開した災害復旧の種類に基づく以下の例に従うことを確認してください。

    • DRベーシックコールドスタンバイのみの場合:

      The /pipelines/application.yaml/pipelines/application.yaml file for DR Basic Cold Standby.

    • DRマネージドホットスタンバイのみの場合:

      The /pipelines/application.yaml/pipelines/application.yaml file for DR Managed Hot Standby.

  5. メインブランチに対してプルリクエストを作成してください。競合を確認して解決してください。

  6. アプリケーションパイプラインの実行が正常に完了していることを確認してください。アプリケーションパイプラインは自動的に動作し、変更を適用します。

  7. パイプラインフォルダに新しいファイルを追加した場合は、Azure DevOpsで新しいパイプラインを作成し、そのパイプライン(パイプラインフォルダ内のyamlファイル)にリンクしてください。詳細は パイプラインのドキュメント をご覧ください。

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

アップデートを元に戻す

アップデート中にエラーが発生したり、ミスを犯したり、アップデートを元に戻したい場合は、アップデートを元に戻して元の状態に戻すことができます。

更新を元に戻して元の状態に戻すには:

  1. インフラストラクチャリポジトリのプルリクエストを元に戻し、インフラストラクチャとフロントドアのパイプラインを実行して変更を適用します。
  2. アプリケーションリポジトリのプルリクエストを元に戻し、アプリケーションパイプラインを実行して変更を適用します。
この記事を改善するための提案がある場合は、 お知らせください!