Delen via


Helm-optieparameters gebruiken om verwijdering bij installatiefouten te voorkomen

SNS-implementaties (Site Network Service) kunnen mislukken omdat een onderliggende NF-implementatie (Network Function) niet correct kan worden geïnstalleerd. Azure Operator Service Manager (AOSM) verwijdert standaard mislukte implementaties uit het beoogde Kubernetes-cluster om resources te behouden. Helm install fouten vereisen vaak dat de resources op het cluster blijven bestaan om fouten op te sporen. In dit artikel wordt beschreven hoe u de NF ARM-sjabloon bewerkt om dit gedrag te overschrijven door de helm install --atomic parameter in te stellen op false.

Vereisten

  • U moet uw NF naar AOSM hebben ge onboardd met behulp van de Az CLI AOSM-extensie. In dit artikel wordt verwezen naar de mapstructuur en bestanden die door de CLI worden uitgevoerd en worden voorbeelden op basis van CLI weergegeven
  • Helm-installatiefouten kunnen complex zijn. Foutopsporing vereist technische kennis van verschillende technologieën naast domeinkennis van uw NF
  • U hebt de Contributor roltoewijzingen nodig voor de resourcegroep die het beheerde artefactarchief van de AOSM bevat
  • Een geschikte IDE, zoals Visual Studio Code
  • De ORAS CLI

Belangrijk

Het wordt sterk aanbevolen dat u hebt getest dat een helm install van uw Helm-pakket slaagt in uw met Arc verbonden Kubernetes-doelomgeving voordat u een implementatie uitvoert met behulp van AOSM.

Overschrijven --atomic voor één Helm-grafiek NF

In deze sectie wordt uitgelegd hoe u een NF overschrijft --atomic die bestaat uit één Helm-grafiek.

De NF BICEP-sjabloon zoeken en bewerken

  1. Navigeer naar de nsd-cli-output map, open de artifacts map en open het <nf-arm-template>.bicep bestand. <nf-arm-template> is geconfigureerd in het NSD-invoerbestand van de Az AOSM CLI-extensie. U kunt bevestigen dat u het juiste bestand hebt door te vergelijken met de volgende voorbeeldsjabloon voor een fictieve netwerkfunctie van Contoso in containers (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. Zoek de naam van de netwerkfunctietoepassing door naar de cnf-cli-output map te navigeren, de nfDefinition map te openen en de waarde te kopiëren van de enige vermelding in de matrix networkFunctionApplications in de nfdv resource. Bevestig dat u de juiste waarde hebt door het volgende fictieve BICEP-codefragment van Contoso te vergelijken. In dit geval is Contosode naam van de netwerkfunctietoepassing.

    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. Bewerk de sjabloon om de standaard-helm-installatieoptie --atomic te overschrijven door de volgende configuratie toe te voegen aan de nfResource eigenschappen in de NF ARM-sjabloon:

    roleOverrideValues: ['{"name": "Contoso-one", "deployParametersMappingRuleProfile": {"applicationEnablement": "Enabled", "helmMappingRuleProfile": {"options": {"installOptions": {"atomic": "false"}},{"upgradeOptions": {"atomic": "false"}}}}}']
    
  4. Controleer of u deze bewerking correct hebt aangebracht door het volgende codefragment van het contoso-voorbeeld NF te vergelijken

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"}}}}}'
    ]}}]

Bouw de bewerkte ARM-sjabloon en upload deze naar de Artefact Store

  1. Navigeer naar de nsd-cli-output/artifacts map die is gemaakt met de az aosm nsd build opdracht en bouw de ARM-sjabloon voor de netwerkfunctie op basis van het BICEP-bestand dat is gegenereerd door de CLI.

    bicep build <nf-name>.bicep
    
  2. Genereer tokenreferenties van het artefactmanifest dat in de az aosm nsd publish opdracht is gemaakt.

    Belangrijk

    U moet het artefactmanifest gebruiken dat in de az aosm nsd publish opdracht is gemaakt. De NF ARM-sjabloon wordt alleen gedeclareerd in dat manifest, dus alleen het bereiktoewijzingstoken dat door dit manifest wordt gegenereerd, kunt u de NF ARM-sjabloon pushen (of ophalen) naar de Artifact Store.

    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. Meld u aan bij de door AOSM beheerde ACR. De door AOSM beheerde ACR-naam vindt u in het overzicht van de Artefact Store-resource in de Azure-portal. De gebruikersnaam en het wachtwoord vindt u in de uitvoer van de vorige stap.

    oras login <aosm-managed-acr-name>.azurecr.io --username <username> --password <scope map token>
    
  4. Gebruik ORAS om de ARM-sjabloon voor netwerkfuncties te uploaden naar de AOSM managed Azure Container Registry (ACR). De <arm-template-version> artefacttag moet een 1.0.0 indeling hebben. De <arm-template-name> en <arm-template-version> moeten overeenkomen met de waarden in het artefactmanifest dat in de az aosm nsd publish opdracht is gemaakt.

Overschrijven --atomic voor een NF-grafiek met meerdere helmen

Veel complexe NF's zijn opgebouwd uit meerdere Helm-grafieken. Deze NF's worden uitgedrukt in de versie van de netwerkfunctiedefinitie (NFDV) met meerdere netwerkfunctietoepassingen en worden geïnstalleerd met meerdere helm install opdrachten: één per Helm-grafiek.

Het proces voor het overschrijven --atomic van een multi-helm NF is hetzelfde als voor één Helm NF, afgezien van de bewerking die is aangebracht in de ARM-sjabloon.

De fictieve multi-helm NF, Contoso-multi-helm, bestaat uit drie Helm-grafieken. De NFDV heeft drie netwerkfunctietoepassingen. Eén netwerkfunctietoepassing wordt toegewezen aan één Helm-grafiek. Voor deze netwerkfunctietoepassingen is een naameigenschap ingesteld op Contoso-one, Contoso-tworespectievelijk Contoso-three . Hier volgt een voorbeeldfragment van de NFDV die deze netwerkfunctie definieert.

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'
          ...
        }]
      }
    }
  }

De --atomic parameter kan onafhankelijk van elkaar worden overschreven voor elk van deze netwerkfunctietoepassingen. Hier volgt een voorbeeld van een NF BICEP-sjabloon die wordt overschreven --atomic voor Contoso-one false en Contoso-two, maar wordt ingesteld atomic op waar voor 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"}}}}}'
    ]}}]

Volgende stappen

U kunt nu de SNS-implementatie opnieuw proberen. U kunt de implementatie opnieuw verzenden via ARM, BICEP of de AOSM REST API. U kunt de mislukte SNS ook verwijderen via het SNS-overzicht van Azure Portal en opnieuw implementeren volgens de quickstart van de operator, waarbij u de quickstart-NF-parameters vervangt door de parameters voor uw netwerkfunctie. De Helm-releases die in het Kubernetes-cluster zijn geïmplementeerd, worden niet verwijderd bij een fout. Foutopsporing in SNS-implementatie beschrijft een toolkit voor het opsporen van veelvoorkomende helm-installatiefouten.