Condividi tramite

Introduzione alle procedure di aggiornamento sicure

  • Articolo

Panoramica

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 aggiornamenti complessi dei carichi di lavoro CNF ospitati in Azure Operator Nexus, in conformità ai requisiti ISSU del partner, se applicabile. Cerca gli articoli futuri in questi servizi per ampliare le funzionalità e le funzionalità di SUP.

Introduzione

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.

Approccio di 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.
  • Le applicazioni NfApps con il parametro "applicationEnabled" impostato su disable vengono ignorati.
  • Le applicazioni NFApp distribuite, ma non a cui fa riferimento il nuovo NFDV, vengono eliminate.
  • 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.

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 i test Helm autonomi, è stato rispettato il parametro rollbackOnTestFailure. Con rollbackOnTestFailure/true, viene eseguito il rollback del grafico non riuscito. Con rollbackOnTestFailure/false, non viene eseguito alcun rollback.

Prerequisiti

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

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

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.

Come usare 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 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 le variabili roleOverrideValues vengano fornite da Operator in fase di esecuzione. Questi roleOverrideValues possono 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 definiti 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 le variabili 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 le variabili roleOverrideValues, impostate 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')]"
        ]
      }
    }
  ]
}

Supporto per negli aggiornamenti del servizio

Azure Operator Service Manager, se possibile, supporta gli aggiornamenti del servizio, un metodo di aggiornamento che avanza una versione di distribuzione senza interrompere il servizio. Tuttavia, la possibilità di aggiornare un determinato servizio senza interruzioni è una funzionalità del servizio stesso. Consultare ulteriormente il server di pubblicazione del servizio per comprendere le funzionalità di aggiornamento nel servizio.

Obiettivi di inoltro

Azure Operator Service Manager continua a crescere con il set di funzionalità procedure di aggiornamento sicuro e migliora i servizi di aggiornamento offerti. Le funzionalità seguenti sono attualmente in considerazione per la disponibilità futura:

  • 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 di NFDV in caso di errore: in base al flag, eseguire il rollback di tutte le NfApp completate in caso di errore.
  • Opera in modo asincrono: possibilità di eseguire più operazioni NfApp alla volta.
  • Scarica immagini: possibilità di precaricare le immagini nel repository perimetrale.
  • Grafici di destinazione per la convalida: possibilità di eseguire un test Helm solo in una specifica NfApp.