Freigeben über

Schnellstart: Veröffentlichen eines NGINX-Containers als Containernetzwerkfunktion (Containerized Network Function, CNF)

  • Artikel

In diesem Schnellstart wird beschrieben, wie Sie die Azure CLI-Erweiterung az aosm verwenden, um eine einfache Netzwerkfunktionsdefinition zu erstellen und zu veröffentlichen. Der Zweck ist es, den Workflow der AOSM-Ressourcen (Azure Operator Service Manager) des Herausgebers zu veranschaulichen. Die hier vorgestellten grundlegenden Konzepte sollen die Benutzer*innen auf die Erstellung spannenderer Dienste vorbereiten.

Voraussetzungen

Erstellen einer Eingabedatei

Erstellen Sie eine Eingabedatei zum Veröffentlichen der Netzwerkfunktionsdefinition. Führen Sie den folgenden Befehl aus, um die Eingabekonfigurationsdatei für die Netzwerkfunktionsdefinition (Network Function Definition, NFD) zu generieren.

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

Mit der Ausführung des obigen Befehls generieren Sie eine Datei vom Typ „cnf-input.jsonc“.

Hinweis

Bearbeiten Sie die Datei „cnf-input.jsonc“. Ersetzen Sie darin die Werte, die im folgenden Beispiel gezeigt werden. Speichern Sie die Datei unter dem Namen input-cnf-nfd.jsonc.

Wenn Sie eine vorhandene Ressourcengruppe verwenden, ändern Sie das Feld publisher_resource_group_name entsprechend.

Tipp

Sie können mehrere Containerregistrierungen als Quellen für Ihre Images in der AOSM-CLI verwenden. Die Images, die aus diesen Registrierungen kopiert werden sollen, werden automatisch basierend auf dem Helm-Paketschema ausgewählt. Die Quellregistrierungen werden in der Liste image_sources in der Datei „cnf-input.jsonc“ konfiguriert.

Wenn Sie ACR-Instanzen verwenden, müssen Sie über die Rollen „Reader“ und „AcrPull“ für ACR verfügen. Wenn Sie andere Registrierungen als ACR verwenden, müssen Sie vor dem Ausführen des az aosm nfd build-Befehls zur Authentifizierung mit allen privaten Registrierungen docker login ausführen. In dieser Schnellstartanleitung wird docker.io als Imagequellregistrierung verwendet. Dies ist eine öffentliche Registrierung und erfordert keine Authentifizierung.

Dies ist ein Beispiel für die Datei „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: Name der Herausgeberressource, unter der Ihre Definition veröffentlicht werden soll. Diese wird erstellt, falls sie noch nicht vorhanden ist.
  • publisher_resource_group_name: Ressourcengruppe für die Herausgeberressource. Diese wird erstellt, falls sie noch nicht vorhanden ist.
  • acr_artifact_store_name – Name der ACR-Artefaktspeicherressource (Azure Container Registry). Diese wird erstellt, falls sie noch nicht vorhanden ist.
  • location: Azure-Standort für das Erstellen von Ressourcen.
  • nf_name: Der Name der NF-Definition.
  • version: Version der NF-Definition im Format A.B.C.
  • image_sources – Liste der Registrierungen, aus denen die Bilder abgerufen werden sollen.
  • helm_packages:
    • name: Der Name des Helm-Pakets.
    • path_to_chart: Der Dateipfad des Helm-Charts auf dem lokalen Datenträger. Zulässige Formate: .tgz, .tar und .tar.gz. Verwenden Sie auch bei der Ausführung unter Windows den Linux-Schrägstrich (/) als Dateitrennzeichen. Der Pfad sollte ein absoluter Pfad oder ein Pfad relativ zum Speicherort der Datei cnf-input.jsonc sein.
    • default_values – Der Dateipfad (absolut oder relativ zu cnf-input.jsonc) der YAML-Wertedatei auf dem lokalen Datenträger, der anstelle der im Steuerdiagramm vorhandenen Datei „values.yaml“ verwendet wird.
    • depends_on: Die Namen der Helm-Pakete, von denen dieses Paket abhängt. Geben Sie ein leeres Array an, wenn keine Abhängigkeiten vorhanden sind.

Erstellen der Netzwerkfunktionsdefinition (Network Function Definition, NFD)

Um die Netzwerkfunktionsdefinition (NFD) zu erstellen, initiieren Sie den Buildprozess.

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

Die Az CLI AOSM-Erweiterung generiert ein Verzeichnis namens cnf-cli-output. Dieses Verzeichnis enthält die BICEP-Dateien, in denen die AOSM-Ressourcen definiert sind, die für die Veröffentlichung eines NFDV und das Hochladen der Images erforderlich sind, die für die Bereitstellung in einem von AOSM verwalteten Speicher benötigt werden. Überprüfen Sie die generierten Dateien, um die Struktur der Netzwerkfunktionsdefinition (NFD) besser zu verstehen.

Verzeichnis/Datei Beschreibung
nfDefinition/deployParameters.json Definiert das Schema der Bereitstellungsparameter, die zum Erstellen einer Netzwerkfunktion (NF) aus dieser Version der Netzwerkfunktionsdefinition (NFDV) erforderlich sind.
nfDefinition/nginxdemo-mappings.json Ordnet die Bereitstellungsparameter für die Version der Netzwerkfunktionsdefinition (Network Function Definition Version, NFDV) den für das Helm-Chart erforderlichen Werten zu.
nfDefinition/deploy.bicep Bicep-Vorlage zum Erstellen der Version der Netzwerkfunktionsdefinition (NFDV) selbst.
artifacts/artifacts.json Eine Liste der Helmpakete und Containerimages, die von der NF benötigt werden.
artifactManifest/deploy.bicep Bicep-Vorlage zum Erstellen des Artefaktmanifests.
base/deploy.bicep Bicep-Vorlage für die Erstellung des Herausgebers, der Netzwerkfunktionsdefinitionsgruppe und der Artefaktspeicherressourcen

Veröffentlichen der Netzwerkfunktionsdefinition und Hochladen von Artefakten

Führen Sie den folgenden Befehl aus, um die Netzwerkfunktionsdefinition (NFD) zu veröffentlichen und die zugehörigen Artefakte hochzuladen:

Hinweis

Wenn Sie Windows verwenden, müssen Sie Docker Desktop während des Veröffentlichungsschritts ausführen.

Hinweis

Herausgebernamen müssen innerhalb einer Region eindeutig sein. Der in der Beispielkonfigurationsdatei definierte Wert für „nginx-publisher“ ist mit hoher Wahrscheinlichkeit bereits vorhanden.

Wenn Sie die Fehlermeldung Eine private Herausgeberressource mit dem Namen "nginx-publisher" ist bereits in der bereitgestellten Region vorhanden. erhalten, bearbeiten Sie das Feld publisher_name in der Konfigurationsdatei so, dass es eindeutig ist (fügen Sie beispielsweise ein zufälliges Zeichenfolgensuffix hinzu). Führen Sie anschließend den build-Befehl (oben) und dann diesen publish-Befehl erneut aus.

Wenn Sie im Anschluss einen Netzwerkdienstentwurf erstellen, müssen Sie diesen neuen Herausgebernamen im resource_element_templates-Array verwenden.

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

Überprüfen Sie nach Abschluss des Befehls die Ressourcen in Ihrer Herausgeberressourcengruppe, um die erstellten Komponenten und Artefakte zu überprüfen.

Nächste Schritte