Share via

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

  • Artigo

Neste guia de instruções, os Editores de Função de Rede e os Designers de Serviço aprendem a usar a extensão da CLI do Azure para começar a usar as Definições de Função de Rede (NFDs) e os Designs de Serviço de Rede (NSDs).

A az aosm extensão CLI destina-se a fornecer suporte para a publicação de designs e definições do Azure Operator Service Manager. A extensão CLI ajuda no processo de publicação de Definições de Função de Rede (NFDs) e Designs de Serviço de Rede (NSDs) para usar com o Azure Operator Service Manager.

Pré-requisitos

Entre em contato com sua equipe de conta da Microsoft para registrar sua assinatura do Azure para acessar o Azure Operator Service Manager (AOSM) ou expressar seu interesse por meio do formulário de registro de parceiro.

Baixar e instalar a CLI do Azure

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

Para usuários que preferem executar comandos de referência da CLI localmente, consulte Como instalar a CLI do Azure.

Se você estiver executando no Windows ou macOS, considere executar a CLI do Azure em um contêiner do Docker. Para obter mais informações, consulte Como executar a CLI do Azure em um contêiner do Docker.

Se você estiver usando uma instalação local, entre na CLI do Azure usando o az login comando e conclua os prompts exibidos em seu terminal para concluir a autenticação. Para obter mais opções de entrada, consulte Entrar com a CLI do Azure.

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

Instale a extensão da CLI do Azure Operator Service Manager (AOSM) usando este comando:

az extension add --name aosm
  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.

Registrar e verificar os provedores de recursos necessários

Antes de começar a usar o Azure Operator Service Manager, certifique-se de registrar o provedor de recursos necessário. Execute os seguintes comandos. Este processo de registo pode demorar até 5 minutos.

# Register Resource Provider
az provider register --namespace Microsoft.HybridNetwork
az provider register --namespace Microsoft.ContainerRegistry

Verifique o status de registro dos provedores de recursos. Execute os seguintes comandos.

# Query the Resource Provider
az provider show -n Microsoft.HybridNetwork --query "{RegistrationState: registrationState, ProviderName: namespace}"
az provider show -n Microsoft.ContainerRegistry --query "{RegistrationState: registrationState, ProviderName: namespace}"

Nota

Pode levar alguns minutos para que o registro do provedor de recursos seja concluído. Depois que o registro for bem-sucedido, você poderá continuar usando o Azure Operator Service Manager (AOSM).

Requisitos da função de rede conteinerizada (CNF)

Para aqueles que utilizam funções de rede conteinerizadas, é essencial garantir que os seguintes pacotes sejam instalados na máquina a partir da qual você está executando a CLI:

  • Instale o Helm, consulte Install Helm CLI.
  • Em algumas circunstâncias, instale o docker, consulte Instalar o mecanismo do Docker. Apenas necessário se a imagem de origem estiver no repositório docker local ou se você não tiver permissões para toda a assinatura necessárias para enviar gráficos e imagens.

Permissões

É necessária uma conta do Azure com uma subscrição ativa. Se você não tiver uma assinatura do Azure, siga as instruções aqui Comece grátis para criar uma conta antes de começar.

Você precisa da função de Colaborador nesta assinatura para criar um Grupo de Recursos ou um Grupo de Recursos existente onde você tenha a função de Colaborador.

Permissões para publicação de CNFs

Se estiver adquirindo as imagens CNF de um ACR existente, você precisará ter Reader/AcrPull permissões desse ACR e, idealmente, Contributor função + AcrPush função (ou uma função personalizada que permita a ação e AcrPush) ao longo de toda a importImage assinatura para poder importar para o novo repositório de artefatos. Se você tiver isso, não precisará que o docker seja instalado localmente e a cópia da imagem será rápida.

Se você não tiver as permissões de toda a assinatura, poderá executar o comando usando o sinalizador para puxar a imagem para sua máquina local e, em seguida, enviá-la por push para o Repositório de Artefatos usando credenciais de manifesto com escopo apenas para o az aosm nfd publish--no-subscription-permissions armazenamento. Requer que o docker seja instalado localmente.

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

Os Editores de Funções de Rede e os Designers de Serviços usam a extensão da CLI do Azure para ajudar com a publicação de Definições de Função de Rede (NFDs) e Designs de Serviço de Rede (NSDs).

Conforme explicado em Funções e Interfaces, um Editor de Funções de Rede tem várias responsabilidades. A extensão CLI auxilia com os itens mostrados em negrito:

  • Crie a função de rede.
  • Codifique isso em um NFD (Network Function Design).
  • Determine os parâmetros de implantação a serem expostos ao Service Designer.
  • Integre o Network Function Design (NFD) ao Azure Operator Service Manager (AOSM).
  • Carregue os artefatos associados.
  • Valide o projeto de função de rede (NFD).

Um Service Designer também tem várias responsabilidades, das quais a extensão CLI auxilia com os itens em negrito:

  • Escolha quais definições de função de rede estão incluídas no Design de serviço.
  • Codifique isso em um Design de Serviço de Rede.
  • Combine a infraestrutura do Azure no Design de Serviço de Rede.
  • Determine como parametrizar o serviço definindo um ou mais esquemas de grupo de configuração (CGSs).
  • Determine como as entradas do Operador de Serviço são mapeadas para os parâmetros exigidos pelas Definições de Função de Rede e pela infraestrutura do Azure.
  • Integre o Network Service Design (NSD) ao Azure Operator Service Manager (AOSM).
  • Carregue os artefatos associados.
  • Valide o Network Service Design (NSD).

Resumo do fluxo de trabalho

Um fluxo de trabalho genérico de uso da extensão CLI é:

  1. Encontre os itens de pré-requisito necessários para o seu caso de uso.

  2. Execute um comando para gerar um generate-config arquivo de configuração JSON de exemplo para comandos subsequentes.

  3. Preencha o arquivo de configuração.

  4. Execute um comando para gerar um build ou mais modelos de bíceps para sua Definição de Função de Rede ou Design de Serviço de Rede.

  5. Revise a saída do comando build, edite a saída conforme necessário para suas necessidades.

  6. Execute um publish comando para:

    • Crie todos os recursos de pré-requisito, como Grupo de Recursos, Editor, Repositórios de Artefatos, Grupos.
    • Implante esses modelos de bíceps.
    • Carregue artefatos para as lojas de artefatos.

Ponto de partida do VNF

Para VNFs, você precisa de um único modelo ARM que criaria os recursos do Azure para sua VNF, por exemplo, uma máquina virtual, discos e NICs. O modelo ARM deve ser armazenado na máquina a partir da qual você está executando a CLI.

Para versões de definição de função de rede virtualizada (VNF NFDVs), a lista networkFunctionApplications deve conter um VhdImageFile e um modelo ARM. É incomum incluir mais de um VhdImageFile e mais de um modelo ARM. A menos que você tenha um motivo forte para não fazê-lo, o modelo ARM deve implantar uma única VM. O Designer de Serviços deve incluir várias cópias da Definição de Função de Rede (NFD) com o Design de Serviço de Rede (NSD) se você quiser implantar várias VMs. O modelo ARM (para AzureCore e Nexus) só pode implantar recursos ARM dos seguintes Provedores de Recursos:

  • Microsoft.Compute

  • Microsoft.Network

  • Microsoft.NetworkCloud

  • Microsoft.Storage

  • Microsoft.NetworkFabric

  • Microsoft.Authorization

  • Microsoft.ManagedIdentity

Você também precisa de uma imagem VHD que seria usada para a máquina virtual VNF. A imagem VHD pode ser armazenada na máquina a partir da qual está a executar a CLI ou no armazenamento de blobs do Azure acessível através de um URI SAS.

Ponto de partida do CNF

Para implantações de CNFs (Containerized Network Functions), é crucial ter o seguinte armazenado na máquina a partir da qual você está executando a CLI:

  • Pacotes Helm com Esquema - Esses pacotes devem estar presentes em seu armazenamento local e referenciados input.json no arquivo de configuração. Ao seguir este início rápido, você baixa o pacote de leme necessário.

  • Criando um arquivo de configuração de exemplo - Gere um arquivo de configuração de exemplo para definir uma implantação CNF. Execute este comando para gerar um input.json arquivo que você precisa preencher com sua configuração específica.

    az aosm nfd generate-config

  • Imagens para o seu CNF - Aqui estão as opções:

    • Uma referência a um Registro de Contêiner do Azure existente que contém as imagens para seu CNF. Atualmente, apenas um ACR e namespace são suportados por CNF. As imagens a serem copiadas deste ACR são preenchidas automaticamente com base no esquema do pacote helm. Você deve ter permissões Reader/AcrPull neste ACR. Para usar essa opção, preencha source_registry e, opcionalmente source_registry_namespace , o arquivo input.json.
    • O nome da imagem do docker de origem da máquina local. Este nome de imagem é para um caso de uso limitado em que o CNF requer apenas uma única imagem docker que existe no repositório docker local. Para usar essa opção, preencha source_local_docker_image o arquivo input.json. Requer que o docker seja instalado. Este guia de início rápido orienta você através do download de uma imagem do docker nginx para usar nessa opção.

  • Opcional: Arquivo de mapeamento (path_to_mappings): Opcionalmente, você pode fornecer um arquivo (no disco) chamado path_to_mappings. Esse arquivo deve espelhar values.yamlo , com os valores selecionados substituídos por parâmetros de implantação. Ao fazê-lo, expõe-os como parâmetros ao CNF. Ou, você pode deixar isso em input.json branco e a CLI gera o arquivo. Por padrão, nesse caso, cada valor dentro values.yaml é exposto como um parâmetro de implantação. Como alternativa, use o --interactive argumento CLI para fazer escolhas interativamente. Este guia de início rápido orienta você através da criação deste arquivo.

Ao configurar o input.json arquivo, certifique-se de listar os pacotes Helm na ordem em que devem ser implantados. Por exemplo, se o pacote "A" deve ser implantado antes do pacote "B", você input.json deve se assemelhar à seguinte estrutura:

"helm_packages": [
    {
        "name": "A",
        "path_to_chart": "Path to package A",
        "path_to_mappings": "Path to package A mappings",
        "depends_on": [
            "Names of the Helm packages this package depends on"
        ]
    },
    {
        "name": "B",
        "path_to_chart": "Path to package B",
        "path_to_mappings": "Path to package B mappings",
        "depends_on": [
            "Names of the Helm packages this package depends on"
        ]
    }
]

Seguir essas diretrizes garante uma abordagem bem organizada e estruturada para implantar Funções de Rede Conteinerizadas (CNFs) com pacotes Helm e configurações associadas.

Ponto de partida da NSD

Para NSDs, você precisa saber os detalhes das Definições de Função de Rede (NFDs) para incorporar em seu design:

  • o grupo de recursos do NFD Publisher
  • o nome e o âmbito do editor NFD
  • o nome do Grupo de Definição de Função de Rede
  • a localização, o tipo e a versão da Versão de Definição de Função de Rede

Você pode usar os az aosm nfd comandos para criar todos esses recursos.

Comandos do Azure Operator Service Manager (AOSM)

Use estes comandos antes de começar:

  1. az login usado para entrar na CLI do Azure.

  2. az account set --subscription <subscription> usado para escolher a assinatura na qual você deseja trabalhar.

Comandos NFD

Obtenha ajuda sobre argumentos de comando:

  • az aosm -h

  • az aosm nfd -h

  • az aosm nfd build -h

Comandos de tipo de definição

Todos esses comandos usam um --definition-type argumento de vnf ou cnf.

Crie um arquivo de configuração de exemplo para criar uma definição:

  • az aosm nfd generate-config

Este comando gera um arquivo chamado input.json, que deve ser preenchido. Uma vez que o arquivo de configuração é preenchido, os seguintes comandos podem ser executados.

Crie uma definição de NFD localmente:

  • az aosm nfd build --config-file input.json

Mais opções sobre como criar uma definição de NFD localmente:

  • Escolha quais dos parâmetros de modelo VNF ARM você deseja expor como NFD deploymentParameters, com a opção de escolher interativamente cada um:

    • az aosm nfd build --config-file input.json --definition_type vnf --order_params
    • az aosm nfd build --config-file input.json --definition_type vnf --order_params --interactive

Escolha quais dos parâmetros de valores do CNF Helm você deseja expor como deploymentParameters NFD:

  • az aosm nfd build --config-file input.json --definition_type cnf --interactive

Publique uma definição pré-criada:

  • az aosm nfd publish --config-file input.json

Suprimir uma definição publicada:

  • az aosm nfd delete --config-file input.json

Exclua uma definição publicada e o editor, os repositórios de artefatos e o grupo NFD:

  • az aosm nfd delete --config-file input.json --clean

Comandos NSD

Obtenha ajuda sobre argumentos de comando:

  • az aosm -h

  • az aosm nsd -h

  • az aosm nsd build -h

Crie um arquivo de configuração de exemplo para criar uma definição:

  • az aosm nsd generate-config

Este comando gera um arquivo chamado input.json, que deve ser preenchido. Uma vez que o arquivo de configuração é preenchido, os seguintes comandos podem ser executados.

Construa uma NSD localmente:

  • az aosm nsd build --config-file input.json

Publique um projeto pré-construído:

  • az aosm nsd publish --config-file input.json

Excluir um design publicado:

  • az aosm nsd delete --config-file input.json

Exclua um design publicado e o editor, os repositórios de artefatos e o grupo NSD:

  • az aosm nsd delete --config-file input.json --clean

Edite a saída da compilação antes de publicar

A az aosm extensão CLI destina-se a fornecer suporte para a publicação de designs e definições do Azure Operator Service Manager. Ele fornece os blocos de construção para a criação de designs e definições personalizados complexos. Você pode editar a saída de arquivos pelo comando antes de build executá-lo publish , para adicionar recursos mais complexos ou personalizados.

A referência completa da API para o Azure Operator Service Manager está aqui: API REST da Rede Híbrida do Azure.

As seções a seguir descrevem algumas maneiras comuns que você pode usar para editar os arquivos criados antes de publicar.

Definições de função de rede (NFDs)

  • Altere o versionStatenetworkfunctiondefinitionversions recurso de Preview para Active. Os NFDVs ativos são imutáveis, enquanto os NFDVs de visualização são mutáveis e estão em estado de rascunho.
  • Para CNFs, altere o releaseNamespacehelmMappingRuleProfile de para alterar o namespace kubernetes no qual o gráfico é implantado.

Projetos de serviços de rede (NSDs)

  • Adicione a Infraestrutura do Azure ao seu Design de Serviço de Rede (NSD). Adicionar a infraestrutura do Azure ao seu pode envolver:
    • Escrever modelos ARM para implantar a infraestrutura.
    • Adicionando esquemas de grupo de configuração (CGSs) para esses modelos ARM.
    • Adicionar ResourceElementTemplates (RETs) do tipo ArmResourceDefinition à sua NSD. Os RETs têm a mesma NetworkFunctionDefinition aparência que os RETs além do type campo.
    • Adicionando os modelos ARM de infraestrutura ao artifact_manifest.bicep arquivo.
    • Editando os configMappings arquivos para incorporar quaisquer saídas dos modelos de infraestrutura como entradas para o NetworkFunctionDefinition ResourceElementTemplates. Por exemplo: "customLocationId": "{outputparameters('infraretname').infraretname.customLocationId.value}"
    • Editando o para os ResourceElementTemplates (RETs) para garantir que os dependsOnProfileNetworkFunctionDefinition RETs de infraestrutura sejam implantados antes dos NF RETs.
  • Altere o versionStatenetworkservicedesignversions recurso de Preview para Active. As NSDs ativas são imutáveis, enquanto as NSDs de visualização são mutáveis e estão em estado de rascunho.