Partager via

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

  • Article

Vue d’ensemble

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 aux utilisateurs finaux d’exécuter en toute sécurité des mises à niveau complexes de charges de travail CNF hébergées sur Azure Operator Nexus, conformément aux exigences d’ISSU (mise à niveau logicielle en cours de service) du partenaire, 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).

Introduction

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.

Approche de la mise à niveau

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.
  • Les NfApps avec le paramètre « applicationEnabled » définies pour la désactivation sont ignorées.
  • Les NfApps déployées, mais non référencées par la nouvelle NFDV, sont supprimées.
  • 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.

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 les tests Helm autonomes, le paramètre rollbackOnTestFailure est respecté. Avec rollbackOnTestFailure/true, le graphique en échec est restauré. Avec rollbackOnTestFailure/false, aucune restauration n’est exécutée.

Prérequis

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

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

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.

Utilisation 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é. Vous pouvez l’utiliser pour exclure des opérations de NfApp pendant le déploiement d’une 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.

{ 
      "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. Ces roleOverrideValues peuvent inclure des paramètres qui ne sont pas par défaut pour 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"
  ]
}

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 qui ne sont pas par défaut pour 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\"}}"
  }
}

Exemple de modèle ARM NF

Le modèle ARM NF est utilisé par l’opérateur pour envoyer la ou les variables roleOverrideValues, définies par la 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.

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

Prise en charge des mises à niveau de service

Azure Operator Service Manager, lorsque cela est possible, prend en charge les mises à niveau de service, une méthode de mise à niveau qui fait avancer une version de déploiement sans interrompre le service. Toutefois, la possibilité de mettre à niveau sans interruption un service donné est une fonctionnalité du service lui-même. Consultez d’autres informations auprès de l’éditeur du service pour comprendre les fonctionnalités de mise à niveau dans le service.

Objectifs prospectifs

Azure Operator Service Manager poursuit le développement de l’ensemble de fonctionnalités Pratiques de mise à niveau sécurisées et améliore les services de mise à jour offerts. Les fonctionnalités suivantes sont à l’examen actuellement en vue d’une disponibilité future :

  • 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 une restauration de NFDV en cas d’échec : en fonction de l’indicateur, restaurez toutes les NfApps terminées en cas d’échec.
  • Exécuter de manière asynchrone : possibilité d’exécuter plusieurs opérations de NfApp à la fois.
  • Télécharger des images : possibilité de précharger des images dans un référentiel en périphérie.
  • Cibler des graphiques pour la validation : possibilité d’exécuter un test Helm uniquement sur une NfApp spécifique.