Incorporación de una función de red en contenedor (CNF) a Azure Operator Service Manager (AOSM)
En esta guía paso a paso, los publicadores de funciones de red y los diseñadores de servicios aprenden a usar la extensión AOSM de la CLI de Azure para incorporar una función de red en contenedores a AOSM. El CNF se puede implementar más adelante en un clúster de Kubernetes conectado a Azure Arc, incluido un clúster Azure Operator Nexus.
La incorporación es un proceso de varios pasos. Una vez que cumpla los requisitos previos, usará la extensión AOSM de la CLI de Azure para:
- Genere archivos BICEP que definan un grupo de definiciones de función de red y una versión (NFD) basados en los gráficos y valores de Helm.yaml.
- Publique NFD y cargue las imágenes y gráficos de CNF en un almacén de artefactos (Azure Container Registry (ACR) administrado por AOSM).
- Agregue el NFD publicado a los archivos BICEP que definen un grupo de diseño de servicios de red y una versión (NSD).
- Publique el NSD.
Requisitos previos
- Ha habilitado AOSM en la suscripción de Azure.
- Si la CNF está pensado para ejecutarse en Azure Operator Nexus, tiene acceso a una instancia de Azure Operator Nexus y ha completado los requisitos previos para la implementación de cargas de trabajo.
Nota:
Se recomienda encarecidamente que haya probado que una instancia helm install
del paquete de Helm se ejecuta correctamente en el entorno de Kubernetes conectado a Arc de destino.
Configuración de permisos
- Necesita el rol Colaborador en la suscripción para crear un grupo de recursos o un grupo de recursos existente en el que tenga el rol Colaborador.
- Necesita las
Reader
/AcrPull
asignaciones de roles en el ACR de origen que contiene las imágenes. - Necesita las asignaciones de roles
Contributor
yAcrPush
en la suscripción que contendrá el Almacén de artefactos administrados de AOSM. Estos permisos permiten que la extensión AOSM de la CLI de Azure realice una copia directa de ACR a ACR. La copia directa es el método más rápido de transferir imágenes de un ACR a otro.- Es posible que la política de su empresa le impida tener permisos de suscripción. El
--no-subscription-permissions
parámetro, disponible en los comandosaz aosm nfd publish
yaz aosm nsd publish
, usa permisos estrechamente con ámbito derivados del servicio AOSM para organizar una copia en dos pasos hacia y desde el equipo local. Esta copia en dos pasos es más lenta, pero no requiere permisos con ámbito de suscripción.
- Es posible que la política de su empresa le impida tener permisos de suscripción. El
Paquetes de Helm
- Los paquetes de Helm que quiere incorporar deben estar presentes en el almacenamiento local de la máquina desde la que está ejecutando la CLI.
- La extensión AOSM de la CLI de Azure usará el
values.yaml
archivo en el paquete de Helm de forma predeterminada. La CLI admite la invalidación de este comportamiento con una alternativavalues.yaml
. Este archivo alternativo debe existir en el almacenamiento local de la máquina desde la que está ejecutando la CLI.
- La extensión AOSM de la CLI de Azure usará el
Nota:
Se recomienda encarecidamente que el paquete de Helm contenga un esquema para los valores de Helm y que las plantillas de paquete de Helm como se espera cuando helm template
se ejecute con values.yaml que pretende usar al incorporarse a AOSM.
Imágenes del contenedor
- Las imágenes de contenedor están presentes en un ACR existente o en un registro de contenedor alternativo que admita la API de Docker. Las imágenes de contenedor deben almacenarse en el registro de origen en una estructura que coincida con la ubicación de la imagen definida en los gráficos de Helm. Este requisito se explica en la detección y carga de imágenes CNF de la CLI.
- Use el
docker login
comando para iniciar sesión en un registro de contenedor que no sea de Azure que hospeda las imágenes de contenedor antes de ejecutar losaz aosm
comandos. Este paso no es necesario si usa un ACR: la extensión AOSM de la CLI de Azure iniciará sesión automáticamente.
Motor de Helm y Docker
- Instale la CLI de Helm en el equipo host. Debe usar Helm v3.8.0 o posterior.
- Instale Docker en el equipo host.
Descarga e instalación de la CLI de Azure
Para instalar la CLI de Azure localmente, consulte Cómo instalar de la CLI de Azure.
Para iniciar sesión en la CLI de Azure, use el az login
comando y complete las indicaciones que se muestran en el terminal para finalizar la autenticación. Para ver más opciones de inicio de sesión, consulte Inicio de sesión con la CLI de Azure.
Nota:
Si utiliza Windows o macOS, considere la posibilidad de ejecutar la CLI de Azure en un contenedor Docker. Para más información, vea Ejecución de la CLI de Azure en un contenedor de Docker. También puede usar el entorno de Bash en Azure Cloud Shell. Para obtener más información, consulte Inicio de Cloud Shell para usar el entorno de Bash en Azure Cloud Shell.
Instalación de la extensión AOSM de la CLI
La extensión AOSM de la CLI de Az requiere la versión 2.54.0 o posterior de la CLI de Azure.
- Ejecute
az version
para ver la versión y las bibliotecas dependientes que están instaladas. - Ejecute
az upgrade
para actualizar a la versión actual de la CLI de Azure.
Instale la extensión AOSM de la CLI mediante este comando:
az extension add --name aosm
Compilación del grupo y la versión de definición de función de red
En este paso se crea una carpeta en el directorio de trabajo denominada cnf-cli-output
con las plantillas de BICEP de los recursos de AOSM que definen el grupo y la versión de la función de red y el almacén de artefactos. Estos recursos se incluirán en última instancia en el diseño del servicio de red.
Genere el archivo de entrada de extensión AOSM de la CLI de Azure para un CNF.
az aosm nfd generate-config --definition-type cnf --output-file <filename.jsonc>
Abra el archivo de entrada que generó en el paso anterior y use los comentarios insertados para especificar los valores necesarios. En este ejemplo se muestra el archivo de entrada de extensión Az CLI de AOSM para un CNF ficticio de Contoso.
Nota:
La extensión AOSM de la CLI de Azure solo expone los parámetros necesarios sin valores predeterminados en la entrada
values.yaml
de forma predeterminada. Puede establecerexpose_all_parameters
entrue
para exponer todos los valores de Helm en la versión de definición de función de red (NFDV) y el esquema de grupo de configuración (CGS). Para obtener más información, consulte La exposición de parámetros mediante la extensión de la CLI de 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": "", } ] }
Ejecute el siguiente comando para compilar el grupo de definiciones de función de red y la versión de BICEP.
az aosm nfd build --definition-type cnf --config-file <filename.jsonc>
Puede revisar la estructura de carpetas y archivos y realizar modificaciones si es necesario.
Publicar el grupo y la versión de definición de función de red
En este paso se crean los recursos de AOSM que definen la definición de función de red y el almacén de artefactos que se usarán para almacenar las imágenes de contenedor de la función de red. También carga las imágenes y los gráficos en el Almacén de artefactos copiándola directamente desde el ACR de origen o, si no tiene el ámbito Contributor
y AcrPush
los roles de la suscripción, re etiquete las imágenes de Docker localmente y cargue en el Almacén de artefactos mediante credenciales de ámbito estrictamente generadas desde el servicio AOSM.
- Ejecute el siguiente comando para publicar el grupo y la versión de definición de función de red. Si no tiene el ámbito de suscripción
Contributor
yAcrPush
los roles, incluya--no-subscription-permissions
en el comando.
Nota:
Si usa Windows, debe tener el escritorio de Docker en ejecución durante el paso de publicación.
az aosm nfd publish --build-output-folder cnf-cli-output --definition-type cnf
Compilación del grupo de diseño y la versión del servicio de red
En esta sección se crea una carpeta en el directorio de trabajo denominado nsd-cli-output
. Esta carpeta contiene las plantillas de BICEP de los recursos de AOSM que definen un grupo de diseño y una versión del servicio de red. Este diseño de servicio de red es una plantilla que se usa en el recurso servicio de red de sitio que implementará la función de red que ha incorporado en las secciones anteriores.
Genere el archivo de entrada NSD de extensión AOSM de la CLI de Azure.
az aosm nsd generate-config --output-file <nsd-output-filename.jsonc>
Abra el archivo de entrada que generó en el paso anterior y use los comentarios insertados para especificar los valores necesarios. El archivo de entrada generado contiene un elemento adicional
resource_element_type
de tipoArmTemplate
. Esto es innecesario al incorporar un CNF; puede eliminarlo. El resultado debería parecerse al de este ejemplo. En el ejemplo se muestra el archivo de entrada de extensión Az de CLI de AOSM para un NSD ficticio de Contoso que se puede usar para implementar un CNF ficticio de Contoso en un clúster de Nexus Kubernetes conectado a 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:
La sección de plantilla de elemento de recurso define qué NFD se incluye en el NSD. Las propiedades deben coincidir con las usadas en el archivo de entrada que se pasa al comando
az aosm nfd build
. Esto se debe a que la extensión AOSM de la CLI de Azure valida que NFD se ha incorporado correctamente al compilar el NSD.Ejecute el siguiente comando para compilar las plantillas grupo de diseño del servicio de red y BICEP de versión.
az aosm nsd build --config-file <nsd-output-filename.jsonc>
Puedes revisar la estructura de carpetas y archivos y hacer modificaciones si es necesario.
Publicar el grupo de diseño y la versión del servicio de red
Este paso crea los recursos de AOSM que definen el grupo de diseño y la versión del servicio de red. También carga artefactos requeridos por el NSD en el almacén de artefactos (plantilla ARM de función de red).
- Ejecute el siguiente comando para publicar el grupo de diseño y la versión del servicio de red. Si no tiene el ámbito de suscripción
Contributor
yAcrPush
los roles, incluya--no-subscription-permissions
en el comando.
az aosm nsd publish --build-output-folder nsd-cli-output
Ahora tiene un conjunto completo de recursos del publicador de AOSM y está listo para realizar el flujo del operador.