Dela via

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

  • Artikel

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 så att felet kan kopplas från. Den här 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 registrerat din NF till 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
  • Du behöver Contributor rolltilldelningarna i resursgruppen som innehåller det AOSM-hanterade artefaktarkivet
  • 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ättning --atomic för ett NF med ett enda helm-diagram

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-mallen

  1. 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)
  }
}]

  2. 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 med följande fiktiva Contoso-exempel BICEP-kodfragment. 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'

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

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

  4. 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

  1. 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

  2. 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'

  3. Logga in på AOSM-hanterad ACR. 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>

  4. 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. Och <arm-template-name> <arm-template-version> måste matcha värdena i artefaktmanifestet som skapades az aosm nsd publish i kommandot .

Åsidosättning --atomic för ett NF-diagram 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-mall som åsidosätter till för och , men som är true atomic för Contoso-three.Contoso-twoContoso-one false --atomic

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-versionerna som distribueras till Kubernetes-klustret tas inte bort vid fel. Hur du felsöker SNS-distributionsfel beskriver en verktygslåda för felsökning av vanliga helm-installationsfel.