Condividi tramite

Usare i parametri dell'opzione Helm per impedire l'eliminazione in caso di errore di installazione

  • Articolo

Le distribuzioni del servizio di rete del sito (SNS) potrebbero non riuscire perché una distribuzione della funzione di rete (NF) sottostante non riesce a eseguire correttamente l'installazione. Azure Operator Service Manager (AOSM) rimuove le distribuzioni non riuscite dal cluster Kubernetes di destinazione per impostazione predefinita per mantenere le risorse. Helm install Spesso gli errori richiedono che le risorse vengano mantenute nel cluster per consentire il debug dell'errore. Questo articolo sulle procedure illustra come modificare il modello arm NF per eseguire l'override di questo comportamento impostando il helm install --atomic parametro su false.

Prerequisiti

  • È necessario aver eseguito l'onboarding di NF in AOSM usando l'estensione AOSM dell'interfaccia della riga di comando di Az. Questo articolo fa riferimento alla struttura di cartelle e ai file restituiti dall'interfaccia della riga di comando e fornisce esempi basati sull'interfaccia della riga di comando
  • Gli errori di installazione helm possono essere complessi. Il debug richiede conoscenze tecniche di diverse tecnologie oltre alla conoscenza del dominio dell'NF
  • Sono necessarie le Contributor assegnazioni di ruolo nel gruppo di risorse che contiene l'archivio artefatti gestito di AOSM
  • Un IDE appropriato, ad esempio Visual Studio Code
  • Interfaccia della riga di comando ORAS

Importante

È consigliabile testare che un helm install pacchetto Helm abbia esito positivo nell'ambiente Kubernetes connesso ad Arc di destinazione prima di tentare una distribuzione usando AOSM.

Eseguire l'override --atomic per un singolo grafico helm NF

In questa sezione viene illustrato come eseguire l'override --atomic di un NF costituito da un singolo grafico helm.

Individuare e modificare il modello BICEP NF

  1. Passare alla nsd-cli-output directory, aprire la artifacts directory e aprire il <nf-arm-template>.bicep file. <nf-arm-template> viene configurato nel file di input NSD dell'estensione dell'interfaccia della riga di comando di Az AOSM. È possibile verificare di avere il file corretto confrontandolo con il modello di esempio seguente per una funzione di rete fittizia contoso in contenitori (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. Trovare il nome dell'applicazione della funzione di rete passando alla cnf-cli-output directory, aprendo la nfDefinition directory e copiando il valore dall'unica voce nella matrice networkFunctionApplications nella nfdv risorsa. Verificare di avere il valore corretto confrontandolo con il frammento di codice BICEP di esempio fittizio seguente. In questo caso, il nome dell'applicazione della funzione di rete è 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. Modificare il modello per eseguire l'override dell'opzione di installazione --atomic helm predefinita aggiungendo la configurazione seguente alle nfResource proprietà nel modello arm NF:

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

  4. Verificare di aver apportato correttamente questa modifica confrontandolo con il frammento di codice seguente dell'esempio NF di 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"}}}}}'
    ]}}]

Compilare il modello di Resource Manager modificato e caricarlo nell'archivio artefatti

  1. Passare alla nsd-cli-output/artifacts directory creata dal az aosm nsd build comando e compilare il modello di Resource Manager della funzione di rete dal file BICEP generato dall'interfaccia della riga di comando.

    bicep build <nf-name>.bicep

  2. Generare le credenziali del token della mappa dell'ambito dal manifesto dell'artefatto creato nel az aosm nsd publish comando .

    Importante

    È necessario usare il manifesto dell'artefatto creato nel az aosm nsd publish comando . Il modello arm NF viene dichiarato solo in tale manifesto, pertanto solo il token della mappa dell'ambito generato da questo manifesto consentirà di eseguire il push (o il pull) del modello arm NF nell'archivio artefatti.

    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. Accedere al Registro Azure Container gestito da AOSM. Il nome del Registro Azure Container gestito di AOSM è disponibile in portale di Azure panoramica delle risorse dell'archivio artefatti. Il nome utente e la password sono disponibili nell'output del passaggio precedente.

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

  4. Usare ORAS per caricare il modello arm della funzione di rete nel Registro Azure Container gestito di AOSM. Il tag dell'artefatto <arm-template-version> deve essere in 1.0.0 formato . e <arm-template-name> <arm-template-version> deve corrispondere ai valori nel manifesto dell'artefatto creato nel az aosm nsd publish comando .

Eseguire l'override --atomic di un grafico multi helm NF

Molte NFS complesse vengono compilate da più grafici helm. Queste funzioni di rete sono espresse nella versione di definizione della funzione di rete (NFDV) con più applicazioni per le funzioni di rete e vengono installate con più helm install comandi, uno per ogni grafico helm.

Il processo di override --atomic per un NF multi-helm è uguale a quello di un singolo NF helm, oltre alla modifica apportata al modello arm.

Il multi-helm fittizio NF, Contoso-multi-helm, è costituito da tre grafici helm. La sua NFDV ha tre applicazioni per le funzioni di rete. Un'applicazione per le funzioni di rete esegue il mapping a un unico grafico helm. Queste applicazioni per le funzioni di rete hanno una proprietà name impostata rispettivamente su Contoso-one, Contoso-twoe Contoso-three . Ecco un frammento di esempio della funzione di rete NFDV che definisce questa funzione di rete.

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

Il --atomic parametro può essere sottoposto a override per ognuna di queste applicazioni di funzione di rete in modo indipendente. Ecco un esempio di modello BICEP NF che esegue l'override di per e Contoso-two, ma imposta su atomic true per Contoso-three.Contoso-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"}}}}}'
    ]}}]

Passaggi successivi

È ora possibile ritentare la distribuzione SNS. È possibile inviare di nuovo la distribuzione tramite ARM, BICEP o l'API REST di AOSM. È anche possibile eliminare il servizio SNS non riuscito tramite la panoramica portale di Azure SNS e ridistribuire dopo l'avvio rapido dell'operatore, sostituendo i parametri NF di avvio rapido con i parametri per la funzione di rete. Le versioni helm distribuite nel cluster Kubernetes non verranno rimosse in caso di errore. Come eseguire il debug degli errori di distribuzione SNS descrive un toolkit per il debug di errori di installazione helm comuni.