Share via

Usare l'estensione dell'interfaccia della riga di comando di Azure Operator Service Manager (AOSM)

  • Articolo

Questa guida pratica illustra come usare l'estensione dell'interfaccia della riga di comando di Azure per iniziare a usare gli NSD (Network Function Definitions) e Network Service Designs (NSD).

L'estensione dell'interfaccia della az aosm riga di comando è progettata per fornire supporto per la pubblicazione di progettazioni e definizioni di Azure Operator Service Manager. L'estensione dell'interfaccia della riga di comando consente di pubblicare definizioni di funzioni di rete (NFD) e progetti di servizi di rete (NSD) da usare con Azure Operator Service Manager.

Prerequisiti

Contattare il team dell'account Microsoft per registrare la sottoscrizione di Azure per l'accesso ad Azure Operator Service Manager (AOSM) o esprimere l'interesse tramite il modulo di registrazione del partner.

Scaricare e installare l'interfaccia della riga di comando di Azure

Usare l'ambiente Bash in Azure Cloud Shell. Per altre informazioni, vedere Avviare Cloud Shell per usare l'ambiente Bash in Azure Cloud Shell.

Per gli utenti che preferiscono eseguire i comandi di riferimento dell'interfaccia della riga di comando in locale, vedere Come installare l'interfaccia della riga di comando di Azure.

Se si esegue in Window o macOS, prendere in considerazione l'esecuzione dell'interfaccia della riga di comando di Azure in un contenitore Docker. Per altre informazioni, vedere Come eseguire l'interfaccia della riga di comando di Azure in un contenitore Docker.

Se si usa un'installazione locale, accedere all'interfaccia della riga di comando di Azure usando il az login comando e completare i prompt visualizzati nel terminale per completare l'autenticazione. Per altre opzioni di accesso, vedere Accedere con l'interfaccia della riga di comando di Azure.

Installare l'estensione dell'interfaccia della riga di comando di Azure Operator Service Manager (AOSM)

Installare l'estensione dell'interfaccia della riga di comando di Azure Operator Service Manager (AOSM) usando questo comando:

az extension add --name aosm
  1. Eseguire az version per visualizzare la versione e le librerie dipendenti installate.
  2. Eseguire az upgrade per eseguire l'aggiornamento alla versione corrente dell'interfaccia della riga di comando di Azure.

Registrare e verificare i provider di risorse necessari

Prima di iniziare a usare Azure Operator Service Manager, assicurarsi di registrare il provider di risorse richiesto. Eseguire i comandi seguenti. Questo processo di registrazione può richiedere fino a 5 minuti.

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

Verificare lo stato di registrazione dei provider di risorse. Eseguire i comandi seguenti.

# 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}"

Nota

Il completamento della registrazione del provider di risorse potrebbe richiedere alcuni minuti. Al termine della registrazione, è possibile procedere con l'uso di Azure Operator Service Manager (AOSM).

Requisiti della funzione di rete in contenitori

Per coloro che usano Funzioni di rete in contenitori, è essenziale assicurarsi che i pacchetti seguenti siano installati nel computer da cui si esegue l'interfaccia della riga di comando:

  • Installare Helm, vedere Installare l'interfaccia della riga di comando helm.
  • In alcune circostanze, installare Docker, vedere Installare il motore Docker. È necessario solo se l'immagine di origine si trova nel repository Docker locale o non si dispone delle autorizzazioni a livello di sottoscrizione necessarie per eseguire il push di grafici e immagini.

Autorizzazioni

È necessario un account Azure con una sottoscrizione attiva. Se non si ha una sottoscrizione di Azure, seguire le istruzioni riportate qui Iniziare gratuitamente per creare un account prima di iniziare.

È necessario il ruolo Collaboratore per questa sottoscrizione per creare un gruppo di risorse o un gruppo di risorse esistente in cui si dispone del ruolo Collaboratore.

Autorizzazioni per la pubblicazione di file CNF

Se si esegue l'origine delle immagini CNF da un Registro Azure Container esistente, è necessario disporre Reader/AcrPull delle autorizzazioni da questo Registro Azure Container e, idealmente, Contributor ruolo + AcrPush ruolo (o un ruolo personalizzato che consenta l'azione importImage e AcrPush) sull'intera sottoscrizione per poter importare nel nuovo archivio artefatti. Se sono disponibili, non è necessario installare Docker in locale e la copia dell'immagine è rapida.

Se non si dispone delle autorizzazioni a livello di sottoscrizione, è possibile eseguire il az aosm nfd publish comando usando il flag per eseguire il --no-subscription-permissions pull dell'immagine nel computer locale e quindi eseguirne il push nell'Archivio artefatti usando credenziali del manifesto con ambito solo nell'archivio. Richiede l'installazione locale di Docker.

Panoramica dell'estensione dell'interfaccia della riga di comando di Azure Operator Service Manager (AOSM)

I server di pubblicazione delle funzioni di rete e le finestre di progettazione dei servizi usano l'estensione dell'interfaccia della riga di comando di Azure per facilitare la pubblicazione di NSD (Network Function Definitions) e Network Service Designs (NSD).

Come spiegato in Ruoli e interfacce, un server di pubblicazione delle funzioni di rete ha varie responsabilità. L'estensione dell'interfaccia della riga di comando è utile per gli elementi visualizzati in grassetto:

  • Creare la funzione di rete.
  • Codificare tale valore in una progettazione di funzioni di rete (NFD).
  • Determinare i parametri di distribuzione da esporre a Service Designer.
  • Eseguire l'onboarding della progettazione delle funzioni di rete (NFD) in Azure Operator Service Manager (AOSM).
  • Caricare gli artefatti associati.
  • Convalidare la progettazione delle funzioni di rete (NFD).

Progettazione servizi ha anche varie responsabilità, di cui l'estensione dell'interfaccia della riga di comando supporta gli elementi in grassetto:

  • Scegliere le definizioni delle funzioni di rete incluse nella progettazione dei servizi.
  • Codificare tale elemento in una progettazione del servizio di rete.
  • Combinare l'infrastruttura di Azure nella progettazione dei servizi di rete.
  • Determinare come parametrizzare il servizio definendo uno o più schemi di gruppo di configurazione (CGSs).
  • Determinare il modo in cui gli input dell'operatore del servizio eseguono il mapping ai parametri richiesti dalle definizioni delle funzioni di rete e dall'infrastruttura di Azure.
  • Eseguire l'onboarding del servizio di rete (NSD) in Azure Operator Service Manager (AOSM).
  • Caricare gli artefatti associati.
  • Convalidare la progettazione del servizio di rete (NSD).

Riepilogo del flusso di lavoro

Un flusso di lavoro generico dell'uso dell'estensione dell'interfaccia della riga di comando è:

  1. Trovare gli elementi dei prerequisiti necessari per il caso d'uso.

  2. Eseguire un comando per restituire un generate-config file di configurazione JSON di esempio per i comandi successivi.

  3. Compilare il file di configurazione.

  4. Eseguire un build comando per restituire uno o più modelli bicep per la definizione della funzione di rete o la progettazione del servizio di rete.

  5. Esaminare l'output del comando di compilazione, modificare l'output in base alle esigenze.

  6. Eseguire un publish comando per:

    • Creare tutte le risorse prerequisite, ad esempio Gruppo di risorse, Server di pubblicazione, Archivi artefatti, Gruppi.
    • Distribuire questi modelli bicep.
    • Caricare gli artefatti negli archivi artefatti.

Punto di inizio VNF

Per le macchine virtuali, è necessario un singolo modello di Resource Manager che creerebbe le risorse di Azure per il VNF, ad esempio una macchina virtuale, dischi e schede di interfaccia di rete. Il modello di Resource Manager deve essere archiviato nel computer da cui si esegue l'interfaccia della riga di comando.

Per le versioni delle definizioni delle funzioni di rete virtualizzate (VNFDV), l'elenco networkFunctionApplications deve contenere un VhdImageFile e un modello arm. È insolito includere più di un VhdImageFile e più di un modello di Resource Manager. A meno che non si disponga di un motivo sicuro, il modello di Resource Manager deve distribuire una singola macchina virtuale. Progettazione servizi deve includere numerose copie della definizione di funzione di rete (NFD) con la progettazione del servizio di rete (NSD) se si desidera distribuire più macchine virtuali. Il modello arm (per AzureCore e Nexus) può distribuire solo le risorse ARM dai provider di risorse seguenti:

  • Microsoft.Compute

  • Microsoft.Network

  • Microsoft.NetworkCloud

  • Microsoft.Storage

  • Microsoft.NetworkFabric

  • Microsoft.Authorization

  • Microsoft.ManagedIdentity

È necessaria anche un'immagine VHD che verrà usata per la macchina virtuale VNF. L'immagine del disco rigido virtuale può essere archiviata nel computer da cui si esegue l'interfaccia della riga di comando o nell'archivio BLOB di Azure accessibile tramite un URI di firma di accesso condiviso.

Punto di inizio CNF

Per le distribuzioni di funzioni di rete in contenitori, è fondamentale archiviare quanto segue nel computer da cui si esegue l'interfaccia della riga di comando:

  • Pacchetti Helm con schema : questi pacchetti devono essere presenti nella risorsa di archiviazione locale e a cui si fa riferimento all'interno del input.json file di configurazione. Quando si segue questa guida introduttiva, scaricare il pacchetto Helm necessario.

  • Creazione di un file di configurazione di esempio: generare un file di configurazione di esempio per la definizione di una distribuzione CNF. Eseguire questo comando per generare un input.json file che è necessario popolare con la configurazione specifica.

    az aosm nfd generate-config

  • Immagini per il CNF : ecco le opzioni seguenti:

    • Riferimento a un Registro Azure Container esistente che contiene le immagini per il CNF. Attualmente, sono supportati un solo record di controllo di accesso e uno spazio dei nomi per CNF. Le immagini da copiare da questo Registro Azure Container vengono popolate automaticamente in base allo schema del pacchetto Helm. Per questo Registro Azure Container è necessario disporre delle autorizzazioni Reader/AcrPull. Per usare questa opzione, compilare source_registry e facoltativamente source_registry_namespace nel file input.json.
    • Nome dell'immagine Docker di origine dal computer locale. Questo nome di immagine è per un caso d'uso limitato in cui il CNF richiede solo una singola immagine Docker esistente nel repository Docker locale. Per usare questa opzione, compilare source_local_docker_image il file input.json. Richiede l'installazione di Docker. Questa guida introduttiva illustra come scaricare un'immagine docker nginx da usare per questa opzione.

  • Facoltativo: file di mapping (path_to_mappings): facoltativamente, è possibile specificare un file (su disco) denominato path_to_mappings. Questo file deve eseguire il mirroring values.yamldi , con i valori selezionati sostituiti dai parametri di distribuzione. In questo modo vengono esposti come parametri al CNF. In alternativa, è possibile lasciare vuoto e input.json l'interfaccia della riga di comando genera il file. Per impostazione predefinita in questo caso, ogni valore all'interno values.yaml viene esposto come parametro di distribuzione. In alternativa, usare l'argomento dell'interfaccia della --interactive riga di comando per effettuare scelte in modo interattivo. Questa guida introduttiva illustra la creazione di questo file.

Quando si configura il input.json file, assicurarsi di elencare i pacchetti Helm nell'ordine in cui devono essere distribuiti. Ad esempio, se il pacchetto "A" deve essere distribuito prima del pacchetto "B", la input.json struttura dovrebbe essere simile alla seguente:

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

Seguendo queste linee guida si garantisce un approccio ben organizzato e strutturato per distribuire funzioni di rete in contenitori con pacchetti Helm e configurazioni associate.

Punto di inizio NSD

Per gli NSD, è necessario conoscere i dettagli delle definizioni delle funzioni di rete (NFD) da incorporare nella progettazione:

  • gruppo di risorse del server di pubblicazione NFD
  • nome e ambito del server di pubblicazione NFD
  • nome del gruppo di definizione della funzione di rete
  • il percorso, il tipo e la versione della versione di definizione della funzione di rete

È possibile usare i az aosm nfd comandi per creare tutte queste risorse.

Comandi di Azure Operator Service Manager (AOSM)

Usare questi comandi prima di iniziare:

  1. az login usato per accedere all'interfaccia della riga di comando di Azure.

  2. az account set --subscription <subscription> usato per scegliere la sottoscrizione su cui si vuole lavorare.

Comandi NFD

Ottenere la Guida sugli argomenti dei comandi:

  • az aosm -h

  • az aosm nfd -h

  • az aosm nfd build -h

Comandi del tipo di definizione

Tutti questi comandi accettano un --definition-type argomento di vnf o cnf.

Creare un file di configurazione di esempio per la compilazione di una definizione:

  • az aosm nfd generate-config

Questo comando restituisce un file denominato input.json, che deve essere compilato. Dopo aver compilato il file di configurazione, è possibile eseguire i comandi seguenti.

Compilare una definizione NFD in locale:

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

Altre opzioni per la creazione di una definizione NFD in locale:

  • Scegliere quale dei parametri del modello arm VNF che si vuole esporre come distribuzione NFDParameters, con l'opzione di scegliere in modo interattivo ognuno di essi:

    • 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

Scegliere i parametri dei valori Helm CNF da esporre come distribuzione NFDParameters:

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

Pubblicare una definizione predefinita:

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

Eliminare una definizione pubblicata:

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

Eliminare una definizione pubblicata e il server di pubblicazione, gli archivi artefatti e il gruppo NFD:

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

Comandi NSD

Ottenere la Guida sugli argomenti dei comandi:

  • az aosm -h

  • az aosm nsd -h

  • az aosm nsd build -h

Creare un file di configurazione di esempio per la compilazione di una definizione:

  • az aosm nsd generate-config

Questo comando restituisce un file denominato input.json, che deve essere compilato. Dopo aver compilato il file di configurazione, è possibile eseguire i comandi seguenti.

Creare un NSD in locale:

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

Pubblicare una progettazione predefinita:

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

Eliminare una progettazione pubblicata:

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

Eliminare una progettazione pubblicata e il server di pubblicazione, gli archivi artefatti e il gruppo NSD:

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

Modificare l'output di compilazione prima della pubblicazione

L'estensione dell'interfaccia della az aosm riga di comando è progettata per fornire supporto per la pubblicazione di progettazioni e definizioni di Azure Operator Service Manager. Fornisce i blocchi predefiniti per la creazione di progettazioni e definizioni personalizzate complesse. È possibile modificare l'output dei file tramite il build comando prima di eseguire il publish comando per aggiungere funzionalità più complesse o personalizzate.

Le informazioni di riferimento complete sull'API per Azure Operator Service Manager sono disponibili qui: API REST di rete ibrida di Azure.

Le sezioni seguenti descrivono alcuni modi comuni che è possibile usare per modificare i file compilati prima della pubblicazione.

Definizioni di funzioni di rete (NFD)

  • Modificare l'oggetto versionState della networkfunctiondefinitionversions risorsa da Preview a Active. Gli NFDV attivi non sono modificabili, mentre gli FNFV di anteprima sono modificabili e nello stato bozza.
  • Per i file CNFS, modificare l'oggetto releaseNamespacehelmMappingRuleProfile di per modificare lo spazio dei nomi kubernetes in cui viene distribuito il grafico.

Progettazioni di servizi di rete (NSD)

  • Aggiungere l'infrastruttura di Azure alla progettazione del servizio di rete (NSD). L'aggiunta dell'infrastruttura di Azure all'operatore può comportare:
    • Scrittura di modelli arm per distribuire l'infrastruttura.
    • Aggiunta di schemi del gruppo di configurazione (CGSs) per questi modelli di Resource Manager.
    • Aggiunta ResourceElementTemplates (RET) di tipo ArmResourceDefinition al gruppo di sicurezza di rete. Le ret hanno lo stesso aspetto delle NetworkFunctionDefinition ret a parte il type campo.
    • Aggiunta dei modelli arm dell'infrastruttura al artifact_manifest.bicep file.
    • Modifica dei configMappings file per incorporare tutti gli output dei modelli di infrastruttura come input per ResourceElementTemplates NetworkFunctionDefinition . Ad esempio: "customLocationId": "{outputparameters('infraretname').infraretname.customLocationId.value}"
    • Modifica di dependsOnProfile per ResourceElementTemplates NetworkFunctionDefinition (RET) per assicurarsi che le RIES dell'infrastruttura vengano distribuite prima delle ret NF.
  • Modificare l'oggetto versionState della networkservicedesignversions risorsa da Preview a Active. I dischi rigidi di rete attivi non sono modificabili, mentre gli NSD di anteprima sono modificabili e in stato bozza.