Compartilhar via

Usar parâmetros de opção do Helm para evitar a exclusão em caso de falha na instalação

  • Artigo

As implantações do SNS (Serviço de Rede do Site) podem falhar porque uma implantação de NF (Função de Rede) subjacente não consegue instalar o helm. O AOSM (Gerenciador de Serviço do Operador do Azure) remove implantações com falha do cluster Kubernetes de destino por padrão para preservar os recursos. Geralmente, as falhas de Helm install requerem que os recursos persistam no cluster para permitir que a falha seja depurada. Este artigo de instruções aborda como editar o modelo do ARM da NF para substituir esse comportamento definindo o parâmetro helm install --atomic como false.

Pré-requisitos

  • Você deve ter integrado a NF ao AOSM usando a extensão AOSM da CLI do Az. Este artigo faz referência à estrutura de pastas e à saída de arquivos pela CLI e fornece exemplos baseados na CLI
  • As falhas de instalação do Helm podem ser complexas. A depuração requer um conhecimento técnico de várias tecnologias, além de dominar o conhecimento da sua NF
  • Você precisa das atribuições de função Contributor no grupo de recursos que contém o Repositório de artefatos gerenciado pelo AOSM
  • Um IDE adequado, como o Visual Studio Code
  • A CLI do ORAS

Importante

É altamente recomendável que você tenha testado que uma helm install do seu pacote do Helm tenha êxito em seu ambiente Kubernetes conectado ao Arc de destino antes de tentar fazer uma implantação usando o AOSM.

Substituir --atomic por uma única NF de gráfico do helm

Esta seção explica como substituir --atomic de uma NF que consiste em um único gráfico do helm.

Localizar e editar o modelo BICEP da NF

  1. Navegue até o diretório nsd-cli-output, abra o diretório artifacts e abra o arquivo <nf-arm-template>.bicep. <nf-arm-template> é configurado no arquivo de entrada do NSD da extensão da CLI do AOSM do Az. Você pode confirmar que tem o arquivo certo comparando com o modelo de exemplo a seguir para uma CNF (função de rede em contêineres) da Contoso fictícia.

    @secure()
param configObject object

var resourceGroupId = resourceGroup().id

var identityObject = (configObject.managedIdentityId == '')  ? {
  type: 'SystemAssigned'
} : {
  type: 'UserAssigned'
  userAssignedIdentities: {
    '${configObject.managedIdentityId}': {}
  }
}

var nfdvSymbolicName = '${configObject.publisherName}/${configObject.nfdgName}/${configObject.nfdv}'

resource nfdv 'Microsoft.Hybridnetwork/publishers/networkfunctiondefinitiongroups/networkfunctiondefinitionversions@2023-09-01' existing = {
  name: nfdvSymbolicName
  scope: resourceGroup(configObject.publisherResourceGroup)
}

resource nfResource 'Microsoft.HybridNetwork/networkFunctions@2023-09-01' = [for (values, i) in configObject.deployParameters: {
  name: '${configObject.nfdgName}${i}'
  location: configObject.location
  identity: identityObject
  properties: {
    networkFunctionDefinitionVersionResourceReference: {
      id: nfdv.id
      idType: 'Open'
    }
    nfviType: 'AzureArcKubernetes'
    nfviId: (configObject.customLocationId == '') ? resourceGroupId : configObject.customLocationId
    allowSoftwareUpdate: true
    configurationType: 'Open'
    deploymentValues: string(values)
  }
}]

  2. Localize o nome do aplicativo de função de rede navegando até o diretório cnf-cli-output, abrindo o diretório nfDefinition e copiando o valor da única entrada na matriz networkFunctionApplications no recurso nfdv. Confirme se você tem o valor correto comparando com o snippet a seguir de código BICEP de exemplo da Contoso fictícia. Nesse caso, o nome do aplicativo de função de rede é Contoso.

    resource nfdv 'Microsoft.Hybridnetwork/publishers/networkfunctiondefinitiongroups/networkfunctiondefinitionversions@2023-09-01' = {
  parent: nfdg
  name: nfDefinitionVersion
  location: location
  properties: {
    deployParameters: string(loadJsonContent('deployParameters.json'))
    networkFunctionType: 'ContainerizedNetworkFunction'
    networkFunctionTemplate: {
      nfviType: 'AzureArcKubernetes'
      networkFunctionApplications: [
        {
          artifactType: 'HelmPackage'
          name: 'Contoso'

  3. Edite o modelo para substituir a opção --atomic de instalação padrão do helm adicionando a seguinte configuração às propriedades nfResource no modelo do ARM da NF:

    roleOverrideValues: ['{"name": "Contoso-one", "deployParametersMappingRuleProfile": {"applicationEnablement": "Enabled", "helmMappingRuleProfile": {"options": {"installOptions": {"atomic": "false"}},{"upgradeOptions": {"atomic": "false"}}}}}']

  4. Confirme se você fez essa edição corretamente comparando com o snippet a seguir da NF de exemplo da Contoso

resource nfResource 'Microsoft.HybridNetwork/networkFunctions@2023-09-01' = [for (values, i) in configObject.deployParameters: {
  name: '${configObject.nfdgName}${i}'
  location: configObject.location
  identity: identityObject
  properties: {
    networkFunctionDefinitionVersionResourceReference: {
      id: nfdv.id
      idType: 'Open'
    }
    nfviType: 'AzureArcKubernetes'
    nfviId: (configObject.customLocationId == '') ? resourceGroupId : configObject.customLocationId
    allowSoftwareUpdate: true
    configurationType: 'Open'
    deploymentValues: string(values)
    roleOverrideValues: [
      '{"name":"Contoso-one","deployParametersMappingRuleProfile":{"helmMappingRuleProfile":{"options":{"installOptions":{"injectArtifactStoreDetails":"true", "atomic": "false"},"upgradeOptions":{"injectArtifactStoreDetails":"true","atomic": "false"}}}}}'
    ]}}]

Criar o modelo do ARM editado e carregá-lo no Repositório de artefatos

  1. Navegue até o diretório nsd-cli-output/artifacts criado pelo comando az aosm nsd build e crie o Modelo do ARM de função de rede a partir do arquivo BICEP gerado pela CLI.

    bicep build <nf-name>.bicep

  2. Gere credenciais de token do mapa de escopo do Manifesto do artefato criado no comando az aosm nsd publish.

    Importante

    Você precisa usar o Manifesto do artefato criado no comando az aosm nsd publish. O modelo do ARM da NF só é declarado nesse manifesto, portanto, somente o token de mapa de escopo gerado por esse manifesto permitirá que você efetue o push (ou o pull) do modelo do ARM da NF para o Repositório de artefatos.

    az rest --method POST --url 'https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.HybridNetwork/publishers/<publisher>/artifactStores/<artifact-store>/artifactManifests/<artifactManifest>/listCredential?api-version=2023-09-01'

  3. Entre no ACR gerenciado pelo AOSM. O nome do ACR gerenciado pelo AOSM pode ser encontrado na visão geral do recurso do Repositório de artefatos do portal do Azure. O nome de usuário e a senha podem ser encontrados na saída da etapa anterior.

    oras login <aosm-managed-acr-name>.azurecr.io --username <username> --password <scope map token>

  4. Use o ORAS para carregar o modelo do ARM da Função de rede para o ACR (Registro de Contêiner do Azure) gerenciado pelo AOSM. A marca de artefato <arm-template-version> deve estar no formato 1.0.0. <arm-template-name> e <arm-template-version> devem corresponder aos valores no Manifesto do artefato criado no comando az aosm nsd publish.

Substituir --atomic por uma NF de gráfico multi-helm

Muitas NFs complexas são criadas a partir de vários gráficos do helm. Essas NFs são expressas na NFDV (Versão da definição de função de rede) com vários aplicativos de função de rede e são instalados com vários comandos de helm install – um por gráfico do helm.

O processo de substituição de --atomic de uma NF multi-helm é o mesmo de uma única NF do helm, além da edição feita no modelo do ARM.

A NF fictícia multi-helm, Contoso-multi-helm, é composta por três gráficos do helm. Sua NFDV tem três aplicativos de função de rede. Um aplicativo de função de rede é mapeado a um gráfico do helm. Esses aplicativos de função de rede têm uma propriedade de nome definida como Contoso-one, Contoso-two e Contoso-three, respectivamente. Aqui está um snippet de exemplo da NFDV definindo essa função de rede.

resource nfdv 'Microsoft.Hybridnetwork/publishers/networkfunctiondefinitiongroups/networkfunctiondefinitionversions@2023-09-01' = {
  parent: nfdg
  name: nfDefinitionVersion
  location: location
  properties: {
    deployParameters: string(loadJsonContent('deployParameters.json'))
    networkFunctionType: 'ContainerizedNetworkFunction'
    networkFunctionTemplate: {
      nfviType: 'AzureArcKubernetes'
      networkFunctionApplications: [
        {
          artifactType: 'HelmPackage'
          name: 'Contoso-one'
          ...
        },
        {
          artifactType: 'HelmPackage'
          name: 'Contoso-two'
          ...
        },
        {
          artifactType: 'HelmPackage'
          name: 'Contoso-three'
          ...
        }]
      }
    }
  }

O parâmetro --atomic pode ser substituído para cada um desses aplicativos de função de rede de forma independente. Aqui está um exemplo de modelo BICEP da NF que substitui --atomic como false por Contoso-one e Contoso-two, mas define atomic como true para Contoso-three.

resource nfResource 'Microsoft.HybridNetwork/networkFunctions@2023-09-01' = [for (values, i) in configObject.deployParameters: {
  name: '${configObject.nfdgName}${i}'
  location: configObject.location
  identity: identityObject
  properties: {
    networkFunctionDefinitionVersionResourceReference: {
      id: nfdv.id
      idType: 'Open'
    }
    nfviType: 'AzureArcKubernetes'
    nfviId: (configObject.customLocationId == '') ? resourceGroupId : configObject.customLocationId
    allowSoftwareUpdate: true
    configurationType: 'Open'
    deploymentValues: string(values)
    roleOverrideValues: [
      '{"name":"Contoso-one","deployParametersMappingRuleProfile":{"helmMappingRuleProfile":{"options":{"installOptions":{"injectArtifactStoreDetails":"true", "atomic": "false"},"upgradeOptions":{"injectArtifactStoreDetails":"true","atomic": "false"}}}}}'
      '{"name":"Contoso-two","deployParametersMappingRuleProfile":{"helmMappingRuleProfile":{"options":{"installOptions":{"injectArtifactStoreDetails":"true", "atomic": "false"},"upgradeOptions":{"injectArtifactStoreDetails":"true","atomic": "false"}}}}}'
      '{"name":"Contoso-three","deployParametersMappingRuleProfile":{"helmMappingRuleProfile":{"options":{"installOptions":{"injectArtifactStoreDetails":"true", "atomic": "false"},"upgradeOptions":{"injectArtifactStoreDetails":"true","atomic": "false"}}}}}'
    ]}}]

Próximas etapas

Agora você pode repetir a implantação do SNS. Você pode enviar a implantação novamente por meio do ARM, do BICEP ou da API REST do AOSM. Você também pode excluir o SNS com falha por meio da visão geral do SNS do portal do Azure e reimplantar após o início rápido do operador, substituindo os parâmetros da NF de início rápido pelos parâmetros para sua função de rede. As versões do helm implantadas no cluster do Kubernetes não serão removidas após uma falha. Como depurar falhas de implantação do SNS descreve um kit de ferramentas para depurar falhas comuns de instalação do helm.