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

Artikel
11/20/2023

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

Ein Azure-Konto mit einem aktiven Abonnement ist erforderlich. Wenn Sie kein Azure-Abonnement haben, folgen Sie vorab den Anweisungen unter Kostenlos starten, um ein Konto zu erstellen.
Die Rollen „Mitwirkender“ und „AcrPush“ für dieses Abonnement, um eine Ressourcengruppe zu erstellen, oder eine vorhandene Ressourcengruppe, in der Sie über die Rolle „Mitwirkender“ verfügen.
Führen Sie den Schnellstart: Abschließen der Voraussetzungen für die Bereitstellung einer Containernetzwerkfunktion in Azure Operator Service Manager aus.

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 „input.json“.

Hinweis

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

Hinweis

Für diese Schnellstartanleitung verwenden wir „source_local_docker_image“. Für weitere CNFs, die Sie in Zukunft eventuell erstellen, haben Sie die Möglichkeit, einen Verweis auf eine vorhandene Azure Container Registry-Instanz zu verwenden, die die Images für Ihre CNF enthält. Derzeit werden nur eine ACR-Instanz und ein Namespace pro CNF unterstützt. Die Images, die aus dieser ACR-Instanz kopiert werden sollen, werden automatisch basierend auf dem Helm-Paketschema aufgefüllt. Um diese Option in Zukunft zu verwenden, geben Sie source_registry und optional source_registry_namespace in der Datei „input.json“ ein. Sie müssen über Lese-/AcrPull-Berechtigungen für diese ACR-Instanz verfügen.

Dies ist ein Beispiel für die Datei „input-cnf-nfd.json“:

{
    "publisher_name": "nginx-publisher",
    "publisher_resource_group_name": "nginx-publisher-rg",
    "nf_name": "nginx",
    "version": "1.0.0",
    "acr_artifact_store_name": "nginx-nsd-acr",
    "location": "uksouth",
    "images": {
        "source_local_docker_image": "nginx:stable"
    },
    "helm_packages": [
        {
            "name": "nginxdemo",
            "path_to_chart": "nginxdemo-0.1.0.tgz",
            "path_to_mappings": "",
            "depends_on": []
        }
    ]
}

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. 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.
images:
- source_local_docker_image: Optional. Der Imagename des Docker-Quellimages von Ihrem lokalen Computer. Für einen eingeschränkten Anwendungsfall, bei dem die CNF nur ein einzelnes Docker-Image erfordert, das im lokalen Docker-Repository vorhanden ist.
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 input.json sein.
- path_to_mappings: Der Dateipfad (absolut oder relativ zu input.json) von Wertzuordnungen auf dem lokalen Datenträger, auf dem ausgewählte Werte durch deploymentParameter-Platzhalter ersetzt werden. Zulässige Formate: .yaml und .yml. Wenn eine leere Zeichenfolge angegeben wird, wird eine Wertzuordnungsdatei generiert, in der jeder Wert einem Bereitstellungsparameter zugeordnet ist. Verwenden Sie eine leere Zeichenfolge und --interactive für den Buildbefehl, um interaktiv auszuwählen, welche Werte zugeordnet werden sollen.
- 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 im interaktiven Modus. Mit diesem Modus können Sie Werte aus values.yaml selektiv als Bereitstellungsparameter (deploymentParameters) verfügbar machen.

az aosm nfd build -f input-cnf-nfd.json --definition-type cnf --interactive

Während des interaktiven Prozesses können Sie mit „n“ (nein) für alle Optionen mit Ausnahme der folgenden beiden antworten:

Um den Parameter serviceAccount_create verfügbar zu machen, antworten Sie mit „y“ (ja).
Um den Parameter service_port verfügbar zu machen, antworten Sie mit „y“ (ja).

Überprüfen Sie nach Abschluss des Builds die generierten Dateien, um die Struktur der Netzwerkfunktionsdefinition (NFD) besser zu verstehen. Diese Dateien werden erstellt:

Verzeichnis/Datei	Beschreibung
configMappings	Ordnet die Bereitstellungsparameter für die Version der Netzwerkfunktionsdefinition (Network Function Definition Version, NFDV) den für das Helm-Chart erforderlichen Werten zu.
generatedValuesMappings	Die YAML-Ausgabe des interaktiven Modus, der configMappings erstellt hat. Bearbeiten Sie die Ausgabe, und führen Sie den Befehl bei Bedarf erneut aus.
Schemas	Definiert die Bereitstellungsparameter, die zum Erstellen einer Netzwerkfunktion (NF) aus dieser Version der Netzwerkfunktionsdefinition (NFDV) erforderlich sind.
cnfartifactmanifests.bicep	Bicep-Vorlage zum Erstellen des Artefaktmanifests.
cnfdefinition.bicep	Bicep-Vorlage zum Erstellen der Version der Netzwerkfunktionsdefinition (NFDV) selbst.

Wenn während der interaktiven Auswahl Fehler gemacht wurden, gibt es zwei Optionen, um sie zu korrigieren:

Führen Sie den Befehl mit der richtigen Auswahl erneut aus.
Passen Sie die generierten Wertzuordnungen im Ordner generatedValuesMappings manuell an. Bearbeiten Sie dann path_to_mappings_file in input.json, um auf den geänderten Dateipfad zu verweisen.

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:

az aosm nfd publish -f input-cnf-nfd.json --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

Schnellstart: Entwerfen eines CNF-Netzwerkdienstentwurfs (Containernetzwerkfunktion) mit NGINX

Share via