Compartilhar via


Comece com práticas seguras de atualização

Visão geral

Este artigo apresenta as práticas seguras de atualização (SUP) do Gerenciador de Serviço do Operador do Microsoft Azure (AOSM). Este conjunto de funcionalidades permite que um usuário final execute com segurança atualizações complexas de cargas de trabalho CNF hospedadas no Nexus do Operador do Azure, em conformidade com os requisitos de ISSU do parceiro, quando aplicável. Procure por artigos futuros nesses serviços para expandir os recursos e funcionalidades do SUP.

Introdução

Um determinado serviço de rede com suporte pelo Gerenciador de Serviço do Operador do Microsoft Azure será composto por uma ou mais funções de rede baseadas em contêiner (CNFs), que, ao longo do tempo, exigirão atualizações de software. Para cada atualização, é necessário executar uma ou mais operações Helm, atualizando aplicativos de funções de rede dependentes (NfApps), em uma ordem específica, de modo a minimizar o impacto no serviço de rede. No Gerenciador de Serviço do Operador do Microsoft Azure, as Práticas Seguras de Atualização representam um conjunto de funcionalidades que podem automatizar as operações CNF necessárias para atualizar um serviço de rede no Nexus do Operador do Azure.

  • Atualização de SNS Reput - Executar a operação de upgrade do Helm em todos os NfApps no NFDV.
  • Plataforma Nexus - Com suporte para operações de SNS Reput em destinos da plataforma Nexus.
  • Tempo limite da operação - Capacidade de definir tempos limite operacionais para cada operação NfApp.
  • Operações síncronas - Capacidade de executar uma operação NfApp serial por vez.
  • Pausa em caso de falha - Com base em um sinalizador, defina o comportamento da falha para reverter apenas a última operação NfApp.
  • Validação do Teste de Gráfico Único - Executar uma operação de teste do Helm após uma criação ou atualização.
  • SNS Reput reformulado - Métodos aprimorados, adiciona ordem de atualização e verificação de limpeza.

Abordagem de atualização

Para atualizar um serviço de rede de site do Gerenciador de Serviço do Operador do Microsoft Azure (SNS) existente, o Operador executa uma solicitação de atualização de reput contra o recurso SNS implantado. Quando o SNS contém CNFs com vários NfApps, a solicitação é distribuída para todas os NfApps definidas na versão da definição da função de rede (NFDV). Por padrão, na ordem em que aparecem, ou opcionalmente na ordem definida pelo parâmetro UpdateDependsOn.

Para cada NfApp, a solicitação de atualização de reput dá suporte para o aumento de uma versão de gráfico do Helm, a adição/remoção de valores do Helm e/ou a adição/remoção de qualquer NfApp. Os tempos limite podem ser definidos por NfApp, com base nos runtimes permitidos conhecidos, mas os NfApps só podem ser processadas em ordem serial, uma após a outra. A atualização de reput implementa a seguinte lógica de processamento:

  • Os NfApps são processados após a ordenação updateDependsOn ou na ordem sequencial em que aparecem.
  • NfApps com o parâmetro "applicationEnabled" definido como desabilitado são ignorados.
  • Os NFApps implantados, mas não referenciados pelo novo NFDV, são excluídos.
  • Os NFApps comuns entre o NFDV antigo e o novo são atualizados.
  • Os NFApps que estão apenas no novo NFDV são instalados.

Para garantir os resultados, há suporte para os testes do NfApp usando o Helm, tanto os testes pré/pós de upgrade do Helm quanto os testes autônomos do Helm. Para falhas em testes pré/pós, o parâmetro atômico é respeitado. Com atomic/true, o gráfico com falha é revertido. Com atomic/false, nenhuma reversão é executada. Para testes independentes de Helm, o parâmetro rollbackOnTestFailure é respeitado. Com rollbackOnTestFailure/true, o gráfico com falha é revertido. Com rollbackOnTestFailure/false, nenhuma reversão é executada.

Pré-requisitos

Ao planejar uma atualização usando o Gerenciador de Serviço do Operador do Microsoft Azure, aborde os seguintes requisitos antes da execução da atualização para otimizar o tempo gasto na tentativa de atualização.

  • Integre artefatos atualizados usando fluxos de trabalho de publicador e/ou designer.

    • Publicador, store, design de serviço de rede (NSDg) e grupo de design de função de rede (NFDg) são estáticos e não precisam ser alterados.
      • Um novo manifesto de artefatos é necessário para armazenar os novos gráficos e imagens. Para mais informações, consulte a documentação de integração para detalhes sobre o upload de novos gráficos e imagens.
    • São necessárias novas versões da NFDV e design de serviço de rede (NSDV) sob os NFDg e NSDg existentes.
      • Cobrimos as mudanças básicas na NFDV na seção passo a passo.
      • Uma nova NSDV só é necessária se um novo esquema de grupo de configuração (CGS) estiver sendo introduzido.
    • Se necessário, novo CGS.
      • Necessário se uma atualização introduzir novos parâmetros de configuração expostos.
  • Crie artefatos atualizados usando o fluxo de trabalho do Operador.

    • Se necessário, crie valores de grupos de configuração (CGVs) com base no novo CGS.
    • Reutilize e elabore o payload confirmando os objetos de site e serviço de rede do site existentes.
  • Atualize os modelos para garantir que os parâmetros de atualização estejam definidos com base na confiança na atualização e no comportamento de falha desejado.

    • As configurações usadas para produção podem suprimir detalhes de falhas, enquanto as configurações usadas para depuração ou testes podem optar por expor esses detalhes.

Procedimento de atualização

Siga o seguinte processo para disparar uma atualização com o Gerenciador de Serviço do Operador do Microsoft Azure.

Criar um recurso NFDV

Para novas versões da NFDV, ela deve estar em um formato SemVer válido, no qual apenas valores incrementais maiores de atualizações de patch e versões menores são permitidos. Uma versão NFDV inferior não é permitida. Dado um CNF implantado usando NFDV 2.0.0, a nova NFDV pode ser da versão 2.0.1 ou 2.1.0, mas não 1.0.0 ou 3.0.0.

Atualizar os novos parâmetros NFDV

As versões do gráfico do Helm podem ser atualizadas, ou os valores do Helm podem ser atualizados ou parametrizados conforme necessário. Novos NfApps também podem ser adicionadas onde não existiam na versão implantada.

Atualize a NFDV para a ordem desejada de NfApps

UpdateDependsOn é um parâmetro NFDV usado para especificar a ordem dos NfApps durante operações de atualização. Se UpdateDependsOn não for fornecido, a ordenação serial dos aplicativos CNF, conforme aparecem na NFDV, será usada.

Atualize a NFDV para o comportamento de atualização desejado

Certifique-se de definir quaisquer tempos limite de aplicativo CNF desejados, o parâmetro atômico e o parâmetro rollbackOnTestFailure. Pode ser útil alterar esses parâmetros ao longo do tempo à medida que mais confiança é adquirida na atualização.

Emitir SNS reput

Com a integração concluída, a operação de reput é submetida. Dependendo do número, tamanho e complexidade dos NfApps, a operação de reput pode levar algum tempo para ser concluída (várias horas).

Examine os resultados do reput

Se o reput estiver relatando um resultado bem-sucedido, a atualização estará concluída e o usuário deverá validar o estado e a disponibilidade do serviço. Se o reput estiver relatando uma falha, siga as etapas na seção de recuperação de falha de atualização para continuar.

Procedimento de repetição

Nos casos em que uma atualização de reput falhar, o seguinte processo pode ser seguido para repetir a operação.

Diagnostique o NfApp com falha

Resolva a causa raiz da falha do NfApp analisando logs e outras informações de depuração.

Ignorar manualmente os gráficos concluídos

Após corrigir o NfApp com falha, mas antes de tentar uma nova atualização, considere alterar o parâmetro applicationEnablement para acelerar o comportamento da repetição. Esse parâmetro pode ser definido como falso, em que um NfApp deve ser ignorado. Este parâmetro pode ser útil onde um NfApp não exige atualização.

Emitir repetição de SNS reput (repetir até obter sucesso)

Por padrão, o reput repete os NfApps na ordem de atualização declarada, a menos que sejam ignoradas usando o sinalizador applicationEnablement.

Como fazer para usar applicationEnablement

No recurso NFDV, sob deployParametersMappingRuleProfile, existe a propriedade applicationEnablement do tipo enumeração, que assume os valores: Desconhecido, Habilitado ou Desabilitado. Pode ser usado para excluir operações NfApp durante a implantação de NF.

Alterações do Publicador

Para a propriedade applicationEnablement, o publicador tem duas opções: fornecer um valor padrão ou parametrizá-lo.

Amostra de NFDV

O NFDV é usado pelo publicador para definir valores padrão para applicationEnablement.

{ 
      "location":"<location>", 
      "properties": {
      "networkFunctionTemplate": {
        "networkFunctionApplications": [
          {
            "artifactProfile": {
              "helmArtifactProfile": { 
                "var":"var"
              },
              "artifactStore": {
                "id": "<artifactStore id>"
              }
            },
            "deployParametersMappingRuleProfile": {
              "helmMappingRuleProfile": {
                "releaseNamespace": "{deployParameters.role1releasenamespace}",
                "releaseName": "{deployParameters.role1releasename}"
              },
              "applicationEnablement": "Enabled"
            },
            "artifactType": "HelmPackage",
            "dependsOnProfile": "null",
            "name": "hellotest"
          },
          {
            "artifactProfile": {
              "helmArtifactProfile": {
                 "var":"var"
              },
              "artifactStore": {
                "id": "<artifactStore id>"
              }
            },
            "deployParametersMappingRuleProfile": {
              "helmMappingRuleProfile": {
                "releaseNamespace": "{deployParameters.role2releasenamespace}",
                "releaseName": "{deployParameters.role2releasename}"
              },
              "applicationEnablement": "Enabled"
            },
            "artifactType": "HelmPackage",
            "dependsOnProfile": "null",
            "name": "hellotest1"
          }
        ],
        "nfviType": "AzureArcKubernetes"
      },
      "description": "null",
      "deployParameters": {"type":"object","properties":{"role1releasenamespace":{"type":"string"},"role1releasename":{"type":"string"},"role2releasenamespace":{"type":"string"},"role2releasename":{"type":"string"}},"required":["role1releasenamespace","role1releasename","role2releasenamespace","role2releasename"]},
      "networkFunctionType": "ContainerizedNetworkFunction"
    }
}

Amostra de recurso de esquema de grupo de configuração (CGS)

O CGS é usado pelo publicador para exigir que as variáveis roleOverrideValues sejam fornecidas pelo Operador em runtime. Esses roleOverrideValues podem incluir configurações não padrão para applicationEnablement.

{
  "type": "object",
  "properties": {
    "location": {
      "type": "string"
    },
    "nfviType": {
      "type": "string"
    },
    "nfdvId": {
      "type": "string"
    },
    "helloworld-cnf-config": {
      "type": "object",
      "properties": {
        "role1releasenamespace": {
          "type": "string"
        },
        "role1releasename": {
          "type": "string"
        },
        "role2releasenamespace": {
          "type": "string"
        },
        "role2releasename": {
          "type": "string"
        },
        "roleOverrideValues1": {
          "type": "string"
        },
        "roleOverrideValues2": {
          "type": "string"
        }
      },
      "required": [
        "role1releasenamespace",
        "role1releasename",
        "role2releasenamespace",
        "role2releasename",
        "roleOverrideValues1",
        "roleOverrideValues2"
      ]
    }
  },
  "required": [
    "nfviType",
    "nfdvId",
    "location",
    "helloworld-cnf-config"
  ]
}

Alterações do Operador

Os operadores herdam valores de applicationEnablement padrão conforme definido pelo NFDV. Se applicationEnablement for parametrizado no CGS, ele precisará ser passado através da propriedade deploymentValues em runtime.

Amostra de recurso de valor de grupo de configuração (CGV)

O CGV é usado pelo operador para definir as variáveis roleOverrideValues em runtime. O roleOverrideValues inclui configurações não padrão para applicationEnablement.

{
  "location": "<location>",
  "nfviType": "AzureArcKubernetes",
  "nfdvId": "<nfdv_id>",
  "helloworld-cnf-config": {
    "role1releasenamespace": "hello-test-releasens",
    "role1releasename": "hello-test-release",
    "role2releasenamespace": "hello-test-2-releasens",
    "role2releasename": "hello-test-2-release",
    "roleOverrideValues1": "{\"name\":\"hellotest\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\":\"Enabled\",\"helmMappingRuleProfile\":{\"releaseName\":\"override-release\",\"releaseNamespace\":\"override-namespace\",\"helmPackageVersion\":\"1.0.0\",\"values\":\"\",\"options\":{\"installOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"30\",\"injectArtifactStoreDetails\":\"true\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"30\",\"injectArtifactStoreDetails\":\"true\"}}}}}",
    "roleOverrideValues2": "{\"name\":\"hellotest1\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\" : \"Enabled\"}}"
  }
}

Exemplo de modelo do ARM NF

O modelo do ARM NF é usado pelo operador para enviar as variáveis roleOverrideValues, definidas pelo CGV, para o RP (provedor de recursos). O operador pode alterar a configuração applicationEnablement no CGV, conforme necessário, e reenviar o mesmo modelo do ARM NF, para alterar o comportamento entre iterações.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "nameValue": {
      "type": "string",
      "defaultValue": "HelloWorld"
    },
    "locationValue": {
      "type": "string",
      "defaultValue": "eastus"
    },
    "nfviTypeValue": {
      "type": "string",
      "defaultValue": "AzureArcKubernetes"
    },
    "nfviIdValue": {
      "type": "string"
    },
    "config": {
      "type": "object",
      "defaultValue": {}
    },
    "nfdvId": {
      "type": "string"
    }
  },
  "variables": {
    "deploymentValuesValue": "[string(createObject('role1releasenamespace', parameters('config').role1releasenamespace, 'role1releasename',parameters('config').role1releasename, 'role2releasenamespace', parameters('config').role2releasenamespace, 'role2releasename',parameters('config').role2releasename))]",
    "nfName": "[concat(parameters('nameValue'), '-CNF')]",
    "roleOverrideValues1": "[string(parameters('config').roleOverrideValues1)]",
    "roleOverrideValues2": "[string(parameters('config').roleOverrideValues2)]"
  },
  "resources": [
    {
      "type": "Microsoft.HybridNetwork/networkFunctions",
      "apiVersion": "2023-09-01",
      "name": "[variables('nfName')]",
      "location": "[parameters('locationValue')]",
      "properties": {
        "networkFunctionDefinitionVersionResourceReference": {
          "id": "[parameters('nfdvId')]",
          "idType": "Open"
        },
        "nfviType": "[parameters('nfviTypeValue')]",
        "nfviId": "[parameters('nfviIdValue')]",
        "allowSoftwareUpdate": true,
        "configurationType": "Open",
        "deploymentValues": "[string(variables('deploymentValuesValue'))]",
        "roleOverrideValues": [
          "[variables('roleOverrideValues1')]",
          "[variables('roleOverrideValues2')]"
        ]
      }
    }
  ]
}

Suporte para atualizações em serviço

O Gerenciador de Serviço do Operador do Microsoft Azure, sempre que possível, dá suporte para atualizações em serviço, um método de atualização que avança a versão da implantação sem interromper o serviço. No entanto, a capacidade de um determinado serviço ser atualizado sem interrupção é uma característica do próprio serviço. Consulte o publicador do serviço para entender as funcionalidades de atualização em serviço.

Objetivos de prospecção

O Gerenciador de Serviço do Operador do Microsoft Azure continua a expandir o conjunto de funcionalidades de Práticas Seguras de Atualização e a promover melhorias nos serviços de atualização oferecidos. As seguintes funcionalidades estão sendo consideradas para futura disponibilidade:

  • Melhorar o Controle de Opções de Atualização - Expor parâmetros de forma mais eficaz.
  • Ignorar NfApp sem Mudanças - Ignorar o processamento de NfApps em que nenhuma alteração ocorre.
  • Executar Rollback do NFDV em caso de Falha - Com base em um sinalizador, reverter todos os NfApps concluídas em caso de falha.
  • Operar Assincronamente - Capacidade de executar múltiplas operações NfApp ao mesmo tempo.
  • Fazer o download de Imagens - Capacidade de pré-carregar imagens no repositório de borda.
  • Validar Gráficos de Destino - Capacidade de executar um teste do Helm apenas em um NfApp específico.