Intégrer une fonction réseau conteneurisée (CNF) à Azure Operator Service Manager (AOSM)

Dans ce guide pratique, les éditeurs de fonctions réseau et les concepteurs de services apprennent à utiliser l’extension Azure CLI AOSM pour intégrer une fonction réseau conteneurisée à AOSM. Le CNF peut être déployé ultérieurement sur un cluster Kubernetes connecté à Azure Arc, y compris un cluster Azure Operator Nexus.

L’intégration est un processus en plusieurs étapes. Une fois les conditions préalables remplies, vous allez utiliser l’extension Azure CLI AOSM pour :

1. Générer des fichiers Bicep qui définissent une version et un groupe de définitions de fonction réseau (NFD) basés sur vos graphiques Helm et valeurs.yaml.
2. Publiez le NFD et chargez les images et graphiques CNF dans un magasin d’artefacts (Azure Container Registry (ACR) géré par AOSM.
3. Ajoutez votre NFD publié aux fichiers Bicep qui définissent un groupe de conception de service réseau et une version (NSD).
4. Publier la NSD.

Conditions préalables

• Vous avez activé AOSM sur votre abonnement Azure.
• Si votre CNF est destiné à s’exécuter sur Azure Operator Nexus, vous avez accès à une instance Azure Operator Nexus et avez rempli les conditions préalables pour le déploiement de la charge de travail.

Configurer les autorisations

• Vous avez besoin du rôle Contributeur sur votre abonnement pour créer un groupe de ressources ou un groupe de ressources existant dans lequel vous avez le rôle Contributeur.
• Vous avez besoin des Reader/AcrPull attributions de rôle sur la source ACR contenant vos images.
• Vous avez besoin des attributions de rôles Contributor et AcrPush sur l’abonnement qui contiendra le Magasin d’artefacts géré par AOSM. Ces autorisations permettent à l’extension Azure CLI AOSM d’effectuer une copie ACR-to-ACR directe. La copie directe est la méthode la plus rapide pour transférer des images d’un ACR vers un autre.
  • Votre stratégie d’entreprise peut vous empêcher d’avoir des autorisations limitées à l’abonnement. Le --no-subscription-permissions paramètre, disponible sur les commandes az aosm nfd publish et az aosm nsd publish, utilise des autorisations étroitement délimitées dérivées du service AOSM pour orchestrer une copie en deux étapes depuis et vers votre ordinateur local. Cette copie en deux étapes est plus lente, mais ne nécessite pas d’autorisations limitées à l’abonnement.

Packages Helm

• Les packages Helm que vous envisagez d’intégrer doivent être présents sur le stockage local de l’ordinateur à partir duquel vous exécutez l’interface CLI.
  • L’extension Azure CLI AOSM utilise le values.yaml fichier dans le package Helm par défaut. L’interface CLI prend en charge la substitution de ce comportement par une alternative values.yaml. Ce fichier de remplacement doit exister sur le stockage local de l’ordinateur à partir duquel vous exécutez l’interface CLI.

Images de conteneur

• Vos images conteneur sont présentes dans un ACR existant ou dans un registre de conteneurs alternatif qui prend en charge l’API Docker. Les images conteneur doivent être stockées dans votre registre source dans une structure qui correspond à l’emplacement de l’image défini dans vos graphiques Helm. Cette exigence est expliquée dans découverte et chargement d’images CLI CNF.
• Utilisez la docker login commande pour vous connecter à un registre de conteneurs non-Azure hébergeant vos images conteneur avant d’exécuter des az aosm commandes. Cette étape n’est pas nécessaire si vous utilisez un ACR : l’extension Azure CLI AOSM se connecte automatiquement.

Moteur Helm et Docker

• Installez Helm CLI sur l’ordinateur hôte. Vous devez utiliser Helm version 3.8.0 ou ultérieure.
• Installez Docker sur l’ordinateur hôte.

Télécharger et installer Azure CLI

Pour installer Azure CLI localement, consultez Comment installer Azure CLI.

Pour vous connecter à Azure CLI, utilisez la commande az login et suivez les prompts affichés dans votre terminal pour terminer l’authentification. Découvrez plus d’options de connexion dans Se connecter avec Azure CLI.

Installer l’extension CLI AOSM

L’extension Az CLI AOSM nécessite la version 2.54.0 ou ultérieure d’Azure CLI.

1. Exécutez az version pour voir la version et les bibliothèques dépendantes installées.
2. Exécutez az upgrade ou mettez à niveau vers la version actuelle d’Azure CLI.

Installez l’extension CLI AOSM à l’aide de cette commande :

az extension add --name aosm

Générer le groupe de définition de fonction réseau et la version

Cette étape crée un dossier dans le répertoire de travail appelé cnf-cli-output avec les fichiers Bicep des ressources AOSM qui définissent votre groupe de définitions de fonction réseau et votre version, ainsi que le magasin d’artefacts. Ces ressources seront finalement incluses dans votre conception de service réseau.

1. Générez le fichier d’entrée de l’extension Azure CLI AOSM pour une CNF.

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

2. Ouvrez le fichier d’entrée que vous avez généré à l’étape précédente et utilisez les commentaires inline pour entrer les valeurs requises. Cet exemple montre le fichier d’entrée de l’extension Az CLI AOSM pour une CNF Contoso fictive.

   Remarque

   L’extension Azure CLI AOSM expose uniquement les paramètres requis sans valeurs par défaut dans l’entrée values.yaml par défaut. Vous pouvez définir expose_all_parameters sur true pour exposer toutes les valeurs helm dans la version de définition de fonction réseau (NFDV) et le schéma de groupe de configuration (CGS). Pour plus d’informations, consultez Parameter expose à l’aide de l’extension CLI 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": "",
         }
     ]
   }
   

3. Exécutez la commande suivante pour construire le groupe de définition de fonction réseau et les fichiers de version Bicep.

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

Vous pouvez passer en revue la structure des dossiers et des fichiers et apporter des modifications si nécessaire.

Publier le groupe de définition de fonction réseau et la version

Cette étape crée les ressources AOSM qui définissent la définition de fonction réseau et le magasin d’artefacts qui seront utilisés pour stocker les images conteneur de la fonction réseau. Elle charge également les images et les graphiques dans le magasin d’artefacts en les copiant directement à partir de l’ACR source ou, si vous n’avez pas les rôles Contributor et AcrPush au niveau de l’abonnement, en réétiquetant les images Docker localement et en chargeant dans le magasin d’artefacts à l’aide d’informations d’identification à étendue étroite générées à partir du service AOSM.

1. Exécutez la commande suivante pour publier le groupe de définitions de fonction réseau et la version. Si vous n’avez pas les rôles Contributor et AcrPush au niveau de l’abonnement, incluez --no-subscription-permissions dans la commande.

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

Génération du groupe de conception des services réseau et de la version

Cette section crée un dossier dans le répertoire de travail appelé nsd-cli-output. Ce dossier contient les fichiers Bicep des ressources AOSM qui définissent un groupe de conception de service réseau et une version. Cette conception de service réseau est un modèle utilisé dans la ressource service de réseau de site qui déploie la fonction réseau que vous avez intégrée dans les sections précédentes.

1. Générez le fichier d’entrée NSD de l’extension AOSM Azure CLI.

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

2. Ouvrez le fichier d’entrée que vous avez généré à l’étape précédente et utilisez les commentaires inline pour entrer les valeurs requises. Le fichier d’entrée généré contient un resource_element_type supplémentaire de type ArmTemplate. Cela n’est pas nécessaire lors de l’intégration d’un CNF ; vous pouvez le supprimer. Le résultat doit être semblable à l'exemple suivant. L’exemple montre le fichier d’entrée d’extension AOSM Az CLI pour un NSD Contoso fictif qui peut être utilisé pour déployer un CNF Contoso fictif sur un cluster Nexus Kubernetes connecté à 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"
               }
           }
       ]
   }
   

   Remarque

   La section du modèle d'élément de ressource définit quel NFD est inclus dans le NSD. Les propriétés doivent correspondre à celles utilisées dans le fichier d’entrée passé à la az aosm nfd build commande. Cela est dû au fait que l’extension Azure CLI AOSM vérifie que le NFD a été correctement intégré lors de la génération du NSD.

3. Exécutez la commande suivante pour générer le groupe de conception de services réseau et les fichiers Bicep de version.

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

Vous pouvez examiner la structure du dossier et des fichiers et apporter des modifications si nécessaire.

Publier le groupe de conception de services réseau et la version

Cette étape crée les ressources AOSM qui définissent le groupe de conception de services réseau et la version. Il charge également les artefacts requis par le NSD dans le magasin d’artefacts (modèle ARM de fonction réseau).

1. Exécutez la commande suivante pour publier le groupe de conception et la version du service réseau. Si vous n’avez pas les rôles Contributor et AcrPush au niveau de l’abonnement, incluez --no-subscription-permissions dans la commande.

az aosm nsd publish --build-output-folder nsd-cli-output

Vous disposez maintenant d’un ensemble complet de ressources de publication AOSM et êtes prêt à effectuer le flux d’opérateur.

Étapes suivantes

• Conditions préalables pour l’opérateur
• Créer un service de réseau de site