Partager via

Intégrer une fonction réseau conteneurisée (CNF) à 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 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.

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) basés sur vos graphiques Helm et valeurs.yaml.
  2. Publier le NFD et charger les images et les graphiques CNF 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é qu’une helm install de votre package Helm réussit sur votre environnement Kubernetes connecté à Arc cible.

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.

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 fichier values.yaml dans le package Helm par défaut. L’interface CLI prend en charge la substitution de ce comportement par une autre values.yaml. Ce fichier de remplacement doit exister sur le stockage local de l’ordinateur à partir duquel vous exécutez l’interface CLI.

Remarque

Il est vivement recommandé que le package Helm contienne un schéma pour les valeurs Helm et que les modèles de package Helm comme prévu lorsque helm template est exécuté à l’aide des valeurs.yaml que vous envisagez d’utiliser lors de l’intégration à AOSM.

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 d’images CNF CLI et chargement.
  • Utilisez la commande docker login pour vous connecter à un registre de conteneurs non-Azure hébergeant vos images conteneur avant d’exécuter des commandes az aosm. 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 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.

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.

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 étape crée un dossier dans le répertoire de travail appelé cnf-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 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 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.
  // 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 générer les modèles BICEP du groupe et de la version de définition de fonction réseau.

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

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

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 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 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.

Remarque

Si vous utilisez Windows, Docker Desktop doit être en exécution pendant l’étape de publication.

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

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 CNF. Vous pouvez le supprimer. Le résultat doit être semblable à l'exemple suivant. L’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 CNF Contoso fictive sur un cluster Nexus Kubernetes connecté sur 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 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 version et le groupe de conception de service réseau

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