Udostępnij za pośrednictwem

Użyj parametrów opcji programu Helm, aby zapobiec usunięciu po niepowodzeniu instalacji

Wdrożenia Usług Sieciowych Lokalizacji (SNS) mogą zakończyć się niepowodzeniem, ponieważ podstawowe wdrożenie funkcji sieci (NF) nie instaluje się poprawnie za pomocą programu Helm. Program Azure Operator Service Manager (AOSM) domyślnie usuwa nieudane wdrożenia z docelowego klastra Kubernetes w celu zachowania zasobów. Helm install błędy często wymagają, aby zasoby zostały zachowane w klastrze, co umożliwia debugowanie awarii. W tym artykule How-To opisano sposób edytowania szablonu NF ARM, aby zastąpić to zachowanie, ustawiając parametr helm install --atomic na false.

Wymagania wstępne

  • Musisz podłączyć swój NF do AOSM, używając rozszerzenia linii poleceń Az CLI AOSM. W tym artykule omawiana jest struktura folderów oraz pliki generowane przez interfejs wiersza polecenia (CLI) i przedstawione są przykłady oparte na CLI.
  • Błędy instalacji programu Helm mogą być złożone. Debugowanie wymaga wiedzy technicznej na temat kilku technologii oraz znajomości domeny NF
  • Potrzebujesz przypisań ról w grupie zasobów, która zawiera zarządzany przez AOSM magazyn artefaktów.
  • Odpowiednie środowisko IDE, takie jak Visual Studio Code
  • Interfejs wiersza polecenia ORAS CLI

Ważne

Zdecydowanie zaleca się przetestowanie, czy helm install element Twojego pakietu Helm zakończy się sukcesem w Twoim docelowym środowisku Kubernetes połączonym z Arc przed podjęciem próby wdrożenia przy użyciu AOSM.

Zastępowanie --atomic pojedynczego wykresu helm NF

W tej sekcji wyjaśniono, jak zastąpić --atomic NF, który składa się z pojedynczego wykresu helm.

Zlokalizuj i edytuj plik NF Bicep

  1. Przejdź do nsd-cli-output katalogu, otwórz artifacts katalog i otwórz <nf-arm-template>.bicep plik. <nf-arm-template> jest skonfigurowany w pliku wejściowym NSD rozszerzenia CLI dla Az AOSM. Możesz potwierdzić, że masz odpowiedni plik, porównując się z poniższym przykładowym szablonem fikcyjnej funkcji sieciowej konteneryzowanej firmy Contoso (CNF).

    @secure()
param configObject object

var resourceGroupId = resourceGroup().id

var identityObject = (configObject.managedIdentityId == '')  ? {
  type: 'SystemAssigned'
} : {
  type: 'UserAssigned'
  userAssignedIdentities: {
    '${configObject.managedIdentityId}': {}
  }
}

var nfdvSymbolicName = '${configObject.publisherName}/${configObject.nfdgName}/${configObject.nfdv}'

resource nfdv 'Microsoft.Hybridnetwork/publishers/networkfunctiondefinitiongroups/networkfunctiondefinitionversions@2023-09-01' existing = {
  name: nfdvSymbolicName
  scope: resourceGroup(configObject.publisherResourceGroup)
}

resource nfResource 'Microsoft.HybridNetwork/networkFunctions@2023-09-01' = [for (values, i) in configObject.deployParameters: {
  name: '${configObject.nfdgName}${i}'
  location: configObject.location
  identity: identityObject
  properties: {
    networkFunctionDefinitionVersionResourceReference: {
      id: nfdv.id
      idType: 'Open'
    }
    nfviType: 'AzureArcKubernetes'
    nfviId: (configObject.customLocationId == '') ? resourceGroupId : configObject.customLocationId
    allowSoftwareUpdate: true
    configurationType: 'Open'
    deploymentValues: string(values)
  }
}]

  2. Aby znaleźć nazwę aplikacji funkcji sieciowej, przejdź do katalogu cnf-cli-output, otwórz katalog nfDefinition i skopiuj wartość z jedynego wpisu w tablicy networkFunctionApplications w zasobie nfdv. Zweryfikuj, czy posiadasz właściwą wartość, porównując ją z poniższym fikcyjnym przykładem fragmentu kodu Bicep firmy Contoso. W takim przypadku nazwa aplikacji funkcji sieciowej to Contoso.

    resource nfdv 'Microsoft.Hybridnetwork/publishers/networkfunctiondefinitiongroups/networkfunctiondefinitionversions@2023-09-01' = {
  parent: nfdg
  name: nfDefinitionVersion
  location: location
  properties: {
    deployParameters: string(loadJsonContent('deployParameters.json'))
    networkFunctionType: 'ContainerizedNetworkFunction'
    networkFunctionTemplate: {
      nfviType: 'AzureArcKubernetes'
      networkFunctionApplications: [
        {
          artifactType: 'HelmPackage'
          name: 'Contoso'

  3. Edytuj szablon, aby nadpisać domyślną opcję instalacji --atomic narzędzia Helm, dodając następującą konfigurację do nfResource właściwości w szablonie NF ARM.

    roleOverrideValues: ['{"name": "Contoso-one", "deployParametersMappingRuleProfile": {"applicationEnablement": "Enabled", "helmMappingRuleProfile": {"options": {"installOptions": {"atomic": "false"}},{"upgradeOptions": {"atomic": "false"}}}}}']

  4. Upewnij się, że edytowałeś to poprawnie, porównując z poniższym fragmentem z przykładu NF firmy Contoso.

resource nfResource 'Microsoft.HybridNetwork/networkFunctions@2023-09-01' = [for (values, i) in configObject.deployParameters: {
  name: '${configObject.nfdgName}${i}'
  location: configObject.location
  identity: identityObject
  properties: {
    networkFunctionDefinitionVersionResourceReference: {
      id: nfdv.id
      idType: 'Open'
    }
    nfviType: 'AzureArcKubernetes'
    nfviId: (configObject.customLocationId == '') ? resourceGroupId : configObject.customLocationId
    allowSoftwareUpdate: true
    configurationType: 'Open'
    deploymentValues: string(values)
    roleOverrideValues: [
      '{"name":"Contoso-one","deployParametersMappingRuleProfile":{"helmMappingRuleProfile":{"options":{"installOptions":{"injectArtifactStoreDetails":"true", "atomic": "false"},"upgradeOptions":{"injectArtifactStoreDetails":"true","atomic": "false"}}}}}'
    ]}}]

Skompiluj edytowany szablon ARM i przekaż go do magazynu artefaktów

  1. Przejdź do katalogu nsd-cli-output/artifacts utworzonego przez polecenie az aosm nsd build i zbuduj Network Function ARM Template z pliku Bicep wygenerowanego przez CLI.

    bicep build <nf-name>.bicep

  2. Wygeneruj poświadczenia tokenu mapy zakresu na podstawie manifestu artefaktu utworzonego w poleceniu az aosm nsd publish .

    Ważne

    Wymagane jest użycie manifestu artefaktu utworzonego w poleceniu az aosm nsd publish . Szablon arm systemu plików NF jest zadeklarowany tylko w tym manifeście, dlatego tylko token mapy zakresu wygenerowany przez ten manifest umożliwia wypychanie (lub ściąganie) szablonu arm systemu plików NF do magazynu artefaktów.

    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'

  3. Zaloguj się do zarządzanego przez AOSM ACR. Nazwę usługi ACR zarządzaną przez usługę AOSM można znaleźć w artykule Omówienie zasobu usługi Artifact Store w witrynie Azure Portal. Nazwę użytkownika i hasło można znaleźć w danych wyjściowych poprzedniego kroku.

    oras login <aosm-managed-acr-name>.azurecr.io --username <username> --password <scope map token>

  4. Użyj usługi ORAS, aby przekazać szablon arm funkcji sieciowej do zarządzanej przez usługę AOSM usługi Azure Container Registry (ACR). Tag <arm-template-version> artefaktu musi mieć 1.0.0 format. Wartości <arm-template-name> i <arm-template-version> muszą być zgodne z wartościami w manifeście artefaktu utworzonym w poleceniu az aosm nsd publish .

Przesłonięcie --atomic w wielu-grafikach helm NF

Wiele złożonych NFs jest tworzonych na podstawie wielu wykresów helm. Te funkcje sieciowe (NF) są określone w wersji definicji funkcji sieciowej (NFDV) z wieloma aplikacjami funkcji sieciowych i są instalowane za pomocą wielu poleceń helm install, po jednym na każdą kartę Helm.

Proces zastępowania --atomic dla NF z wieloma helmami jest taki sam jak dla pojedynczego helm NF, oprócz zmiany wprowadzonej w szablonie ARM.

Fikcyjny multi-helm NF, Contoso-multi-helm, składa się z trzech diagramów helm. Jego NFDV ma trzy aplikacje funkcji sieciowych. Jedna aplikacja funkcji sieciowej mapuje na jeden wykres helm. Te aplikacje funkcji sieciowych mają właściwość name ustawioną odpowiednio na Contoso-one, Contoso-twoi Contoso-three . Oto przykładowy fragment kodu NFDV definiujący tę funkcję sieciową.

resource nfdv 'Microsoft.Hybridnetwork/publishers/networkfunctiondefinitiongroups/networkfunctiondefinitionversions@2023-09-01' = {
  parent: nfdg
  name: nfDefinitionVersion
  location: location
  properties: {
    deployParameters: string(loadJsonContent('deployParameters.json'))
    networkFunctionType: 'ContainerizedNetworkFunction'
    networkFunctionTemplate: {
      nfviType: 'AzureArcKubernetes'
      networkFunctionApplications: [
        {
          artifactType: 'HelmPackage'
          name: 'Contoso-one'
          ...
        },
        {
          artifactType: 'HelmPackage'
          name: 'Contoso-two'
          ...
        },
        {
          artifactType: 'HelmPackage'
          name: 'Contoso-three'
          ...
        }]
      }
    }
  }

Parametr --atomic można zastąpić niezależnie dla każdej z tych aplikacji funkcji sieciowych. Oto przykładowy plik Bicep systemu plików NF, który zastępuje --atomic na false dla Contoso-one i Contoso-two, ale ustawia atomic na prawda dla Contoso-three.

resource nfResource 'Microsoft.HybridNetwork/networkFunctions@2023-09-01' = [for (values, i) in configObject.deployParameters: {
  name: '${configObject.nfdgName}${i}'
  location: configObject.location
  identity: identityObject
  properties: {
    networkFunctionDefinitionVersionResourceReference: {
      id: nfdv.id
      idType: 'Open'
    }
    nfviType: 'AzureArcKubernetes'
    nfviId: (configObject.customLocationId == '') ? resourceGroupId : configObject.customLocationId
    allowSoftwareUpdate: true
    configurationType: 'Open'
    deploymentValues: string(values)
    roleOverrideValues: [
      '{"name":"Contoso-one","deployParametersMappingRuleProfile":{"helmMappingRuleProfile":{"options":{"installOptions":{"injectArtifactStoreDetails":"true", "atomic": "false"},"upgradeOptions":{"injectArtifactStoreDetails":"true","atomic": "false"}}}}}'
      '{"name":"Contoso-two","deployParametersMappingRuleProfile":{"helmMappingRuleProfile":{"options":{"installOptions":{"injectArtifactStoreDetails":"true", "atomic": "false"},"upgradeOptions":{"injectArtifactStoreDetails":"true","atomic": "false"}}}}}'
      '{"name":"Contoso-three","deployParametersMappingRuleProfile":{"helmMappingRuleProfile":{"options":{"installOptions":{"injectArtifactStoreDetails":"true", "atomic": "false"},"upgradeOptions":{"injectArtifactStoreDetails":"true","atomic": "false"}}}}}'
    ]}}]

Dalsze kroki

Teraz możesz ponowić próbę wdrożenia SNS. Wdrożenie można przesłać ponownie za pomocą usługi ARM, Bicep lub interfejsu API REST usługi AOSM. Możesz również usunąć nieudane sns za pomocą przeglądu sns witryny Azure Portal i ponownie wdrożyć go, wykonując kroki opisane w przewodniku Szybki start, zastępując parametry systemu plików NF przewodnika Szybki start parametrami funkcji sieciowej. Wydania narzędzia Helm wdrożone w klastrze Kubernetes nie zostaną usunięte po awarii. Jak debugować błędy wdrażania sns opisuje zestaw narzędzi do debugowania typowych błędów instalacji narzędzia Helm.