Adicionar recursos do Azure Resource Manager (ARM) a uma versão de design de serviço de rede (NSDV) do Azure Operator Service Manager (AOSM)

O Azure Operator Service Manager (AOSM) permite combinar modelos NFDV (Network Function Definition Versions) e ARM (Azure Resource Manager) em uma NSDV (Network Service Design Version). O NSDV torna-se um modelo único para um Serviço de Rede que contém uma Função de Rede e a infraestrutura do Azure necessária para ser executada. Um operador pode então implantar a Função de Rede (NF) e sua infraestrutura em uma operação.

Neste guia de instruções, você aprenderá a usar a extensão AOSM da CLI do Azure para criar e publicar um NSDV contendo uma Função de Rede Conteinerizada (CNF) e um recurso do Azure Resource Manager (ARM).

A integração é um processo de várias etapas. Depois de atender aos pré-requisitos, você usará a extensão AOSM da CLI do Azure para:

1. Modifique um arquivo de entrada NSDV existente para um CNF integrado anteriormente.
2. Preencha o arquivo de entrada com as informações necessárias para criar as definições de recursos do AOSM.
3. Gere arquivos BICEP que definem um NSDV (Network Service Design Group and Version) com base no arquivo de entrada e no modelo ARM.
4. Publique o NSDV e carregue o Modelo ARM em um Repositório de Artefatos (Registro de Contêiner do Azure (ACR) gerenciado pelo AOSM).

Este guia de instruções usa o Azure Key Vault (AKV) como um exemplo de um Recurso do Azure, no entanto, qualquer recurso do Azure pode ser integrado seguindo as mesmas etapas. Este artigo utiliza um CNF como exemplo de NF; o processo é idêntico para uma função de rede virtualizada (VNF), além de pequenas diferenças no arquivo de entrada NSDV.

Pré-requisitos

• Você habilitou o AOSM em sua assinatura do Azure.
• Se o CNF se destinar a ser executado no Azure Operator Nexus, você terá acesso a uma instância do Azure Operator Nexus e concluiu os pré-requisitos para a implantação da carga de trabalho.
• Você integrou um CNF e tem o arquivo de entrada gerado com o az aosm nsd generate-config arquivo disponível no armazenamento local da máquina a partir da qual está executando a CLI.

Configurar permissões

• Você precisa da função de Colaborador em sua assinatura para criar um Grupo de Recursos ou um Grupo de Recursos existente onde você tenha a função de Colaborador.
• Você precisa das Contributor atribuições e AcrPush de função na assinatura que conterá o Repositório de Artefatos gerenciado pelo AOSM.
  • A política da sua empresa pode impedir que você tenha permissões com escopo de assinatura. O --no-subscription-permissions parâmetro, disponível no az aosm nsd publish comando, usa permissões com escopo restrito derivadas do serviço AOSM para orquestrar uma cópia de duas etapas de e para sua máquina local. Essa cópia em duas etapas é mais lenta, mas não requer permissões com escopo de assinatura.

Modelos de ARM

• Você deve ter um modelo ARM que defina os recursos do Azure que deseja implantar presentes no armazenamento local da máquina a partir da qual você está executando a CLI.
• Todos os parâmetros que você deseja expor ao operador que implantará seu NSDV devem ser definidos como parâmetros no modelo ARM.

Motor Helm e Docker

• Instale a CLI do Helm no computador host. Você deve usar o Helm v3.8.0 ou posterior.
• Instale o Docker no computador host.

Baixar e instalar a CLI do Azure

Para instalar a CLI do Azure localmente, consulte Como instalar a CLI do Azure.

Para entrar na CLI do Azure, use o az login comando e conclua os prompts exibidos no terminal para concluir a autenticação. Para obter mais opções de entrada, consulte Entrar com a CLI do Azure.

Instalar a extensão AOSM CLI

A Extensão AOSM da Az CLI requer a versão 2.54.0 ou posterior da CLI do Azure.

1. Execute az version para ver a versão e as bibliotecas dependentes que estão instaladas.
2. Execute az upgrade para atualizar para a versão atual da CLI do Azure.

Instale a extensão AOSM CLI usando este comando:

az extension add --name aosm

Criar o grupo e a versão do Network Service Design

1. Abra o arquivo de entrada NSDV que você gerou quando integrou seu CNF.

   Nota

   Você pode gerar um novo arquivo de entrada usando o az aosm nsd generate-config --output-file <nsd-output-filename.jsonc> comando se não tiver o arquivo de entrada NSDV da sua integração CNF.

2. Insira os valores necessários usando os comentários embutidos no arquivo de entrada. Este exemplo mostra o arquivo de entrada de extensão AOSM Az CLI para um NSDV Contoso fictício que pode ser usado para implantar um CNF Contoso fictício em um cluster Nexus Kubernetes conectado ao Arc e uma instância AKV em um local do Azure.

   {
       // Azure location to use when creating resources e.g uksouth
       "location": "eastus",
       // Name of the Publisher resource you want your definition published to.
       // Will be created if it does not exist.
       "publisher_name": "contoso",
       // Resource group for the Publisher resource.
       // Will be created if it does not exist.
       "publisher_resource_group_name": "contoso",
       // Name of the ACR Artifact Store resource.
       // Will be created if it does not exist.
       "acr_artifact_store_name": "contoso-artifact-store",
       // Network Service Design (NSD) name. This is the collection of Network Service Design Versions. Will be created if it does not exist.
       "nsd_name": "contoso-nsd",
       // Version of the NSD to be created. This should be in the format A.B.C
       "nsd_version": "1.0.0",
       // Optional. Description of the Network Service Design Version (NSDV).
       "nsdv_description": "An NSD that deploys the onboarded contoso-cnf NFD and an Azure Key Vault",
       // List of Resource Element Templates (RETs).
       // There must be at least one NF RET.
       // ArmTemplate RETs are optional. Delete if not required.
       "resource_element_templates": [
           {
               // Type of Resource Element. Either NF or ArmTemplate
               "resource_element_type": "NF",
               "properties": {
                   // The name of the existing publisher for the NSD.
                   "publisher": "contoso",
                   // The resource group that the publisher is hosted in.
                   "publisher_resource_group": "contoso",
                   // The name of the existing Network Function Definition Group to deploy using this NSD.
                   // This will be the same as the NF name if you published your NFDV using the CLI.
                   "name": "contoso-cnf-nfd",
                   // The version of the existing Network Function Definition to base this NSD on.
                   // This NSD will be able to deploy any NFDV with deployment parameters compatible with this version.
                   "version": "1.0.0",
                   // The region that the NFDV is published to.
                   "publisher_offering_location": "eastus",
                   // Type of Network Function. Valid values are 'cnf' or 'vnf'.
                   "type": "cnf"
               }
           },
           {
               // Type of Resource Element. Either NF or ArmTemplate
               "resource_element_type": "ArmTemplate",
               // Properties of the Resource Element.
               "properties": {
                   // Name of the artifact. Used as internal reference only.
                   "artifact_name": "contoso-keyvault",
                   // Version of the artifact in 1.1.1 format (three integers separated by dots).
                   "version": "1.0.0",
                   // File path (absolute or relative to this configuration file) of the artifact you wish to upload from your local disk.
                   // Use Linux slash (/) file separator even if running on Windows.
                   "file_path": "./contoso-keyvault.json"
               }
           }
       ]
   }
   

   Nota

   A seção de modelo de elemento de recurso define qual NFD está incluído na NSD. As propriedades devem corresponder às usadas no arquivo de entrada passado para o az aosm nfd build comando. Isso ocorre porque a Extensão AOSM da CLI do Azure valida que o NFD foi integrado corretamente ao criar o NSD.

3. Execute o seguinte comando para criar os modelos Network Service Design Group e Version BICEP.

az aosm nsd build --config-file <nsd-output-filename.jsonc>

Você pode revisar a estrutura de pastas e arquivos e fazer modificações, se necessário.

Publicar o Grupo e a Versão do Design do Serviço de Rede

Esta etapa cria os recursos do AOSM que definem o Grupo e a Versão do Design do Serviço de Rede. Ele também carrega artefatos exigidos pelo NSDV para o Repositório de Artefatos (modelo NF ARM e modelo AKV ARM).

1. Execute o seguinte comando para publicar o Network Service Design Group and Version. Se você não tiver escopo Contributor e AcrPush funções de assinatura, inclua --no-subscription-permissions no comando.

az aosm nsd publish --build-output-folder nsd-cli-output

Agora você tem um conjunto completo de recursos do editor AOSM e está pronto para executar o fluxo do operador.

Próximos passos

• Pré-requisitos para Operador
• Criar um Serviço de Rede de Site