Configure Managed Cloud

Update Managed Cloud

Version:

Managed Cloud Containers lets you install the MCC package with the latest updates. This is an important process for keeping an implementation current with the latest advances for Managed Cloud Containers. We recommend that you plan these updates as part of your regular maintenance plans and, for example, schedule time for MCC updates monthly.

To learn more about the content of an update package, refer to the release notes. The release notes for every package are available from the same location as the upgrade package (release_notes.<mcc package version>.md).

Important

Sitecore Managed Cloud Containers solution can be updated only if it supports a modularized repository structure. Modularized structure is supported starting from versions 10.1.0-r.182868 and 10.1.1-r.182925. To check your version, go to the Application repository and check the version of your version.txt file. If you have an earlier version, you must follow the migration process. If you have the solution.json file, your environment already uses a modularized structure and you can continue the upgrade process described in this topic.

To update your Managed Cloud solution, you must first prepare the update, update the infrastructure, then update the application.

This topic describes how to:

Prepare the update

To prepare the update:

Go to the mccsharedupgradestorage storage account, open the mcc-upgrades container, and find the latest revision for your topology and Sitecore version:

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

Note

If you cannot access the storage account, open a service request for DevOps Engineer access.
Download and unzip the package to a temporary folder.
Review your repositories and look for the customizations you have made:
- If you want to add new Azure resources, follow the procedure described in the Configure Managed Cloud topic in the Add a new infrastructure module section.
- For customized files in the Application repository: move the custom files to separate Ansible roles. For example, if you added additional public services, follow the process described in the Add a public service topic. If you added monitoring extensions, read the Add a custom Prometheus alert topic and the Import and export your Grafana dashboard topic.

Update the infrastructure

How you update the infrastructure depends on whether your environment has disaster recovery (DR) and the type of disaster recovery.

Note

If you have customized files, make sure that all custom changes are separated into different modules.

Update the infrastructure of an environment that does not have DR

To update the infrastructure of an environment that does not have DR:

Create a feature branch and copy all content of the Infrastructure folder to the Infrastructure repository except the following folder:
- config\resources
Create a pull request against the main branch. Review and resolve any conflicts.
Compare the config\resources\resources.json and sku\resources.{topology-size}.json files. Update config\resources\resources.json if there are any differences in the structure.
If you have any other new files added to the pipelines folder, make sure you create a new pipeline in Azure DevOps and link it to the new pipeline .yaml file from the pipelines folder. See the pipelines documentation for details.

Update the infrastructure of an environment that has DR Basic Cold Standby

To update the infrastructure of an environment that has DR Basic Cold Standby:

Create a feature branch and copy all content of the Infrastructure folder to the Infrastructure repository except the following folder:
- config\resources
Create a pull request against the main branch. Review and resolve any conflicts.
Compare config\resources\resources.json and sku\resources.{topology-size}.json files. Update config\resources\resources.json if there are any differences in the structure.
Make sure that the following files contain the highlighted code:
- The /config/remote-mcc-modules/modules.json file:
- The /pipelines/templates/infrastructure.yaml file:
- The /main.tf file:
- The /pipelines/scripts/enable-tls-1dot2.ps1 file:
- The /pipelines/scripts/update-tags.ps1 file:
- The /pipelines/update-resource-group-tags.yaml file:
- The /pipelines/scripts/managed-identity-access.ps1 file:
  
  The /pipelines/hadr/geosync/geosync.yaml file:
Make sure that the /pipelines/infrastructure.yaml file contains the following highlighted code:

Warning

Check the type of disaster recovery type you have deployed. DR Basic Cold Standby and DR Managed Hot Standby have different /pipelines/infrastructure.yaml files. Make sure that you follow the example below that is based on the type of Disaster Recovery you have deployed.

Add the following snippet to the bottom of the main_override.tf file (if the snippet is not already in the file).

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
}

If it doesn't already exist, add a new secret named dr-sc-type with a value of external.
Complete the pull request. The Infrastructure pipeline will run and apply the changes automatically.
Make sure that the infrastructure pipeline run finished successfully.
If you have any other new files added to the pipelines folder, make sure you create a new pipeline in Azure DevOps and link it to the new pipeline .yaml file from the pipelines folder. See the pipelines documentation for details.

Update the infrastructure of an environment that has DR Managed Hot Standby

To update the infrastructure of an environment that has DR Managed Hot Standby:

Create a feature branch and copy all content of the Infrastructure folder to the Infrastructure repository except the following folder:
- config\resources
Create a pull request against the main branch. Review and resolve any conflicts.
Compare config\resources\resources.json and sku\resources.{topology-size}.json files. Update config\resources\resources.json if there are any differences in the structure.
Make sure that the following files contain the highlighted code:
- The /config/remote-mcc-modules/modules.json file:
- The /pipelines/templates/infrastructure.yaml file:
- The /main.tf file:
- The /pipelines/scripts/enable-tls-1dot2.ps1 file:
- The /pipelines/scripts/update-tags.ps1 file:
- The /pipelines/update-resource-group-tags.yaml file:
- The /pipelines/scripts/managed-identity-access.ps1 file:
  
  The /pipelines/hadr/geosync/geosync.yaml file:
Make sure that the /pipelines/infrastructure.yaml file contains the following highlighted code:

Warning

Check the type of disaster recovery type you have deployed. DR Basic Cold Standby and DR Managed Hot Standby have different /pipelines/infrastructure.yaml files. Make sure that you follow the example below that is based on the type of Disaster Recovery you have deployed.

Add the following snippet to the bottom of the main_override.tf file (if the snippet is not already in the file).

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
}

Create a new Disaster Recovery cluster version upgrade .yaml file.

To create a new DR cluster version upgrade yaml file, copy the following code snippet to a text editor and save the file as dr-cluster-version-upgrade.yaml. Then add the yaml file to the infrastructure repository, in the pipelines folder.

Refer to the following structure:

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

Note

If the code has been removed, go back to the commit with these files in main and copy the highlighted code to the files on the feature branch.

If it doesn't already exist, add a new secret named dr-sc-type with a value of external.
Complete the pull request. The Infrastructure pipeline will run and apply the changes automatically.
Make sure that the infrastructure pipeline run finished successfully.
Create a new pipeline named dr cluster version upgrade, then link it to the .yaml file you created in step 7 and disable continuous integration. See the pipelines documentation for details.
If you have any other new files added to the pipelines folder, make sure you create a new pipeline in Azure DevOps and link it to the new pipeline .yaml file from the pipelines folder. See the pipelines documentation for details.

Update the application

How you update the application depends on whether your environment has disaster recovery and the type of disaster recovery.

Note

If you have customized files, make sure that all custom changes are separated into different modules.

Update the application of an environment that does not have DR

To update the application of an environment that does not have DR:

Create a feature branch and copy all content of the Application folder to the Application repository except the following folder:
- config\resources
Compare config\resources\resources.json and sku\resources.{topology-size}.json files. Update config\resources\resources.json if there are any differences in the structure.
Create a pull request against the main branch. Review and resolve any conflicts.
If you have new files added to the pipelines folder, make sure you create a new pipeline in Azure DevOps and link it to the new pipeline (the yaml file from the pipelines folder). See the pipelines documentation for detail.

Note

If you apply any patches, make sure that your patch scripts are not removed from the repository.

Update the application of an environment that has DR

To update the application for an environment that has DR:

Create a feature branch and copy all content of the Application folder to the Application repository except the following folder:
- config\resources
Compare config\resources\resources.json and sku\resources.{topology-size}.json files. Update config\resources\resources.json if there are any differences in the structure.
Make sure that the following files contain the highlighted code:
- The /pipelines/templates/application.yaml file:
- The /main.yaml file:
Note

If the code has been removed, go back to the commit with these files in main and copy the highlighted code to the files on the feature branch.
Make sure that the /pipelines/application.yaml file contains the following highlighted code:

Warning

Check the type of disaster recovery type you have deployed. DR Basic Cold Standby and DR Managed Hot Standby have different /pipelines/application.yaml files. Make sure that you follow the example below that is based on the type of disaster recovery you have deployed.
- For DR Basic Cold Standby only:
- For DR Managed Hot Standby only:
Create a pull request against the main branch. Review and resolve any conflicts.
Make sure that the application pipeline run finished successfully. The application pipeline runs and applies changes automatically.
If you have new files added to the pipelines folder, make sure you create a new pipeline in Azure DevOps and link it to the new pipeline (the yaml file from the pipelines folder). See the pipelines documentation for detail.

Note

If you apply any patches, make sure that your patch scripts are not removed from the repository.

Revert an update

If you encountered an error during an update, made a mistake, or want to undo an update, you can revert the update and return to the original state.

To revert an update and return to the original state:

Revert the pull request for the Infrastructure repository and run Infrastructure and Frontdoor pipelines to apply changes.
Revert the pull request for the Application repository and run the Application pipeline to apply changes.

If you have suggestions for improving this article, let us know!