Partager via

Ajout de ressources ARM à une NSDV d’AOSM

  • Article

AOSM vous permet de combiner les versions de définition de fonction réseau (NFDV, Network Function Definition Version) et les modèles ARM dans une NSDV. La NSDV devient un modèle unique pour un service réseau qui contient à la fois une fonction réseau (NF, Network Function) et l’infrastructure Azure dont il a besoin pour s’exécuter. Un opérateur peut ensuite déployer la NF et son infrastructure en une seule opération.

Dans ce guide pratique, vous allez apprendre à utiliser l’extension AOSM de l’Azure CLI pour générer et publier une NSDV contenant à la fois une fonction réseau conteneurisée (CNF, Containerized Network Function) et une ressource ARM.

Le processus d’intégration comprend plusieurs étapes. Une fois les conditions préalables remplies, vous allez utiliser l’extension AOSM de l’Azure CLI pour :

  1. Modifiez un fichier d’entrée NSDV existant pour une CNF précédemment intégrée.
  2. Remplissez le fichier d’entrée avec les informations requises pour générer les définitions de ressources AOSM.
  3. Générez des fichiers BICEP qui définissent un groupe de conception de service réseau et une NSDV en fonction du fichier d’entrée et de votre modèle ARM.
  4. Publiez la NSDV et chargez le modèle ARM dans un Magasin d’artefacts (Azure Container Registry (ACR) géré par AOSM).

Ce guide pratique utilise Azure Key Vault (AKV) comme exemple de ressource Azure, cependant, toute ressource Azure peut être intégrée en suivant les mêmes étapes. Cet article utilise une CNF comme exemple de NF ; le processus est identique pour une fonction de réseau virtualisée (VNF, Virtualized Network Function) à l’exception de quelques différences mineures dans le fichier d’entrée NSDV.

Prérequis

  • Vous avez activé AOSM sur votre abonnement Azure.
  • Si votre CNF est destinée à fonctionner sur Azure Operator Nexus, vous avez accès à une instance Azure Operator Nexus et vous avez terminé les prérequis pour le déploiement de la charge de travail.
  • Vous avez intégré une CNF et vous avez le fichier d’entrée que vous avez généré avec le fichier az aosm nsd generate-config disponible sur le stockage local de l’ordinateur à partir duquel vous exécutez la CLI.

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 Contributor et AcrPush sur l’abonnement qui contiendra le Magasin d’artefacts géré par AOSM.
    • 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 la commande 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.

Modèles ARM

  • Vous devez disposer d’un modèle ARM, qui définit les ressources Azure que vous souhaitez déployer, sur le stockage local de l’ordinateur à partir duquel vous exécutez la CLI.
  • Tous les paramètres que vous souhaitez exposer à l’opérateur qui déploiera votre NSDV doivent être définis en tant que paramètres dans le modèle ARM.

Remarque

L’extension AOSM de l’Azure CLI ne prend pas en charge l’intégration des ressources Azure définies dans un modèle BICEP. Toutefois, vous pouvez utiliser la commande bicep build pour convertir vos fichiers BICEP en modèles ARM. Consultez la documentation bicep CLI pour des informations détaillées et des instructions.

Moteur Helm et Docker

  • Installez la 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.

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.

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.

Installation de l’extension AOSM de la CLI

L’extension AOSM de l’Azure CLI nécessite la version 2.54.0 ou ultérieure de l’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 AOSM de l’Azure CLI à l’aide de la commande :

az extension add --name aosm

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

  1. Ouvrez le fichier d’entrée NSDV que vous avez généré lorsque vous avez intégré votre CNF.

    Remarque

    Vous pouvez générer un nouveau fichier d’entrée à l’aide de la commande az aosm nsd generate-config --output-file <nsd-output-filename.jsonc> si vous n’avez pas le fichier d’entrée NSDV de votre intégration CNF.

  2. Entrez les valeurs requises à l’aide des commentaires inclus dans votre fichier d’entrée. Cet exemple montre le fichier d’entrée de l’extension AOSM de l’Azure CLI pour une NSDV Contoso fictive qui peut être utilisé pour déployer une CNF Contoso fictive sur un cluster Nexus Kubernetes connecté sur Arc et une instance AKV dans un emplacement Azure.

    {
    // 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 and an Azure Key Vault",
    // 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"
            }
        },
        {
            // Type of Resource Element. Either NF or ArmTemplate
            "resource_element_type": "ArmTemplate",
            // Properties of the Resource Element.
            "properties": {
                // Name of the artifact. Used as internal reference only.
                "artifact_name": "contoso-keyvault",
                // 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": "./contoso-keyvault.json"
            }
        }
    ]
}

    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 AOSM de l’Azure CLI vérifie que la NFD a été correctement intégrée lors de la génération de la NSD.

  3. Exécutez la commande suivante pour construire les modèles BICEP du groupe de conception des services réseau et de version.

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.

Publication du groupe de conception des services réseau et de version

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

  1. Exécutez la commande suivante pour publier le groupe de conception des services 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 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