Afficher en anglais

Partage via

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

  • Article

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 à un utilisateur final d’exécuter en toute sécurité des mises à niveau complexes des charges de travail CNF (Container Network Function) hébergées sur Azure Operator Nexus, en conformité avec les exigences de mise à niveau logicielle du partenaire (ISSU), le cas échéant. Recherchez les futurs articles de ces services pour développer les fonctionnalités et capacités des pratiques de mise à niveau sécurisées (SUP).

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

Un service réseau donné pris en charge par Azure Operator Service Manager sera composé d’une à plusieurs fonctions réseau basées sur un conteneur (CNF) qui, au fil du temps, nécessitera des mises à jour logicielles. Pour chaque mise à jour, il est nécessaire d’exécuter une à plusieurs opérations Helm, ce qui met à niveau des applications de fonction réseau (NfApps) dépendantes dans un ordre particulier, d’une manière qui a le moins d’impact sur le service réseau. Sur Azure Operator Service Manager, les pratiques de mise à niveau sécurisées (SUP) constituent un ensemble de fonctionnalités qui peuvent automatiser les opérations CNF requises pour mettre à jour un service réseau sur Azure Operator Nexus.

  • Mise à jour Reput de service réseau de site (SNS) : exécutez une opération de mise à niveau Helm dans toutes les NfApps dans la version de définition de fonction réseau (NFDV).
  • Plateforme Nexus : prise en charge des opérations Reput SNS sur des cibles de plateforme Nexus.
  • Délais d’expiration des opérations : possibilité de définir des délais d’expiration opérationnels pour chaque opération de NfApp.
  • Opérations synchrones : possibilité d’exécuter une opération de NfApp en série à la fois.
  • Pause en cas d’échec : en fonction de l’indicateur, définissez le comportement d’échec pour restaurer uniquement l’opération 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.
  • Reput de SNS refactorisé : méthodes améliorées, ajoute un ordre de mise à jour et une vérification des nettoyages.
  • Améliorer le contrôle des options de mise à niveau : exposez plus efficacement des paramètres.
  • Ignorer une NfApp en cas d’absence de modification : ignorez le traitement de NfApps ayant un résultat sans changement.
  • Exécuter la restauration au niveau NF en cas d’échec : en fonction de l’indicateur, restaurez toutes les NfApps terminées en cas d’échec.
  • 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 réseau de site Azure Operator Service Manager (SNS), l’Operator exécute une demande de mise à jour Reput 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 elle apparaît ou éventuellement dans l’ordre défini par le paramètre UpdateDependsOn.

Pour chaque NfApp, la demande de mise à jour Reput prend en charge l’augmentation d’une version de graphique Helm, l’ajout ou la suppression des valeurs Helm et/ou l’ajout ou la suppression de NfApps. Vous pouvez définir les délais d’expiration par NfApp, en fonction des runtimes autorisés connus, mais les NfApps peuvent uniquement être traitées dans un ordre en série, l’une après l’autre. La mise à jour Reput implémente la logique de traitement suivante :

  • Les NfApps sont traitées en suivant l’ordre updateDependsOn ou dans l’ordre séquentiel de leur apparition.
  • NfApps avec le paramètre applicationEnabled défini pour désactiver sont ignorés.
  • NfApps avec le paramètre skipUpgrade défini sur activé sont ignorés si aucune modification n’a été détectée.
  • Les applications NFApp qui sont communes entre l’ancien et le nouveau NFDV sont mises à niveau.
  • Les applications NFApps qui se trouvent uniquement dans le nouveau NFDV sont installées.
  • Les NfApps déployées, mais non référencées par la nouvelle NFDV, sont supprimées.

Pour garantir les résultats, le test de NfApp est pris en charge en utilisant Helm, qu’il s’agisse de tests antérieurs ou postérieurs à la mise à niveau Helm ou de tests Helm autonome. Pour les échecs antérieurs ou postérieurs aux tests, le paramètre atomique est respecté. Avec atomique/true, le graphique en échec est restauré. Avec atomique/false, aucune restauration n’est exécutée. 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

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 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 affecté 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 application NfApp avec plusieurs réplicas, AOSM respecte les paramètres du profil de déploiement pour l’option de déploiement 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 en utilisant Azure Operator Service Manager, traitez les exigences suivantes avant l’exécution de la mise à niveau pour optimiser le temps passé à tenter la mise à niveau.

  • Intégrez les artifacts mis à jour en utilisant des workflows de concepteur et/ou d’éditeur.

    • L’éditeur, le magasin, le groupe de conception de service réseau (NSDg) et le groupe de conception de fonction réseau (NFDg) sont statiques et ne nécessitent aucune modification.
      • Un nouveau manifeste d’artefact est nécessaire pour stocker les nouvelles images et les nouveaux graphiques. Pour découvrir plus d’informations détaillées, consultez la documentation sur l’intégration relative au chargement de nouvelles images et de nouveaux graphiques.
    • Une nouvelle NFDV et une nouvelle version de conception de service réseau (NSDV) sont nécessaires sous le groupe de conception de service réseau et le groupe de conception de fonction réseau existants.
      • Nous abordons les modifications de base apportées à la NFDV dans la section étape par étape.
      • 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 Azure Operator Service Manager.

Créer une ressource NFDV

Pour les nouvelles versions de NFDV, il doit s’agir d’un format SemVer valide où seules des valeurs d’incrémentation plus élevées de patch et de mises à jours mineures de versions sont autorisées. Une version de NFDV antérieure n’est pas autorisée. Pour une CNF déployée en utilisant NFDV 2.0.0, la nouvelle NFDV peut être une version 2.0.1 ou 2.1.0, mais pas 1.0.0 ou 3.0.0.

Mise à jour de nouveaux paramètres de 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. Vous pouvez également ajouter de nouvelles NfApps non existantes dans une version déployée.

Mettre à jour une NFDV pour un ordre de NfApp souhaité

UpdateDependsOn est un paramètre de NFDV utilisé pour spécifier l’ordre des NfApps pendant des opérations de mise à jour. Si le paramètre UpdateDependsOn n’est pas fourni, un ordre en série des applications CNF, comme affiché dans la NFDV, est utilisé.

Mettre à jour une NFDV pour un comportement de mise à niveau souhaité

Veillez à définir les délais d’expiration de l’application CNF, le paramètre atomique et le paramètre rollbackOnTestFailure souhaités. 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’exécution de l’opération Reput peut prendre du temps (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. Vous pouvez définir ce paramètre sur la valeur false quand une NfApp doit être ignorée. Ce paramètre peut être utile quand une NfApp n’exige 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.

Ignorer nfApps à l’aide d’applicationEnablement

Dans la ressource de NFDV, sous deployParametersMappingRuleProfile, il existe la propriété applicationEnablement de type enum qui comprend les valeurs : Inconnu, Activé ou Désactivé. Il peut être utilisé pour exclure les opérations NfApp pendant le déploiement de la fonction réseau (NF).

Modifications d’éditeur

Pour la propriété applicationEnablement, l’éditeur dispose de deux options : fournir une valeur par défaut ou la paramétriser.

Échantillon de NFDV

NFDV est utilisé par l’éditeur pour définir les valeurs par défaut pour applicationEnablement.

JSON 
{ 
      "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"
    }
}

Exemple de ressource de schéma de groupe de configurations (CGS)

Le CGS est utilisée par l’éditeur pour exiger que la ou les variables roleOverrideValues soient fournies par l’opérateur lors du runtime. RoleOverrideValues peut inclure des paramètres non définis pour applicationEnablement.

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

Modifications d’opérateur

Les opérateurs héritent des valeurs applicationEnablement par défaut définies par NFDV. Si applicationEnablement est paramétrable dans le CGS, elle doit alors être transmise via la propriété deploymentValues lors du runtime.

Exemple de ressource de valeur de groupe de configurations (CGV)

La CGV est utilisée par l’opérateur pour définir la ou les variables roleOverrideValues lors du runtime. RoleOverrideValues inclut des paramètres non définis pour applicationEnablement.

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

Exemple de modèle ARM NF

Le modèle ARM NF est utilisé par l’opérateur pour envoyer la variable roleOverrideValues, définie par CGV, au fournisseur de ressources (RP). L’opérateur peut modifier le paramètre applicationEnablement dans la CGV, si nécessaire, et soumettre à nouveau le même modèle ARM NF pour modifier le comportement entre les itérations.

JSON 
{
  "$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')]"
        ]
      }
    }
  ]
}

Ignorer les NfApps qui n’ont 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 :

  1. L'état de déploiement nfApplication est réussi.
  2. Il n’existe aucune modification dans le nom ou la version du graphique Helm.
  3. Aucune modification n’est apportée aux 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.

JSON 
{
    "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.