Integrar uma função de rede conteinerizada (CNF) ao Azure Operator Service Manager (AOSM)

Artigo
05/22/2024

Neste guia de instruções, os Editores de Função de Rede e os Designers de Serviço aprendem a usar a extensão AOSM da CLI do Azure para integrar uma função de rede conteinerizada ao AOSM. O CNF pode ser implantado posteriormente em um cluster Kubernetes conectado ao Azure Arc, incluindo um cluster do Azure Operator Nexus.

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:

Gere arquivos BICEP que definem um Grupo e Versão de Definição de Função de Rede (NFD) com base em seus gráficos e valores Helm.yaml.
Publique o NFD e carregue as imagens e gráficos CNF em um Repositório de Artefatos (Azure Container Registry (ACR) gerenciado pelo AOSM).
Adicione seu NFD publicado aos arquivos BICEP que definem um Network Service Design Group and Version (NSD).
Publique a NSD.

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.

Nota

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

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 Reader/AcrPull atribuições de função no ACR de origem que contém suas imagens.
Você precisa das Contributor atribuições e AcrPush de função na assinatura que conterá o Repositório de Artefatos gerenciado pelo AOSM. Essas permissões permitem que a Extensão AOSM da CLI do Azure faça uma cópia direta de ACR para ACR. A cópia direta é o método mais rápido de transferir imagens de um ACR para outro.
- 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 nos az aosm nfd publish comandos and az aosm nsd publish , 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.

Pacotes Helm

Os pacotes Helm que você pretende integrar devem estar presentes no armazenamento local da máquina a partir da qual você está executando a CLI.
- A extensão AOSM da CLI do Azure usará o values.yaml arquivo no pacote helm por padrão. A CLI oferece suporte à substituição desse comportamento por uma alternativa values.yaml. Esse arquivo alternativo deve existir no armazenamento local da máquina a partir da qual você está executando a CLI.

Nota

É altamente recomendável que o pacote Helm contenha um esquema para os valores helm e que os modelos de pacote helm como você espera quando helm template for executado usando o values.yaml que você pretende usar ao integrar ao AOSM.

Imagens de contentor

Suas imagens de contêiner estão presentes em um ACR existente ou em um registro de contêiner alternativo que ofereça suporte à API do Docker. As imagens de contêiner devem ser armazenadas em seu registro de origem em uma estrutura que corresponda ao local da imagem definido em seus gráficos de leme. Este requisito é explicado na descoberta e upload de imagens CNF da CLI.
Use o docker login comando para entrar em um registro de contêiner que não seja do Azure hospedando suas imagens de contêiner antes de executar qualquer az aosm comando. Esta etapa não é necessária se você estiver usando um ACR: a extensão AOSM da CLI do Azure entrará automaticamente.

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.

Nota

Se estiver a utilizar o Windows ou macOS, considere executar a CLI do Azure num contentor Docker. Para obter mais informações, consulte Como executar a CLI do Azure em um contêiner do Docker. Você também pode usar o ambiente Bash no shell de nuvem do Azure. Para obter mais informações, consulte Iniciar o Cloud Shell para usar o ambiente Bash no Azure Cloud Shell.

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.

Execute az version para ver a versão e as bibliotecas dependentes que estão instaladas.
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 de Definição de Função de Rede

Esta etapa cria uma pasta no diretório de trabalho chamada cnf-cli-output com os modelos BICEP dos recursos AOSM que definem seu Grupo e Versão de Definição de Função de Rede e o Repositório de Artefatos. Em última análise, esses recursos serão incluídos no seu Design de Serviço de Rede.

Gere o arquivo de entrada de extensão AOSM da CLI do Azure para um CNF.

az aosm nfd generate-config --definition-type cnf --output-file <filename.jsonc>

Abra o arquivo de entrada gerado na etapa anterior e use os comentários embutidos para inserir os valores necessários. Este exemplo mostra o arquivo de entrada da extensão AOSM Az CLI para um CNF fictício da Contoso.

Nota

A extensão AOSM da CLI do Azure expõe apenas os parâmetros necessários sem valores padrão na entrada values.yaml por padrão. Você pode definir expose_all_parameters para true expor todos os valores de leme na Versão de Definição de Função de Rede (NFDV) e no Esquema de Grupo de Configuração (CGS). Para obter mais informações, consulte Exposição de parâmetros usando a extensão AOSM CLI.

{
  // 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.
  // You should create this before running the publish command
  "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",
  // Name of NF definition.
  "nf_name": "contoso-cnf-nfd",
  // Version of the NF definition in 1.1.1 format (three integers separated by dots).
  "version": "1.0.0",
  // If set to true, all NFD configuration parameters are made available to the designer, including optional parameters and those with defaults.
  // If not set or set to false, only required parameters without defaults will be exposed.
  "expose_all_parameters": false,
  // List of registries from which to pull the image(s).
  // For example ["sourceacr.azurecr.io/test", "myacr2.azurecr.io", "ghcr.io/path"].
  // For non Azure Container Registries, ensure you have run a docker login command before running build.
  "image_sources": ["contoso.azuercr.io/contoso", "docker.io"],
  // List of Helm packages to be included in the CNF.
  "helm_packages": [
      {
          // The name of the Helm package.
          "name": "contoso-helm-package",
          // The file path to the helm chart on the local disk, relative to the directory from which the command is run.
          // Accepts .tgz, .tar or .tar.gz, or an unpacked directory. Use Linux slash (/) file separator even if running on Windows.
          "path_to_chart": "/home/cnf-onboard/contoso-cnf-helm-chart-0-1-0.tgz",
          // The file path (absolute or relative to this configuration file) of YAML values file on the local disk which will be used instead of the values.yaml file present in the helm chart.
          // Accepts .yaml or .yml. Use Linux slash (/) file separator even if running on Windows.
          "default_values": "",
      }
  ]
}

Execute o seguinte comando para criar os modelos Network Function Definition Group e Version BICEP.

az aosm nfd build --definition-type cnf --config-file <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 grupo de definições de função de rede

Esta etapa cria os recursos do AOSM que definem a Definição de Função de Rede e o Repositório de Artefatos que serão usados para armazenar as imagens de contêiner da Função de Rede. Ele também carrega as imagens e gráficos para o Repositório de Artefatos copiando-os diretamente do ACR de origem ou, se você não tiver escopo Contributor e AcrPush funções de assinatura, remarcando as imagens do docker localmente e carregando para o Repositório de Artefatos usando credenciais com escopo restrito geradas a partir do serviço AOSM.

Execute o seguinte comando para publicar o Grupo e a Versão de Definição de Função de Rede. Se você não tiver escopo Contributor e AcrPush funções de assinatura, inclua --no-subscription-permissions no comando.

Nota

Se você estiver usando o Windows, deverá ter o Docker Desktop em execução durante a etapa de publicação.

az aosm nfd publish --build-output-folder cnf-cli-output --definition-type cnf

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

Esta seção cria uma pasta no diretório de trabalho chamada nsd-cli-output. Esta pasta contém os modelos BICEP dos recursos AOSM que definem um Grupo e Versão de Design de Serviço de Rede. Este Design de Serviço de Rede é um modelo usado no recurso Serviço de Rede do Site que implantará a Função de Rede integrada nas seções anteriores.

Gere o arquivo de entrada NSD da extensão AOSM da CLI do Azure.

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

Abra o arquivo de entrada gerado na etapa anterior e use os comentários embutidos para inserir os valores necessários. O arquivo de entrada gerado contém um adicional resource_element_type do tipo ArmTemplate. Isso é desnecessário ao integrar um CNF; você pode excluí-lo. O resultado deve ser semelhante a este exemplo. O exemplo mostra o arquivo de entrada Az CLI AOSM extension para um Contoso NSD fictício que pode ser usado para implantar um CNF Contoso fictício em um cluster Nexus Kubernetes conectado ao Arc.

{
    // 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",
    // 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"
            }
        }
    ]
}

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.

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 pela NSD para o Repositório de Artefatos (modelo ARM de Função de Rede).

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.

Partilhar via

Integrar uma função de rede conteinerizada (CNF) ao Azure Operator Service Manager (AOSM)

Pré-requisitos

Configurar permissões

Pacotes Helm

Imagens de contentor

Motor Helm e Docker

Baixar e instalar a CLI do Azure

Instalar a extensão AOSM CLI

Criar o Grupo e a Versão de Definição de Função de Rede

Publicar o grupo e a versão do grupo de definições de função de rede

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

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

Próximos passos

Comentários

Recursos adicionais