Share via

Uso de la extensión de la CLI de Azure Operator Service Manager (AOSM)

  • Artículo

En esta guía paso a paso, los editores de funciones de red y los diseñadores de servicios aprenden a usar la extensión de la CLI de Azure para empezar a trabajar con definiciones de funciones de red (NFD) y diseños de servicio de red (NSD).

La extensión de la az aosm CLI está pensada para proporcionar compatibilidad con la publicación de diseños y definiciones de Azure Operator Service Manager. La extensión de la CLI ayuda en el proceso de publicación de definiciones de funciones de red (NFD) y diseños de servicio de red (NSD) para usarlos con Azure Operator Service Manager.

Requisitos previos

Póngase en contacto con el equipo de la cuenta microsoft para registrar su suscripción de Azure para acceder a Azure Operator Service Manager (AOSM) o expresar su interés a través del formulario de registro de partners.

Descarga e instalación de la CLI de Azure

Use el entorno de Bash en Azure Cloud Shell. Para más información, consulte Inicio de Cloud Shell para usar el entorno de Bash en Azure Cloud Shell.

Para los usuarios que prefieren ejecutar comandos de referencia de la CLI localmente, consulte Instalación de la CLI de Azure.

Si se ejecuta en Window o macOS, considere la posibilidad de ejecutar la CLI de Azure en un contenedor de Docker. Para más información, vea Ejecución de la CLI de Azure en un contenedor de Docker.

Si usa una instalación local, inicie sesión en la CLI de Azure con el az login comando y complete las indicaciones que se muestran en el terminal para finalizar la autenticación. Para más opciones de inicio de sesión, consulte Inicio de sesión con la CLI de Azure.

Instalación de la extensión de la CLI de Azure Operator Service Manager (AOSM)

Instale la extensión de la CLI de Azure Operator Service Manager (AOSM) mediante este comando:

az extension add --name aosm
  1. Ejecute az version para ver la versión y las bibliotecas dependientes que están instaladas.
  2. Ejecute az upgrade para actualizar a la versión actual de la CLI de Azure.

Registro y comprobación de los proveedores de recursos necesarios

Antes de empezar a usar Azure Operator Service Manager, asegúrese de registrar el proveedor de recursos necesario. Ejecute los siguientes comandos. Este proceso de registro puede tardar hasta 5 minutos.

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

Compruebe el estado de registro de los proveedores de recursos. Ejecute los siguientes 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:

El registro del proveedor de recursos puede tardar unos minutos en completarse. Una vez que el registro se realiza correctamente, puede continuar con el uso de Azure Operator Service Manager (AOSM).

Requisitos de la función de red en contenedores (CNF)

Para aquellos que usan funciones de red en contenedores, es esencial asegurarse de que los siguientes paquetes están instalados en la máquina desde la que se ejecuta la CLI:

  • Instale Helm, consulte Instalación de la CLI de Helm.
  • En algunas circunstancias, instale Docker, consulte Instalación del motor de Docker. Solo es necesario si la imagen de origen está en el repositorio de Docker local o no tiene permisos para toda la suscripción necesarios para insertar gráficos e imágenes.

Permisos

Se requiere una cuenta de Azure con una suscripción activa. Si no tiene una suscripción de Azure, siga las instrucciones que se indican aquí : Comience gratis para crear una cuenta antes de comenzar.

Necesita el rol Colaborador en esta suscripción para crear un grupo de recursos o un grupo de recursos existente en el que tenga el rol Colaborador.

Permisos para publicar CNF

Si abastece las imágenes CNF de un ACR existente, debe tener Reader/AcrPull permisos de este ACR y, idealmente, Contributor rol + AcrPush rol (o un rol personalizado que permita la importImage acción y AcrPush) en toda la suscripción para poder importarlo al nuevo almacén de artefactos. Si los tiene, no es necesario instalar Docker localmente y la copia de la imagen es rápida.

Si no tiene los permisos para toda la suscripción, puede ejecutar el az aosm nfd publish comando con la --no-subscription-permissions marca para extraer la imagen en el equipo local y, a continuación, insertarla en el Almacén de artefactos con credenciales de manifiesto solo en el almacén. Requiere que Docker se instale localmente.

Introducción a la extensión de la CLI de Azure Operator Service Manager (AOSM)

Los editores de funciones de red y los diseñadores de servicios usan la extensión de la CLI de Azure para ayudar con la publicación de definiciones de funciones de red (NFD) y diseños de servicio de red (NSD).

Como se explica en Roles e interfaces, un publicador de funciones de red tiene varias responsabilidades. La extensión de la CLI ayuda con los elementos que se muestran en negrita:

  • Cree la función de red.
  • Codifique eso en un diseño de función de red (NFD).
  • Determine los parámetros de implementación que se van a exponer al Diseñador de servicios.
  • Incorpore el diseño de funciones de red (NFD) a Azure Operator Service Manager (AOSM).
  • Cargue los artefactos asociados.
  • Valide el diseño de funciones de red (NFD).

Un Diseñador de servicios también tiene varias responsabilidades, de las cuales la extensión de la CLI ayuda con los elementos en negrita:

  • Elija qué definiciones de función de red se incluyen en el diseño del servicio.
  • Codifique eso en un diseño de servicio de red.
  • Combine la infraestructura de Azure en el diseño del servicio de red.
  • Determine cómo parametrizar el servicio definiendo uno o varios esquemas de grupo de configuración (CGSs).
  • Determine cómo las entradas del operador de servicio se asignan a los parámetros requeridos por las definiciones de funciones de red y la infraestructura de Azure.
  • Incorpore el diseño del servicio de red (NSD) a Azure Operator Service Manager (AOSM).
  • Cargue los artefactos asociados.
  • Valide el diseño del servicio de red (NSD).

Resumen del flujo de trabajo

Un flujo de trabajo genérico de uso de la extensión de la CLI es:

  1. Busque los elementos previos que necesita para su caso de uso.

  2. Ejecute un generate-config comando para generar un archivo de configuración JSON de ejemplo para los comandos posteriores.

  3. Rellene el archivo de configuración.

  4. Ejecute un build comando para generar una o varias plantillas de bicep para la definición de función de red o el diseño del servicio de red.

  5. Revise la salida del comando de compilación y edite la salida según sea necesario para sus requisitos.

  6. Ejecute un publish comando para:

    • Cree todos los recursos de requisitos previos, como grupo de recursos, publicador, almacenes de artefactos, grupos.
    • Implemente esas plantillas de bicep.
    • Cargue artefactos en los almacenes de artefactos.

Punto de inicio de VNF

En el caso de las VNFs, necesita una sola plantilla de ARM que cree los recursos de Azure para VNF, por ejemplo, una máquina virtual, discos y NIC. La plantilla de ARM debe almacenarse en la máquina desde la que se ejecuta la CLI.

Para las versiones de definición de función de red virtualizada (NFDV de VNF), la lista networkFunctionApplications debe contener un VhdImageFile y una plantilla de ARM. Es inusual incluir más de un VhdImageFile y más de una plantilla de ARM. A menos que tenga una razón fuerte para no hacerlo, la plantilla de ARM debe implementar una sola máquina virtual. El Diseñador de servicios debe incluir numerosas copias de la definición de función de red (NFD) con el diseño del servicio de red (NSD) si desea implementar varias máquinas virtuales. La plantilla de ARM (tanto para AzureCore como Nexus) solo puede implementar recursos de ARM desde los siguientes proveedores de recursos:

  • Microsoft.Compute

  • Microsoft.Network

  • Microsoft.NetworkCloud

  • Microsoft.Storage

  • Microsoft.NetworkFabric

  • Microsoft.Authorization

  • Microsoft.ManagedIdentity

También necesita una imagen de disco duro virtual que se usaría para la máquina virtual VNF. La imagen del disco duro virtual se puede almacenar en la máquina desde la que ejecuta la CLI o en Azure Blob Storage accesible a través de un URI de SAS.

Punto de inicio de CNF

En el caso de las implementaciones de funciones de red en contenedor (CNF), es fundamental tener lo siguiente almacenado en la máquina desde la que está ejecutando la CLI:

  • Paquetes de Helm con esquema : estos paquetes deben estar presentes en el almacenamiento local y se debe hacer referencia a ellos en el archivo de input.json configuración. Al seguir este inicio rápido, descargará el paquete de Helm necesario.

  • Crear un archivo de configuración de ejemplo: genere un archivo de configuración de ejemplo para definir una implementación de CNF. Emita este comando para generar un input.json archivo que necesita rellenar con su configuración específica.

    az aosm nfd generate-config

  • Imágenes para su CNF : estas son las opciones:

    • Referencia a una instancia de Azure Container Registry existente que contiene las imágenes de su CNF. Actualmente, solo se admite un ACR y un espacio de nombres por CNF. Las imágenes que se van a copiar de este ACR se rellenan automáticamente en función del esquema del paquete helm. Debe tener permisos lector/AcrPull en este ACR. Para usar esta opción, rellene source_registry y, opcionalmente source_registry_namespace , en el archivo input.json.
    • Nombre de la imagen de Docker de origen de la máquina local. Este nombre de imagen es para un caso de uso limitado en el que CNF solo requiere una sola imagen de Docker que exista en el repositorio de Docker local. Para usar esta opción, rellene source_local_docker_image el archivo input.json. Requiere que docker esté instalado. Este inicio rápido le guía a través de la descarga de una imagen de Docker de nginx para usarla para esta opción.

  • Opcional: Archivo de asignación (path_to_mappings): opcionalmente, puede proporcionar un archivo (en disco) denominado path_to_mappings. Este archivo debe reflejar values.yaml, con los valores seleccionados reemplazados por parámetros de implementación. Si lo hace, los expone como parámetros al CNF. O bien, puede dejar esto en blanco en input.json y la CLI genera el archivo. De forma predeterminada, en este caso, cada valor de values.yaml se expone como parámetro de implementación. También puede usar el argumento de la --interactive CLI para tomar decisiones de forma interactiva. Este inicio rápido le guía a través de la creación de este archivo.

Al configurar el input.json archivo, asegúrese de enumerar los paquetes de Helm en el orden en que se deben implementar. Por ejemplo, si el paquete "A" debe implementarse antes del paquete "B", input.json debe ser similar a la estructura siguiente:

"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"
        ]
    }
]

Siguiendo estas instrucciones, se garantiza un enfoque bien organizado y estructurado para implementar funciones de red en contenedores (CNFs) con paquetes de Helm y configuraciones asociadas.

Punto de inicio de NSD

En el caso de los NSD, debe conocer los detalles de las definiciones de funciones de red (NFD) para incorporar en el diseño:

  • el grupo de recursos NFD Publisher
  • el nombre y el ámbito del publicador NFD
  • el nombre del grupo de definiciones de función de red
  • la ubicación, el tipo y la versión de la versión de definición de función de red

Puede usar los az aosm nfd comandos para crear todos estos recursos.

Comandos de Azure Operator Service Manager (AOSM)

Use estos comandos antes de comenzar:

  1. az login se usa para iniciar sesión en la CLI de Azure.

  2. az account set --subscription <subscription> se usa para elegir la suscripción en la que desea trabajar.

Comandos NFD

Obtenga ayuda sobre los argumentos de comando:

  • az aosm -h

  • az aosm nfd -h

  • az aosm nfd build -h

Comandos de tipo de definición

Todos estos comandos toman un --definition-type argumento de vnf o cnf.

Cree un archivo de configuración de ejemplo para crear una definición:

  • az aosm nfd generate-config

Este comando genera un archivo denominado input.json, que debe rellenarse. Una vez rellenado el archivo de configuración, se pueden ejecutar los siguientes comandos.

Compile una definición NFD localmente:

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

Más opciones para crear una definición de NFD localmente:

  • Elija cuál de los parámetros de plantilla de ARM de VNF que desea exponer como implementación NFDParameters, con la opción de elegir de forma interactiva cada uno:

    • 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

Elija cuál de los parámetros de valores de Helm de CNF que desea exponer como implementación NFDParameters:

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

Publicar una definición precompilada:

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

Eliminar una definición publicada:

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

Elimine una definición publicada y el publicador, almacenes de artefactos y grupo NFD:

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

Comandos NSD

Obtenga ayuda sobre los argumentos de comando:

  • az aosm -h

  • az aosm nsd -h

  • az aosm nsd build -h

Cree un archivo de configuración de ejemplo para crear una definición:

  • az aosm nsd generate-config

Este comando genera un archivo denominado input.json, que debe rellenarse. Una vez rellenado el archivo de configuración, se pueden ejecutar los siguientes comandos.

Compile un NSD localmente:

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

Publicar un diseño precompilado:

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

Eliminar un diseño publicado:

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

Elimine un diseño publicado y el publicador, almacenes de artefactos y grupo NSD:

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

Edición de la salida de compilación antes de publicar

La extensión de la az aosm CLI está pensada para proporcionar compatibilidad con la publicación de diseños y definiciones de Azure Operator Service Manager. Proporciona los bloques de creación para crear definiciones y diseños personalizados complejos. Puede editar la salida de los archivos mediante el build comando antes de ejecutar el publish comando para agregar características más complejas o personalizadas.

La referencia de API completa de Azure Operator Service Manager está aquí: API REST de azure Hybrid Network.

En las secciones siguientes se describen algunas formas comunes que puede usar para editar los archivos creados antes de publicarlos.

Definiciones de funciones de red (NFD)

  • Cambie el versionStatenetworkfunctiondefinitionversions valor del recurso de Preview a Active. Los NFDV activos son inmutables, mientras que los NFDV en versión preliminar son mutables y en estado de borrador.
  • En el caso de las CNF, cambie el releaseNamespace de helmMappingRuleProfile para cambiar el espacio de nombres de Kubernetes en el que se implementa el gráfico.

Diseños de servicio de red (NSD)

  • Agregue la infraestructura de Azure al diseño del servicio de red (NSD). La adición de la infraestructura de Azure a su puede implicar lo siguiente:
    • Escritura de plantillas de ARM para implementar la infraestructura.
    • Agregar esquemas de grupo de configuración (CGS) para estas plantillas de ARM.
    • Agregar ResourceElementTemplates (RET) de tipo ArmResourceDefinition al NSD. Los RET tienen el mismo aspecto que NetworkFunctionDefinition los RET aparte del type campo.
    • Agregar las plantillas de ARM de infraestructura al artifact_manifest.bicep archivo.
    • Editar los configMappings archivos para incorporar las salidas de las plantillas de infraestructura como entradas a NetworkFunctionDefinition ResourceElementTemplates. Por ejemplo: "customLocationId": "{outputparameters('infraretname').infraretname.customLocationId.value}"
    • Edite para dependsOnProfile ResourceElementTemplates NetworkFunctionDefinition (RET) para asegurarse de que los RET de infraestructura se implementan antes de los RET NF.
  • Cambie el versionStatenetworkservicedesignversions valor del recurso de Preview a Active. Los NSD activos son inmutables, mientras que los NSD de versión preliminar son mutables y en estado de borrador.