Använd Helm-alternativparametrar för att förhindra borttagning vid installationsfel

Distributioner av platsnätverkstjänsten (SNS) kan misslyckas eftersom en underliggande NF-distribution (Network Function) inte kan installera helm korrekt. Azure Operator Service Manager (AOSM) tar bort misslyckade distributioner från det riktade Kubernetes-klustret som standard för att bevara resurser. Helm install fel kräver ofta att resurserna bevaras i klustret för att felet ska kunna felsökas. Den här How-To artikeln beskriver hur du redigerar NF ARM-mallen för att åsidosätta det här beteendet genom att ange parametern helm install --atomic till false.

Förutsättningar

Du måste ha integrerat din NF med AOSM med hjälp av Az CLI AOSM-tillägget. Den här artikeln refererar till mappstrukturen och filernas utdata från CLI och ger CLI-baserade exempel
Helm-installationsfel kan vara komplexa. Felsökning kräver teknisk kunskap om flera tekniker utöver domänkunskaper om din NF
- Praktisk kunskap om Helm
- Arbetskunskaper om Kubernetes- och kubectl-kommandon
- Arbetskunskaper om att hämta och skicka artefakter till Azure Container Registry
Du behöver Contributor rolltilldelning för resursgruppen som innehåller det artefaktarkiv som hanteras av AOSM.
En lämplig IDE, till exempel Visual Studio Code
ORAS CLI

Viktigt!

Vi rekommenderar starkt att du har testat att ett helm install Helm-paket lyckas i din Arc-anslutna Kubernetes-målmiljö innan du försöker distribuera med hjälp av AOSM.

Åsidosätt `--atomic` för en enstaka helm-chart NF

I det här avsnittet beskrivs hur du åsidosätter --atomic för en NF som består av ett enda helm-diagram.

Leta upp och redigera NF Bicep-filen

Gå till nsd-cli-output katalogen, öppna artifacts katalogen och öppna <nf-arm-template>.bicep filen. <nf-arm-template> har konfigurerats i Az AOSM CLI-tilläggets NSD-indatafil. Du kan bekräfta att du har rätt fil genom att jämföra med följande exempelmall för en fiktiv Contoso-containerbaserad nätverksfunktion (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)
  }
}]

Hitta namnet på nätverksfunktionens program genom att gå till cnf-cli-output katalogen, öppna nfDefinition katalogen och kopiera värdet från den enda posten i matrisen networkFunctionApplications i resursen nfdv . Bekräfta att du har rätt värde genom att jämföra mot följande fiktiva Contoso-exempel Bicep-snippet. I det här fallet är Contosonamnet på nätverksfunktionens program .

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'

Redigera mallen för att åsidosätta standardalternativet helm install --atomic genom att lägga till följande konfiguration i egenskaperna för nfResource i NF ARM Template:

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

Bekräfta att du har gjort den här redigeringen korrekt genom att jämföra med följande kodfragment från Contoso-exempel-NF

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

Skapa den redigerade ARM-mallen och ladda upp den till Artefaktarkivet

Gå till katalogen nsd-cli-output/artifacts som skapades av az aosm nsd build kommandot och skapa ARM-mallen för nätverksfunktionen från Bicep-filen som genereras av CLI.
```
bicep build <nf-name>.bicep
```
Generera autentiseringsuppgifter för omfångsmappningstoken från artefaktmanifestet som skapades az aosm nsd publish i kommandot .

Viktigt!

Du måste använda artefaktmanifestet som skapades az aosm nsd publish i kommandot . NF ARM-mallen deklareras endast i det manifestet, och därför kan du bara skicka (eller hämta) NF ARM-mallen till 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'
```
Logga in på ACR hanterad av AOSM. Det AOSM-hanterade ACR-namnet finns i resursöversikten för Artefaktarkivet i Azure-portalen. Användarnamnet och lösenordet finns i utdata från föregående steg.
```
oras login <aosm-managed-acr-name>.azurecr.io --username <username> --password <scope map token>
```
Använd ORAS för att ladda upp ARM-mallen för nätverksfunktionen till AOSM-hanterade Azure Container Registry (ACR). Artefakttaggen <arm-template-version> måste vara i 1.0.0 format. De <arm-template-name> och <arm-template-version> måste matcha värdena i artefaktmanifestet som skapats i kommandot az aosm nsd publish.

Åsidosätta `--atomic` för ett NF med flera helm-diagram

Många komplexa NF:er skapas från flera helm-diagram. Dessa NFs uttrycks i nätverksfunktionsdefinitionsversionen (NFDV) med flera program för nätverksfunktioner och installeras med flera helm install kommandon – ett per helm-diagram.

Processen för att --atomic åsidosätta för en NF med flera helm-enheter är densamma som för en enda helm-NF, förutom den redigering som gjorts i ARM-mallen.

Den fiktiva NF:n med flera helm:er, Contoso-multi-helm, består av tre helm-diagram. Dess NFDV har tre nätverksfunktionsprogram. Ett nätverksfunktionsprogram mappar till ett helm-diagram. Dessa nätverksfunktionsprogram har en namnegenskap inställd på Contoso-one, Contoso-tworespektive Contoso-three . Här är ett exempelfragment av NFDV som definierar den här nätverksfunktionen.

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

Parametern --atomic kan åsidosättas för vart och ett av dessa nätverksfunktionsprogram oberoende av varandra. Här är ett exempel på en NF Bicep-fil som åsidosätter --atomic till false för Contoso-one och Contoso-two, men ställer in atomic på true för 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"}}}}}'
    ]}}]

Nästa steg

Nu kan du försöka med SNS-distributionen igen. Du kan skicka distributionen igen via ARM, Bicep eller AOSM REST API. Du kan också ta bort det misslyckade SNS via översikten över Azure Portal SNS och distribuera om efter operatorns snabbstart och ersätta NF-parametrarna för snabbstarten med parametrarna för din nätverksfunktion. Helm-utgåvorna som distribueras till Kubernetes-klustret kommer inte att tas bort vid ett fel. Hur du felsöker SNS-distributionsfel beskriver en verktygslåda för felsökning av vanliga helm-installationsfel.

Feedback

Var den här sidan till hjälp?

Last updated on 2025-05-20

Dela via