Walkthrough: Updating Managed Cloud

Current version: 10.1

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.

  • Update the infrastructure.

  • Update the application.

  • Revert an update.

Prepare the update

To prepare the update:

  1. 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.

  2. Download and unzip the package to a temporary folder.

  3. Review your repositories and look for the customizations you have made:

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:

  1. Create a feature branch and copy all content of the Infrastructure folder to the Infrastructure repository except the following folder:

    • config\resources

  2. Create a pull request against the main branch. Review and resolve any conflicts.

  3. 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.

  4. 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:

  1. Create a feature branch and copy all content of the Infrastructure folder to the Infrastructure repository except the following folder:

    • config\resources

  2. Create a pull request against the main branch. Review and resolve any conflicts.

  3. 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.

  4. Make sure that the following files contain the highlighted code:

    • The /config/remote-mcc-modules/modules.json file:

      /config/remote-mcc-modules/modules.json
    • The /pipelines/templates/infrastructure.yaml file:

      /pipelines/templates/infrastructure.yaml
    • The /main.tf file:

      /main.tf
    • The /pipelines/scripts/enable-tls-1dot2.ps1 file:

      /pipelines/scripts/enable-tls-1dot2.ps1
  5. 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.

    DR Basic Cold Standby /pipelines/infrastructure.yaml
  6. Add the following snippet to the bottom of the main_override.tf file (if the snippet is not already in the file).

    RequestResponse
    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. Add a new secret dr-sc-type with value external.

  8. Complete the pull request. The Infrastructure pipeline will run and apply the changes automatically.

  9. Make sure that the infrastructure pipeline run finished successfully.

  10. 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:

  1. Create a feature branch and copy all content of the Infrastructure folder to the Infrastructure repository except the following folder:

    • config\resources

  2. Create a pull request against the main branch. Review and resolve any conflicts.

  3. 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.

  4. Make sure that the following files contain the highlighted code:

    • The /config/remote-mcc-modules/modules.json file:

      /config/remote-mcc-modules/modules.json
    • The /pipelines/templates/infrastructure.yaml file:

      /pipelines/templates/infrastructure.yaml
    • The /main.tf file:

      /main.tf
    • The /pipelines/scripts/enable-tls-1dot2.ps1 file:

      /pipelines/scripts/enable-tls-1dot2.ps1
  5. 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.

    DR Managed Hot Standby /pipelines/infrastructure.yaml
  6. Add the following snippet to the bottom of the main_override.tf file ((if the snippet is not already in the file).

    RequestResponse
    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. 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:

    RequestResponse
    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
    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.

  8. Add a new secret dr-sc-type with value external.

  9. Complete the pull request. The Infrastructure pipeline will run and apply the changes automatically.

  10. Make sure that the infrastructure pipeline run finished successfully.

  11. 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.

    New DR cluster version upgrade pipeline
  12. 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:

  1. Create a feature branch and copy all content of the Application folder to the Application repository except the following folder:

    • config\resources

  2. 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.

  3. Create a pull request against the main branch. Review and resolve any conflicts.

  4. 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:

  1. Create a feature branch and copy all content of the Application folder to the Application repository except the following folder:

    • config\resources

  2. 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.

  3. Make sure that the following files contain the highlighted code:

    • The /pipelines/templates/application.yaml file:

      /pipelines/templates/application.yaml
    • The /main.yaml file:

      main.yaml
    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.

  4. 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:

      The /pipelines/application.yaml/pipelines/application.yaml file for DR Basic Cold Standby.
    • For DR Managed Hot Standby only:

      The /pipelines/application.yaml/pipelines/application.yaml file for DR Managed Hot Standby.
  5. Create a pull request against the main branch. Review and resolve any conflicts.

  6. Make sure that the application pipeline run finished successfully. The application pipeline runs and applies changes automatically.

  7. 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:

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

  2. Revert the pull request for the Application repository and run the Application pipeline to apply changes.

Do you have some feedback for us?

If you have suggestions for improving this article,