Partager via

Intégrer une fonction de réseau virtualisée (VNF) pour le déploiement sur Azure Operator Nexus vers Azure Operator Service Manager (AOSM)

  • Article

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 virtualisée à AOSM. Cette VNF peut ensuite être déployée sur Azure Operator Nexus. Le processus d’intégration comprend 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).
  2. Publier le NFD et charger l’image VNF dans un magasin d’artefacts (Azure Container Registry (ACR) géré par AOSM).
  3. Ajouter votre NFD publiée aux fichiers BICEP qui définissent une version et un groupe de conception de service réseau (NSD).
  4. Publier la NSD.

Prérequis

Remarque

Il est fortement recommandé d’avoir testé que le déploiement de la machine virtuelle réussit sur votre instance Azure Operator Nexus avant d’intégrer la VNF à AOSM.

Images de machine virtuelle Azure Operator Nexus et modèles Azure Resource Manager (ARM)

  • Vous avez créé une image pour la machine virtuelle Azure Operator Nexus. Cette image doit être disponible dans un ACR.

  • Vous avez créé un modèle ARM qui déploie une machine virtuelle Azure Operator Nexus.

  • Le modèle ARM de machine virtuelle (pour AzureCore et Azure Operator Nexus) peut déployer des ressources ARM uniquement à partir des fournisseurs de ressources suivants

    • Microsoft.Compute
    • Microsoft.Network
    • Microsoft.NetworkCloud
    • Microsoft.Storage
    • Microsoft.NetworkFabric
    • Microsoft.Authorization
    • Microsoft.ManagedIdentity

  • Le modèle ARM VNF doit déployer une machine virtuelle. Plusieurs machines virtuelles peuvent être déployées en incluant plusieurs instances de la NFDV dans la NSDV.

Configurer les autorisations

  • Vous devez disposer du rôle Contributeur sur cet abonnement afin de créer un groupe de ressources, ou d’un groupe de ressources existant dans lequel vous disposez du rôle Contributeur.
  • Vous avez besoin des attributions de rôles Reader/AcrPull sur l’ACR source 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-vers-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 au niveau de l’abonnement. Le paramètre --no-subscription-permissions, disponible sur les commandes az aosm nfd publish et az aosm nsd publish, utilise des autorisations à étendues étroites dérivées du service AOSM pour orchestrer une copie en deux étapes vers et depuis votre ordinateur local. Cette copie en deux étapes est plus lente, mais ne nécessite pas d’autorisations au niveau de l’abonnement.

Télécharger et installer Azure CLI

Pour obtenir des instructions sur l’installation d’Azure CLI, consultez Comment installer Azure CLI.

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

Remarque

Si vous exécutez sur Windows ou macOS, envisagez d’exécuter Azure CLI dans un conteneur Docker. Pour plus d’informations, consultez Guide pratique pour exécuter Azure CLI dans un conteneur Docker. Vous pouvez aussi utiliser l’environnement Bash dans Azure Cloud Shell. Pour plus d’informations, consultez Démarrer le Cloud Shell pour utiliser l’environnement Bash dans Azure Cloud Shell.

Moteur Helm et Docker

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

Installer l’extension Interface 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 Interface CLI AOSM à l’aide de la commande :

az extension add --name aosm

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

Cette section crée un dossier dans le répertoire de travail appelé vnf-cli-output avec les modèles BICEP des ressources AOSM qui définissent votre version et groupe de définition de fonction réseau, 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 VNF.

    az aosm nfd generate-config --definition-type vnf-nexus --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 VNF Contoso fictive, qui s’exécute sur Azure Operator Nexus.

    Remarque

    L’extension Azure CLI AOSM expose uniquement les paramètres requis sans valeurs par défaut dans le modèle ARM d’entrée par défaut. Vous pouvez définir expose_all_parameters sur true pour exposer tous les paramètres de modèle ARM 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 Exposition des paramètres à l’aide de l’extension Interface 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.
    // Will be created if it does not exist.
    "publisher_resource_group_name": "contoso-vnf",
    // Name of the ACR Artifact Store resource.
    // Will be created if it does not exist.
    "acr_artifact_store_name": "contoso-vnf-artifact-store",
    // Name of the network function.
    "nf_name": "contoso-vnf",
    // Version of the network function 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,
    // ARM template configuration. The ARM templates given here would deploy a VM if run. They will be used to generate the VNF.
    "arm_templates": [
        {
            // Name of the artifact. Used as internal reference only.
            "artifact_name": "contoso-vnf",
            // Version of the artifact in 1.1.1 format (three integers separated by dots).
            "version": "1.0.0",
            // File path (absolute or relative to this configuration file) of the artifact you wish to upload from your local disk.
            // Use Linux slash (/) file separator even if running on Windows.
            "file_path": "/home/contoso-vnf/contoso-vnf-arm-template.json"
        }
    ],
    // List of images to be pulled from the acr registry.
    // You must provide the source acr registry, the image name and the version.
    // For example: 'sourceacr.azurecr.io/imagename:imageversion'.
    "images": ["contoso-vnf.azurecr.io/contosovnf:1.0.0"]
}```

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

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

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

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 de machine virtuelle de la fonction réseau. Elle charge également les images 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 la version et le groupe de définition de fonction 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 nfd publish --build-output-folder vnf-cli-output --definition-type vnf

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

Construire la version et le groupe de conception de service réseau

Cette section crée un dossier dans le répertoire de travail appelé nsd-cli-output. Ce dossier contient les modèles BICEP des ressources AOSM qui définissent la version et le groupe de conception de service réseau. 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 Azure CLI AOSM.

    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’une VNF. Vous pouvez le supprimer. Cet exemple montre le fichier d’entrée de l’extension Az CLI AOSM pour une NSD Contoso fictive qui peut être utilisé pour déployer une VNF Contoso fictive sur une instance Azure Operator Nexus.

    {
    // 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-vnf",
    // Name of the ACR Artifact Store resource.
    // Will be created if it does not exist.
    "acr_artifact_store_name": "contoso-vnf-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-vnf-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-vnf 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-vnf",
                // 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-vnf",
                // 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": "vnf"
            }
        }
    ]
}

    Remarque

    La section du modèle d’élément de ressource définit quelle NFD est incluse dans la NSD. Les propriétés doivent correspondre à celles utilisées dans le fichier d’entrée transmis à la commande az aosm nfd build. 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 construire les modèles BICEP de version et de groupe de conception de services réseau.

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

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

Publier la conception de services réseau (NSD)

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

  1. Exécutez la commande suivante pour publier la version et le groupe de conception de services 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 d’éditeur AOSM et êtes prêt à effectuer le flux d’opérateur.

Étapes suivantes