Freigeben über

Probleme mit der AOSM-Erweiterung (Azure Operator Service Manager) für die Azure CLI

  • Artikel

Dieses Dokument enthält eine Liste mit allgemeinen Problemen bei der Verwendung der AOSM-Erweiterung der Azure CLI für das Onboarding von Netzwerkfunktionen sowie entsprechende Lösungen.

Häufige Probleme

Der Herausgeber ist bereits in der Region vorhanden.

Herausgebernamen müssen innerhalb einer Azure-Region eindeutig sein. Wenn der folgende Fehler angezeigt wird, wird der von Ihnen ausgewählte Herausgebername bereits verwendet:

Message: A private publisher resource with the name 'nginx-publisher' already exists in the provided region.

So beheben Sie diesen Fehler:

Wenn Sie der Besitzer des Herausgebers sind, er sich in Ihrem Mandanten befindet und Sie ihn erneut verwenden möchten:

Der Herausgeber wird in der Konfigurationsdatei der AOSM-Erweiterung für die CLI definiert. Die Felder publisher_name und publisher_resource_group_name müssen mit denen des vorhandenen Herausgebers übereinstimmen, und er muss sich in dem Mandanten befinden, den Sie für diese Bereitstellung verwenden.

Ändern Sie publisher_resource_group_name in der Konfigurationsdatei so, dass auf den vorhandenen Herausgeber verwiesen wird. Führen Sie den entsprechenden build-Befehl erneut aus, und führen Sie dann den Befehl publish erneut aus.

Sie besitzen nicht den vorhandenen Herausgeber:

Verwenden Sie einen neuen Herausgebernamen.

Fehler beim Hochladen von NSD-Artefakten (Network Service Design; Netzwerkdienstentwurf)

In seltenen Fällen können beim Hochladen von Artefakten mithilfe des Befehls az aosm nsd publish Fehler auftreten. Der in diesem Fall ausgegebene Fehler lautet:

ValueError: Issue retrieving session url: {'errors': [{'code': 'UNAUTHORIZED', 'message': 'authentication required, visit https://aka.ms/acr/authorization for more information.', 'detail': [{'Type': 'repository', 'Name': 'contoso-nsd', 'Action': 'pull'}, {'Type': 'repository', 'Name': 'contoso-nsd', 'Action': 'push'}]}]}

So beheben Sie diesen Fehler:

Option 1. Vergewissern Sie sich, dass Ihnen für das Abonnement, das Sie verwenden möchten, die Rollen Contributor und AcrPush zugewiesen sind. Weisen Sie sie andernfalls zu. Falls diese Rollen nicht zugewiesen werden können, führen Sie den Befehl az aosm nsd publish mit dem Parameter --no-subscription-permissions aus.

Option 2. Sollte das Problem durch diese Berechtigungen nicht behoben werden, führen Sie die folgenden Befehle über den Ordner nsd-cli-output/artifacts aus, der mithilfe des Befehls az aosm nsd build erstellt wurde:

  • Erstellen Sie die ARM-Vorlage für die Netzwerkfunktion auf der Grundlage der die von der CLI generierten BICEP-Datei:
bicep build <nf-name>.bicep
  • Generieren Sie Bereichszuordnungstoken-Anmeldeinformationen auf der Grundlage des Artefaktmanifests, das im Befehl az aosm nsd publish erstellt wurde.

Wichtig

Sie müssen das im Befehl az aosm nsd publish erstellte Artefaktmanifest verwenden. Die NF-ARM-Vorlage wird nur in diesem Manifest deklariert, sodass es nur mit dem durch dieses Manifest generierten Bereichszuordnungstoken möglich ist, die NF-ARM-Vorlage an den Artefaktspeicher zu pushen (oder daraus zu pullen).

az rest --method POST --url 'https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.HybridNetwork/publishers/<publisher>/artifactStores/<artifact-store>/artifactManifests/<artifactManifest>/listCredential?api-version=2023-09-01'

oras login <aosm-managed-acr-name>.azurecr.io --username <username> --password <scope map token>
  • Verwenden Sie ORAS, um die ARM-Vorlage der Netzwerkfunktion in die von AOSM verwaltete ACR-Instanz (Azure Container Registry) hochzuladen. Das Artefakttag <arm-template-version> muss im Format 1.0.0 vorliegen.
oras push <aosm-managed-acr-name>.azurecr.io/Contoso-nsd:<arm-template-version> ./nsd-cli-output/artifacts/<nf-name>.json

Mandantenübergreifende Kopierfehler

Die AOSM-Erweiterung der Azure CLI unterstützt keine mandantenübergreifenden Imagekopien. Es ist jedoch möglich, Ihre CLI-Umgebung so zu konfigurieren, dass diese Funktion verwendet werden kann. Legen Sie hierzu das Azure-Standardabonnement auf das Abonnement fest, das die ACR-Quellinstanz enthält, melden Sie sich bei der ACR-Quellinstanz an, führen Sie alle Befehle vom Typ az aosm mit dem Parameter --subscription aus, und legen Sie dabei den Wert auf das Zielabonnement fest. Die Quell- und Zielabonnements können sich in unterschiedlichen Mandanten befinden.

az account set --subscription <source-acr-subscription>
az acr login --name <source-acr-name> -u <source-acr-username> -p <source-acr-password> --subscription <source-acr-subscription>
az aosm nfd publish --definition-type cnf --subscription <target-subscription>

Häufige Konfigurationsfehler

Nicht erfolgreiche SNS-Bereitstellung (Site Network Service; Standortnetzwerkdienst) bei abweichendem Standort und abweichender Version des Netzwerkdienstentwurfs (Network Service Design Version, NSDV)

SNS-Erstellungsversuche sind nicht erfolgreich, wenn die nfvi-Eigenschaft der Standortressource nicht mit der nfvisFromSite-Eigenschaft der NSDV übereinstimmt. Der Fehler ist:

{
"statusMessage": "{\"status\":\"Failed\",\"error\":{\"code\":\"ResourceOperationFailure\",\"message\":\"The resource operation completed with terminal provisioning state 'Failed'.\",\"details\":[{\"code\":\"InvalidRequestContent\",\"message\":\"For NfviAlias = nfvi1, either NfviName = nsd-contoso_NFVI and NfviType = AzureCore does not match with site resource.\"}]}}",
}

In diesem Beispiel enthält die nfvisFromSite-Eigenschaft der NSDV Folgendes:

    nfvisFromSite: {
      nfvi1: {
        name: 'nsd-contoso_NFVI1'
        type: 'AzureArcKubernetes'
      }

Die nfvi-Eigenschaft der Standortressource muss dem Namen und Typ in der NSDV entsprechen.

resource site 'Microsoft.HybridNetwork/sites@2023-09-01' = {
  name: 'contoso-site'
  location: 'eastus'
  properties: {
    nfvis : [
      {
        name: 'nsd-contoso_NFVI1'
        nfviType: 'AzureArcKubernetes'
        customLocationReference: {
          id: '<custom-location-arm-id>'
        }
      }
    ]
  }
}

Der NFDV-Name (nfdvName) im Konfigurationsgruppenwert (Configuration Group Value, CGV) und der veröffentlichten Version der Netzwerkfunktionsdefinition (Network Function Definition Version, NFDV) stimmt nicht überein.

Konfigurationsgruppenschemas, die von der AOSM-Erweiterung der Azure CLI generiert werden, besitzen einen obligatorischen Parameter namens nfdvName. nfdvname ist der Name der NFDV. Hierbei handelt es sich um eine Zeichenfolge im Format 1.0.0. Es ist nicht der Name der Netzwerkfunktion (NF) oder der Netzwerkfunktionsdefinitionsgruppe (NFDG). Das folgende Beispiel zeigt die korrekte Verwendung:

{
    "nsd-contoso": {
        "nfdvName": "1.0.0",
        "deployParameters": [
            {}
        ],
        "customLocationId": "<custom-location-arm-id>",
        "managedIdentityId": "<managed-id-arm-id>"
    }
}

Falsche CGV-Eigenschaft, wenn keine Parameter in einem Konfigurationsgruppenschema (Configuration Group Schema, CGS) verfügbar gemacht werden

Konfigurationsgruppenschemas, die von der AOSM-Erweiterung der Azure CLI generiert werden, machen ein deployParameters-Feld verfügbar, das standardmäßig ein Array von JSON-Objekten ist. Es gibt mehrere mögliche Gründe für die Erstellung eines CGV mit einem leeren deployParameters-Feld:

  • Sie haben keine Konfiguration im Konfigurationsgruppenschema verfügbar gemacht, und alle Werte werden in der YAML-Datei mit Standardwerten im Helm-Chart festgelegt.
  • Sie haben ein Konfigurationsgruppenschema erstellt, das Standardwerte enthält, und möchten sie nicht außer Kraft setzen.

Wenn Sie einen CGV mit einem leeren deployParameters-Feld erstellen, muss der Feldwert ein Array sein, das ein leeres JSON-Objekt enthält.

{
    "nsd-contoso": {
        "nfdv": "1.0.0",
        "deployParameters": [
            {}
        ],
        "customLocationId": "<custom-location-arm-id>",
        "managedIdentityId": "<managed-id-arm-id>"
    }
}

AOSM gibt die folgende Fehlermeldung zurück, wenn der CGV anstelle eines Arrays mit einem leeren Objekt ([{}]) ein leeres Array ([]) enthält:

{"code":"BadRequest","message":"NSDV ResourceElementTemplate (name: 'mco-nsdg', type: 'NetworkFunctionDefinition') expects at least one 'networkfunctions' resource in the associated template. Please use the type: 'ArmResourceDefinition' to install generic ARM resources."}

Konflikt zwischen der Imageeigenschaft in Helm-Charts und dem Speicherort in der ACR-Quellinstanz

Die AOSM-CLI erfordert, dass sich die Images in Ihrer Quellregistrierung in der gleichen Repositorystruktur befinden, die auch in Ihrem Helm-Chart festgelegt ist. So muss beispielsweise ein Image, das in einem Helm-Chart als core/contoso-a:1.0.0 enthalten ist, in der Quellregistrierung an einem Pfad verfügbar sein, der mit core/contoso-a:1.0.0 endet. Wenn das Image nicht in den korrekten Pfad in der Quellregistrierung hochgeladen wird, tritt für az aosm nfd publish der folgende Fehler auf:

Code: InvalidParameters
Message: Operation registries-cd9ad97d-f3a3-11ee-a728-6b163569f55a failed. Resource /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ContainerRegistry/registries/contoso Invalid message NotFound Not Found {"errors":[{"code":"MANIFEST_UNKNOWN","message":"manifest tagged by \"0.0.0-9\" is not found","detail":{"Tag":"0.0.0-9"}}]}

Hierfür sind mehrere Lösungen verfügbar.

  • Bearbeiten Sie Ihr Helm-Chart, oder übergeben Sie die Imagepfade in „values.yaml“, und legen Sie sie so fest, dass sie der Repositorystruktur in Ihrer Quellregistrierung entsprechen.
  • Laden Sie die Images so in die Quellregistrierung hoch, dass die Verkettung von „image_sources“ in der Datei cnf-input.jsonc und der Imagepfad aus dem Helm-Chart mit dem hochgeladenen Speicherort in der Quellregistrierung übereinstimmt.
  • Die AOSM-CLI speichert Metadaten für die in cnf-cli-output/artifacts/artifacts.json entdeckten Images. Der Pfad, den die AOSM-CLI in der Quellregistrierung durchsucht, lautet <registry_name>/<registry_namespace>/<artifact_name>/<artifact_version>. Sie können diese Datei manuell bearbeiten, damit die Werte dem Speicherort des Image in Ihrer ACR-Quellinstanz entsprechen.

CGVs entsprechen nicht dem CGS, wenn der Parameter einen NULL-Typ besitzt.

null wird von AOSM derzeit nicht als Standardwert im deployParameters-Schema unterstützt. Das bedeutet, dass der Standardwert null auch in Konfigurationsgruppenschemas nicht zulässig ist. Um dieses Problem zu umgehen, legt die AOSM-CLI den Standardwert für Parameter vom Typ NULL auf die Zeichenfolge "null" fest, was die erfolgreiche Veröffentlichung einer NFDV ermöglicht.

Wenn Sie zum Erstellen von CGVs das Portal verwenden, wird Ihr Parameter automatisch mit dem Wert "null" ausgefüllt. Wenn Sie diesen Wert nicht ändern, wird im Portal eine Fehlermeldung mit dem Hinweis angezeigt, dass der neue Konfigurationsgruppenwert nicht dem Schema entspricht und die Werte bearbeitet werden müssen.

Screenshot: Fehlermeldung im Portal, da die Konfigurationsgruppenwerte nicht dem Konfigurationsgruppenschema entsprechen

Ändern Sie "null" in den CGVs in null, um diesen Fehler zu beheben.

Beispiel: Ursprünglich lautete der Wert "null":

"serviceAccount_name": "null",

Dieser muss in den Wert null geändert werden.

"serviceAccount_name": null,