Problemas da extensão AOSM (Azure Operator Service Manager) da CLI do Azure

Este documento contém uma lista de problemas comuns ao usar a extensão AOSM da CLI do Azure para integrar Funções de Rede e suas resoluções.

Problemas comuns

O publicador já existe na região

Os nomes do publicador devem ser exclusivos em uma região do Azure. Se você vir o seguinte erro, o nome do editor escolhido já está em uso:

Message: A private publisher resource with the name 'nginx-publisher' already exists in the provided region.

Para resolver esse erro:

Se você possui o editor, ele está em seu locatário, e você deseja reutilizá-lo:

O publicador é definido no arquivo de configuração de extensão da CLI do AOSM. Os campos publisher_name e publisher_resource_group_name devem corresponder aos do publicador existente e devem estar no locatário que você está usando para esta implantação.

Altere o publisher_resource_group_name no arquivo de configuração para que ele faça referência ao publicador existente, execute novamente o comando correspondente build e execute novamente o comando publish.

Você não possui o publicador existente:

Use um novo nome de editor.

Falha de upload do artefato NSD (Design do Serviço de Rede)

Pode ocorreu erro com uploads de artefato usando o comando az aosm nsd publish em raras ocasiões. A saída do erro nesse caso é

ValueError: Issue retrieving session url: {'errors': [{'code': 'UNAUTHORIZED', 'message': 'authentication required, visit https://aka.ms/acr/authorization for more information.', 'detail': [{'Type': 'repository', 'Name': 'contoso-nsd', 'Action': 'pull'}, {'Type': 'repository', 'Name': 'contoso-nsd', 'Action': 'push'}]}]}

Para resolver esse erro:

Opção 1. Confirme se você tem as atribuições de função Contributor e AcrPush na assinatura que deseja usar. Atribua-as se ainda não o fez. Se não for possível definir essa atribuição de função, execute o comando az aosm nsd publish com o parâmetro --no-subscription-permissions.

Opção 2. Se essas permissões não resolverem o problema, execute os seguintes comandos na pasta nsd-cli-output/artifacts criada pelo comando az aosm nsd build:

• Crie o Modelo do ARM de Função de Rede a partir do arquivo BICEP gerado pela CLI

bicep build <nf-name>.bicep

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

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'

• Instale o ORAS (Open Container Initiative Registry as Storage) e entre no ACR gerenciado pelo AOSM. O nome do ACR gerenciado pelo AOSM pode ser encontrado na página 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>

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

oras push <aosm-managed-acr-name>.azurecr.io/Contoso-nsd:<arm-template-version> ./nsd-cli-output/artifacts/<nf-name>.json

Falhas de cópia entre locatários

A Extensão AOSM da CLI do Azure não dá suporte nativo a cópias de imagem entre locatários. No entanto, é possível configurar o ambiente da CLI de uma maneira que permita essa funcionalidade. O processo é definir a assinatura padrão do Azure para a assinatura que contém o ACR de origem, entrar no ACR de origem e, em seguida, executar todos os comandos az aosm com o parâmetro --subscription, definindo o valor para a assinatura de destino. As assinaturas de origem e de destino podem estar em locatários diferentes.

az account set --subscription <source-acr-subscription>
az acr login --name <source-acr-name> -u <source-acr-username> -p <source-acr-password> --subscription <source-acr-subscription>
az aosm nfd publish --definition-type cnf --subscription <target-subscription>

Configurações incorretas comuns

A implantação do SNS (Serviço de Rede do Site) falha quando a configuração NSDV (Versão de Design do Serviço de Rede e Site) não corresponde

As tentativas de criação de SNS falharão se a propriedade nfvi do recurso do Site não corresponder à propriedade nfvisFromSite do NSDV. O erro é

{
"statusMessage": "{\"status\":\"Failed\",\"error\":{\"code\":\"ResourceOperationFailure\",\"message\":\"The resource operation completed with terminal provisioning state 'Failed'.\",\"details\":[{\"code\":\"InvalidRequestContent\",\"message\":\"For NfviAlias = nfvi1, either NfviName = nsd-contoso_NFVI and NfviType = AzureCore does not match with site resource.\"}]}}",
}

Neste exemplo, a propriedade nfvisFromSite NSDV contém:

    nfvisFromSite: {
      nfvi1: {
        name: 'nsd-contoso_NFVI1'
        type: 'AzureArcKubernetes'
      }

A propriedade nfvi de recurso do Site deve corresponder ao nome e ao tipo no NSDV.

resource site 'Microsoft.HybridNetwork/sites@2023-09-01' = {
  name: 'contoso-site'
  location: 'eastus'
  properties: {
    nfvis : [
      {
        name: 'nsd-contoso_NFVI1'
        nfviType: 'AzureArcKubernetes'
        customLocationReference: {
          id: '<custom-location-arm-id>'
        }
      }
    ]
  }
}

O nfdvName no Valor do Grupo de Configuração (CGV) não corresponde à Versão de Definição de Função de Rede (NFDV) publicada

Os esquemas de grupo de configuração gerados pela Extensão AOSM da CLI do Azure têm um parâmetro obrigatório chamado nfdvName. nfdvname é o nome do NFDV, que é uma cadeia de caracteres no formato 1.0.0. Não é o nome da Função de Rede (NF) ou do Grupo de Definição de Função de Rede (NFDG). O exemplo a seguir mostra o uso correto.

{
    "nsd-contoso": {
        "nfdvName": "1.0.0",
        "deployParameters": [
            {}
        ],
        "customLocationId": "<custom-location-arm-id>",
        "managedIdentityId": "<managed-id-arm-id>"
    }
}

Propriedade de valores CGV incorretos ao expor nenhum parâmetro em um CGS (Esquema de Grupo de Configuração)

Os esquemas de grupo de configuração gerados pela Extensão AOSM da CLI do Azure expõem um campo deployParameters que, por padrão, é uma matriz de objetos JSON. Há vários motivos pelos quais você pode querer criar um CGV com um campo deployParameters vazio:

• Você não tem nenhuma configuração exposta no Esquema de Grupo de Configuração e todos os valores são definidos no values.yaml padrão no gráfico do Helm.
• Você criou um esquema de grupo de configuração que inclui valores padrão e não deseja substituí-los.

Se você estiver criando um CGV com um campo deployParameters vazio, o valor do campo deverá ser uma matriz contendo um objeto JSON vazio.

{
    "nsd-contoso": {
        "nfdv": "1.0.0",
        "deployParameters": [
            {}
        ],
        "customLocationId": "<custom-location-arm-id>",
        "managedIdentityId": "<managed-id-arm-id>"
    }
}

O AOSM retornará a seguinte mensagem de erro se o CGV contiver uma matriz vazia (ou seja, []) em vez de uma matriz contendo um objeto vazio ([{}]).

{"code":"BadRequest","message":"NSDV ResourceElementTemplate (name: 'mco-nsdg', type: 'NetworkFunctionDefinition') expects at least one 'networkfunctions' resource in the associated template. Please use the type: 'ArmResourceDefinition' to install generic ARM resources."}

Incompatibilidade entre a propriedade de imagem em gráficos do Helm e o local no ACR de origem

A CLI do AOSM requer que as imagens no seu registro de origem estejam na mesma estrutura do namespace como escrita no seu gráfico do Helm. Por exemplo, uma imagem incluída em um gráfico do Helm como core/contoso-a:1.0.0 precisa estar disponível no registro de origem em um caminho que termine em core/contoso-a:1.0.0. A falha ao carregar a imagem no caminho correto no registro de origem faz com que az aosm nfd publish falhe com o erro a seguir.

Code: InvalidParameters
Message: Operation registries-cd9ad97d-f3a3-11ee-a728-6b163569f55a failed. Resource /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ContainerRegistry/registries/contoso Invalid message NotFound Not Found {"errors":[{"code":"MANIFEST_UNKNOWN","message":"manifest tagged by \"0.0.0-9\" is not found","detail":{"Tag":"0.0.0-9"}}]}

Há várias soluções disponíveis.

• Edite o gráfico do Helm ou passe os caminhos de imagem em values.yaml e defina os caminhos de imagem para corresponder à estrutura do repositório no registro de origem.
• Carregue as imagens no registro de origem de modo que a concatenação de "image_sources" no arquivo cnf-input.jsonc e o caminho da imagem do gráfico do Helm corresponda ao local carregado no registro de origem.
• A CLI do AOSM armazena metadados para as imagens descobertas em cnf-cli-output/artifacts/artifacts.json. O caminho que a CLI do AOSM pesquisa no registro de origem é <registry_name>/<registry_namespace>/<artifact_name>/<artifact_version>. Você pode editar manualmente esse arquivo para que os valores correspondam à localização da imagem no ACR de origem.

CGVs não correspondem ao CGS quando o parâmetro tem tipo nulo

Atualmente, o AOSM não dá suporte a null como um valor padrão no esquema deployParameters, o que significa que o valor padrão null também não é permitido em Esquemas de Grupo de Configuração. Para contornar esse problema, a CLI do AOSM define o valor padrão para que os parâmetros do tipo nulo sejam a cadeia de caracteres "null", o que permite que um NFDV publique com êxito.

Ao usar o portal para criar CGVs, o parâmetro é filtrado automaticamente para ter "null" como seu valor. Se você não alterar esse valor, o Portal mostrará uma mensagem de erro dizendo: "Novo Valor do Grupo de Configuração não corresponde ao esquema. Edite os valores".

Para corrigir esse erro, altere "null" para null nos CGVs.

Por exemplo, originalmente, temos o valor "null":

"serviceAccount_name": "null",

Que deve ser alterado para o valor null.

"serviceAccount_name": null,