Partager via


Exécuter des tests après l’installation ou la mise à niveau

Cet article décrit comment Azure Operator Service Manager (AOSM) peut exécuter des tests sur des fonctions réseau (NFs) dans le cadre des opérations d’installation ou de mise à niveau. Lorsqu’elle est activée, chaque application de fonction réseau (nfApp) est testée après l’installation ou la mise à niveau du composant. Un résultat réussi sur tous les tests nfApp est requis pour que l’état de l’opération NF se termine correctement.

Vue d’ensemble

Dans le cadre du programme de mise à niveau sécurisée, AOSM prend en charge l’utilisation de tests Helm en tant qu’étape de mise à niveau pendant les opérations d’installation ou de mise à niveau de la fonction réseau. Le flux de travail suivant décrit la logique utilisée par AOSM lors de l’inclusion de cette couche supplémentaire de validation :

  • Les utilisateurs créent leurs propres tests et les incluent dans le package Helm pendant l’intégration de NF.
  • Uniquement lorsqu’il est activé, AOSM exécute ces tests Helm sur chaque nfApp.
  • En cas de réussite des tests, AOSM passe à l’application nfApp suivante.
  • En cas d’échec de test, AOSM respecte rollbackOnTestFail pour déterminer si nfApp est restaurée.
  • L’opération NF parente se termine par un échec si nfApp échoue un test configuré.
  • En cas d’échec parent, AOSM respecte la méthode configurée du contrôle d’échec NF, pause-on-failure ou rollback-on-failure.

Remarque

Le test Helm n’est pris en charge que dans le cadre de l’opération d’installation ou de mise à niveau et ne peut pas être exécuté autonome.

Création de tests Helm

L’éditeur est responsable de la création des tests Helm lors de la construction des graphiques Helm. Les tests Helm sont définis dans le graphique Helm sous le dossier : <ChartName>/Templates/. Chaque test inclut une définition de travail qui spécifie un environnement de conteneur et une commande à exécuter. L’environnement de conteneur doit se quitter correctement pour qu’un test soit considéré comme un succès. La définition de tâche doit inclure l’annotation de hook de test Helm (helm.sh/hook: test) à reconnaître comme un test par Helm.

Activer les tests Helm pendant les opérations

AOSM fournit un ensemble d’options d’installation et de mise à niveau configurables pour chaque application nfApp. Ces options existantes sont étendues avec un nouveau paramètre testOptions . Avec ce paramètre, l’utilisateur peut spécifier testOptions paramètres par nfApp et par type d’opération. Le paramètre testOptions prend en charge les paramètres suivants :

  • enable
    • Active ou désactive le test Helm sur une application nfApp une fois l’installation ou la mise à niveau terminée.
    • La valeur par défaut est False.
  • timeout
    • Prend une valeur qui représente le délai d’expiration du test en minutes.
    • La valeur par défaut est 20 minutes.
  • rollbackOnTestFailure
    • Active ou désactive la restauration sur l’échec de test nfApp helm.
    • La valeur par défaut est true.
  • filter
    • Permet à une méthode d’exécuter uniquement un sous-ensemble de tests. Accepte une liste de chaînes, où chaque chaîne de la liste représente un test à exécuter.
    • La valeur par défaut n’est pas de filtre et tous les tests sont exécutés.

Exposition du contrôle de test Helm via des paramètres

AOSM prend déjà en charge les paramètres de charge utile NF installOptions et upgradeOptions pour chaque nfApp sous roleOverrideValues. Ces paramètres sont étendus pour inclure de nouveaux paramètres testOptions. L’exposition de ces nouveaux paramètres permet à l’opérateur de contrôler le comportement de mise à niveau au moment de l’exécution. Consultez les trois exemples suivants illustrant l’utilisation de testOptions.

exemple d’échappement roleOverrideValues

Voici un exemple d’échappement roleOverrideValues avec testOptions sous installOptions et upgradeOptions pour un composant nommé application1. Cet exemple utilise un filter, pour exécuter uniquement des tests qui correspondent à la chaîne fournie, utilise un délai d’attente personnalisé et active rollbackOnTestFailures.

"roleOverrideValues": [  
"{\"name\":\"application1\",\"deployParametersMappingRuleProfile\":{\"helmMappingRuleProfile\":{\"helmPackageVersion\":\"2.1.3\",\"values\":\"{\\\"roleOneParam\\\":\\\"roleOneOverrideValue\\\"}\",\"options\":{\"installOptions\":{\"atomic\":\”true\”,\"wait\":\"true\",\"timeout\":\"30m\",\”testOptions\”:{\”enable\”:\”true\”,\”timeout\”:\”15\”,\”rollbackOnTestFailure\”:\”true\”,\”filter\”:[\”test1\”,\”test2\”,\”test3\”]}},\"upgradeOptions\":{\"atomic\": \”true\”,\"wait\":\"true\",\"timeout\":\"30\", \”testOptions\”:{\”enable ”:\”true\”,\”timeout\”:\”15\”,\”rollbackOnTestFailure\”:\”true\”,\” filter \”:[\”test1\”,\”test2\”,\”test3\”]}}}}}}"]

exemple non échappé roleOverrideValues

Voici un exemple non échappé roleOverrideValues charge utile NF avec testOptions sous installOptions et upgradeOptions pour un composant nommé hellotest. Cet exemple utilise une filter pour exécuter uniquement des tests qui correspondent à la chaîne fournie, utilise un délai d’attente personnalisé et active rollbackOnTestFailures.

"roleOverrideValues": ["{
   "name":"hellotest",
    "deployParametersMappingRuleProfile": {
      "helmMappingRuleProfile": {
       "options": {
        "installOptions": {
         "atomic":"true",
         "wait":"true",
         "timeout":"1"
         “testOptions”: {
          “enable”: “true”,
          “timeout”: “10”,
          “rollbackOnTestFailure”: “true”,
          "filter”: [“test1”, “test2”]	} },
        "upgradeOptions": {
         "atomic":"true",
         "wait":"true",
         "timeout":"2",
         “testOptions”: {
          “enable”: “true”,
          “timeout”: “10”,
          “rollbackOnTestFailure”: “true”,
          "filter”: [“test1”, “test2”] } } } } } }"
]

Exemple de charge utile NF

Voici un exemple de charge utile NF avec testOptions sous installOptions et upgradeOptions pour un composant nommé application1. Cet exemple utilise un filter pour exécuter uniquement des tests qui correspondent à la chaîne fournie, utilise un délai d’attente personnalisé et active rollbackOnTestFailures.

{
    "location": "eastus",
    "properties": {
        "publisherName": "testVendor",
        "publisherScope": "Public",
        "networkFunctionDefinitionGroupName": "testnetworkFunctionDefinitionGroupName",
        "networkFunctionDefinitionVersion": "1.0.1",
        "networkFunctionDefinitionOfferingLocation": "eastus",
        "nfviType": "AzureArcKubernetes",
        "nfviId": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/testResourceGroup/providers/Microsoft.ExtendedLocation/customLocations/testCustomLocation",
        "allowSoftwareUpdate": true,
        "deploymentValues": "{\"releaseName\":\"testReleaseName\",\"namespace\":\"testNamespace\",\"wait\":\"false\"}",
       "roleOverrideValues": [ 
            "{\"name\":\"application1\",\"deployParametersMappingRuleProfile\":{\"helmMappingRuleProfile\":{\"helmPackageVersion\":\"2.1.3\",\"values\":\"{\\\"roleOneParam\\\":\\\"roleOneOverrideValue\\\"}\",\"options\":{\"installOptions\":{\"atomic\":\”true\”,\"wait\":\"true\",\"timeout\":\"30m\",\” testOptions \”:{\” enable \”:\”true\”,\” timeout\”:\”15\”,\”rollbackOnTestFailure\”:\”true\”,\” filter \”:[\”test1\”,\”test2\”,\”test3\”]}},\"upgradeOptions\":{\"atomic\": \”true\”,\"wait\":\"true\",\"timeout\":\"30\", \” testOptions \”:{\” enable \”:\”true\”,\” timeout\”:\”15\”,\”rollbackOnTestFailure\”:\”true\”,\” filter \”:[\”test1\”,\”test2\”,\”test3\”]}}}}}}" 
        ]
    }
}