Korzystanie z rozszerzenia interfejsu wiersza polecenia programu Azure Operator Service Manager (AOSM)

  • Artykuł

W tym przewodniku z instrukcjami wydawcy funkcji sieciowych i usługi Projektant dowiesz się, jak rozpocząć pracę z definicjami funkcji sieciowych (NFD) i projektami usług sieciowych (NSD).

Rozszerzenie interfejsu az aosm wiersza polecenia ma zapewnić obsługę publikowania projektów i definicji programu Azure Operator Service Manager. Rozszerzenie interfejsu wiersza polecenia ułatwia proces publikowania definicji funkcji sieci (NFD) i sieciowych wzorów usług (NSD) do użycia z programem Azure Operator Service Manager.

Wymagania wstępne

Skontaktuj się z zespołem ds. kont Microsoft, aby zarejestrować subskrypcję platformy Azure w celu uzyskania dostępu do programu Azure Operator Service Manager (AOSM) lub wyrazić zainteresowanie za pośrednictwem formularza rejestracji partnera.

Pobieranie i instalowanie interfejsu wiersza polecenia platformy Azure

Użyj ś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.

W przypadku użytkowników, którzy wolą uruchamiać polecenia referencyjne interfejsu wiersza polecenia lokalnie, zobacz Jak zainstalować interfejs wiersza polecenia platformy Azure.

Jeśli korzystasz z okna lub systemu macOS, rozważ uruchomienie interfejsu wiersza polecenia platformy Azure w kontenerze platformy Docker. Aby uzyskać więcej informacji, zobacz Jak uruchomić interfejs wiersza polecenia platformy Azure w kontenerze platformy Docker.

Jeśli używasz instalacji lokalnej, zaloguj się do interfejsu wiersza polecenia platformy Azure przy użyciu 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.

Instalowanie rozszerzenia interfejsu wiersza polecenia programu Azure Operator Service Manager (AOSM)

Zainstaluj rozszerzenie interfejsu wiersza polecenia programu Azure Operator Service Manager (AOSM) przy użyciu tego polecenia:

az extension add --name aosm
  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.

Rejestrowanie i weryfikowanie wymaganych dostawców zasobów

Przed rozpoczęciem korzystania z programu Azure Operator Service Manager upewnij się, że zarejestrowano wymaganego dostawcę zasobów. Wykonaj następujące polecenia. Ten proces rejestracji może potrwać do 5 minut.

# Register Resource Provider
az provider register --namespace Microsoft.HybridNetwork
az provider register --namespace Microsoft.ContainerRegistry

Sprawdź stan rejestracji dostawców zasobów. Wykonaj następujące polecenia.

# Query the Resource Provider
az provider show -n Microsoft.HybridNetwork --query "{RegistrationState: registrationState, ProviderName: namespace}"
az provider show -n Microsoft.ContainerRegistry --query "{RegistrationState: registrationState, ProviderName: namespace}"

Uwaga

Ukończenie rejestracji dostawcy zasobów może potrwać kilka minut. Po pomyślnym zakończeniu rejestracji możesz kontynuować korzystanie z programu Azure Operator Service Manager (AOSM).

Wymagania dotyczące funkcji sieci konteneryzowanej (CNF)

W przypadku osób korzystających z konteneryzowanych funkcji sieciowych niezbędne jest upewnienie się, że na maszynie, na której jest wykonywany interfejs wiersza polecenia, są zainstalowane następujące pakiety:

  • Zainstaluj program Helm, zobacz Instalowanie interfejsu wiersza polecenia programu Helm.
  • W niektórych okolicznościach zainstaluj platformę Docker, zapoznaj się z artykułem Instalowanie aparatu platformy Docker. Potrzebne tylko wtedy, gdy obraz źródłowy znajduje się w lokalnym repozytorium platformy Docker lub nie masz uprawnień dotyczących całej subskrypcji wymaganych do wypychania wykresów i obrazów.

Uprawnienia

Wymagane jest konto platformy Azure z aktywną subskrypcją. Jeśli nie masz subskrypcji platformy Azure, przed rozpoczęciem postępuj zgodnie z instrukcjami podanymi w temacie Rozpocznij bezpłatnie , aby utworzyć konto.

Aby utworzyć grupę zasobów lub istniejącą grupę zasobów, w której masz rolę Współautor, musisz mieć rolę Współautor.

Uprawnienia do publikowania plików CNFs

W przypadku określania źródła obrazów CNF z istniejącej usługi ACR musisz mieć Reader/AcrPull uprawnienia z tego rekordu ACR i w idealnym przypadku rolę i AcrPush rolę (lub rolę niestandardową, Contributor która umożliwia importImage działanie i AcrPush) w całej subskrypcji, aby móc zaimportować je do nowego magazynu artefaktów. Jeśli masz te elementy, nie musisz instalować platformy Docker lokalnie, a kopiowanie obrazu jest szybkie.

Jeśli nie masz uprawnień dla całej subskrypcji, możesz uruchomić az aosm nfd publish polecenie przy użyciu --no-subscription-permissions flagi , aby ściągnąć obraz na komputer lokalny, a następnie wypchnąć go do magazynu artefaktów przy użyciu poświadczeń manifestu o zakresie tylko do magazynu. Wymaga zainstalowania platformy Docker lokalnie.

Omówienie rozszerzenia interfejsu wiersza polecenia programu Azure Operator Service Manager (AOSM)

Wydawcy funkcji sieciowych i usługi Projektant używają rozszerzenia interfejsu wiersza polecenia platformy Azure, aby ułatwić publikowanie definicji funkcji sieciowych (NFD) i sieciowych projektów usług (NSD).

Jak wyjaśniono w temacie Role i interfejsy, wydawca funkcji sieciowej ma różne obowiązki. Rozszerzenie interfejsu wiersza polecenia pomaga w wyświetlaniu elementów pogrubionych:

  • Utwórz funkcję sieciową.
  • Zakoduj je w projekcie funkcji sieciowej (NFD).
  • Określ parametry wdrożenia, aby uwidocznić Projektant usługi.
  • Dołącz projekt funkcji sieciowej (NFD) do programu Azure Operator Service Manager (AOSM).
  • Przekaż skojarzone artefakty.
  • Zweryfikuj projekt funkcji sieciowej (NFD).

Usługa Projektant ma również różne obowiązki, z których rozszerzenie interfejsu wiersza polecenia pomaga w pogrubieniu elementów:

  • Wybierz definicje funkcji sieciowych uwzględnione w projekcie usługi.
  • Zakoduj to w projekcie usługi sieciowej.
  • Łączenie infrastruktury platformy Azure z projektem usługi sieciowej.
  • Określ, jak parametryzować usługę, definiując co najmniej jeden schemat grupy konfiguracji (CGSs).
  • Określ sposób mapowania danych wejściowych z operatora usługi na parametry wymagane przez definicje funkcji sieciowych i infrastrukturę platformy Azure.
  • Dołącz projekt usługi sieciowej (NSD) do programu Azure Operator Service Manager (AOSM).
  • Przekaż skojarzone artefakty.
  • Zweryfikuj projekt usługi sieciowej (NSD).

Podsumowanie przepływu pracy

Ogólny przepływ pracy korzystania z rozszerzenia interfejsu wiersza polecenia to:

  1. Znajdź wymagane elementy wymagań wstępnych dla danego przypadku użycia.

  2. Uruchom polecenie , generate-config aby wyświetlić przykładowy plik konfiguracji JSON dla kolejnych poleceń.

  3. Wypełnij plik konfiguracji.

  4. Uruchom polecenie , build aby wyświetlić co najmniej jeden szablon bicep dla definicji funkcji sieciowej lub projektu usługi sieciowej.

  5. Przejrzyj dane wyjściowe polecenia kompilacji, edytuj dane wyjściowe zgodnie z wymaganiami.

  6. publish Uruchom polecenie, aby:

    • Utwórz wszystkie zasoby wymagań wstępnych, takie jak grupa zasobów, wydawca, magazyny artefaktów, grupy.
    • Wdróż te szablony bicep.
    • Przekazywanie artefaktów do magazynów artefaktów.

Punkt początkowy systemu plików VNF

W przypadku plików VNFs potrzebny jest pojedynczy szablon usługi ARM, który tworzy zasoby platformy Azure dla systemu plików VNF, na przykład maszynę wirtualną, dyski i karty sieciowe. Szablon usługi ARM musi być przechowywany na maszynie, z której wykonujesz interfejs wiersza polecenia.

W przypadku zwirtualizowanych wersji definicji funkcji sieci (VNF NFDVs) lista networkFunctionApplications musi zawierać jeden plik VhdImageFile i jeden szablon usługi ARM. Nietypowe jest uwzględnienie więcej niż jednego szablonu VhdImageFile i więcej niż jednego szablonu usługi ARM. Jeśli nie masz silnego powodu, szablon usługi ARM powinien wdrożyć jedną maszynę wirtualną. Usługa Projektant powinna zawierać wiele kopii definicji funkcji sieciowej (NFD) z projektem usługi sieciowej (NSD), jeśli chcesz wdrożyć wiele maszyn wirtualnych. Szablon usługi ARM (zarówno dla platformy AzureCore, jak i 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

Potrzebny jest również obraz wirtualnego dysku twardego, który będzie używany dla maszyny wirtualnej VNF. Obraz wirtualnego dysku twardego może być przechowywany na maszynie, z której wykonujesz interfejs wiersza polecenia lub w magazynie obiektów blob platformy Azure dostępnym za pośrednictwem identyfikatora URI sygnatury dostępu współdzielonego.

Punkt początkowy CNF

W przypadku wdrożeń konteneryzowanych funkcji sieciowych (CNFs) kluczowe jest przechowywanie następujących elementów na maszynie, z której jest wykonywany interfejs wiersza polecenia:

  • Pakiety Helm ze schematem — te pakiety powinny znajdować się w magazynie lokalnym i przywoływne w input.json pliku konfiguracji. Korzystając z tego przewodnika Szybki start, pobierz wymagany pakiet helm.

  • Tworzenie przykładowego pliku konfiguracji — generowanie przykładowego pliku konfiguracji do definiowania wdrożenia systemu CNF. Wydaj to polecenie, aby wygenerować input.json plik, który należy wypełnić za pomocą określonej konfiguracji.

    az aosm nfd generate-config

  • Obrazy dla systemu CNF — oto opcje:

    • Odwołanie do istniejącej usługi Azure Container Registry zawierającej obrazy dla systemu CNF. Obecnie tylko jeden rekord ACR i przestrzeń nazw są obsługiwane dla systemu plików CNF. Obrazy, które mają być kopiowane z tego usługi ACR, są wypełniane automatycznie na podstawie schematu pakietu helm. Musisz mieć uprawnienia Czytelnik/AcrPull dla tego usługi ACR. Aby użyć tej opcji, wypełnij source_registry i opcjonalnie source_registry_namespace w pliku input.json.
    • Nazwa obrazu źródłowego obrazu platformy Docker z komputera lokalnego. Ta nazwa obrazu dotyczy ograniczonego przypadku użycia, w którym system plików CNF wymaga tylko jednego obrazu platformy Docker, który istnieje w lokalnym repozytorium platformy Docker. Aby użyć tej opcji, wypełnij source_local_docker_image plik input.json. Wymaga zainstalowania platformy Docker. Ten przewodnik Szybki start przeprowadzi Cię przez proces pobierania obrazu platformy Docker nginx do użycia dla tej opcji.

  • Opcjonalnie: Plik mapowania (path_to_mappings): opcjonalnie możesz podać plik (na dysku) o nazwie path_to_mappings. Ten plik powinien dublować values.yamlelement z wybranymi wartościami zastąpionymi parametrami wdrożenia. W ten sposób uwidacznia je jako parametry dla systemu CNF. Możesz również pozostawić to pole puste w input.json pliku i wygenerować plik za pomocą interfejsu wiersza polecenia. Domyślnie każda wartość w tym values.yaml przypadku jest uwidoczniona jako parametr wdrożenia. Alternatywnie użyj argumentu interfejsu --interactive wiersza polecenia, aby interaktywnie dokonać wyborów. Ten przewodnik Szybki start przeprowadzi Cię przez proces tworzenia tego pliku.

Podczas konfigurowania input.json pliku upewnij się, że masz listę pakietów Helm w kolejności ich wdrożenia. Jeśli na przykład pakiet "A" musi zostać wdrożony przed pakietem "B" input.json , powinien on przypominać następującą strukturę:

"helm_packages": [
    {
        "name": "A",
        "path_to_chart": "Path to package A",
        "path_to_mappings": "Path to package A mappings",
        "depends_on": [
            "Names of the Helm packages this package depends on"
        ]
    },
    {
        "name": "B",
        "path_to_chart": "Path to package B",
        "path_to_mappings": "Path to package B mappings",
        "depends_on": [
            "Names of the Helm packages this package depends on"
        ]
    }
]

Przestrzeganie tych wytycznych zapewnia dobrze zorganizowane i ustrukturyzowane podejście do wdrażania konteneryzowanych funkcji sieciowych (CNFs) przy użyciu pakietów Helm i skojarzonych konfiguracji.

Punkt początkowy NSD

W przypadku dysków NSD należy znać szczegóły definicji funkcji sieciowych (NFD), aby uwzględnić je w projekcie:

  • grupa zasobów wydawcy NFD
  • nazwa i zakres wydawcy NFD
  • nazwa sieciowej grupy definicji funkcji
  • lokalizacja, typ i wersja wersji definicji funkcji sieciowej

Możesz użyć az aosm nfd poleceń , aby utworzyć wszystkie te zasoby.

Polecenia programu Azure Operator Service Manager (AOSM)

Przed rozpoczęciem użyj następujących poleceń:

  1. az login służy do logowania się do interfejsu wiersza polecenia platformy Azure.

  2. az account set --subscription <subscription> służy do wybierania subskrypcji, nad którą chcesz pracować.

Polecenia NFD

Uzyskaj pomoc dotyczącą argumentów poleceń:

  • az aosm -h

  • az aosm nfd -h

  • az aosm nfd build -h

Polecenia typu definicji

Wszystkie te polecenia przyjmują --definition-type argument lub vnfcnf.

Utwórz przykładowy plik konfiguracji na potrzeby tworzenia definicji:

  • az aosm nfd generate-config

To polecenie generuje plik o nazwie input.json, który musi być wypełniony. Po wypełnieniu pliku konfiguracji można uruchomić następujące polecenia.

Lokalnie skompiluj definicję NFD:

  • az aosm nfd build --config-file input.json

Więcej opcji tworzenia definicji NFD lokalnie:

  • Wybierz parametry szablonu usługi ARM systemu plików VNF, które chcesz uwidocznić jako parametry wdrożenia systemu plików NFD, z opcją interaktywnego wybierania każdego z nich:

    • az aosm nfd build --config-file input.json --definition_type vnf --order_params
    • az aosm nfd build --config-file input.json --definition_type vnf --order_params --interactive

Wybierz parametry wartości CNF programu Helm, które mają być uwidocznione jako wdrożenie systemu plików NFDParameters:

  • az aosm nfd build --config-file input.json --definition_type cnf --interactive

Publikowanie wstępnie utworzonej definicji:

  • az aosm nfd publish --config-file input.json

Usuń opublikowaną definicję:

  • az aosm nfd delete --config-file input.json

Usuń opublikowaną definicję i wydawcę, magazyny artefaktów i grupę NFD:

  • az aosm nfd delete --config-file input.json --clean

Polecenia NSD

Uzyskaj pomoc dotyczącą argumentów poleceń:

  • az aosm -h

  • az aosm nsd -h

  • az aosm nsd build -h

Utwórz przykładowy plik konfiguracji na potrzeby tworzenia definicji:

  • az aosm nsd generate-config

To polecenie generuje plik o nazwie input.json, który musi być wypełniony. Po wypełnieniu pliku konfiguracji można uruchomić następujące polecenia.

Skompiluj NSD lokalnie:

  • az aosm nsd build --config-file input.json

Publikowanie wstępnie utworzonego projektu:

  • az aosm nsd publish --config-file input.json

Usuń opublikowany projekt:

  • az aosm nsd delete --config-file input.json

Usuń opublikowany projekt i wydawcę, magazyny artefaktów i grupę NSD:

  • az aosm nsd delete --config-file input.json --clean

Edytowanie danych wyjściowych kompilacji przed opublikowaniem

Rozszerzenie interfejsu az aosm wiersza polecenia ma zapewnić obsługę publikowania projektów i definicji programu Azure Operator Service Manager. Udostępnia bloki konstrukcyjne do tworzenia złożonych projektów niestandardowych i definicji. Możesz edytować pliki wyjściowe za pomocą build polecenia przed uruchomieniem publish polecenia, aby dodać bardziej złożone lub niestandardowe funkcje.

Pełna dokumentacja interfejsu API dla programu Azure Operator Service Manager znajduje się tutaj: Interfejs API REST sieci hybrydowej platformy Azure.

W poniższych sekcjach opisano niektóre typowe sposoby edytowania skompilowanych plików przed opublikowaniem.

Definicje funkcji sieci (NFD)

  • versionStatenetworkfunctiondefinitionversions Zmień wartość zasobu z Preview na Active. Aktywne NFDV są niezmienne, natomiast NFDV w wersji zapoznawczej są modyfikowalne i w stanie roboczym.
  • W przypadku plików CNFs zmień wartość releaseNamespace elementu helmMappingRuleProfile , aby zmienić przestrzeń nazw kubernetes wdrożona na wykresie.

Projekty usług sieciowych (NSD)

  • Dodaj infrastrukturę platformy Azure do projektu usługi sieciowej (NSD). Dodawanie infrastruktury platformy Azure do usługi może obejmować:
    • Pisanie szablonów usługi ARM w celu wdrożenia infrastruktury.
    • Dodawanie schematów grup konfiguracji (CGS) dla tych szablonów usługi ARM.
    • Dodawanie ResourceElementTemplates typu (RETs) ArmResourceDefinition do sieciowej grupy zabezpieczeń. ReTs wyglądają tak samo jak NetworkFunctionDefinition rets poza polem type .
    • Dodawanie szablonów usługi ARM infrastruktury do artifact_manifest.bicep pliku.
    • Edytowanie plików w configMappings celu uwzględnienia wszystkich danych wyjściowych z szablonów infrastruktury jako danych wejściowych do elementu NetworkFunctionDefinition ResourceElementTemplates. Na przykład: "customLocationId": "{outputparameters('infraretname').infraretname.customLocationId.value}".
    • Edytuj element dependsOnProfileNetworkFunctionDefinition ResourceElementTemplates (RETs), aby upewnić się, że infrastruktury są wdrażane przed sieciami RETs systemu plików NF.
  • versionStatenetworkservicedesignversions Zmień wartość zasobu z Preview na Active. Aktywne dyski NSD są niezmienne, natomiast wirtualne dyski NSD w wersji zapoznawczej są modyfikowalne i w stanie roboczym.