Udostępnij za pośrednictwem

Dołączanie konteneryzowanej funkcji sieciowej (CNF) 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ć 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 AOSM interfejsu wiersza polecenia platformy Azure, aby:

  1. Wygeneruj pliki BICEP, które definiują grupę definicji funkcji sieciowych i wersję (NFD) na podstawie wykresów i wartości.yaml programu Helm.
  2. Opublikuj plik NFD i przekaż obrazy i wykresy CNF do magazynu artefaktów (AOSM zarządzane 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

  • Aplikacja AOSM została włączona w ramach subskrypcji platformy Azure.
  • Jeśli twój serwer CNF ma działać na platformie Azure Operator Nexus, masz dostęp do wystąpienia narzędzia Nexus operatora platformy Azure i zostały spełnione wymagania wstępne dotyczące wdrożenia obciążenia.

Uwaga

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

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.

Pakiety helm

  • Pakiety helm, które zamierzasz dołączyć, muszą znajdować się w lokalnym magazynie maszyny, z której jest wykonywany interfejs wiersza polecenia.
    • Rozszerzenie AOSM interfejsu wiersza polecenia platformy Azure będzie domyślnie używać values.yaml pliku w pakiecie helm. Interfejs wiersza polecenia obsługuje zastępowanie tego zachowania alternatywnym values.yamlrozwiązaniem . Ten alternatywny plik musi istnieć w lokalnym magazynie maszyny, z której jest wykonywany interfejs wiersza polecenia.

Uwaga

Zdecydowanie zaleca się, aby pakiet Helm zawierał schemat wartości programu Helm i że szablony pakietów helm zgodnie z oczekiwaniami helm template podczas uruchamiania przy użyciu 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 platformy 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 artykule Odnajdywanie i przekazywanie obrazów CNF interfejsu wiersza polecenia.
  • docker login Użyj polecenia , aby zalogować się do rejestru kontenerów spoza platformy Azure hostowania obrazów kontenerów przed uruchomieniem jakichkolwiek az aosm poleceń. Ten krok nie jest wymagany, jeśli używasz usługi ACR: rozszerzenie AOSM interfejsu wiersza polecenia platformy Azure automatycznie się zaloguje.

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.

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.

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

Ten krok tworzy folder w katalogu roboczym o nazwie cnf-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 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 interfejsu wiersza polecenia dla fikcyjnej firmy Contoso CNF.

    Uwaga

    Rozszerzenie AOSM interfejsu wiersza polecenia platformy Azure uwidacznia tylko wymagane parametry bez wartości domyślnych w danych wejściowych values.yaml . Można ustawić expose_all_parameters wartość , aby uwidocznić true wszystkie wartości programu Helm w wersji definicji funkcji sieciowej (NFDV) i schematu grupy konfiguracji (CGS). Aby uzyskać więcej informacji, zobacz Parametr uwidaczniaj przy użyciu rozszerzenia interfejsu wiersza polecenia usługi 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 szablony BICEP wersji.

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.

Publikowanie sieciowej grupy definicji funkcji i wersji

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 Contributor subskrypcji i AcrPush ról, uwzględnij --no-subscription-permissions je w poleceniu .

Uwaga

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 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 CNF; można go usunąć. Wynik powinien wyglądać podobnie do tego przykładu. W przykładzie pokazano plik wejściowy rozszerzenia AOSM interfejsu wiersza polecenia dla fikcyjnej domeny NSD firmy Contoso, która może służyć do wdrożenia fikcyjnego systemu CNF firmy Contoso w klastrze 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

    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 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ż 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