Use os parâmetros da opção Helm para evitar a exclusão em caso de falha na instalação

Artigo
05/22/2024

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

Pré-requisitos

Você deve ter integrado seu NF ao AOSM usando a extensão Az CLI AOSM. Este artigo faz referência à estrutura de pastas e aos arquivos gerados pela CLI e fornece exemplos baseados em CLI
As falhas de instalação do leme podem ser complexas. A depuração requer conhecimento técnico de várias tecnologias, além do conhecimento de domínio da sua NF
- Conhecimento prático do Leme
- Conhecimento prático dos comandos Kubernetes e kubectl
- Conhecimento prático de extração e envio de artefatos para o Registro de Contêiner do Azure
Você precisa das Contributor atribuições de função 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 ORAS

Importante

É altamente recomendável que você tenha testado se um helm install de seus pacotes Helm é bem-sucedido em seu ambiente Kubernetes conectado ao Arc de destino antes de tentar uma implantação usando o AOSM.

Substituir `--atomic` para um único gráfico de leme NF

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

Localize e edite o modelo NF BICEP

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

@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)
  }
}]

Localize o nome do aplicativo de função de rede navegando até o cnf-cli-output diretório, abrindo o nfDefinition diretório e copiando o valor da única entrada na matriz networkFunctionApplications no nfdv recurso. Confirme se você tem o valor correto comparando com o seguinte trecho BICEP de exemplo fictício da Contoso. Nesse caso, o nome do aplicativo da 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'

Edite o modelo para substituir a opção de instalação --atomic de leme padrão adicionando a seguinte configuração às nfResource propriedades no Modelo NF ARM:

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

Confirme que você fez essa edição corretamente comparando com o seguinte trecho 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"}}}}}'
    ]}}]

Crie o modelo ARM editado e carregue-o para o Repositório de Artefatos

Navegue até o nsd-cli-output/artifacts diretório criado pelo az aosm nsd build comando e crie o modelo ARM de função de rede a partir do arquivo BICEP gerado pela CLI.
```
bicep build <nf-name>.bicep
```
Gere credenciais de token de mapa de escopo a partir do Manifesto de Artefato criado no az aosm nsd publish comando.

Importante

É necessário usar o Manifesto de Artefato criado no az aosm nsd publish comando. O modelo NF ARM só é declarado nesse manifesto, portanto, somente o token de mapa de escopo gerado por esse manifesto permitirá que você envie (ou extraia) o modelo NF ARM 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'
```
Entre no ACR gerenciado pelo AOSM. O nome ACR gerenciado pelo AOSM pode ser encontrado na visão geral dos recursos 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>
```
Use o ORAS para carregar o modelo ARM da Função de Rede no Registro de Contêiner do Azure (ACR) gerenciado pelo AOSM. A <arm-template-version> tag de artefato deve estar no 1.0.0 formato. O <arm-template-name> e <arm-template-version> deve corresponder aos valores no Manifesto de Artefato criado no az aosm nsd publish comando.

Substituir `--atomic` para um gráfico de vários lemes NF

Muitos NFs complexos são construídos a partir de vários gráficos de leme. Esses NFs são expressos na versão de definição de função de rede (NFDV) com vários aplicativos de função de rede e são instalados com vários helm install comandos - um por gráfico de leme.

O processo de substituição --atomic para uma NF de leme múltiplo é o mesmo que para uma NF de leme único, além da edição feita no modelo ARM.

O NF fictício de vários helms, Contoso-multi-helm, consiste em três gráficos de leme. Seu NFDV tem três aplicações de função de rede. Um aplicativo de função de rede mapeia para um gráfico de leme. Esses aplicativos de função de rede têm uma propriedade name definida como Contoso-one, Contoso-twoe Contoso-three respectivamente. Aqui está um trecho de exemplo do NFDV que define 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 --atomic parâmetro pode ser substituído para cada um desses aplicativos de função de rede independentemente. Aqui está um exemplo de modelo NF BICEP que substitui --atomic para false e Contoso-one 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óximos passos

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

Partilhar via

Use os parâmetros da opção Helm para evitar a exclusão em caso de falha na instalação

Pré-requisitos

Substituir `--atomic` para um único gráfico de leme NF

Localize e edite o modelo NF BICEP

Crie o modelo ARM editado e carregue-o para o Repositório de Artefatos

Substituir `--atomic` para um gráfico de vários lemes NF

Próximos passos

Comentários

Recursos adicionais

Partilhar via

Use os parâmetros da opção Helm para evitar a exclusão em caso de falha na instalação

Pré-requisitos

Substituir --atomic para um único gráfico de leme NF

Localize e edite o modelo NF BICEP

Crie o modelo ARM editado e carregue-o para o Repositório de Artefatos

Substituir --atomic para um gráfico de vários lemes NF

Próximos passos

Comentários

Recursos adicionais

Substituir `--atomic` para um único gráfico de leme NF

Substituir `--atomic` para um gráfico de vários lemes NF