Condividi tramite

Eseguire l'onboarding di una funzione di rete in contenitori (CNF) in Azure Operator Service Manager (AOSM)

  • Articolo

Questa guida pratica illustra come usare l'estensione AOSM dell'interfaccia della riga di comando di Azure per eseguire l'onboarding di una funzione di rete in contenitori in AOSM. Il CNF può essere distribuito in un secondo momento in un cluster Kubernetes connesso ad Azure Arc, incluso un cluster Nexus operatore di Azure.

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. Generare file BICEP che definiscono un gruppo di definizioni di funzione di rete e una versione (NFD) in base ai grafici Helm e ai valori.yaml.
  2. Pubblicare il file NFD e caricare le immagini e i grafici CNF in un archivio artefatti (AOSM-managed Registro Azure Container (ACR)).
  3. Aggiungere l'NFD pubblicato ai file BICEP che definiscono un gruppo di progettazione e una versione del servizio di rete (NSD).
  4. Pubblicare il gruppo di sicurezza di rete.

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.

Nota

È consigliabile testare che un helm install pacchetto Helm abbia esito positivo nell'ambiente Kubernetes connesso ad Arc di destinazione.

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 Reader/AcrPull assegnazioni di ruolo nel Registro Azure Container di origine contenente le immagini.
  • Sono necessarie le assegnazioni di Contributor ruolo e AcrPush nella sottoscrizione che conterrà l'archivio artefatto gestito di AOSM. Queste autorizzazioni consentono all'estensione AOSM dell'interfaccia della riga di comando di Azure di eseguire una copia diretta da Registro Azure Container a Registro Azure Container. La copia diretta è il metodo più rapido per trasferire le immagini da un Registro Azure Container a un altro.
    • I criteri aziendali potrebbero impedire la presenza di autorizzazioni con ambito sottoscrizione. Il --no-subscription-permissions parametro, disponibile nei az aosm nfd publish comandi e az aosm nsd publish , 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.

Pacchetti Helm

  • I pacchetti Helm di cui si intende eseguire l'onboarding devono essere presenti nella risorsa di archiviazione locale del computer da cui si esegue l'interfaccia della riga di comando.
    • L'estensione AOSM dell'interfaccia della riga di comando di Azure userà il values.yaml file nel pacchetto Helm per impostazione predefinita. L'interfaccia della riga di comando supporta l'override di questo comportamento con un'alternativa values.yaml. Questo file alternativo deve esistere nella risorsa di archiviazione locale del computer da cui si esegue l'interfaccia della riga di comando.

Nota

È consigliabile che il pacchetto Helm contenga uno schema per i valori helm e che i modelli di pacchetto Helm come previsto quando helm template vengono eseguiti usando values.yaml che si intende usare durante l'onboarding in AOSM.

Immagini del contenitore

  • Le immagini del contenitore sono presenti in un Registro Azure Container esistente o in un registro contenitori alternativo che supporta l'API Docker. Le immagini del contenitore devono essere archiviate nel registro di origine in una struttura che corrisponde alla posizione dell'immagine definita nei grafici Helm. Questo requisito è illustrato nell'individuazione e caricamento delle immagini CNF dell'interfaccia della riga di comando.
  • Usare il docker login comando per accedere a un registro contenitori non Azure che ospita le immagini del contenitore prima di eseguire qualsiasi az aosm comando. Questo passaggio non è obbligatorio se si usa un Registro Azure Container: l'estensione AOSM dell'interfaccia della riga di comando di Azure accederà automaticamente.

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 definizioni e la versione della funzione di rete

Questo passaggio crea una cartella nella directory di lavoro denominata cnf-cli-output con i modelli BICEP delle risorse di AOSM che definiscono il gruppo di definizione e la versione della funzione di rete e l'archivio artefatti. Queste risorse verranno infine incluse nella progettazione del servizio di rete.

  1. Generare il file di input dell'estensione AOSM dell'interfaccia della riga di comando di Azure per un CNF.

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

  2. Aprire il file di input generato nel passaggio precedente e usare i commenti inline per immettere i valori richiesti. Questo esempio mostra il file di input dell'estensione AOSM dell'interfaccia della riga di comando az per un CNF fittizio contoso.

    Nota

    L'estensione AOSM dell'interfaccia della riga di comando di Azure espone solo i parametri obbligatori senza valori predefiniti nell'input values.yaml per impostazione predefinita. È possibile impostare expose_all_parameters su true per esporre tutti i valori helm nella versione di definizione della funzione di rete (NFDV) e nello schema del gruppo di configurazione (CGS). Per altre informazioni, vedere Esporre i parametri usando l'estensione dell'interfaccia della riga di comando di 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. Eseguire il comando seguente per compilare i modelli Network Function Definition Group e Version BICEP.

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

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

Pubblicare il gruppo di definizioni e la versione della funzione di rete

Questo passaggio crea le risorse di AOSM che definiscono la definizione della funzione di rete e l'archivio artefatti che verranno usati per archiviare le immagini del contenitore della funzione di rete. Carica anche le immagini e i grafici nell'Archivio artefatti copiandoli direttamente dal Registro Azure Container di origine oppure, se non si dispone di un ambito Contributor e AcrPush di ruoli di sottoscrizione, ritagginging delle immagini Docker in locale e caricamento nell'archivio artefatti usando credenziali con ambito stretto generate dal servizio AOSM.

  1. Eseguire il comando seguente per pubblicare il gruppo di definizioni di funzione di rete e la versione. Se l'ambito Contributor e AcrPush i ruoli della sottoscrizione non sono disponibili, includere --no-subscription-permissions nel comando .

Nota

Se si usa Windows, è necessario che Docker Desktop sia in esecuzione durante il passaggio di pubblicazione.

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

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

Questa sezione crea una cartella nella directory di lavoro denominata nsd-cli-output. Questa cartella contiene i modelli BICEP delle risorse AOSM che definiscono un gruppo di progettazione e una versione del servizio di rete. Questa progettazione del servizio di rete è un modello usato nella risorsa servizio di rete del sito che distribuirà la funzione di rete di cui è stato eseguito l'onboarding nelle sezioni precedenti.

  1. Generare il file di input NSD dell'estensione AOSM dell'interfaccia della riga di comando di Azure.

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

  2. Aprire il file di input generato nel passaggio precedente e usare i commenti inline per immettere i valori richiesti. Il file di input generato contiene un valore aggiuntivo resource_element_type di tipo ArmTemplate. Questo non è necessario quando si esegue l'onboarding di un CNF; è possibile eliminarlo. Il risultato dovrebbe essere simile a questo esempio. L'esempio mostra il file di input dell'estensione AOSM dell'interfaccia della riga di comando di Az per un NSD fittizio contoso che può essere usato per distribuire un CNF fittizio Contoso in un cluster Nexus Kubernetes connesso ad 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"
            }
        }
    ]
}

    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 dal gruppo di sicurezza di rete nell'archivio artefatti (modello arm della funzione di rete).

  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