Freigeben über

Durchführen des Onboardings für eine containerisierte Netzwerkfunktion (CNF) in Azure Operator Service Manager (AOSM)

  • Artikel

In dieser Schrittanleitung erfahren Herausgeber von Netzwerkfunktionen und Dienstentwickler, wie sie die Azure CLI-Erweiterung für AOSM verwenden, um das Onboarding für eine containerisierte Netzwerkfunktion in AOSM durchzuführen. Die CNF kann später in einem mit Azure Arc verbundenen Kubernetes-Cluster bereitgestellt werden, einschließlich eines Azure Operator Nexus-Clusters.

Das Onboarding ist ein mehrstufiger Prozess. Nach Erfüllung der Voraussetzungen können Sie die Azure CLI-Erweiterung für AOSM für Folgendes verwenden:

  1. Generieren von BICEP-Dateien, die Gruppe und Version der Netzwerkfunktionsdefinition (NFD) basierend auf Ihren Helm-Charts und der Datei „values.yaml“ definieren
  2. Veröffentlichen der NFD und Hochladen der CNF-Images und -Charts in einen Artefaktspeicher (von AOSM verwaltete ACR-Instanz (Azure Container Registry))
  3. Hinzufügen der veröffentlichten NFD zu den BICEP-Dateien, die Gruppe und Version eines Netzwerkdienstentwurfs (Network Service Design, NSD) definieren
  4. Veröffentlichen des NSD

Voraussetzungen

  • Sie haben AOSM in Ihrem Azure-Abonnement aktiviert.
  • Wenn Ihre CNF in Azure Operator Nexus ausgeführt werden soll, müssen Sie über Zugriff auf eine Azure Operator Nexus-Instanz verfügen und die Voraussetzungen für die Workloadbereitstellung erfüllen.

Hinweis

Es wird dringend empfohlen, zu testen, ob helm install für Ihr Helm-Paket in Ihrer mit Arc verbundenen Kubernetes-Zielumgebung erfolgreich ist.

Konfigurieren von Berechtigungen

  • Sie benötigen die Rolle „Mitwirkender“ für Ihr Abonnement, um eine Ressourcengruppe erstellen zu können. Alternativ benötigen Sie eine bereits vorhandene Ressourcengruppe, in der Sie über die Rolle „Mitwirkender“ verfügen.
  • Sie benötigen die Rollenzuweisungen Reader/AcrPull für die ACR-Quellinstanz, die Ihre Images enthält.
  • Sie benötigen die Rollenzuweisungen Contributor und AcrPush für das Abonnement, das den von AOSM verwalteten Artefaktspeicher enthalten soll. Mit diesen Berechtigungen kann die Azure CLI-Erweiterung für AOSM einen direkten Kopiervorgang von ACR zu ACR ausführen. Das direkte Kopieren ist die schnellste Methode zum Übertragen von Images von einer ACR-Instanz zu einer anderen.
    • Ihre Unternehmensrichtlinien verhindern möglicherweise, dass Sie über abonnementbezogene Berechtigungen verfügen. Der für die Befehle az aosm nfd publish und az aosm nsd publish verfügbare Parameter --no-subscription-permissions verwendet stark bereichsbezogene Berechtigungen, die vom AOSM-Dienst abgeleitet werden, um einen zweistufigen Kopiervorgang auf Ihren lokalen Computer und von Ihrem lokalen Computer zu orchestrieren. Dieser zweistufige Kopiervorgang ist zwar langsamer, erfordert aber keine Abonnementberechtigungen.

Helm-Pakete

  • Die Helm-Pakete, für die Sie ein Onboarding durchführen möchten, müssen im lokalen Speicher des Computers vorhanden sein, auf dem Sie die CLI ausführen.
    • Die Azure CLI-Erweiterung für AOSM verwendet standardmäßig die Datei values.yaml im Helm-Paket. Die CLI unterstützt das Überschreiben dieses Verhaltens mit einer alternativen Datei vom Typ values.yaml. Diese alternative Datei muss im lokalen Speicher des Computers vorhanden sein, auf dem Sie die CLI ausführen.

Hinweis

Es wird dringend empfohlen, dass das Helm-Paket ein Schema für die Helm-Werte enthält und dass die Helm-Paketvorlagen so aussehen, wie Sie es bei der Ausführung von helm template mit der Datei „values.yaml“ erwarten, die Sie beim Onboarding in AOSM verwenden möchten.

Containerimages

  • Ihre Containerimages sind entweder in einer vorhandenen ACR-Instanz oder einer alternativen Containerregistrierung vorhanden, die die Docker-API unterstützt. Containerimages müssen in Ihrer Quellregistrierung in einer Struktur gespeichert werden, die dem in Ihren Helm-Charts definierten Imagespeicherort entspricht. Diese Anforderung wird im Artikel zu Ermittlung und Upload von CNF-Images mit der CLI erläutert.
  • Verwenden Sie den Befehl docker login, um sich bei einer anderen Containerregistrierung als Azure anzumelden, die Ihre Containerimages hostet, bevor Sie az aosm-Befehle ausführen. Dieser Schritt ist nicht erforderlich, wenn Sie eine ACR-Instanz verwenden: Die Azure CLI-Erweiterung für AOSM wird automatisch angemeldet.

Helm und Docker-Engine

Herunterladen und Installieren der Azure CLI

Informationen zum lokalen Installieren der Azure CLI finden Sie unter Installieren der Azure CLI.

Um sich bei der Azure CLI anzumelden, verwenden Sie den Befehl az login, und befolgen Sie die in Ihrem Terminal angezeigten Eingabeaufforderungen, um die Authentifizierung abzuschließen. Weitere Anmeldeoptionen finden Sie unter Anmelden mit der Azure CLI.

Hinweis

Wenn Sie Windows oder macOS ausführen, sollten Sie die Azure CLI in einem Docker-Container ausführen. Weitere Informationen finden Sie unter Ausführen der Azure CLI in einem Docker-Container. Sie können auch die Bash-Umgebung in Azure Cloud Shell verwenden. Weitere Informationen zur Verwendung der Bash-Umgebung in Azure Cloud Shell finden Sie unter Starten der Cloud Shell.

Installieren der AOSM-CLI-Erweiterung

Für die AOSM-Erweiterung der Azure CLI ist mindestens die Version 2.54.0 der Azure CLI erforderlich.

  1. Führen Sie az version aus, um die installierte Version und die abhängigen Bibliotheken anzuzeigen.
  2. Führen Sie az upgrade aus, um ein Upgrade auf die aktuelle Version der Azure CLI durchzuführen.

Installieren Sie die AOSM-CLI-Erweiterung mithilfe des folgenden Befehls:

az extension add --name aosm

Erstellen der Netzwerkfunktionsdefinitionsgruppe und -version

In diesem Schritt wird ein Ordner im Arbeitsverzeichnis namens cnf-cli-output mit den BICEP-Vorlagen der AOSM-Ressourcen erstellt, die Ihre Netzwerkfunktionsdefinitionsgruppe und -version definieren. Außerdem wird der Artefaktspeicher erstellt. Diese Ressourcen werden letztendlich im Netzwerkdienstentwurf enthalten sein.

  1. Generieren Sie die Eingabedatei der Azure CLI-AOSM-Erweiterung für eine CNF.

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

  2. Öffnen Sie die Eingabedatei, die Sie im vorherigen Schritt generiert haben, und verwenden Sie die Inlinekommentare, um die erforderlichen Werte einzugeben. Dieses Beispiel zeigt die Eingabedatei der Azure CLI-AOSM-Erweiterung für eine fiktive Contoso-CNF.

    Hinweis

    Die Azure CLI-AOSM-Erweiterung macht standardmäßig nur erforderliche Parameter ohne Standardwerte in der Eingabe values.yaml verfügbar. Sie können expose_all_parameters auf true festlegen, um alle Helm-Werte in der Netzwerkfunktionsdefinitionsversion (NFDV) und im Konfigurationsgruppenschema (Configuration Group Schema, CGS) verfügbar zu machen. Weitere Informationen finden Sie im Artikel zum Verfügbarmachen von Parametern mithilfe der AOSM-CLI-Erweiterung.

    {
  // 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. Führen Sie den folgenden Befehl aus, um die BICEP-Vorlagen für die Netzwerkfunktionsdefinitionsgruppe und -version zu erstellen:

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

Sie können die Ordner- und Dateistruktur überprüfen und ggf. Änderungen vornehmen.

Veröffentlichen der Netzwerkfunktionsdefinitionsgruppe und -version

In diesem Schritt werden die AOSM-Ressourcen erstellt, die die Netzwerkfunktionsdefinition und den Artefaktspeicher definieren, der zum Speichern der Containerimages der Netzwerkfunktion verwendet wird. Außerdem werden die Images und Charts in den Artefaktspeicher hochgeladen. Dazu kopieren Sie sie entweder direkt aus der ACR-Quellinstanz oder versehen die Docker-Images lokal mit einem neuen Tag und laden sie mithilfe stark bereichsbezogener Anmeldeinformationen, die vom AOSM-Dienst erstellt wurden, in den Artefaktspeicher hoch, falls Sie nicht über die Rollen Contributor und AcrPush im Abonnementbereich verfügen.

  1. Führen Sie den folgenden Befehl aus, um die Netzwerkfunktionsdefinitionsgruppe und -version zu veröffentlichen. Falls Sie nicht über die Rollen Contributor und AcrPush im Abonnementbereich verfügen, schließen Sie --no-subscription-permissions in den Befehl ein.

Hinweis

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

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

Erstellen der Netzwerkdienstentwurfsgruppe und -version

In diesem Abschnitt wird ein Ordner im Arbeitsverzeichnis nsd-cli-output erstellt. Dieser Ordner enthält die BICEP-Vorlagen der AOSM-Ressourcen, die eine Netzwerkdienstentwurfsgruppe und -version definieren. Dieser Netzwerkdienstentwurf ist eine Vorlage, die in der Standortnetzwerkdienst-Ressource verwendet wird, die die in den vorherigen Abschnitten integrierte Netzwerkfunktion bereitstellt.

  1. Generieren Sie die NSD-Eingabedatei der Azure CLI-AOSM-Erweiterung.

    az aosm nsd generate-config --output-file <nsd-output-filename.jsonc>

  2. Öffnen Sie die Eingabedatei, die Sie im vorherigen Schritt generiert haben, und verwenden Sie die Inlinekommentare, um die erforderlichen Werte einzugeben. Die generierte Eingabedatei enthält ein zusätzliches resource_element_type-Element vom Typ ArmTemplate. Dies ist beim Onboarding einer CNF unnötig. Sie können es löschen. Das Ergebnis sollte wie dieses Beispiel aussehen. Das Beispiel zeigt die Eingabedatei der Azure CLI-AOSM-Erweiterung für einen fiktiven Contoso-NSD, der zum Bereitstellen einer fiktiven Contoso-CNF in einem mit Arc verbundenen Nexus Kubernetes-Cluster verwendet werden kann.

    {
    // 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"
            }
        }
    ]
}

    Hinweis

    Der Ressourcenelement-Vorlagenabschnitt definiert, welche NFD im NSD enthalten ist. Die Eigenschaften müssen mit den Eigenschaften übereinstimmen, die in der an den Befehl az aosm nfd build übergebenen Eingabedatei verwendet werden. Das liegt daran, dass die AOSM-Erweiterung der Azure CLI beim Erstellen des NSD überprüft, ob das Onboarding der NFD ordnungsgemäß durchgeführt wurde.

  3. Führen Sie den folgenden Befehl aus, um die BICEP-Vorlagen für die Netzwerkdienstentwurfsgruppe und -version zu erstellen:

az aosm nsd build --config-file <nsd-output-filename.jsonc>

Sie können die Ordner- und Dateistruktur überprüfen und ggf. Änderungen vornehmen.

Veröffentlichen der Netzwerkdienstentwurfsgruppe und -version

In diesem Schritt werden die AOSM-Ressourcen erstellt, die die Netzwerkdienstentwurfsgruppe und -version definieren. Außerdem werden vom NSD benötigte Artefakte in den Artefaktspeicher hochgeladen (Netzwerkfunktions-ARM-Vorlage ).

  1. Führen Sie den folgenden Befehl aus, um die Netzwerkdienstentwurfsgruppe und -version zu veröffentlichen. Falls Sie nicht über die Rollen Contributor und AcrPush im Abonnementbereich verfügen, schließen Sie --no-subscription-permissions in den Befehl ein.
az aosm nsd publish --build-output-folder nsd-cli-output

Sie verfügen jetzt über einen vollständigen Satz von AOSM-Herausgeberressourcen und können den Operatorflow ausführen.

Nächste Schritte