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

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 How-To 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 utilizzando l'estensione Az CLI per AOSM. 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 di Helm possono essere complessi. Il debug richiede conoscenze tecniche di diverse tecnologie oltre alla conoscenza del dominio dell'NF
- Conoscenza operativa di Helm
- Conoscenza approfondita dei comandi kubernetes e kubectl
- Conoscenza pratica del trasferimento di artefatti tramite pull e push nel Registro dei Contenitori di Azure
Sono necessarie le Contributor assegnazioni di ruolo nel gruppo di risorse che contiene l'archivio di artefatti gestito da AOSM.
Un IDE appropriato, ad esempio Visual Studio Code
ORAS CLI

Importante

Si raccomanda vivamente di aver testato che un helm install del 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 file Bicep NF

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 CLI Az AOSM. È possibile verificare di avere il file corretto confrontandolo con il seguente modello di esempio per la funzione di rete in contenitori fittizia di 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)
  }
}]

Trova il nome dell'applicazione della funzione di rete accedendo alla cartella cnf-cli-output, aprendo la cartella nfDefinition e copiando il valore dall'unica voce nell'array networkFunctionApplications nella risorsa nfdv. Verificare di avere il valore corretto confrontandolo con il seguente frammento di esempio fittizio di Bicep da Contoso. 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'

Modificare il modello per eseguire l'override dell'opzione di installazione predefinita --atomic Helm aggiungendo la configurazione seguente alle proprietà nfResource nel modello ARM NF.

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

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 Template ARM modificato e caricarlo nell'Archivio di Artifact

Passare alla nsd-cli-output/artifacts directory creata dal comando az aosm nsd build e costruire il modello ARM della Funzione di Rete dal file Bicep generato dall'interfaccia della riga di comando.
```
bicep build <nf-name>.bicep
```
Generare le credenziali del token della mappa dell'ambito dal manifesto dell'artefatto creato nel comando az aosm nsd publish.

Importante

È necessario usare il manifesto dell'artefatto creato nel comando az aosm nsd publish. 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'
```
Accedi all'Azure Container Registry gestito da AOSM. Il nome ACR gestito da AOSM può essere trovato nella panoramica delle risorse dell'Archivio artefatti nel portale di Azure. 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>
```
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 formato 1.0.0. Il <arm-template-name> e <arm-template-version> devono corrispondere ai valori nel manifesto dell'artefatto creato nel comando az aosm nsd publish.

Sostituire `--atomic` per 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 diverse applicazioni di funzione di rete e vengono installate con più comandi helm install, uno per ogni helm chart.

Il processo di override di --atomic per un NF multi-helm è uguale a quello di un singolo NF helm, a parte la modifica apportata al modello ARM.

Il multi-helm fittizio NF, Contoso-multi-helm, è costituito da tre helm chart. La sua NFDV ha tre applicazioni per le funzioni di rete. Un'applicazione di funzione di rete corrisponde a un unico schema 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 in cui la NFDV 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 file Bicep NF che esegue l'override di --atomic in false per Contoso-one e Contoso-two, ma imposta atomic su true per 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"}}}}}'
    ]}}]

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 di SNS del portale di Azure 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 comuni di installazione di Helm.

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2025-05-20

Condividi tramite