Udostępnij za pośrednictwem

Dołączanie zwirtualizowanej funkcji sieci (VNF) do wdrożenia na platformie Azure Operator Nexus do programu Azure Operator Service Manager (AOSM)

  • Artykuł

W tym przewodniku z instrukcjami wydawcy funkcji sieciowych i usługi Projektant dowiesz się, jak dołączać funkcję sieciową do usługi AOSM za pomocą rozszerzenia AOSM interfejsu wiersza polecenia platformy Azure. Ten system plików VNF można następnie wdrożyć na platformie Azure Operator Nexus. Dołączanie jest procesem wieloetapowym. Po spełnieniu wymagań wstępnych użyjesz rozszerzenia AOSM interfejsu wiersza polecenia platformy Azure, aby:

  1. Wygeneruj pliki BICEP, które definiują grupę definicji funkcji sieci i wersję (NFD).
  2. Opublikuj plik NFD i przekaż obraz systemu plików VNF do magazynu artefaktów (AOSM zarządzanego przez usługę Azure Container Registry (ACR)).
  3. Dodaj opublikowany system plików NFD do plików BICEP, które definiują grupę projektową usługi sieciowej i wersję (NSD).
  4. Opublikuj NSD.

Wymagania wstępne

Uwaga

Zdecydowanie zaleca się przetestowanie, czy wdrożenie maszyny wirtualnej zakończy się pomyślnie w wystąpieniu narzędzia Nexus operatora platformy Azure przed dołączeniu systemu plików VNF do programu AOSM.

Obrazy maszyn wirtualnych platformy Azure Operator Nexus i szablony usługi Azure Resource Manager (ARM)

  • Utworzono obraz maszyny wirtualnej Nexus operatora platformy Azure. Ten obraz musi być dostępny w usłudze ACR.

  • Utworzono szablon usługi ARM, który wdraża maszynę wirtualną Platformy Azure Operator Nexus.

  • Szablon arm maszyny wirtualnej (zarówno dla platformy AzureCore, jak i operatora platformy Azure Nexus) może wdrażać tylko zasoby usługi ARM od następujących dostawców zasobów

    • Microsoft.Compute
    • Microsoft.Network
    • Microsoft.NetworkCloud
    • Microsoft.Storage
    • Microsoft.NetworkFabric
    • Microsoft.Authorization
    • Microsoft.ManagedIdentity

  • Szablon arm systemu plików VNF powinien wdrożyć jedną maszynę wirtualną. Wiele maszyn wirtualnych można wdrożyć, włączając wiele wystąpień NFDV w NSDV.

Konfiguracja uprawnień

  • Aby utworzyć grupę zasobów lub istniejącą grupę zasobów, w której masz rolę Współautor, musisz mieć rolę Współautor.
  • Wymagane są Reader/AcrPull przypisania ról w źródłowym rekordzie ACR zawierającym obrazy.
  • Wymagane są Contributor przypisania ról i AcrPush w subskrypcji, które będą zawierać zarządzany magazyn artefaktów usługi AOSM. Te uprawnienia umożliwiają rozszerzeniu AOSM interfejsu wiersza polecenia platformy Azure wykonywanie bezpośredniej kopii usługi ACR-to-ACR. Kopiowanie bezpośrednie to najszybsza metoda przesyłania obrazów z jednego rekordu ACR do innego.
    • Zasady firmy mogą uniemożliwić posiadanie uprawnień w zakresie subskrypcji. Parametr --no-subscription-permissions dostępny w az aosm nfd publish poleceniach i az aosm nsd publish używa ściśle ograniczonych uprawnień pochodzących z usługi AOSM, aby zorganizować dwuetapową kopię na maszynie lokalnej i z niego. Ta kopia dwuetapowa jest wolniejsza, ale nie wymaga uprawnień w zakresie subskrypcji.

Pobieranie i instalowanie interfejsu wiersza polecenia platformy Azure

Aby zainstalować interfejs wiersza polecenia platformy Azure lokalnie, zobacz Jak zainstalować interfejs wiersza polecenia platformy Azure.

Aby zalogować się do interfejsu wiersza polecenia platformy Azure, użyj az login polecenia i ukończ monity wyświetlane w terminalu, aby zakończyć uwierzytelnianie. Aby uzyskać więcej opcji logowania, zobacz Logowanie się przy użyciu interfejsu wiersza polecenia platformy Azure.

Uwaga

Jeśli korzystasz z systemu Windows lub macOS, rozważ uruchomienie interfejsu wiersza polecenia platformy Azure w kontenerze Docker. Aby uzyskać więcej informacji, zobacz Jak uruchomić interfejs wiersza polecenia platformy Azure w kontenerze platformy Docker. Możesz również użyć środowiska powłoki Bash w usłudze Azure Cloud Shell. Aby uzyskać więcej informacji, zobacz Uruchamianie usługi Cloud Shell w celu korzystania ze środowiska powłoki Bash w usłudze Azure Cloud Shell.

Aparat Helm i Docker

  • Zainstaluj interfejs wiersza polecenia programu Helm na komputerze hosta. Należy użyć programu Helm w wersji 3.8.0 lub nowszej.
  • Zainstaluj platformę Docker na komputerze hosta.

Instalowanie rozszerzenia interfejsu wiersza polecenia programu AOSM

Rozszerzenie AOSM interfejsu wiersza polecenia az wymaga wersji 2.54.0 lub nowszej interfejsu wiersza polecenia platformy Azure.

  1. Uruchom polecenie az version , aby wyświetlić zainstalowaną wersję i biblioteki zależne.
  2. Uruchom polecenie az upgrade , aby uaktualnić do bieżącej wersji interfejsu wiersza polecenia platformy Azure.

Zainstaluj rozszerzenie interfejsu wiersza polecenia programu AOSM przy użyciu tego polecenia:

az extension add --name aosm

Tworzenie grupy i wersji definicji funkcji sieci

Ta sekcja tworzy folder w katalogu roboczym o nazwie vnf-cli-output z szablonami BICEP zasobów AOSM, które definiują grupę definicji funkcji sieci i wersję oraz magazyn artefaktów. Te zasoby zostaną ostatecznie uwzględnione w projekcie usługi sieciowej

  1. Wygeneruj plik wejściowy rozszerzenia AOSM interfejsu wiersza polecenia platformy Azure dla systemu plików VNF.

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

  2. Otwórz plik wejściowy wygenerowany w poprzednim kroku i użyj wbudowanych komentarzy, aby wprowadzić wymagane wartości. W tym przykładzie przedstawiono plik wejściowy rozszerzenia AOSM interfejsu wiersza polecenia dla fikcyjnego systemu plików VNF firmy Contoso, który działa na platformie Azure Operator Nexus.

    Uwaga

    Rozszerzenie AOSM interfejsu wiersza polecenia platformy Azure uwidacznia tylko wymagane parametry bez wartości domyślnych w wejściowym szablonie usługi ARM. Można ustawić expose_all_parameters wartość tak, aby true uwidocznić wszystkie parametry szablonu usługi ARM w wersji definicji funkcji sieciowej (NFDV) i schemacie grupy konfiguracji (CGS). Aby uzyskać bardziej szczegółowe informacje, zobacz Parametr uwidaczniany przy użyciu rozszerzenia interfejsu wiersza polecenia AOSM.

    {
    // 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-vnf",
    // Name of the ACR Artifact Store resource.
    // Will be created if it does not exist.
    "acr_artifact_store_name": "contoso-vnf-artifact-store",
    // Name of the network function.
    "nf_name": "contoso-vnf",
    // Version of the network function 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,
    // ARM template configuration. The ARM templates given here would deploy a VM if run. They will be used to generate the VNF.
    "arm_templates": [
        {
            // Name of the artifact. Used as internal reference only.
            "artifact_name": "contoso-vnf",
            // 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": "/home/contoso-vnf/contoso-vnf-arm-template.json"
        }
    ],
    // List of images to be pulled from the acr registry.
    // You must provide the source acr registry, the image name and the version.
    // For example: 'sourceacr.azurecr.io/imagename:imageversion'.
    "images": ["contoso-vnf.azurecr.io/contosovnf:1.0.0"]
}```

  3. Wykonaj następujące polecenie, aby skompilować grupę definicji funkcji sieciowych i wersję.

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

Publikowanie sieciowej grupy definicji funkcji i wersji

W tym kroku są tworzone zasoby AOSM, które definiują definicję funkcji sieciowej i magazyn artefaktów, które będą używane do przechowywania obrazów maszyn wirtualnych funkcji sieciowej. Przekazuje również obrazy do magazynu artefaktów, kopiując je bezpośrednio ze źródłowego rekordu ACR lub, jeśli nie masz zakresu Contributor subskrypcji i AcrPush ról, przełączając obrazy platformy Docker lokalnie i przekazując je do magazynu artefaktów przy użyciu ściśle ograniczonych poświadczeń wygenerowanych z usługi AOSM.

  1. Wykonaj następujące polecenie, aby opublikować grupę definicji funkcji sieciowych i wersję. Jeśli nie masz zakresu Contributor subskrypcji i AcrPush ról, uwzględnij --no-subscription-permissions je w poleceniu .
az aosm nfd publish --build-output-folder vnf-cli-output --definition-type vnf

W razie potrzeby możesz przejrzeć strukturę folderów i plików oraz wprowadzić modyfikacje.

Tworzenie grupy i wersji projektu usługi sieciowej

Ta sekcja tworzy folder w katalogu roboczym o nazwie nsd-cli-output. Ten folder zawiera szablony BICEP zasobów AOSM, które definiują grupę projektową i wersję usługi sieciowej. Ten projekt usługi sieciowej jest szablonem używanym w zasobie usługi sieci lokacji, który wdroży funkcję sieciową dołączona w poprzednich sekcjach.

  1. Wygeneruj plik wejściowy NSD rozszerzenia AOSM dla interfejsu wiersza polecenia platformy Azure.

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

  2. Otwórz plik wejściowy wygenerowany w poprzednim kroku i użyj wbudowanych komentarzy, aby wprowadzić wymagane wartości. Wygenerowany plik wejściowy zawiera dodatkowy resource_element_type typ ArmTemplate. Jest to niepotrzebne podczas dołączania systemu plików VNF; można go usunąć. W tym przykładzie pokazano plik wejściowy rozszerzenia AOSM interfejsu wiersza polecenia dla fikcyjnej domeny NSD firmy Contoso, który może służyć do wdrożenia fikcyjnego systemu plików VNF firmy Contoso na wystąpieniu urządzenia Azure Operator Nexus.

    {
    // 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-vnf",
    // Name of the ACR Artifact Store resource.
    // Will be created if it does not exist.
    "acr_artifact_store_name": "contoso-vnf-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-vnf-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-vnf 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-vnf",
                // 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-vnf",
                // 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": "vnf"
            }
        }
    ]
}

    Uwaga

    Sekcja szablonu elementu zasobu definiuje, który plik NFD jest zawarty w NSD. Właściwości muszą być zgodne z właściwościami używanymi w pliku wejściowym przekazanym az aosm nfd build do polecenia . Dzieje się tak, ponieważ rozszerzenie AOSM interfejsu wiersza polecenia platformy Azure sprawdza, czy plik NFD został poprawnie dołączony podczas kompilowania sieciowej bazy danych.

  3. Wykonaj następujące polecenie, aby skompilować szablony Network Service Design Group i Version BICEP.

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

W razie potrzeby możesz przejrzeć strukturę folderów i plików oraz wprowadzić modyfikacje.

Publikowanie projektu usługi sieciowej (NSD)

W tym kroku zostaną utworzone zasoby AOSM, które definiują grupę projektową i wersję usługi sieciowej. Przekazuje również artefakty wymagane przez NSD do magazynu artefaktów (szablon arm funkcji sieciowej).

  1. Wykonaj następujące polecenie, aby opublikować grupę projektową i wersję usługi sieciowej. Jeśli nie masz zakresu Contributor subskrypcji i AcrPush ról, uwzględnij --no-subscription-permissions je w poleceniu .
az aosm nsd publish --build-output-folder nsd-cli-output

Masz teraz kompletny zestaw zasobów wydawcy AOSM i możesz przystąpić do wykonywania przepływu operatora.

Następne kroki