Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Mit Azure Operator Service Manager (AOSM) können Sie Network Function Definition Versions (NFDV) und Azure Resource Manager (ARM)-Vorlagen in einer Network Service Design Version (NSDV) kombinieren. Der NSDV wird zu einer einzelnen Vorlage für einen Netzwerkdienst, der sowohl eine Netzwerkfunktion als auch die Azure-Infrastruktur enthält, die ausgeführt werden muss. Ein Operator kann dann die Network Function (NF) und seine Infrastruktur in einem Einzigen Vorgang bereitstellen.
In dieser Anleitung erfahren Sie, wie Sie die Azure CLI AOSM-Erweiterung verwenden, um eine NSDV zu erstellen und zu veröffentlichen, die sowohl eine Containerized Network Function (CNF) als Auch eine Azure Resource Manager (ARM)-Ressource enthält.
Das Onboarding ist ein mehrstufiger Prozess. Sobald Sie die Voraussetzungen erfüllt haben, verwenden Sie die Azure CLI AOSM-Erweiterung für:
- Ändern Sie eine bereits vorhandene NSDV-Eingabedatei für eine CNF-Datei, für die das Onboarding bereits durchgeführt wurde.
- Füllen Sie die Eingabedatei mit den informationen aus, die zum Erstellen der AOSM-Ressourcendefinitionen erforderlich sind.
- Generieren Sie Bicep-Dateien, die eine Netzwerk-Service-Design-Gruppe und Version (NSDV) basierend auf der Eingabedatei und Ihrer ARM-Vorlage definieren.
- Veröffentlichen Sie die NSDV und Laden Sie die ARM-Vorlage in einen Artefaktspeicher (von AOSM-verwaltete ACR-Instanz (Azure Container Registry)) hoch.
Diese Anleitung verwendet Azure Key Vault (AKV) als Beispiel für eine Azure-Ressource, aber jede Azure-Ressource kann integriert werden, indem Sie die gleichen Schritte ausführen. In diesem Artikel wird ein CNF als Beispiel-NF verwendet. Der Prozess ist für eine virtualisierte Netzwerkfunktion (VNF) identisch, abgesehen von geringfügigen Unterschieden in der NSDV-Eingabedatei.
Voraussetzungen
- Sie haben AOSM in Ihrem Azure-Abonnement aktiviert.
- Wenn Ihr CNF auf Azure Operator Nexus ausgeführt werden soll, haben Sie Zugriff auf eine Azure Operator Nexus-Instanz und haben die Voraussetzungen für die Workloadbereitstellung abgeschlossen.
- Sie haben eine CNF integriert und haben die Eingabedatei, die Sie mit der
az aosm nsd generate-configDatei generiert haben, die auf dem lokalen Speicher des Computers verfügbar ist, von dem Sie die CLI ausführen.
Konfigurieren von Berechtigungen
- Sie benötigen die Rolle "Mitwirkender" für Ihr Abonnement, um eine Ressourcengruppe zu erstellen, oder Sie benötigen eine vorhandene Ressourcengruppe, in der Sie über die Rolle "Mitwirkender" verfügen.
- Sie benötigen die Rollenzuweisungen
ContributorundAcrPushfür das Abonnement, das den von AOSM verwalteten Artefaktspeicher enthalten soll.- Ihre Unternehmensrichtlinie verhindert möglicherweise, dass Sie über Berechtigungen mit Abonnementbereich verfügen. Der
--no-subscription-permissions-Parameter, der für denaz aosm nsd publish-Befehl verfügbar ist, verwendet eng definierte Berechtigungen, die vom AOSM-Dienst abgeleitet wurden, um eine zweistufige Kopie auf Ihren lokalen Computer und von diesem zu orchestrieren. Diese zweistufige Kopie ist langsamer, erfordert jedoch keine Abonnementberechtigungen.
- Ihre Unternehmensrichtlinie verhindert möglicherweise, dass Sie über Berechtigungen mit Abonnementbereich verfügen. Der
ARM-Vorlagen
- Sie müssen über eine ARM-Vorlage verfügen, die die Azure-Ressourcen definiert, die Sie im lokalen Speicher des Computers bereitstellen möchten, von dem aus Sie die CLI ausführen.
- Alle Parameter, die Sie dem Operator zur Verfügung stellen möchten, der Ihren NSDV bereitstellt, muss als Parameter in der ARM-Vorlage definiert werden.
Hinweis
Die Az CLI AOSM-Erweiterung unterstützt das Onboarding von Azure-Ressourcen, die in einer Bicep-Datei definiert sind, nicht. Sie können jedoch den bicep build Befehl verwenden, um Ihre BICEP-Dateien in ARM-Vorlagen zu konvertieren. Ausführliche Informationen und Anweisungen finden Sie in der Bicep CLI-Dokumentation .
Helm und Docker-Engine
- Installieren Sie Helm CLI auf dem Hostcomputer. Sie müssen Helm V3.8.0 oder höher verwenden.
- Installieren Sie Docker auf dem Hostcomputer.
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 mit Windows oder macOS arbeiten, 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
Die Az CLI AOSM-Erweiterung erfordert Version 2.54.0 oder höher der Azure CLI.
- Führen Sie
az versionaus, um die installierte Version und die abhängigen Bibliotheken anzuzeigen. - Führen Sie
az upgradeaus, um ein Upgrade auf die aktuelle Version der Azure CLI durchzuführen.
Installieren Sie die AOSM CLI-Erweiterung mit diesem Befehl:
az extension add --name aosm
Netzwerkdienstdesign-Gruppe und Version erstellen
Öffnen Sie die NSDV-Eingabedatei, die Sie beim Onboarding Ihrer CNF generiert haben.
Hinweis
Sie können eine neue Eingabedatei mithilfe des
az aosm nsd generate-config --output-file <nsd-output-filename.jsonc>Befehls generieren, wenn Sie nicht über die NSDV-Eingabedatei in Ihrem CNF-Onboarding verfügen.Geben Sie die erforderlichen Werte mithilfe der Inlinekommentare in Die Eingabedatei ein. Dieses Beispiel zeigt die Eingabedatei der Az CLI AOSM-Erweiterung für ein fiktives Contoso NSDV, das verwendet werden kann, um ein fiktives Contoso CNF auf einem Arc-verbundenen Nexus Kubernetes-Cluster und einer AKV-Instanz an einem Azure-Standort bereitzustellen.
{ // 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 and an Azure Key Vault", // 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" } }, { // Type of Resource Element. Either NF or ArmTemplate "resource_element_type": "ArmTemplate", // Properties of the Resource Element. "properties": { // Name of the artifact. Used as internal reference only. "artifact_name": "contoso-keyvault", // Version of the artifact in 1.1.1 format (three integers separated by dots). "version": "1.0.0", // File path (absolute or relative to this configuration file) of the artifact you wish to upload from your local disk. // Use Linux slash (/) file separator even if running on Windows. "file_path": "./contoso-keyvault.json" } } ] }Hinweis
Der Ressourcenelement-Vorlagenabschnitt definiert, welche NFD im NSD enthalten ist. Die Eigenschaften müssen mit den Eigenschaften übereinstimmen, die in der An den
az aosm nfd buildBefehl übergebenen Eingabedatei verwendet werden. Dies liegt daran, dass die Azure CLI AOSM-Erweiterung überprüft, ob die NFD beim Erstellen der NSD ordnungsgemäß integriert wurde.Führen Sie den folgenden Befehl aus, um die Dateien Network Service Design Group und Version Bicep zu erstellen.
az aosm nsd build --config-file <nsd-output-filename.jsonc>
Sie können die Struktur des Ordners und der Dateien überprüfen und ggf. Änderungen vornehmen.
Veröffentlichen Sie die Netzwerkdienstentwurfsgruppe und -version
In diesem Schritt werden die AOSM-Ressourcen erstellt, die die Netzwerkdienstentwurfsgruppe und -version definieren. Außerdem lädt es die vom NSDV benötigten Artefakte in den Artefaktspeicher hoch (NF ARM-Vorlage und AKV ARM-Vorlage).
- Führen Sie den folgenden Befehl aus, um die Netzwerkdienstentwurfsgruppe und -version zu veröffentlichen. Wenn Sie weder den Abonnementbereich
Contributornoch die RollenAcrPushhaben, fügen Sie--no-subscription-permissionszum Befehl hinzu.
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.