Condividi tramite

Aggiungere risorse di Azure Resource Manager (ARM) a una versione di progettazione del servizio di rete (AOSM) di Azure Operator Service Manager (NSDV)

  • Articolo

Azure Operator Service Manager (AOSM) consente di combinare le versioni di definizione delle funzioni di rete (NFDV) e i modelli di Azure Resource Manager (ARM) in una versione NSDV (Network Service Design Version). L'NSDV diventa un singolo modello per un servizio di rete che contiene sia una funzione di rete che l'infrastruttura di Azure necessaria per l'esecuzione. Un operatore può quindi distribuire la funzione di rete (NF) e la relativa infrastruttura in un'unica operazione.

Questa guida pratica illustra come usare l'estensione AOSM dell'interfaccia della riga di comando di Azure per compilare e pubblicare un NSDV contenente sia una funzione di rete in contenitori (CNF) una risorsa di Azure Resource Manager (ARM).

L'onboarding è un processo in più passaggi. Dopo aver soddisfatto i prerequisiti, si userà l'estensione AOSM dell'interfaccia della riga di comando di Azure per:

  1. Modificare un file di input NSDV esistente per un CNF caricato in precedenza.
  2. Compilare il file di input con le informazioni necessarie per compilare le definizioni delle risorse di AOSM.
  3. Generare file BICEP che definiscono un gruppo di progettazione del servizio di rete e una versione (NSDV) in base al file di input e al modello arm.
  4. Pubblicare il NSDV e caricare il modello di Resource Manager in un archivio artefatti (AOSM gestito Registro Azure Container(ACR).

Questa guida pratica usa Azure Key Vault (AKV) come esempio di una risorsa di Azure, tuttavia, è possibile eseguire l'onboarding di qualsiasi risorsa di Azure seguendo la stessa procedura. Questo articolo usa un CNF come esempio NF; il processo è identico per una funzione di rete virtualizzata (VNF) a parte le piccole differenze nel file di input NSDV.

Prerequisiti

  • È stato abilitato AOSM nella sottoscrizione di Azure.
  • Se il CNF è destinato all'esecuzione in Azure Operator Nexus, è possibile accedere a un'istanza di Nexus dell'operatore di Azure e aver completato i prerequisiti per la distribuzione del carico di lavoro.
  • È stato eseguito l'onboarding di un CNF e il file di input generato con il az aosm nsd generate-config file disponibile nella risorsa di archiviazione locale del computer da cui si esegue l'interfaccia della riga di comando.

Configura autorizzazioni

  • È necessario il ruolo Collaboratore per la sottoscrizione per creare un gruppo di risorse o un gruppo di risorse esistente in cui si ha il ruolo Collaboratore.
  • Sono necessarie le assegnazioni di Contributor ruolo e AcrPush nella sottoscrizione che conterrà l'archivio artefatto gestito di AOSM.
    • I criteri aziendali potrebbero impedire la presenza di autorizzazioni con ambito sottoscrizione. Il --no-subscription-permissions parametro, disponibile nel az aosm nsd publish comando, usa autorizzazioni con ambito limitato derivate dal servizio AOSM per orchestrare una copia in due passaggi da e verso il computer locale. Questa copia in due passaggi è più lenta, ma non richiede autorizzazioni con ambito sottoscrizione.

Modelli di Azure Resource Manager

  • È necessario disporre di un modello di Resource Manager che definisce le risorse di Azure da distribuire nella risorsa di archiviazione locale del computer da cui si esegue l'interfaccia della riga di comando.
  • Tutti i parametri da esporre all'operatore che distribuirà il NSDV devono essere definiti come parametri nel modello di Resource Manager.

Nota

L'estensione AOSM dell'interfaccia della riga di comando di Az non supporta l'onboarding delle risorse di Azure definite in un modello BICEP. Tuttavia, è possibile usare il bicep build comando per convertire i file BICEP in modelli di Resource Manager. Per informazioni dettagliate e istruzioni, vedere la documentazione dell'interfaccia della riga di comando bicep.

Motore Helm e Docker

  • Installare l'interfaccia della riga di comando helm nel computer host. È necessario usare Helm v3.8.0 o versione successiva.
  • Installare Docker nel computer host.

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

Per installare l'interfaccia della riga di comando di Azure in locale, vedere Come installare l'interfaccia della riga di comando di Azure.

Per accedere all'interfaccia della riga di comando di Azure, usare 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.

Nota

Per l'esecuzione in Windows o macOS, è consigliabile eseguire l'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. È anche possibile usare l'ambiente Bash in Azure Cloud Shell. Per altre informazioni, vedere Avviare Cloud Shell per usare l'ambiente Bash in Azure Cloud Shell.

Installare l'estensione dell'interfaccia della riga di comando di AOSM

L'estensione AOSM dell'interfaccia della riga di comando di Az richiede la versione 2.54.0 o successiva dell'interfaccia della riga di comando di Azure.

  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.

Installare l'estensione dell'interfaccia della riga di comando di AOSM usando questo comando:

az extension add --name aosm

Creare il gruppo di progettazione e la versione del servizio di rete

  1. Aprire il file di input NSDV generato durante l'onboarding del CNF.

    Nota

    È possibile generare un nuovo file di input usando il az aosm nsd generate-config --output-file <nsd-output-filename.jsonc> comando se non si dispone del file di input NSDV dall'onboarding CNF.

  2. Immettere i valori obbligatori usando i commenti inline nel file di input. Questo esempio mostra il file di input dell'estensione AOSM dell'interfaccia della riga di comando di Az per un NSDV fittizio contoso che può essere usato per distribuire un CNF fittizio Contoso in un cluster Nexus Kubernetes connesso ad Arc e un'istanza di AKV in una posizione di Azure.

    {
    // 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 and an Azure Key Vault",
    // 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"
            }
        },
        {
            // Type of Resource Element. Either NF or ArmTemplate
            "resource_element_type": "ArmTemplate",
            // Properties of the Resource Element.
            "properties": {
                // Name of the artifact. Used as internal reference only.
                "artifact_name": "contoso-keyvault",
                // 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": "./contoso-keyvault.json"
            }
        }
    ]
}

    Nota

    La sezione modello di elemento della risorsa definisce quale NFD è incluso nel gruppo di sicurezza di rete. Le proprietà devono corrispondere a quelle usate nel file di input passato al az aosm nfd build comando . Ciò è dovuto al fatto che l'estensione AOSM dell'interfaccia della riga di comando di Azure convalida che l'onboarding dell'NFD è stato eseguito correttamente durante la compilazione del gruppo di sicurezza di rete.

  3. Eseguire il comando seguente per compilare i modelli BICEP e gruppo di progettazione del servizio di rete.

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

È possibile esaminare la struttura di cartelle e file e apportare modifiche, se necessario.

Pubblicare il gruppo di progettazione e la versione del servizio di rete

Questo passaggio crea le risorse AOSM che definiscono il gruppo e la versione del servizio di rete. Carica anche gli artefatti richiesti dall'NSDV nell'archivio artefatti (modello ARM NF e modello arm AKV).

  1. Eseguire il comando seguente per pubblicare il gruppo e la versione del servizio di rete. Se l'ambito Contributor e AcrPush i ruoli della sottoscrizione non sono disponibili, includere --no-subscription-permissions nel comando .
az aosm nsd publish --build-output-folder nsd-cli-output

È ora disponibile un set completo di risorse dell'editore AOSM e si è pronti per eseguire il flusso dell'operatore.

Passaggi successivi