Irakurri ingelesez

Partekatu honen bidez:

Ejecución de pruebas después de instalar o actualizar

  • Artikulua

En este artículo se describe cómo Azure Operator Service Manager (AOSM) puede ejecutar pruebas en funciones de red (NF) como parte de las operaciones de instalación o actualización. Cuando está habilitada, cada aplicación de función de red (nfApp) se prueba después de la instalación del componente o la finalización de la actualización. Se requiere un resultado correcto en todas las pruebas nfApp para que el estado de la operación NF se complete correctamente.

Información general

Como parte del programa de actualización segura, AOSM es compatible con el uso de pruebas de Helm como paso de comprobación durante las operaciones de instalación o actualización de funciones de red. El siguiente flujo de trabajo describe la lógica usada por AOSM al incluir esta capa adicional de validación:

  • Los usuarios crean sus propias pruebas y las incluyen en el paquete Helm durante la incorporación de NF.
  • Solo cuando está habilitado, AOSM ejecuta estas pruebas de Helm en cada nfApp.
  • Si la prueba se realiza correctamente, AOSM pasa a la siguiente nfApp.
  • Si la prueba falla, AOSM sigue rollbackOnTestFail para determinar si la nfApp se vuelve a implementar.
  • La operación NF principal finaliza con un error si alguna nfApp falla una prueba configurada.
  • Tras un error primario, AOSM respeta el método configurado del control de errores NF, ya sea pause-on-failure o rollback-on-failure.

Oharra

Helm solo es compatible como parte de la operación de instalación o actualización y no se puede ejecutar de forma independiente.

Creación de pruebas de Helm

El publicador es responsable de crear las pruebas de Helm durante la construcción de los gráficos de Helm. Las pruebas de Helm se definen en el gráfico de Helm en la carpeta : <ChartName>/Templates/. Cada prueba incluye una definición de trabajo que especifica un entorno de contenedor y un comando que se va a ejecutar. El entorno de contenedor debe salir correctamente para que una prueba se considere correcta. La definición del trabajo debe incluir la anotación (helm.sh/hook: test) del enlace de prueba de Helm para que se reconozca como una prueba de Helm.

Habilitación de pruebas de Helm durante las operaciones

AOSM proporciona un conjunto de opciones de instalación y actualización configurables para cada nfApp. Estas opciones existentes se extienden con un nuevo parámetro testOptions. Con este parámetro, el usuario puede especificar las configuraciones de testOptions por nfApp y por tipo de operación. El parámetro testOptions admite los parámetros siguientes:

  • enable
    • Habilita o deshabilita la prueba de Helm en una nfApp una vez completada la instalación o actualización.
    • El valor predeterminado es Falso.
  • timeout
    • Toma un valor que representa el tiempo de espera de la prueba en minutos.
    • El valor predeterminado es 20 minutos.
  • rollbackOnTestFailure
    • Habilita o deshabilita la reversión en un error de prueba de helm de nfApp.
    • El valor predeterminado es true.
  • filter
    • Permite que un método ejecute solo un subconjunto de pruebas. Acepta una lista de cadenas, donde cada cadena de la lista representa una prueba que se va a ejecutar.
    • El valor predeterminado es sin filtro y se ejecutan todas las pruebas.

Exposición del control de pruebas de Helm a través de parámetros

AOSM ya es compatible con los parámetros de carga útil NF installOptions y upgradeOptions para cada nfApp en roleOverrideValues. Estos parámetros se extienden para incluir la nueva configuración de testOptions. La exposición de estos nuevos parámetros de configuración permite al Operador controlar el comportamiento de la actualización en tiempo de ejecución. Vea los tres ejemplos siguientes que demuestran el uso de testOptions.

Ejemplo de escape de roleOverrideValues

A continuación se muestra un ejemplo de escape de roleOverrideValues con testOptions bajo installOptions y upgradeOptions para un componente llamado application1. Este ejemplo usa un filter para ejecutar solo las pruebas que coincidan con la cadena proporcionada, usa un tiempo de espera personalizado y habilita 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\”]}}}}}}"]

Ejemplo sin escape de roleOverrideValues

A continuación se muestra un ejemplo sin escape de la carga útil NF roleOverrideValues con testOptions bajo installOptions y upgradeOptions para un componente llamado hellotest. Este ejemplo usa un filter para ejecutar solo las pruebas que coincidan con la cadena proporcionada, usa un tiempo de espera personalizado y habilita 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”] } } } } } }"
]

Ejemplo de carga de NF

A continuación se muestra un ejemplo de carga útil NF con testOptions en installOptions y upgradeOptions para un componente llamado application1. Este ejemplo usa un filter para ejecutar solo las pruebas que coincidan con la cadena proporcionada, usa un tiempo de espera personalizado y habilita 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\”]}}}}}}" 
        ]
    }
}