Ausführen von Tests nach der Installation oder dem Upgrade

Artikel
02/27/2025

In diesem Artikel wird beschrieben, wie Azure Operator Service Manager (AOSM) Tests für Netzwerkfunktionen (NF) als Teil von Installations- oder Upgradevorgängen ausführen kann. Wenn diese Option aktiviert ist, wird jede Netzwerkfunktionsanwendung (NFApp) getestet, nachdem die Installation oder das Upgrade der Komponente abgeschlossen ist. Ein erfolgreiches Ergebnis für alle NFApp-Tests ist erforderlich, damit der NF-Betriebsstatus erfolgreich abgeschlossen werden kann.

Übersicht

Im Rahmen des Programms für sichere Upgrades unterstützt AOSM die Verwendung von Helm-Tests als Kontrollschritt während der Installation oder des Upgrades von Netzwerkfunktionen. Der folgende Workflow beschreibt die von AOSM verwendete Logik, wenn diese zusätzliche Prüfungsebene eingeschlossen wird:

Benutzer erstellen ihre eigenen Tests und fügen sie beim NF-Onboarding in das Helm-Paket ein.
Nur wenn diese Option aktiviert ist, führt AOSM diese Helm-Tests für jede NFApp aus.
Nach einem erfolgreichen Test fährt AOSM mit der nächsten NFApp fort.
Wenn der Test fehlschlägt, berücksichtigt AOSM rollbackOnTestFail, um zu bestimmen, ob die NFApp zurückgesetzt wird.
Der übergeordnete NF-Vorgang wird mit einem Fehler beendet, wenn eine NFApp einen konfigurierten Test nicht besteht.
Wenn ein übergeordneter Vorgang fehlschlägt, berücksichtigt AOSM die konfigurierte Methode der NF-Fehlersteuerung, entweder pause-on-failure oder rollback-on-failure.

Hinweis

Der Helm-Test wird nur als Teil des Installations- oder Upgradevorgangs unterstützt und kann nicht eigenständig ausgeführt werden.

Erstellen von Helm-Tests

Der Herausgeber ist für die Erstellung der Helm-Tests während der Erstellung der Helm-Diagramme verantwortlich. Die Helm-Tests werden im Helm-Diagramm unter diesem Ordner definiert: <ChartName>/Templates/. Jeder Test enthält eine Auftragsdefinition, die eine Containerumgebung und einen auszuführenden Befehl angibt. Die Containerumgebung sollte erfolgreich beendet werden, damit ein Test als Erfolg angesehen wird. Die Auftragsdefinition muss die Hook-Anmerkung des Helm-Tests (helm.sh/hook: test) enthalten, damit dies von Helm als Test erkannt wird.

Aktivieren von Helm-Tests während des Betriebs

AOSM bietet eine Reihe konfigurierbarer Installations- und Upgradeoptionen für jede NFApp. Diese vorhandenen Optionen werden um einen neuen testOptions-Parameter erweitert. Mit diesem Parameter kann der Benutzer testOptions-Einstellungen pro NFApp und pro Vorgangstyp angeben. Der testOptions-Parameter unterstützt die folgenden Parameter:

enable
- Aktiviert oder deaktiviert den Helm-Test auf einer NFApp nach Abschluss der Installation oder des Upgrades.
- Der Standardwert ist „false“.
timeout
- Akzeptiert einen Wert, der das Testtimeout in Minuten darstellt.
- Der Standardwert ist 20 Minuten.
rollbackOnTestFailure
- Aktiviert oder deaktiviert die Zurücksetzung, wenn der Helm-Test einer NFApp fehlschlägt.
- Der Standardwert ist true.
filter
- Ermöglicht es einer Methode, nur eine Teilmenge von Tests auszuführen. Akzeptiert eine Liste von Zeichenfolgen, wobei jede Zeichenfolge in der Liste einen Test darstellt, der ausgeführt werden soll.
- Standardmäßig ist kein Filter angewendet, und alle Tests werden ausgeführt.

Verfügbarmachen der Helm-Teststeuerung über Parameter

AOSM unterstützt bereits die NF-Payloadparameter installOptions und upgradeOptions für jede NFApp unter roleOverrideValues. Diese Parameter werden erweitert, um neue testOptions-Einstellungen einzuschließen. Durch das Verfügbarmachen dieser neuen Parametereinstellungen kann das Upgradeverhalten zur Laufzeit gesteuert werden. In den drei folgenden Beispielen wird die Verwendung von testOptions veranschaulicht.

Beispiel für roleOverrideValues mit Escape-Zeichen

Nachfolgend sehen Sie ein Escape-Beispiel roleOverrideValues mit testOptions unter installOptions und upgradeOptions für eine Komponente mit dem Namen application1. In diesem Beispiel wird eine filter-Instanz verwendet, um nur Tests auszuführen, die der angegebenen Zeichenfolge entsprechen. Außerdem wird ein benutzerdefiniertes Timeout verwendet, und rollbackOnTestFailures ist aktiviert.

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

Beispiel für roleOverrideValues ohne Escape-Zeichen

Nachfolgend sehen Sie ein Beispiel ohne Escape-Zeichen für eine roleOverrideValues-NF-Payload mit testOptions unter installOptions und upgradeOptions für eine Komponente mit dem Namen hellotest. In diesem Beispiel wird eine filter-Instanz verwendet, um nur Tests auszuführen, die der angegebenen Zeichenfolge entsprechen. Außerdem wird ein benutzerdefiniertes Timeout verwendet, und rollbackOnTestFailures ist aktiviert.

"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”] } } } } } }"
]

Beispiel für NF-Payload

Nachfolgend sehen Sie ein Beispiel für eine NF-Payload mit testOptions unter installOptions und upgradeOptions für eine Komponente mit dem Namen application1. In diesem Beispiel wird eine filter-Instanz verwendet, um nur Tests auszuführen, die der angegebenen Zeichenfolge entsprechen. Außerdem wird ein benutzerdefiniertes Timeout verwendet, und rollbackOnTestFailures ist aktiviert.

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

Teilen über