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)

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. Ce VNF peut ensuite être déployé sur l’opérateur Azure 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érez des fichiers Bicep qui définissent un groupe de définitions de fonction réseau et une version (NFD).
  2. Publiez le NFD et chargez l’image VNF 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

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 le 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 Nexus de l’opérateur Azure. Cette image doit être disponible dans un ACR.

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

  • Le modèle ARM de machine virtuelle (pour AzureCore et Azure Operator Nexus) ne peut déployer que des ressources ARM à 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 du NFDV dans le NSDV.

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.

Télécharger et installer Azure CLI

Pour installer Azure CLI localement, reportez-vous à l’installation d’Azure CLI.

Pour vous connecter à Azure CLI, utilisez la az login commande et terminez 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 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.

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 section crée un dossier dans le répertoire de travail appelé vnf-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 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 l’exposition de paramètres à 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.
    // 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 générer le groupe de définitions de fonction réseau et la version.

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

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 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 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 vnf-cli-output --definition-type vnf

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

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 VNF ; vous pouvez le supprimer. Cet 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 VNF Contoso fictif 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 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 la conception de services réseau (NSD)

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

  • Last updated on