Udostępnij za pomocą

Dołączanie konteneryzowanej funkcji sieciowej (CNF) do programu Azure Operator Service Manager (AOSM)

W tym przewodniku z instrukcjami wydawcy funkcji sieciowych i projektanci usług dowiedzą się, jak dołączać konteneryzowaną funkcję sieciową do usługi AOSM za pomocą rozszerzenia AOSM interfejsu wiersza polecenia platformy Azure. System CNF można później wdrożyć w klastrze Kubernetes połączonym z usługą Azure Arc, w tym w klastrze Nexus operatora platformy Azure.

Dołączanie jest procesem wieloetapowym. Po spełnieniu wymagań wstępnych, użyjesz rozszerzenia Azure CLI AOSM, aby:

  1. Wygeneruj pliki Bicep, które definiują grupę i wersję Network Function Definition (NFD) na podstawie wykresów Helm i values.yaml.
  2. Opublikuj NFD i przekaż obrazy oraz wykresy CNF do sklepu artefaktów (Azure Container Registry (ACR) zarządzane przez AOSM).
  3. Dodaj opublikowany NFD do plików Bicep, które definiują Grupę Projektową Usługi Sieciowej i Wersję (NSD).
  4. Opublikuj NSD.

Wymagania wstępne

Uwaga / Notatka

Zdecydowanie zaleca się przetestowanie, czy helm install pakiet Helm powiedzie się w docelowym środowisku Kubernetes połączonym z usługą Arc.

Konfigurowanie uprawnień

  • Musisz mieć rolę Współautora w swojej subskrypcji, aby móc utworzyć nową grupę zasobów lub mieć dostęp do istniejącej grupy zasobów, w której masz rolę Współautora.
  • 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 obowiązujące w Twojej firmie mogą uniemożliwić posiadanie uprawnień związanych z subskrypcjami. Parametr --no-subscription-permissions, dostępny w poleceniach az aosm nfd publish i az aosm nsd publish, używa ściśle ograniczonych uprawnień pochodzących z usługi AOSM, aby koordynować dwuetapową kopię na maszynę lokalną i z niej. Ta kopia dwuetapowa jest wolniejsza, ale nie wymaga uprawnień w zakresie subskrypcji.

Pakiety Helm

  • Pakiety Helm, które zamierzasz dodać, muszą znajdować się w lokalnej pamięci maszyny, z której uruchamiasz CLI.
    • Rozszerzenie AOSM Azure CLI będzie domyślnie używać pliku values.yaml w pakiecie Helm. Interfejs wiersza polecenia obsługuje zastępowanie tego zachowania czymś alternatywnym values.yaml. Ten alternatywny plik musi istnieć w lokalnej pamięci maszyny, z której uruchamiasz CLI.

Uwaga / Notatka

Zdecydowanie zaleca się, aby pakiet Helm zawierał schemat wartości Helm i aby szablony pakietów Helm działały zgodnie z oczekiwaniami, gdy helm template jest uruchamiany z użyciem pliku values.yaml, którego zamierzasz użyć podczas dołączania do usługi AOSM.

Obrazy kontenerów

  • Obrazy kontenerów znajdują się w istniejącym rejestrze ACR lub alternatywnym rejestrze kontenerów, który obsługuje interfejs API Docker. Obrazy kontenerów muszą być przechowywane w rejestrze źródłowym w strukturze zgodnej z lokalizacją obrazu zdefiniowaną na wykresach helm. To wymaganie zostało wyjaśnione w Odkrywanie i przesyłanie obrazów CLI CNF.
  • Użyj polecenia docker login , aby zalogować się do rejestru kontenerów spoza Azure, który hostuje Twoje obrazy kontenerów, przed uruchomieniem jakichkolwiek poleceń az aosm. Ten krok nie jest wymagany, jeśli używasz usługi ACR: rozszerzenie AOSM interfejsu wiersza polecenia platformy Azure automatycznie się zaloguje.

Helm i silnik Docker

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 / Notatka

Jeśli korzystasz z systemu Windows lub macOS, rozważ uruchomienie Azure CLI w kontenerze Docker. Aby uzyskać więcej informacji, zobacz Jak uruchomić Azure CLI w kontenerze 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.

Instalowanie rozszerzenia interfejsu wiersza polecenia programu AOSM

Rozszerzenie AOSM dla Azure CLI wymaga wersji 2.54.0 lub nowszej Azure CLI.

  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

Ten krok tworzy folder w katalogu roboczym o nazwie cnf-cli-output z plikami Bicep zasobów AOSM, które definiują grupę definicji funkcji sieciowych i wersję oraz magazyn artefaktów. Te zasoby zostaną ostatecznie uwzględnione w projekcie usługi sieciowej.

  1. Wygeneruj plik wejściowy rozszerzenia AOSM dla Azure CLI dla CNF.

    az aosm nfd generate-config --definition-type cnf --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 CLI dla fikcyjnego Contoso CNF.

    Uwaga / Notatka

    Rozszerzenie Azure CLI AOSM domyślnie uwidacznia tylko wymagane parametry bez wartości domyślnych w danych wejściowych values.yaml. Można ustawić expose_all_parameters do true, aby uwidocznić wszystkie wartości helm w wersji definicji funkcji sieciowej (NFDV) i schematu grupy konfiguracji (CGS). Aby uzyskać więcej informacji, zobacz Uwidacznianie parametrów przy użyciu rozszerzenia CLI 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.
  // 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. Wykonaj następujące polecenie, aby skompilować grupę definicji funkcji sieci i pliki wersji Bicep.

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

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

Opublikuj Grupę Definicji Funkcji Sieciowej i Wersję

W tym kroku zostaną utworzone zasoby AOSM definiujące definicję funkcji sieciowej i magazyn artefaktów, które będą używane do przechowywania obrazów kontenerów funkcji sieciowej. Przekazuje również obrazy i wykresy do magazynu artefaktów, kopiując je bezpośrednio ze źródłowego usługi 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 subskrypcji Contributor i ról AcrPush, uwzględnij --no-subscription-permissions w poleceniu.

Uwaga / Notatka

Jeśli używasz systemu Windows, musisz mieć uruchomiony program Docker Desktop podczas kroku publikowania.

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

Tworzenie grupy projektowej usługi sieciowej oraz jej wersji

Ta sekcja tworzy folder w katalogu roboczym o nazwie nsd-cli-output. Ten folder zawiera pliki Bicep zasobów AOSM, które definiują grupę projektową i wersję usługi sieciowej. Ten projektowanie usługi sieciowej jest szablonem używanym w zasobie usługi sieciowej strony, który wdroży funkcję sieciową, którą zintegrowałeś w poprzednich sekcjach.

  1. Wygeneruj plik wejściowy NSD rozszerzenia AOSM dla Azure CLI.

    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 CNF; można go usunąć. Wynik powinien wyglądać podobnie do tego przykładu. W przykładzie pokazano plik wejściowy rozszerzenia Az CLI AOSM dla fikcyjnej domeny NSD Contoso, który może służyć do wdrożenia fikcyjnego systemu CNF Contoso na klastrze Nexus Kubernetes połączonym z usługą Arc.

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

    Uwaga / Notatka

    W sekcji szablonu elementu zasobu określono, który NFD jest zawarty w NSD. Właściwości muszą być zgodne z właściwościami używanymi w pliku wejściowym przekazanym przez polecenie az aosm nfd build. Dzieje się tak, ponieważ rozszerzenie CLI AOSM platformy Azure sprawdza, czy NFD został poprawnie wdrożony podczas tworzenia NSD.

  3. Wykonaj następujące polecenie, aby skompilować pliki Grupy Projektowania Usługi Sieciowej oraz pliki wersji 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 grupy i wersji projektu usługi sieciowej

W tym kroku zostaną utworzone zasoby AOSM, które definiują grupę projektową i wersję usługi sieciowej. Przekazuje również zasoby wymagane przez Deskryptor Usługi Sieciowej (NSD) do repozytorium 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 subskrypcji Contributor i ról AcrPush, uwzględnij --no-subscription-permissions 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 procesu operatorskiego.

Dalsze kroki

  • Last updated on