Démarrage avec les pratiques de mise à niveau sécurisées

Cet article présente les pratiques de mise à niveau sécurisées (SUP) d’Azure Operator Service Manager (AOSM). Cet ensemble de fonctionnalités permet des mises à niveau vers une fonction réseau de conteneur complexe (CNF) hébergée sur Azure Operator Nexus. Ces mises à niveau prennent généralement en charge les méthodes et exigences de mise à niveau logicielle du partenaire in Service (ISSU). Bien que cet article présente des concepts de base, recherchez d’autres articles qui s’étendent sur les fonctionnalités et fonctionnalités avancées de SUP.

Présentation des mises à niveau sécurisées

Un service réseau donné pris en charge par AOSM, composé d’un à plusieurs cnFs, inclut des composants qui, au fil du temps, nécessitent des modifications logicielles et/ou de configuration. Pour apporter ces modifications au niveau du composant, il est nécessaire d’exécuter une à de nombreuses opérations helm, de mettre à niveau chaque application de fonction réseau (nfApp) dans un ordre particulier et d’une manière qui a un impact minimum sur le service réseau. Les pratiques de mise à niveau sécurisée AOSM appliquent les fonctionnalités de haut niveau suivantes pour gérer les exigences de processus de mise à niveau et de flux de travail :

• Prise en charge de Reput de SNS : exécutez l’opération de mise à niveau Helm sur toutes les nfApps dans la version de conception de fonction réseau (NFDV).
• Plateforme Nexus : prise en charge des opérations Reput SNS sur des cibles de plateforme Nexus.
• Délai d’expiration des opérations : possibilité de définir des délais d’attente opérationnels pour chaque opération nfApp.
• Opérations synchrones : possibilité d’exécuter une opération nfApp série à la fois.
• Définir un ordre de contrôle différent pour l'installation et la mise à niveau de l'application nfApp.
• Pause en cas d'échec - Le comportement par défaut est de faire une pause après une défaillance lors d'une opération nfApp.
• Restauration en cas d’échec : comportement facultatif, restauration terminée nfApps avant l’échec de nfApp.
• Validation de test de graphique unique : exécution d’une opération de test Helm après une création ou une mise à jour.
• Ignorer une nfApp en cas d’absence de modification : ignorez le traitement de nfApps ayant un résultat sans changement.
• Préchargement d’images : possibilité de précharger des images dans un référentiel edge.

Approche de mise à niveau sécurisée

Pour mettre à jour un service de réseau de site AOSM existant (SNS), l’opérateur exécute une demande de renom sur la ressource SNS déployée. Dans le service de réseau de site (SNS) contenant des CNF avec plusieurs nfApps, la demande est distribuée sur toutes les nfApps définies dans la version de définition de fonction réseau (NFDV). Par défaut, dans l’ordre dans lequel ils apparaissent, ou éventuellement dans l’ordre défini par updateDependsOn paramètre.

Pour chaque nfApp, la demande de reput prend en charge différentes modifications, notamment l’augmentation d’une version de graphique Helm, l’ajout/la suppression de valeurs helm et/ou l’ajout/suppression de nfApps. Bien que les délais d’expiration puissent être définis par nfApp, en fonction des runtimes autorisés connus, les nfApps ne peuvent être traités que dans l’ordre série, l’un après l’autre. La mise à jour Reput implémente la logique de traitement suivante :

• Les nfApps sont traités en suivant updateDependsOn l’ordre ou dans l’ordre séquentiel qu’ils apparaissent.
• Les nfApps dont le paramètre applicationEnabled est défini pour désactiver sont ignorées.
• nfApps avec le paramètre skipUpgrade défini sur enabled sont ignorées si aucune modification n’a été détectée.
• nfApps qui sont communs entre l’ancien et le nouveau NFDV sont mis à niveau à l’aide helm upgradede .
• nfApps qui sont uniquement dans le nouveau NFDV sont installés à l’aide helm installde .
• les nfApps déployés, mais non référencés par le nouveau NFDV, sont supprimés à l’aide helm deletede .

Pour garantir les résultats, les tests nfApp sont pris en charge à l’aide de méthodes helm, soit des tests déclenchés par helm avant ou post-crochets, soit à l’aide du hook de test helm autonome. En cas d’échec de pré ou de post-crochet, le atomic paramètre est respecté. Avec atomique/true, le graphique en échec est restauré. Avec atomique/false, aucune restauration n’est exécutée. Pour l’échec du hook de test helm autonome, il rollbackOnTestFailure est honoré, suivant une logique similaire à atomique. Pour plus d’informations sur les tests Helm autonomes, consultez l’article suivant : Exécuter des tests après l’installation ou la mise à niveau

Lorsqu’un échec d’opération nfApp se produit et qu’après l’échec de nfApp est géré via atomic ou rollbackOnTestFailure par paramètres, l’opérateur peut contrôler le comportement de gestion des nfApps modifiés avant l’échec de nfApp. Avec la pause sur défaillance, l’opérateur peut forcer AOSM à s’arrêter après avoir adressé l’application nfApp ayant échoué, en conservant l’environnement de version mixte. Avec la restauration en cas de défaillance, l’opérateur peut forcer AOSM à restaurer nfApp antérieur, en restaurant l’instantané d’environnement d’origine. Pour plus d’informations sur le contrôle du comportement d’échec de mise à niveau, consultez l’article suivant : Contrôle du comportement d’échec de mise à niveau

Considérations relatives aux mises à niveau dans le service

Azure Operator Service Manager prend généralement en charge les mises à niveau de service, une méthode de mise à niveau qui avance une version de déploiement sans interrompre le service en cours d’exécution. Certaines considérations relatives au propriétaire de la fonction réseau sont nécessaires pour garantir le comportement approprié d’AOSM pendant les opérations d’émission.

• Où AOSM effectue une mise à niveau sur un ensemble ordonné de plusieurs nfApps, AOSM commence par mettre à niveau ou crée toutes les nouvelles nfApps, puis supprime tous les anciens nfApps. Cette approche garantit que le service n’est pas impacté tant que tous les nouveaux nfApps ne sont pas prêts, mais nécessite une capacité de plateforme supplémentaire pour l’hébergement temporaire de nfApps anciens et nouveaux.
• Lorsque AOSM met à niveau une nfApp avec plusieurs réplicas, AOSM respecte les paramètres du profil de déploiement pour l’option de roulement ou de recréation. Lorsque le déploiement est utilisé, exposez les valeurs maxUnavailable et maxSurge en tant que paramètres CGS, qui peuvent ensuite être définis via l’opérateur CGV au moment de l’exécution.

En fin de compte, la possibilité pour un service donné d’être mis à niveau sans interruption est une fonctionnalité du service lui-même. Pour plus d’informations, consultez l’éditeur de service pour comprendre les fonctionnalités de mise à niveau dans le service et vérifier qu’elles sont alignées sur les options comportementales AOSM appropriées.

Conditions préalables à la mise à niveau sécurisée

Lors de la planification d’une mise à niveau à l’aide d’AOSM, répondez aux exigences suivantes à l’avance de l’exécution de la mise à niveau, afin d’optimiser le temps passé à tenter et à garantir la réussite de la mise à niveau.

• Intégrez les artifacts mis à jour en utilisant des workflows de concepteur et/ou d’éditeur.
  • Dans la plupart des cas, utilisez l’éditeur existant pour héberger de nouveaux artefacts de version.
    • L’utilisation d’un éditeur existant prend en charge la mise à jour par helm upgrade d’un SNS vers une version différente.
    • L’utilisation d’un nouvel éditeur nécessite une helm delete sur le SNS actuel, puis une helm install pour la nouvelle version de SNS.
  • Le magasin d’artefacts, le groupe de conception de service réseau (NSDG) et le groupe de conception de fonction réseau (NFDG) sont immuables et ne peuvent pas changer.
    • La modification de l’une de ces ressources nécessite le déploiement d’un nouveau SNS.
  • Un nouveau manifeste d’artefact est nécessaire pour stocker les nouvelles images et les nouveaux graphiques.
    • Consultez la documentation d’intégration pour plus d’informations sur le chargement de nouveaux graphiques et images.
  • Un nouveau NFDV, et éventuellement une nouvelle version de conception de service réseau (NSDV), est nécessaire.
    • Les modifications du NFDV peuvent être complexes. Nous abordons uniquement les modifications de base de cet article.
    • Une nouvelle NSDV est uniquement requise si une nouvelle version de schéma de groupe de configurations (CGS) est mise en place.
  • Si nécessaire, un nouveau CGS.
    • Requis si une mise à niveau introduit de nouveaux paramètres de configuration exposés.

• Créez des artifacts mis à jour en utilisant un workflow Operator.
  • Le cas échéant, créez de nouvelles valeurs de groupe de configurations (CGV) en fonction du nouveau CGS.
  • Réutilisez et élaborez une charge utile en confirmant les objets de service réseau de site et le site existants.
• Mettez à jour les modèles pour veiller à ce que les paramètres de mise à niveau soient définis en fonction de la confiance dans la mise à niveau et du comportement d’échec souhaité.
  • Les paramètres utilisés pour la production peuvent supprimer les détails des échecs, alors que les paramètres utilisés pour le débogage ou les tests peuvent choisir de les exposer.

Procédure de mise à niveau sécurisée

Suivez le processus suivant pour déclencher une mise à niveau avec AOSM.

• Créer une ressource NFDV
  • Pour les nouvelles versions de NFDV, il doit être au format SemVer valide. La nouvelle version peut être une mise à niveau, une valeur supérieure par rapport à la version déployée ou une rétrogradation, une valeur inférieure par rapport à la version déployée. La nouvelle version peut varier selon les valeurs majeures, mineures ou correctives.
• Mettre à jour les nouveaux paramètres NFDV
  • Vous pouvez mettre à jour des versions de graphique Helm ou vous pouvez mettre à jour ou paramétrer des valeurs Helm, le cas échéant. Les nouvelles applications nfApps peuvent également être ajoutées là où elles n’existaient pas dans la version déployée.
• Mettre à jour une NFDV pour un ordre de nfApp souhaité
  • UpdateDependsOn est un paramètre NFDV utilisé pour spécifier l’ordre des nfApps pendant les opérations de mise à jour. Si updateDependsOn n'est pas fourni, le classement en série des applications CNF, comme indiqué dans le NFDV, est utilisé.
• Mettre à jour le modèle ARM pour le comportement de mise à niveau souhaité
  • Veillez à définir l'application CNF timeout souhaitée, le paramètre atomic, et le paramètre rollbackOnTestFailure. Il peut être utile de modifier ces paramètres au fil du temps à mesure que davantage de confiance est acquise dans la mise à niveau.
• Problème de Reput de SNS
  • Une fois l’intégration terminée, l’opération Reput est soumise. En fonction du nombre, de la taille et de la complexité des nfApps, l'opération de repositionnement pourrait prendre un certain temps pour se terminer (plusieurs heures).
• Examiner les résultats de Reput
  • Si l’opération Reput signale un résultat correct, la mise à niveau est terminée et l’utilisateur doit valider l’état et la disponibilité du service. Si l’opération Reput signale un échec, suivez les étapes de la section sur la récupération d’un échec de mise à niveau pour continuer.

Procédure de nouvelle tentative de mise à niveau sécurisée

En cas d’échec de la mise à jour Reput, le processus suivant peut être suivi pour réessayer l’opération.

• Diagnostiquer une nfApp en échec
  • Résolvez la cause racine de l’échec de la nfApp en analysant les journaux d’activité et d’autres informations sur le débogage.
• Ignorer manuellement des graphiques terminés
  • Après avoir corrigé la nfApp en échec et avant d’essayer une nouvelle tentative de mise à niveau, envisagez de modifier le paramètre applicationEnablement pour accélérer le comportement de nouvelle tentative. Ce paramètre peut être défini sur false, où une application nfApp doit être ignorée. Ce paramètre peut être utile lorsqu’une application nfApp ne nécessite pas de mise à niveau.
• Problème de nouvelle tentative Reput de SNS (répéter jusqu’à la réussite)
  • Par défaut, l’opération Reput effectue une nouvelle tentative des nfApps dans l’ordre de mise à jour déclaré, sauf si elles sont ignorées en utilisant l’indicateur applicationEnablement.

Contrôler les délais d’expiration avec installOptions et UpgradeOptions

Lorsqu’une opération SNS démarre une helm install ou une helm upgrade, une valeur de délai d’expiration par défaut de 27 minutes est utilisée. Bien que cette valeur puisse être personnalisée au niveau de la fonction réseau globale (NF), nous vous recommandons de personnaliser cette valeur au niveau NF du composant à l’aide roleOverrideValues du modèle de charge utile NF. En outre, l’exposition de l’élément roleOverrideValues CGS/CGV autorise le contrôle par l’opérateur au moment de l’exécution. L’exemple suivant illustre les paramètres installOptions et upgradeOptions pris en charge appliqués sur deux composants nfApp ;

{
  "roleOverrideValues": [
    {
      "name": "nfApplication1",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            } } } } },
    {
      "name": "nfApplication2",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            } } } } }
  ]
}

Ignorer nfApps à l’aide d’applicationEnablement

Dans la ressource NFDV, sous deployParametersMappingRuleProfile, il existe une propriété prise en charge applicationEnablement de type enum, qui prend les valeurs Unknown, Enabled ou disabled. Il peut être utilisé pour exclure manuellement les opérations nfApp pendant le déploiement de fonction réseau. L’exemple suivant illustre une méthode générique pour paramétrer applicationEnablement en tant que valeur incluse dans roleOverrideValues la propriété.

Modifications apportées au modèle NFDV

Bien qu’aucune modification NFDV ne soit nécessaire, le serveur de publication peut éventuellement utiliser le NFDV pour définir une valeur par défaut pour la applicationEnablement propriété. La valeur par défaut est utilisée, sauf si elle a été modifiée via roleOverrideValues. Utilisez le modèle NFDV pour définir une valeur par défaut pour applicationEnablement. L’exemple suivant définit enabled l’état comme valeur par défaut pour hellotest networkfunctionApplication.

      "location":"<location>", 
      "properties": {
      "networkFunctionTemplate": {
        "networkFunctionApplications": [
            "deployParametersMappingRuleProfile": {
              "applicationEnablement": "Enabled"
            },
            "name": "hellotest"
        ],
        "nfviType": "AzureArcKubernetes"
        },
      }

Pour gérer la applicationEnablement valeur plus dynamiquement, l’opérateur peut passer une valeur en temps réel à l’aide de la propriété de modèle roleOverrideValues NF. Bien qu’il soit possible pour l’opérateur de manipuler directement le modèle NF, paramétrez plutôt le roleOverrideValues, afin que les valeurs puissent être transmises via un modèle CGV au moment de l’exécution. Les exemples suivants illustrent les modifications nécessaires apportées aux modèles CGS, NF et enfin au CGV.

Modifications du modèle CGS

Le modèle CGS doit être mis à jour pour inclure une déclaration de variable pour chaque ligne à paramétrer sous roleOverrideValues. L’exemple suivant illustre trois valeurs de remplacement.

        "roleOverrideValues0": {
          "type": "string"        
        },    
        "roleOverrideValues1": {
          "type": "string"        
        },        
        "roleOverrideValues2": {
          "type": "string"
        }

Modifications apportées au modèle de charge utile NF

Le modèle NF doit être mis à jour de trois façons. Tout d’abord, le paramètre de configuration implicite doit être défini en tant qu’objet de type. Deuxièmement, roleOverrideValues0, roleOverrideValues1et roleOverrideValues2 doit être déclaré en tant que variables mappées au paramètre de configuration. Troisièmement, roleOverrideValues0, roleOverrideValues1et roleOverrideValues2 doit être référencé pour la substitution dans roleOverrideValues l’ordre approprié et suivant la syntaxe appropriée.

  "parameters": {
    "config": {
      "type": "object",
      "defaultValue": {}
    }
  }
  "variables": {
    "roleOverrideValues0": "[string(parameters('config').roleOverrideValues1)]",
    "roleOverrideValues1": "[string(parameters('config').roleOverrideValues1)]",
    "roleOverrideValues2": "[string(parameters('config').roleOverrideValues2)]"
  },
  "resources": [
  {
<snip>
     "roleOverrideValues": [
          "[variables('roleOverrideValues0')]",
          "[variables('roleOverrideValues1')]",
          "[variables('roleOverrideValues2')]"
        ]
   }

Modifications apportées au modèle CGV

Le modèle CGV peut maintenant être mis à jour pour inclure le contenu de chaque variable à remplacer dans roleOverrideValues la propriété au moment de l’exécution. L’exemple suivant définit rollbackEnabled sur vrai, suivi par des réglages de remplacement pour hellotest et hellotest1 nfApplications.

{
    "roleOverrideValues0": "{\"nfConfiguration\":{\"rollbackEnabled\":true}}",
    "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\"}}"
}

Avec ce cadre en place, l'opérateur peut gérer n'importe lequel des roleOverrideValues par de simples mises à jour de la CGV, suivies de l'attachement de cette CGV à l'opération SNS souhaitée.

Ignorer les applications nfApps qui n’ont subi aucune modification

La fonctionnalité skipUpgrade est conçue pour optimiser le temps nécessaire aux mises à niveau CNF. Lorsque l’éditeur active cet indicateur dans roleOverrideValues sous upgradeOptions, la couche de service AOSM effectue certaines vérifications préalables pour déterminer si une mise à niveau pour un élément spécifique nfApplication peut être ignorée. Si tous les critères de vérification préalable sont remplis, la mise à niveau est ignorée pour cette application. Sinon, une mise à niveau est exécutée au niveau du cluster.

Critères de pré-vérification

Une mise à niveau peut être ignorée si toutes les conditions suivantes sont remplies :

• L'état de déploiement nfApplication est réussi.
• Il n’existe aucune modification dans le nom ou la version du graphique Helm.
• Il n'y a pas de changement dans les valeurs Helm.

Activation ou désactivation de la fonctionnalité SkipUpgrade

La fonctionnalité skipUpgrade est désactivée par défaut. Si ce paramètre facultatif n’est pas spécifié roleOverrideValues sous upgradeOptions, les mises à niveau CNF continuent de manière traditionnelle, où nfApplications sont mises à niveau au niveau du cluster.

Activation de SkipUpgrade dans la ressource de fonction réseau

Pour activer la fonctionnalité SkipUpgrade via roleOverrideValues, reportez-vous à l’exemple suivant.

{
    "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\"}}}}}"
        ]
    }
}

Explication de l’exemple

• nfApplication : hellotest
  • L’indicateur skipUpgrade est activé. Si la demande de mise à niveau pour hellotest répond aux critères de pré-vérification, la mise à niveau est ignorée.
• nfApplication : runnerTest
  • L’indicateur skipUpgrade n’est pas spécifié. Par conséquent, runnerTest exécute une mise à niveau Helm traditionnelle au niveau du cluster, même si les critères de pré-vérification sont remplis.

Informations de référence sur l’option RoleOverrideValues

Rassembler tous les exemples de cet article et d’autres articles, la référence suivante illustre toutes les options actuellement prises en charge disponibles par le biais du roleOverrideValues mécanisme.

{
  "roleOverrideValues": [
    {
      "nfConfiguration": {
        "rollbackEnabled": "true"
      }
    },
    {
      "name": "nfApplication1",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "skipUpgrade": "true",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            }
          }
        }
      }
    },
    {
      "name": "nfApplication2",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "skipUpgrade": "true",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            }
          }
        }
      }
    }
  ]
}