Introduzione alle procedure di aggiornamento sicure

Questo articolo presenta le procedure di aggiornamento sicuro (SUP) di Azure Operator Service Manager (AOSM). Questo set di funzionalità consente a un utente finale di eseguire in modo sicuro gli aggiornamenti complessi dei carichi di lavoro CNF (Container Network Function) ospitati in Azure Operator Nexus, in conformità ai requisiti isSU (Partner In Service Software Upgrade), ove applicabile. Cerca gli articoli futuri in questi servizi per ampliare le funzionalità e le funzionalità di SUP.

Introduzione agli aggiornamenti sicuri

Un determinato servizio di rete supportato da Azure Operator Service Manager sarà composto da una o più funzioni di rete basate su contenitori che, nel corso del tempo, richiederanno aggiornamenti software. Per ogni aggiornamento, è necessario eseguire una a molte operazioni Helm, aggiornando le applicazioni di funzione di rete dipendenti (NfApps), in un ordine particolare, in modo che influisca meno sul servizio di rete. In Azure Operator Service Manager, Safe Upgrade Practices rappresenta un set di funzionalità, che può automatizzare le operazioni CNF necessarie per aggiornare un servizio di rete in Azure Operator Nexus.

• Aggiornamento del Reput SNS: eseguire l'operazione di aggiornamento Helm in tutte le NfApp in NFDV.
• Nexus Platform: supporta le operazioni di reput SNS sulle destinazioni della piattaforma Nexus.
• Timeout dell'operazione: possibilità di impostare timeout operativi per ogni operazione NfApp.
• Operazioni sincrone: possibilità di eseguire un'operazione NfApp seriale alla volta.
• Sospendi in caso di errore: in base al flag, impostare il comportamento di errore per eseguire il rollback solo dell'ultima operazione NfApp.
• Convalida dei test a grafico singolo: esecuzione di un'operazione di test Helm dopo una creazione o un aggiornamento.
• Reput SNS sottoposto a refactoring: metodi migliorati, aggiunge il controllo dell'ordine di aggiornamento e della pulizia.
• Migliorare il controllo Opzioni di aggiornamento: esporre i parametri in modo più efficace.
• Ignora NfApp su Nessuna modifica: ignora l'elaborazione di NfApps in cui non vengono apportate modifiche.
• Eseguire il rollback a livello di NF in caso di errore: in base al flag, eseguire il rollback di tutte le NfApp completate in caso di errore.
• Precaricamento delle immagini: possibilità di precaricare le immagini nel repository perimetrale.

Approccio sicuro per l'aggiornamento

Per aggiornare un servizio di rete del sito SNS (Azure Operator Service Manager) esistente, l'operatore esegue una richiesta di aggiornamento del reput sulla risorsa SNS distribuita. Dove SNS contiene file CNF con più applicazioni NfApps, la richiesta viene fan-out in tutte le applicazioni NfApp definite nella versione di definizione della funzione di rete (NFDV). Per impostazione predefinita, nell'ordine in cui vengono visualizzate o facoltativamente nell'ordine definito dal parametro UpdateDependsOn.

Per ogni NfApp, la richiesta di aggiornamento del reput supporta l'aumento di una versione del grafico Helm, l'aggiunta/rimozione dei valori Helm e/o l'aggiunta/rimozione di eventuali app NfApp. I timeout possono essere impostati per NfApp, in base a runtime consentiti noti, ma NfApps può essere elaborato solo in ordine seriale, uno dopo l'altro. L'aggiornamento del reput implementa la logica di elaborazione seguente:

• Le applicazioni NfApps vengono elaborate dopo l'ordinamento updateDependsOn o nell'ordine sequenziale visualizzato.
• NfApps con il parametro applicationEnabled impostato per disabilitare vengono ignorati.
• NfApps con parametro skipUpgrade impostato su enabled vengono ignorati se non sono state rilevate modifiche.
• Le applicazioni NFApp comuni tra la versione precedente e la nuova NFDV vengono aggiornate.
• Vengono installate le applicazioni NFApp che si trovano solo nella nuova NFDV.
• Le applicazioni NFApp distribuite, ma non a cui fa riferimento il nuovo NFDV, vengono eliminate.

Per garantire i risultati, il test NfApp è supportato usando Helm, i test Helm di pre/post di aggiornamento o quelli autonomi. Per gli errori di pre/post test, viene rispettato il parametro atomico. Con atomico/true, viene eseguito il rollback del grafico non riuscito. Con atomico/false, non viene eseguito alcun rollback. Per altre informazioni sui test helm autonomi, vedere l'articolo seguente: Eseguire test dopo l'installazione o l'aggiornamento

Considerazioni per gli aggiornamenti nel servizio

Azure Operator Service Manager supporta in genere gli aggiornamenti del servizio, un metodo di aggiornamento che avanza una versione di distribuzione senza interrompere il servizio in esecuzione. Alcune considerazioni sono necessarie per garantire il comportamento corretto di AOSM durante le operazioni ISSU.

• Dove AOSM esegue un aggiornamento rispetto a un set ordinato di più nfApps, AOSM prima aggiorna o crea tutte le nuove app nfApps, quindi elimina tutte le vecchie nfApps. Questo approccio garantisce che il servizio non sia interessato fino a quando tutte le nuove app nfApp non sono pronte, ma richiedono capacità aggiuntiva della piattaforma per l'hosting temporaneo di nfApp precedenti e nuove.
• Dove AOSM aggiorna un'app NfApp con più repliche, AOSM rispetta le impostazioni del profilo di distribuzione per l'opzione di rollback o ricreazione. Dove viene usato il rollover, esporre i valori maxUnavailable e maxSurge come parametri CGS, che possono quindi essere impostati tramite CGV dell'operatore in fase di esecuzione.

In definitiva, la possibilità di aggiornare un determinato servizio senza interruzioni è una funzionalità del servizio stesso. Consultare ulteriormente l'editore del servizio per comprendere le funzionalità di aggiornamento nel servizio e assicurarsi che siano allineate alle opzioni comportamentali appropriate di AOSM.

Prerequisiti per l'aggiornamento sicuro

Quando si pianifica un aggiornamento usando Azure Operator Service Manager, soddisfare i requisiti seguenti prima dell'esecuzione dell'aggiornamento per ottimizzare il tempo impiegato per tentare l'aggiornamento.

• Eseguire l'onboarding degli artefatti aggiornati usando flussi di lavoro del server di pubblicazione e/o della finestra di progettazione.

  • Publisher, store, network service design (NSDg) e Network Function Design Group (NFDg) sono statici e non devono essere modificati.
    • Per archiviare i nuovi grafici e le nuove immagini, è necessario un nuovo manifesto dell'artefatto. Per altre informazioni, vedere la documentazione sull'onboarding per informazioni dettagliate sul caricamento di nuovi grafici e immagini.
  • Sono necessarie nuove versioni di progettazione del servizio di rete e NFDV (NSDV), in NFDg e NSDg esistenti.
    • Verranno illustrate le modifiche di base apportate alla versione NFDV nella sezione dettagliata.
    • La nuova NSDV è necessaria solo se viene introdotta una nuova versione CGS (Configuration Group Schema).
  • Se necessario, nuovo CGS.
    • Obbligatorio se un aggiornamento introduce nuovi parametri di configurazione esposti.

• Creare artefatti aggiornati usando il flusso di lavoro Operatore.

  • Se necessario, creare nuovi valori del gruppo di configurazione (CGV) in base al nuovo CGS.
  • Riutilizzare e creare il payload confermando gli oggetti del servizio di rete del sito e del sito esistenti.

• Aggiornare i modelli per assicurarsi che i parametri di aggiornamento siano impostati in base all'attendibilità dell'aggiornamento e del comportamento di errore desiderato.

  • Le impostazioni usate per l'ambiente di produzione possono eliminare i dettagli degli errori, mentre le impostazioni usate per il debug o i test possono scegliere di esporre questi dettagli.

Procedura di aggiornamento sicuro

Seguire la procedura seguente per attivare un aggiornamento con Azure Operator Service Manager.

Creare una nuova risorsa NFDV

Per le nuove versioni NFDV, deve essere in un formato SemVer valido, in cui sono consentiti solo valori di incremento più elevati di aggiornamenti patch e versioni secondarie. Non è consentita una versione NFDV inferiore. Dato che un CNF distribuito con NFDV 2.0.0, la nuova NFDV può essere di versione 2.0.1 o 2.1.0, ma non 1.0.0 o 3.0.0.

Aggiornare i nuovi parametri NFDV

Le versioni del grafico Helm possono essere aggiornate o i valori Helm possono essere aggiornati o parametrizzati in base alle esigenze. È anche possibile aggiungere nuove app NfApps in cui non esistevano nella versione distribuita.

Aggiornare NFDV per l'ordine NfApp desiderato

UpdateDependsOn è un parametro NFDV usato per specificare l'ordinamento di NfApps durante le operazioni di aggiornamento. Se UpdateDependsOn non viene specificato, viene usato l'ordinamento seriale delle applicazioni CNF, come visualizzato nella NFDV.

Aggiornare NFDV per il comportamento di aggiornamento desiderato

Assicurarsi di impostare i timeout dell'applicazione CNF desiderati, il parametro atomico e il parametro rollbackOnTestFailure. Può essere utile modificare questi parametri nel corso del tempo man mano che si ottiene maggiore attendibilità nell'aggiornamento.

Problema di reput SNS

Al termine dell'onboarding, viene inviata l'operazione di reput. A seconda del numero, delle dimensioni e della complessità delle applicazioni NfApps, l'operazione di reput potrebbe richiedere del tempo (più ore).

Esaminare i risultati del reput

Se il reput segnala un risultato positivo, l'aggiornamento è completo e l'utente deve convalidare lo stato e la disponibilità del servizio. Se il reput segnala un errore, seguire la procedura descritta nella sezione Relativa al ripristino degli errori di aggiornamento per continuare.

Procedura di ripetizione dei tentativi di aggiornamento sicuro

Nei casi in cui un aggiornamento del reput non riesce, è possibile seguire il processo seguente per ritentare l'operazione.

Diagnosticare NfApp non riuscito

Risolvere la causa radice dell'errore NfApp analizzando i log e altre informazioni di debug.

Ignorare manualmente i grafici completati

Dopo aver corretto NfApp non riuscito, ma prima di tentare un nuovo tentativo di aggiornamento, provare a modificare il parametro applicationEnablement per accelerare il comportamento di ripetizione dei tentativi. Questo parametro può essere impostato su false, in cui deve essere ignorato un oggetto NfApp. Questo parametro può essere utile in cui un'applicazione NfApp non richiede un aggiornamento.

Eseguire un nuovo tentativo di reput SNS (ripetere fino all'esito positivo)

Per impostazione predefinita, il reput ritenta NfApps nell'ordine di aggiornamento dichiarato, a meno che non vengano ignorati usando il flag applicationEnablement.

Ignorare nfApps con applicationEnablement

Nella risorsa NFDV, in deployParametersMappingRuleProfile è presente la proprietà applicationEnablement di tipo enumerazione, che accetta valori: Unknown, Enabled o Disabled. Può essere usato per escludere le operazioni NfApp durante la distribuzione della funzione di rete (NF).

Modifiche al server di pubblicazione

Per la proprietà applicationEnablement, il server di pubblicazione dispone di due opzioni: specificare un valore predefinito o parametrizzarlo.

Esempio di NFDV

Il valore NFDV viene usato dal server di pubblicazione per impostare i valori predefiniti per applicationEnablement.

{ 
      "location":"<location>", 
      "properties": {
      "networkFunctionTemplate": {
        "networkFunctionApplications": [
          {
            "artifactProfile": {
              "helmArtifactProfile": { 
                "var":"var"
              },
              "artifactStore": {
                "id": "<artifactStore id>"
              }
            },
            "deployParametersMappingRuleProfile": {
              "helmMappingRuleProfile": {
                "releaseNamespace": "{deployParameters.role1releasenamespace}",
                "releaseName": "{deployParameters.role1releasename}"
              },
              "applicationEnablement": "Enabled"
            },
            "artifactType": "HelmPackage",
            "dependsOnProfile": "null",
            "name": "hellotest"
          },
          {
            "artifactProfile": {
              "helmArtifactProfile": {
                 "var":"var"
              },
              "artifactStore": {
                "id": "<artifactStore id>"
              }
            },
            "deployParametersMappingRuleProfile": {
              "helmMappingRuleProfile": {
                "releaseNamespace": "{deployParameters.role2releasenamespace}",
                "releaseName": "{deployParameters.role2releasename}"
              },
              "applicationEnablement": "Enabled"
            },
            "artifactType": "HelmPackage",
            "dependsOnProfile": "null",
            "name": "hellotest1"
          }
        ],
        "nfviType": "AzureArcKubernetes"
      },
      "description": "null",
      "deployParameters": {"type":"object","properties":{"role1releasenamespace":{"type":"string"},"role1releasename":{"type":"string"},"role2releasenamespace":{"type":"string"},"role2releasename":{"type":"string"}},"required":["role1releasenamespace","role1releasename","role2releasenamespace","role2releasename"]},
      "networkFunctionType": "ContainerizedNetworkFunction"
    }
}

Risorsa di esempio dello schema del gruppo di configurazione (CGS)

Il CGS viene usato dal server di pubblicazione per richiedere che una variabile roleOverrideValues venga fornita da Operator in fase di esecuzione. RoleOverrideValues può includere impostazioni non predefinite per applicationEnablement.

{
  "type": "object",
  "properties": {
    "location": {
      "type": "string"
    },
    "nfviType": {
      "type": "string"
    },
    "nfdvId": {
      "type": "string"
    },
    "helloworld-cnf-config": {
      "type": "object",
      "properties": {
        "role1releasenamespace": {
          "type": "string"
        },
        "role1releasename": {
          "type": "string"
        },
        "role2releasenamespace": {
          "type": "string"
        },
        "role2releasename": {
          "type": "string"
        },
        "roleOverrideValues1": {
          "type": "string"
        },
        "roleOverrideValues2": {
          "type": "string"
        }
      },
      "required": [
        "role1releasenamespace",
        "role1releasename",
        "role2releasenamespace",
        "role2releasename",
        "roleOverrideValues1",
        "roleOverrideValues2"
      ]
    }
  },
  "required": [
    "nfviType",
    "nfdvId",
    "location",
    "helloworld-cnf-config"
  ]
}

Modifiche dell'operatore

Gli operatori ereditano i valori predefiniti di applicationEnablement, come definito dalla funzione NFDV. Se applicationEnablement è parametrizzato in CGS, deve essere passato tramite la proprietà deploymentValues in fase di esecuzione.

Risorsa CGV (Configuration Group Value) di esempio

Il CGV viene usato dall'operatore per impostare la variabile roleOverrideValues in fase di esecuzione. RoleOverrideValues include impostazioni non predefinite per applicationEnablement.

{
  "location": "<location>",
  "nfviType": "AzureArcKubernetes",
  "nfdvId": "<nfdv_id>",
  "helloworld-cnf-config": {
    "role1releasenamespace": "hello-test-releasens",
    "role1releasename": "hello-test-release",
    "role2releasenamespace": "hello-test-2-releasens",
    "role2releasename": "hello-test-2-release",
    "roleOverrideValues1": "{\"name\":\"hellotest\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\":\"Enabled\",\"helmMappingRuleProfile\":{\"releaseName\":\"override-release\",\"releaseNamespace\":\"override-namespace\",\"helmPackageVersion\":\"1.0.0\",\"values\":\"\",\"options\":{\"installOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"30\",\"injectArtifactStoreDetails\":\"true\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"30\",\"injectArtifactStoreDetails\":\"true\"}}}}}",
    "roleOverrideValues2": "{\"name\":\"hellotest1\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\" : \"Enabled\"}}"
  }
}

Modello arm NF di esempio

Il modello arm NF viene usato dall'operatore per inviare la variabile roleOverrideValues, impostata da CGV, al provider di risorse (RP). L'operatore può modificare l'impostazione applicationEnablement in CGV, in base alle esigenze, e inviare nuovamente lo stesso modello arm NF per modificare il comportamento tra iterazioni.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "nameValue": {
      "type": "string",
      "defaultValue": "HelloWorld"
    },
    "locationValue": {
      "type": "string",
      "defaultValue": "eastus"
    },
    "nfviTypeValue": {
      "type": "string",
      "defaultValue": "AzureArcKubernetes"
    },
    "nfviIdValue": {
      "type": "string"
    },
    "config": {
      "type": "object",
      "defaultValue": {}
    },
    "nfdvId": {
      "type": "string"
    }
  },
  "variables": {
    "deploymentValuesValue": "[string(createObject('role1releasenamespace', parameters('config').role1releasenamespace, 'role1releasename',parameters('config').role1releasename, 'role2releasenamespace', parameters('config').role2releasenamespace, 'role2releasename',parameters('config').role2releasename))]",
    "nfName": "[concat(parameters('nameValue'), '-CNF')]",
    "roleOverrideValues1": "[string(parameters('config').roleOverrideValues1)]",
    "roleOverrideValues2": "[string(parameters('config').roleOverrideValues2)]"
  },
  "resources": [
    {
      "type": "Microsoft.HybridNetwork/networkFunctions",
      "apiVersion": "2023-09-01",
      "name": "[variables('nfName')]",
      "location": "[parameters('locationValue')]",
      "properties": {
        "networkFunctionDefinitionVersionResourceReference": {
          "id": "[parameters('nfdvId')]",
          "idType": "Open"
        },
        "nfviType": "[parameters('nfviTypeValue')]",
        "nfviId": "[parameters('nfviIdValue')]",
        "allowSoftwareUpdate": true,
        "configurationType": "Open",
        "deploymentValues": "[string(variables('deploymentValuesValue'))]",
        "roleOverrideValues": [
          "[variables('roleOverrideValues1')]",
          "[variables('roleOverrideValues2')]"
        ]
      }
    }
  ]
}

Ignorare NfApps che non hanno alcuna modifica

La skipUpgrade funzionalità è progettata per ottimizzare il tempo impiegato per gli aggiornamenti CNF. Quando il server di pubblicazione abilita questo flag in , roleOverrideValuesupgradeOptionsil livello di servizio AOSM esegue determinati controlli preliminari per determinare se un aggiornamento per uno specifico nFApplication può essere ignorato. Se vengono soddisfatti tutti i criteri di controllo preliminare, l'aggiornamento viene ignorato per tale applicazione. In caso contrario, viene eseguito un aggiornamento a livello di cluster.

Criteri di controllo preliminare

Un aggiornamento può essere ignorato se vengono soddisfatte tutte le condizioni seguenti:

1. Lo nfApplication stato di provisioning è Succeeded.
2. Non sono state apportate modifiche al nome o alla versione del grafico Helm.
3. Non sono state apportate modifiche ai valori Helm.

Abilitazione o disabilitazione della funzionalità skipUpgrade

La skipUpgrade funzionalità è disabilitata per impostazione predefinita. Se questo parametro facoltativo non viene specificato in roleOverrideValuesupgradeOptions, gli aggiornamenti CNF proseguono nel modo tradizionale, in cui vengono nfApplications aggiornati a livello di cluster.

Abilitazione di SkipUpgrade all'interno della risorsa funzione di rete

Per abilitare la funzionalità SkipUpgrade tramite roleOverrideValues, fare riferimento all'esempio seguente.

{
    "location": "eastus2euap",
    "properties": {
        "publisherName": "xyAzureArcRunnerPublisher",
        "publisherScope": "Private",
        "networkFunctionDefinitionGroupName": "AzureArcRunnerNFDGroup",
        "networkFunctionDefinitionVersion": "1.0.0",
        "networkFunctionDefinitionOfferingLocation": "eastus2euap",
        "nfviType": "AzureArcKubernetes",
        "nfviId": "/subscriptions/4a0479c0-b795-4d0f-96fd-c7edd2a2928f/resourcegroups/ashutosh_test_rg/providers/microsoft.extendedlocation/customlocations/ashutosh_test_cl",
        "deploymentValues": "",
        "roleOverrideValues": [
            "{\"name\":\"hellotest\",\"deployParametersMappingRuleProfile\":{\"helmMappingRuleProfile\":{\"options\":{\"installOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"1\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"4\",\"skipUpgrade\":\"true\"}}}}}",
            "{\"name\":\"runnerTest\",\"deployParametersMappingRuleProfile\":{\"helmMappingRuleProfile\":{\"options\":{\"installOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"5\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"5\"}}}}}"
        ]
    }
}

Spiegazione dell'esempio

• NfApplication: hellotest
  • Il skipUpgrade flag è abilitato. Se la richiesta di aggiornamento per hellotest soddisfa i criteri di controllo preliminare, l'aggiornamento viene ignorato.
• NfApplication: runnerTest
  • Il skipUpgrade flag non è specificato. Pertanto, runnerTest esegue un aggiornamento Helm tradizionale a livello di cluster, anche se vengono soddisfatti i criteri di controllo preliminare.