Partager via

Démarrage rapide : publier un conteneur Nginx en tant que fonction réseau conteneurisée (CNF)

  • Article

Ce guide de démarrage rapide décrit comment utiliser l’extension Azure CLI az aosm pour créer et publier une définition de fonction réseau de base. Son objectif est de démontrer le flux de travail des ressources de l'éditeur Azure Operator Service Manager (AOSM). Les concepts de base présentés ici visent à préparer les utilisateurs à créer des services plus intéressants.

Prérequis

Créer un fichier d'entrée

Créez un fichier d'entrée pour publier la définition de fonction réseau. Exécutez la commande suivante pour générer le fichier de configuration d'entrée pour la définition de fonction réseau (NFD).

az aosm nfd generate-config --definition-type cnf

L’exécution de la commande précédente génère un fichier cnf-input.jsonc.

Remarque

Modifier le fichier cnf-input.jsonc. Remplacez-le par les valeurs indiquées dans l'exemple suivant. Enregistrer le fichier sous input-cnf-nfd.json.

Si vous utilisez un groupe de ressources existant, modifiez le champ publisher_resource_group_name pour qu’il lui corresponde.

Conseil

Vous pouvez utiliser plusieurs registres de conteneurs comme sources pour vos images dans l’interface CLI AOSM. Les images à copier à partir de ces registres sont sélectionnées automatiquement en fonction du schéma du package Helm. Les registres sources sont configurés dans la liste image_sources du fichier cnf-input.jsonc.

Lorsque vous utilisez des registres ACR, vous devez disposer des rôles Lecteur et AcrPull sur le registre ACR. Lorsque vous utilisez des registres autres qu’ACR, vous devez exécuter docker login pour vous authentifier auprès de chaque registre privé avant d’exécuter la commande az aosm nfd build. Dans ce guide de démarrage rapide, nous utilisons docker.io comme registre de source d’image. Il s’agit d’un registre public, et il ne nécessite pas d’authentification.

Voici un exemple de fichier input-cnf-nfd.jsonc :

{
  // Azure location to use when creating resources e.g uksouth
  "location": "uksouth",
  // Name of the Publisher resource you want your definition published to.
  // Will be created if it does not exist.
  "publisher_name": "nginx-publisher",
  // Resource group for the Publisher resource.
  // Will be created if it does not exist.
  "publisher_resource_group_name": "nginx-publisher-rg",
  // Name of the ACR Artifact Store resource.
  // Will be created if it does not exist.
  "acr_artifact_store_name": "nginx-nsd-acr",
  // Name of NF definition.
  "nf_name": "nginx",
  // Version of the NF definition in 1.1.1 format (three integers separated by dots).
  "version": "1.0.0",
  // 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": ["docker.io"],
  // List of Helm packages to be included in the CNF.
  "helm_packages": [
    {
      "name": "nginxdemo",
      "path_to_chart": "nginxdemo-0.3.0.tgz",
      "default_values": ""
    }
  ]
}
  • publisher_name : nom de la ressource Publisher sur laquelle vous souhaitez publier votre définition. Créé s'il n'existe pas déjà.
  • publisher_resource_group_name : groupe de ressources pour la ressource Publisher. Créé s'il n'existe pas déjà.
  • acr_artifact_store_name : nom de la ressource Azure Container Registry (ACR) Artifact Store. Créé s'il n'existe pas déjà.
  • location : emplacement Azure à utiliser lors de la création de ressources.
  • nf_name : nom de la définition de fonction réseau.
  • version : version de la définition de fonction réseau au format A.B.C.
  • image_sources : liste des registres depuis lesquels extraire les images.
  • helm_packages :
    • name : nom du package Helm.
    • path_to_chart : chemin d’accès au fichier du graphique Helm sur le disque local. Accepte .tgz, .tar ou .tar.gz. Utilisez le séparateur de fichiers de la barre oblique Linux (/) même si l’exécution est sur Windows. Le chemin d’accès doit être absolu ou relatif à l’emplacement du fichier cnf-input.jsonc.
    • default_values -: chemin d’accès du fichier (absolu ou relatif à cnf-input.jsonc) du fichier de valeurs YAML sur le disque local utilisé au lieu du fichier values.yaml présent dans le graphique Helm.
    • depends_on : noms des packages Helm dont dépend ce package. Laissez le tableau vide s’il n’y a pas de dépendances.

Construire la définition de fonction réseau (NFD)

Pour construire la définition de fonction réseau (NFD), lancez le processus de génération.

az aosm nfd build -f input-cnf-nfd.jsonc --definition-type cnf

L’extension Az CLI AOSM génère un répertoire appelé cnf-cli-output. Ce répertoire contient les fichiers BICEP définissant les ressources AOSM requises pour publier une NFDV et charger les images nécessaires pour le déployer dans un stockage géré par AOSM. Examinez les fichiers générés pour mieux comprendre la structure NFD (Network Function Definition).

Directory/File Description
nfDefinition/deployParameters.json Définit le schéma des paramètres de déploiement requis pour créer une fonction réseau (NF) à partir de cette version de définition de fonction réseau (NFDV).
nfDefinition/nginxdemo-mappings.json Met en correspondance les paramètres de déploiement de la version de définition de fonction réseau (NFDV) avec les valeurs requises pour le graphique Helm.
nfDefinition/deploy.bicep Modèle Bicep pour créer la version de définition de fonction réseau (NFDV) elle-même.
artifacts/artifacts.json Liste des packages Helm et des images conteneur requis par la NF.
artifactManifest/deploy.bicep Modèle Bicep pour créer le manifeste d'artefacts.
base/deploy.bicep Modèle Bicep pour créer les ressources du serveur de publication, du groupe de définitions de fonction réseau et du magasin d’artefacts

Publier la définition de la fonction réseau et télécharger les artefacts

Exécutez la commande suivante pour publier la définition de fonction réseau (NFD) et charger les artefacts associés :

Remarque

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

Remarque

Les noms d’éditeurs doivent être uniques au sein de la région. Il est très probable que le « nginx-publisher » défini dans l’exemple de fichier de configuration existe déjà.

Si vous obtenez une erreur indiquant « Une ressource d’éditeur privé portant le nom «nginx-publisher » existe déjà dans la région fournie », modifiez le champ publisher_name dans le fichier de configuration afin qu’il soit unique (par exemple, ajoutez un suffixe de chaîne aléatoire), réexécutez la commande build (ci-dessus), puis réexécutez cette commande publish.

Si vous créez ensuite une conception de service réseau, vous devez utiliser ce nouveau nom d’éditeur dans le tableau resource_element_templates.

az aosm nfd publish -b cnf-cli-output --definition-type cnf

Une fois la commande terminée, examinez les ressources de votre groupe de ressources Publisher pour passer en revue les composants et artefacts créés.

Étapes suivantes