Compartir a través de

Introducción a los procedimientos de actualización seguros

  • Artículo

Información general

En este artículo se presentan los procedimientos de actualización seguros (SUP) de Azure Operator Service Manager (AOSM). Este conjunto de características permite a un usuario final ejecutar de forma segura actualizaciones complejas de cargas de trabajo de CNF hospedadas en Azure Operator Nexus, conforme a los requisitos de ISSU del partner, si procede. Busque futuros artículos en estos servicios para expandir las características y funcionalidades de SUP.

Introducción

Un servicio de red determinado compatible con Azure Operator Service Manager se compone de una a varias funciones de red basadas en contenedores (CNF) que, con el tiempo, requerirán actualizaciones de software. Para cada actualización, es necesario ejecutar de una a varias operaciones de Helm, actualizando las aplicaciones de funciones de red dependientes (NfApps), en un orden determinado, de manera que afecte lo menos posible al servicio de red. En Azure Operator Service Manager, los procedimientos de actualización segura representan un conjunto de características, que pueden automatizar las operaciones de CNF necesarias para actualizar un servicio de red en Azure Operator Nexus.

  • Actualización de la reputación de un SNS: ejecute la operación de actualización de Helm en todas las NfApps de la NFDV.
  • Nexus Platform: admite operaciones de la reputación de un SNS en los destinos de la plataforma Nexus.
  • Tiempos de espera de operación: capacidad de establecer tiempos de espera operativos para cada operación de NfApp.
  • Operaciones sincrónicas: capacidad de ejecutar una operación de NfApp en serie cada vez.
  • Pausar en caso de error: en función de la marca, establezca el comportamiento de error para revertir solo la última operación de NfApp.
  • Validación de pruebas de gráfico único: ejecutar una operación de prueba de Helm después de crear o actualizar.
  • Refactorización de la reputación de un SNS: métodos mejorados, agrega el orden de actualización y la comprobación de limpieza.

Enfoque de actualización

Para actualizar un servicio de red de sitio (SNS) de Azure Operator Service Manager existente, el operador ejecuta una solicitud de actualización de reputación en el recurso SNS implementado. Cuando el SNS contiene CNF con varias NfApps, la solicitud se agrupa en todas las NfApps definidas en la versión de definición de función de red (NFDV). De forma predeterminada, en el orden en que aparecen, u opcionalmente, en el orden definido por el parámetro UpdateDependsOn.

Para cada NfApp, la solicitud de actualización de reputación admite el aumento de una versión del gráfico de Helm, la adición o eliminación de valores de Helm o la adición o eliminación de cualquier NfApp. Los tiempos de espera se pueden establecer por NfApp, en función de los runtime permitidos conocidos, pero las NfApps solo se puede procesar en orden serial, una tras otra. La actualización de reputación implementa la siguiente lógica de procesamiento:

  • NfApps se procesa siguiendo el orden updateDependsOn o en el orden secuencial que aparecen.
  • Se omiten nfApps con el parámetro "applicationEnabled" establecido en disable.
  • Las NFApps implementadas, pero no referenciadas por el nuevo NFDV, se eliminan.
  • Las NFApps que son comunes entre NFDV antiguos y nuevos se actualizan.
  • Las NFApps que solo están instaladas en el nuevo NFDV.

Para garantizar los resultados, las pruebas de NfApp se realizan mediante Helm, ya sean pruebas previas o posteriores a la actualización de Helm o pruebas independientes de Helm. En el caso de los errores de las pruebas previas y posteriores, se respeta el parámetro atomic. Con atomic/true, el gráfico con errores se revierte. Con atomic/false, no se ejecuta ninguna reversión. En el caso de las pruebas independientes de Helm, se respeta el parámetro rollbackOnTestFailure. Con rollbackOnTestFailure/true, el gráfico con errores se revierte. Con rollbackOnTestFailure/false, no se ejecuta ninguna reversión.

Requisitos previos

Cuando planifique una actualización mediante Azure Operator Service Manager, solucione los siguientes requisitos antes de la ejecución de la actualización para optimizar el tiempo dedicado a intentar la actualización.

  • Incorpore artefactos actualizados mediante flujos de trabajo de editor o diseñador.

    • El editor, el almacén, el diseño del servicio de red (NSDg) y el grupo de diseño de la función de red (NFDg) son estáticos y no necesitan cambiar.
      • Se necesita un nuevo manifiesto de artefacto para almacenar los nuevos gráficos e imágenes. Para más información, consulte la documentación de incorporación para obtener detalles sobre cómo cargar nuevos gráficos e imágenes.
    • Se necesitan nuevas versiones de la NFDV y de diseño de servicios de red (NSDV), en el marco del NFDg y NSDg existentes.
      • Tratamos los cambios básicos en la NFDV en la sección paso a paso.
      • El nuevo NSDV solo es necesario si se introduce una nueva versión de esquema de grupo de configuración (CGS).
    • Si es necesario, nuevo CGS.
      • Obligatorio si una actualización introduce nuevos parámetros de configuración expuestos.

  • Cree artefactos actualizados mediante el flujo de trabajo del operador.

    • Si es necesario, cree nuevos valores de grupo de configuración (CGV) basados en el nuevo CGS.
    • Reutilice y cree una carga útil confirmando los objetos de servicio del sitio y de la red del sitio existentes.

  • Actualice las plantillas para garantizar que los parámetros de actualización se establecen en función de la confianza en la actualización y el comportamiento de error deseado.

    • La configuración usada para producción puede suprimir los detalles de los errores, mientras que la configuración usada para la depuración o las pruebas puede optar por exponer estos detalles.

Procedimiento de actualización

Siga el siguiente proceso para desencadenar una actualización con Azure Operator Service Manager.

Creación de un nuevo recurso NFDV

Para las nuevas versiones de la NFDV, debe estar en un formato SemVer válido, en el que solo se permitan valores de incremento superiores de actualizaciones de revisión y versiones menores. No se permite una versión de la NFDV inferior. Dada una CNF implementada mediante NFDV 2.0.0, la nueva NFDV puede ser de la versión 2.0.1, o 2.1.0, pero no 1.0.0, o 3.0.0.

Actualización de nuevos parámetros de la NFDV

Las versiones del gráfico de Helm se pueden actualizar o los valores de Helm se pueden actualizar o parametrizar según sea necesario. También se pueden agregar nuevas NfApps cuando no existían en la versión implementada.

Actualización de la NFDV para el pedido de NfApp deseado

UpdateDependsOn es un parámetro de NFDV que se usa para especificar el orden de NfApps durante las operaciones de actualización. Si no se proporciona UpdateDependsOn, se usa el orden en serie de las aplicaciones de CNF, tal como aparece en la NFDV.

Actualización de la NFDV para el comportamiento de actualización deseado

Asegúrese de establecer los tiempos de espera de la aplicación de CNF deseados, el parámetro atomic y el parámetro rollbackOnTestFailure. Puede ser útil cambiar estos parámetros a lo largo del tiempo, ya que se obtiene más confianza en la actualización.

Problema de reputación de un SNS

Una vez completada la incorporación, se envía la operación de reputación. Según el número, el tamaño y la complejidad de las NfApps, la operación de reputación puede tardar un tiempo en completarse (varias horas).

Examen de los resultados de reputación

Si se notifica un resultado correcto, la actualización se completa y el usuario debe validar el estado y la disponibilidad del servicio. Si se notifica un error, siga los pasos descritos en la sección recuperación de errores de actualización para continuar.

Procedimiento de reintento

En los casos en los que se produce un error en una actualización de reputación, se puede seguir el siguiente proceso para reintentar la operación.

Diagnóstico de una NfApp con errores

Resuelva la causa principal del error de la NfApp mediante el análisis de registros y otra información de depuración.

Omisión manual de los gráficos completados

Después de corregir el error de la NfApp, pero antes de reintentar la actualización, considere la posibilidad de cambiar el parámetro applicationEnablement para acelerar el comportamiento del reintento. Este parámetro se puede establecer en false, donde se debe omitir una NfApp. Este parámetro puede ser útil cuando una NfApp no requiere una actualización.

Reintentos de reputación de un SNS (repetir hasta que se realiza correctamente)

De forma predeterminada, la reputación reintenta NfApps en el orden de actualización declarado, a menos que se omitan mediante la marca applicationEnablement.

Uso de applicationEnablement

En el recurso de NFDV, en deployParametersMappingRuleProfile hay la propiedad applicationEnablement de tipo de enumeración, que toma valores: Desconocido, Habilitado o Deshabilitado. Se puede usar para excluir las operaciones de NfApp durante la implementación de NF.

Cambios del publicador

En el caso de la propiedad applicationEnablement, el publicador tiene dos opciones: proporcionar un valor predeterminado o parametrizarlo.

NFDV de ejemplo

El publicador usa NFDV para establecer valores predeterminados para 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"
    }
}

Recurso de esquema de grupo de configuración (CGS) de ejemplo

El publicador usa CGS para requerir que el operador proporcione las variables roleOverrideValues en tiempo de ejecución. Estos roleOverrideValues pueden incluir valores que no son predeterminados para 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"
  ]
}

Cambios del operador

Los operadores heredan los valores predeterminados applicationEnablement tal como se define en NFDV. Si applicationEnablement está parametrizado en CGS, debe pasarse a través de la propiedad deploymentValues en tiempo de ejecución.

Recurso de valor de grupo de configuración (CGV) de ejemplo

El operador utiliza el CGV para establecer las variables roleOverrideValues en tiempo de ejecución. RoleOverrideValues incluye una configuración que no es predeterminada para 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\"}}"
  }
}

Plantilla de ARM NF de ejemplo

El operador usa la plantilla de ARM NF para enviar las variables roleOverrideValues, establecidas por CGV, en el proveedor de recursos (RP). El operador puede cambiar la configuración applicationEnablement en CGV, según sea necesario, y volver a enviar la misma plantilla de ARM NF, para modificar el comportamiento entre iteraciones.

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

Compatibilidad con en actualizaciones de servicio

Azure Operator Service Manager, siempre que sea posible, admite en las actualizaciones de servicio, un método de actualización que avanza una versión de implementación sin interrumpir el servicio. Sin embargo, la capacidad de actualizar un servicio determinado sin interrupciones es una característica del propio servicio. Consulte más información con el publicador de servicios para comprender las funcionalidades de actualización en el servicio.

Objetivos de búsqueda de reenvío

Azure Operator Service Manager sigue ampliando el conjunto de características prácticas de actualización segura e impulsa mejoras en los servicios de actualización ofrecidos. Actualmente se está estudiando la disponibilidad futura de las siguientes funciones:

  • Mejora del control de opciones de actualización: exponga parámetros de forma más eficaz.
  • Omisión de NfApp si no hay ningún cambio: omita el procesamiento de NfApps si no hay cambios.
  • Ejecución de la reversión de una NFDV en caso de error: en función de la marca, revierta todas las NfApps completadas en caso de error.
  • Operación asincrónica: capacidad para ejecutar varias operaciones de NfApp a la vez.
  • Descarga de imágenes: capacidad de cargar previamente imágenes en el repositorio perimetral.
  • Gráficos de destino para validación: capacidad de ejecutar una prueba de Helm solo en una NfApp específica.