Dela via


Registrera en containerbaserad nätverksfunktion (CNF) till Azure Operator Service Manager (AOSM)

I den här instruktionsguiden lär sig nätverksfunktionsutgivare och tjänstdesigners hur du använder Azure CLI AOSM-tillägget för att registrera en containerbaserad nätverksfunktion i AOSM. CNF kan senare distribueras till ett Azure Arc-anslutet Kubernetes-kluster, inklusive ett Azure Operator Nexus-kluster.

Registrering är en process i flera steg. När du uppfyller kraven använder du Azure CLI AOSM-tillägget för att:

  1. Generera BICEP-filer som definierar en NFD (Network Function Definition Group and Version) baserat på dina Helm-diagram och values.yaml.
  2. Publicera NFD och ladda upp CNF-avbildningar och diagram till ett Artefaktarkiv (AOSM-hanterat Azure Container Registry (ACR)).
  3. Lägg till din publicerade NFD i BICEP-filerna som definierar en nätverkstjänstdesigngrupp och -version (NSD).
  4. Publicera NSD:n.

Förutsättningar

  • Du har aktiverat AOSM för din Azure-prenumeration.
  • Om din CNF är avsedd att köras på Azure Operator Nexus har du åtkomst till en Azure Operator Nexus-instans och har slutfört förutsättningarna för arbetsbelastningsdistribution.

Kommentar

Vi rekommenderar starkt att du har testat att ett helm install Helm-paket lyckas i din Arc-anslutna Kubernetes-målmiljö.

Konfigurera behörigheter

  • Du behöver rollen Deltagare för din prenumeration för att kunna skapa en resursgrupp eller en befintlig resursgrupp där du har rollen Deltagare.
  • Du behöver Reader/AcrPull rolltilldelningarna på käll-ACR som innehåller dina bilder.
  • Du behöver Contributor rolltilldelningarna och AcrPush för prenumerationen som ska innehålla det AOSM-hanterade artefaktarkivet. Med de här behörigheterna kan Azure CLI AOSM-tillägget göra en direkt ACR-till-ACR-kopia. Direktkopiering är den snabbaste metoden för att överföra bilder från en ACR till en annan.
    • Din företagsprincip kan hindra dig från att ha behörigheter med prenumerationsomfång. Parametern --no-subscription-permissions , som är tillgänglig för az aosm nfd publish kommandona och az aosm nsd publish , använder strikt begränsade behörigheter som härleds från AOSM-tjänsten för att samordna en tvåstegskopia till och från den lokala datorn. Den här tvåstegskopian är långsammare, men kräver inte behörigheter med prenumerationsomfång.

Helm-paket

  • Helm-paketen som du tänker registrera måste finnas på den lokala lagringen för den dator som du kör CLI från.
    • Azure CLI AOSM-tillägget använder values.yaml filen i helm-paketet som standard. CLI stöder åsidosättande av det här beteendet med en alternativ values.yaml. Den här alternativa filen måste finnas på den lokala lagringen på den dator som du kör CLI från.

Kommentar

Vi rekommenderar starkt att Helm-paketet innehåller ett schema för helm-värdena och att helm-paketmallarna som du förväntar dig när helm template körs med hjälp av values.yaml som du tänker använda när du registrerar till AOSM.

Containeravbildningar

  • Dina containeravbildningar finns antingen i en befintlig ACR eller i ett alternativt containerregister som stöder Docker-API:et. Containeravbildningar måste lagras i källregistret i en struktur som matchar avbildningsplatsen som definieras i helm-diagrammen. Det här kravet förklaras i CLI CNF-avbildningsidentifiering och uppladdning.
  • docker login Använd kommandot för att logga in på ett containerregister som inte är azure-container som är värd för dina containeravbildningar innan du kör några az aosm kommandon. Det här steget krävs inte om du använder en ACR: Azure CLI AOSM-tillägget loggar automatiskt in.

Helm- och Docker-motor

  • Installera Helm CLI på värddatorn. Du måste använda Helm v3.8.0 eller senare.
  • Installera Docker på värddatorn.

Ladda ned och installera Azure CLI

Om du vill installera Azure CLI lokalt läser du Så här installerar du Azure CLI.

Om du vill logga in på Azure CLI använder du az login kommandot och slutför anvisningarna som visas i terminalen för att slutföra autentiseringen. Fler inloggningsalternativ finns i Logga in med Azure CLI.

Kommentar

Om du kör i Windows eller macOS kan du köra Azure CLI i en Docker-container. Mer information finns i Så här kör du Azure CLI i en Docker-container. Du kan också använda Bash-miljön i Azure Cloud Shell. Mer information finns i Starta Cloud Shell för att använda Bash-miljön i Azure Cloud Shell.

Installera AOSM CLI-tillägget

Az CLI AOSM-tillägget kräver version 2.54.0 eller senare av Azure CLI.

  1. Kör az version för att se vilken version och beroende bibliotek som är installerade.
  2. Kör az upgrade för att uppgradera till den aktuella versionen av Azure CLI.

Installera AOSM CLI-tillägget med det här kommandot:

az extension add --name aosm

Skapa nätverksfunktionsdefinitionsgruppen och -versionen

Det här steget skapar en mapp i arbetskatalogen som heter cnf-cli-output med BICEP-mallarna för de AOSM-resurser som definierar din definitionsgrupp för nätverksfunktion och version och Artefaktarkivet. Dessa resurser kommer i slutändan att ingå i nätverkstjänstdesignen.

  1. Generera indatafilen för Azure CLI AOSM-tillägget för en CNF.

    az aosm nfd generate-config --definition-type cnf --output-file <filename.jsonc>
    
  2. Öppna indatafilen som du genererade i föregående steg och använd infogade kommentarer för att ange de värden som krävs. Det här exemplet visar az CLI AOSM-tilläggets indatafil för en fiktiv Contoso CNF.

    Kommentar

    Azure CLI AOSM-tillägget exponerar endast obligatoriska parametrar utan standardvärden i indata values.yaml som standard. Du kan ange expose_all_parameters till för true att exponera alla helm-värden i NFDV (Network Function Definition Version) och Configuration Group Schema (CGS). Mer information finns i Exponera parameter med hjälp av AOSM CLI-tillägget.

    {
      // 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. Kör följande kommando för att skapa definitionsgruppen för nätverksfunktionen och version BICEP-mallarna.

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

Du kan granska mapp- och filstrukturen och göra ändringar om det behövs.

Publicera nätverksfunktionsdefinitionsgruppen och -versionen

Det här steget skapar de AOSM-resurser som definierar nätverksfunktionsdefinitionen och artefaktarkivet som ska användas för att lagra nätverksfunktionens containeravbildningar. Den laddar också upp bilderna och diagrammen till Artefaktarkivet antingen genom att kopiera dem direkt från källans ACR eller, om du inte har prenumerationsomfång Contributor och AcrPush roller, genom att återta Docker-avbildningarna lokalt och ladda upp dem till Artifact Store med hjälp av strikt begränsade autentiseringsuppgifter som genereras från AOSM-tjänsten.

  1. Kör följande kommando för att publicera nätverksfunktionens definitionsgrupp och version. Om du inte har prenumerationsomfång Contributor och AcrPush roller ska du inkludera --no-subscription-permissions i kommandot .

Kommentar

Om du använder Windows måste Docker Desktop köras under publiceringssteget.

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

Skapa nätverkstjänstdesigngruppen och -versionen

Det här avsnittet skapar en mapp i arbetskatalogen med namnet nsd-cli-output. Den här mappen innehåller BICEP-mallarna för de AOSM-resurser som definierar en nätverkstjänstdesigngrupp och version. Den här nätverkstjänstdesignen är en mall som används i resursen Site Network Service som distribuerar den nätverksfunktion som du registrerade i föregående avsnitt.

  1. Generera NSD-indatafilen för Azure CLI AOSM-tillägget.

    az aosm nsd generate-config --output-file <nsd-output-filename.jsonc>
    
  2. Öppna indatafilen som du genererade i föregående steg och använd infogade kommentarer för att ange de värden som krävs. Den genererade indatafilen innehåller ytterligare resource_element_type en typ ArmTemplate. Detta är onödigt när du registrerar en CNF; du kan ta bort den. Resultatet bör se ut som i det här exemplet. Exemplet visar az CLI AOSM-tilläggets indatafil för en fiktiv Contoso NSD som kan användas för att distribuera en fiktiv Contoso CNF till ett Arc-anslutet Nexus Kubernetes-kluster.

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

    Kommentar

    Avsnittet resurselementmall definierar vilken NFD som ingår i NSD. Egenskaperna måste matcha de som används i indatafilen som skickas az aosm nfd build till kommandot. Det beror på att Azure CLI AOSM-tillägget verifierar att NFD har registrerats korrekt när NSD skapas.

  3. Kör följande kommando för att skapa BICEP-mallar för nätverkstjänstdesign och version.

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

Du kan granska mapp- och filstrukturen och göra ändringar om det behövs.

Publicera nätverkstjänstdesigngruppen och -versionen

Det här steget skapar de AOSM-resurser som definierar nätverkstjänstdesigngruppen och versionen. Den laddar också upp artefakter som krävs av NSD:n till Artefaktarkivet (ARM-mall för nätverksfunktion).

  1. Kör följande kommando för att publicera nätverkstjänstens designgrupp och version. Om du inte har prenumerationsomfång Contributor och AcrPush roller ska du inkludera --no-subscription-permissions i kommandot .
az aosm nsd publish --build-output-folder nsd-cli-output

Nu har du en fullständig uppsättning AOSM-utgivarresurser och är redo att utföra operatorflödet.

Nästa steg