Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Neste guia de instruções, os Editores de Funções de Rede e designers de serviço aprendem a usar a extensão AOSM da CLI do Azure para integrar uma função de rede em contêineres ao AOSM. O CNF pode ser implantado posteriormente em um Cluster Kubernetes conectado ao Azure Arc, incluindo um cluster Nexus do Operador Azure.
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:
- Gerar arquivos Bicep que definem um Grupo e Versão de Definição de Função de Rede (NFD) com base nos seus gráficos Helm e values.yaml.
- Publique o NFD e carregue as imagens e gráficos do CNF em um Artifact Store (Registro de Contêiner do Azure (ACR) gerenciado pelo AOSM).
- Adicionar sua NFD publicada aos arquivos Bicep que definem um Grupo e Versão de Design de Serviço de Rede (NSD).
- Publique o NSD.
Pré-requisitos
- Você habilitou o AOSM na sua assinatura do Azure.
- Se o seu CNF for destinado a ser executado no Azure Operator Nexus, você terá acesso a uma instância do Azure Operator Nexus e terá concluído os pré-requisitos para implantação de carga de trabalho.
Observação
É altamente recomendável que você tenha testado se um helm install do seu pacote Helm foi bem-sucedido no seu ambiente Kubernetes conectado ao Arc de destino.
Configurar permissões
- Você precisa da função Colaborador em sua assinatura para criar um Grupo de Recursos ou um Grupo de Recursos existente em que você tenha a função colaborador.
- Você precisa das
Reader/AcrPullatribuições de função no ACR de origem que contém suas imagens. - Você precisa das atribuições de função
ContributoreAcrPushna 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.- Sua política de empresa pode impedir que você tenha permissões com escopo de assinatura. O parâmetro
--no-subscription-permissions, disponível nos comandosaz aosm nfd publisheaz aosm nsd publish, usa permissões com escopo rígido derivadas do serviço AOSM para orquestrar a cópia em duas etapas para e desde o seu computador local. Essa cópia em duas etapas é mais lenta, mas não requer permissões no escopo da assinatura.
- Sua política de empresa pode impedir que você tenha permissões com escopo de assinatura. O parâmetro
Pacotes do Helm
- Os pacotes do Helm que você pretende integrar devem estar presentes no armazenamento local do computador do qual você está executando a CLI.
- A extensão AOSM da CLI do Azure usará o arquivo
values.yamlno pacote Helm por padrão. A CLI dá suporte à substituição desse comportamento com uma alternativavalues.yaml. Esse arquivo alternativo deve existir no armazenamento local do computador do qual você está executando a CLI.
- A extensão AOSM da CLI do Azure usará o arquivo
Observação
É altamente recomendável que o pacote Helm contenha um esquema para os valores do Helm e que os modelos do pacote Helm, conforme esperado quando helm template, sejam executados usando o values.yaml que você pretende usar ao integrar o AOSM.
Imagens de contêiner
- Suas imagens de contêiner estão presentes em um ACR existente ou em um registro de contêiner alternativo que dá suporte à API do Docker. As imagens de contêiner devem ser armazenadas no seu registro de origem em uma estrutura que corresponda ao local da imagem definido nos seus gráficos do Helm. Esse requisito é explicado em Descoberta e upload de imagem CLI CNF.
- Use o comando
docker loginpara entrar em um registro de contêiner fora do Azure que hospede suas imagens de contêiner antes de executar qualquer comandoaz aosm. Essa etapa não será necessária se você estiver usando um ACR: a extensão AOSM da CLI do Azure entrará automaticamente.
Helm e motor Docker
- Instale a CLI do Helm no computador host. É necessário 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 comando az login e preencha os prompts exibidos no seu terminal para concluir a autenticação. Para ver mais opções de entrada, confira Entrar na CLI do Azure.
Observação
Se você estiver executando no Windows ou no macOS, considere executar a CLI do Azure em um contêiner do Docker. Para obter mais informações, confira Como executar a CLI do Azure em um contêiner do Docker. Você também pode usar o ambiente Bash no Azure Cloud Shell. Para obter mais informações, consulte Iniciar o Cloud Shell para usar o ambiente Bash no Azure Cloud Shell.
Instalar a extensão da CLI do AOSM
A Extensão AOSM da CLI do Az requer a versão 2.54.0 ou posterior da CLI do Azure.
- Execute
az versionpara ver a versão e as bibliotecas dependentes que estão instaladas. - Execute
az upgradepara atualizar para a versão mais recente da CLI do Azure.
Instale a extensão da CLI do AOSM usando este comando:
az extension add --name aosm
Criar o Grupo de Definição de Função de Rede e sua Versão
Esta etapa cria uma pasta no diretório de trabalho chamada cnf-cli-output com os arquivos Bicep dos recursos AOSM que definem o Grupo e a Versão de Definição de Função de Rede e o Repositório de Artefatos. Esses recursos serão incluídos no design do serviço de rede.
Gere o arquivo de entrada da extensão AOSM do 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. Esse exemplo mostra o arquivo de entrada da extensão Az CLI AOSM para um CNF fictício da Contoso.
Observação
A extensão AOSM da CLI do Azure expõe apenas os parâmetros necessários sem valores padrão na entrada
values.yamlpor padrão. Você pode definirexpose_all_parameterscomotruepara expor todos os valores do helm 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 CLI do AOSM.{ // 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 arquivos Network Function Definition Group e Version Bicep.
az aosm nfd build --definition-type cnf --config-file <filename.jsonc>
Você pode examinar a estrutura de pastas e arquivos e fazer modificações, se necessário.
Publicar o grupo de definição de função de rede e a versão
Esta etapa cria os recursos 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 os gráficos para o Artifact Store, copiando-os diretamente do ACR de origem ou, se você não tiver escopo de assinatura Contributor e funções AcrPush, remarcando as imagens do Docker localmente e carregando para o Artifact Store usando credenciais de escopo restrito geradas pelo serviço AOSM.
- Execute o comando a seguir para publicar o Grupo de Definição de Função de Rede e a Versão. Se você não tiver escopo de assinatura
ContributoreAcrPushfunções, inclua--no-subscription-permissionsno comando.
Observação
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
Crie o grupo de design de serviço de rede e a versão
Esta seção cria uma pasta no diretório de trabalho chamado nsd-cli-output. Essa pasta contém os arquivos Bicep dos recursos do AOSM que definem um Grupo de Design de Serviço de Rede e uma Versão. Esse Design de Serviço de Rede é um modelo usado no recurso Serviço de Rede do Site que implantará a Função de Rede que você integrou nas seções anteriores.
Gere o arquivo de entrada NSD da extensão AOSM do 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
resource_element_typeadicional do tipoArmTemplate. 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 da extensão Az CLI AOSM para um NSD Contoso 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" } } ] }Observação
A seção de modelo de elemento de recurso define qual NFD está incluído no NSD. As propriedades devem corresponder às usadas no arquivo de entrada passado para o comando
az aosm nfd build. Isso ocorre porque a Extensão AOSM da CLI do Azure valida que o NFD foi integrado corretamente ao compilar o NSD.Execute o seguinte comando para criar os arquivos Network Service Design Group e Version Bicep.
az aosm nsd build --config-file <nsd-output-filename.jsonc>
Você pode examinar a estrutura de pastas e arquivos e fazer modificações, se necessário.
Publicar o grupo de design e a versão do serviço de rede
Esta etapa cria os recursos AOSM que definem o Grupo de Design do Serviço de Rede e a Versão. Ele também carrega artefatos exigidos pelo NSD para o Artifact Store (modelo ARM de função de rede).
- Execute o comando a seguir para publicar o Grupo de Design e a Versão do Serviço de Rede. Se você não tiver escopo de assinatura
ContributoreAcrPushfunções, inclua--no-subscription-permissionsno comando.
az aosm nsd publish --build-output-folder nsd-cli-output
Agora você tem um conjunto completo de recursos do publicador AOSM e está pronto para executar o fluxo do operador.