Operaciones para cargas de trabajo críticas en Azure

2025-01-30

Al igual que con cualquier aplicación, el cambio se produce en las cargas de trabajo críticas. La aplicación evolucionará con el tiempo, las claves expirarán, se liberarán las revisiones y mucho más. Todos los cambios y el mantenimiento deben aplicarse mediante canalizaciones de implementación. En este artículo se proporcionan instrucciones operativas para realizar cambios y actualizaciones comunes.

La alineación organizativa es igualmente importante para los procedimientos de operación. Es fundamental para el éxito operativo de una carga de trabajo crítica que las responsabilidades de un extremo a otro se encuentran dentro de un único equipo, el equipo de DevOps.

La ejecución técnica debe aprovechar las funcionalidades de la plataforma nativa de Azure y el uso de Azure Pipelines automatizado para implementar cambios en la aplicación, la infraestructura y la configuración. De nuevo, las tareas de mantenimiento deben automatizarse y se deben evitar tareas manuales.

En las secciones siguientes se describen los enfoques para controlar los distintos tipos de cambios.

Automatización de aplicaciones

La integración continua y la implementación continua (CI/CD) permiten la implementación y comprobación adecuadas de las cargas de trabajo críticas. CI/CD es el enfoque preferido para implementar cambios en cualquier entorno, desarrollo/pruebas, producción y otros. En el caso de las cargas de trabajo críticas, los cambios enumerados en la sección siguiente deben dar lugar a la implementación de una marca completamente nueva. El nuevo stamp debe probarse exhaustivamente como parte del proceso de lanzamiento antes de que el tráfico se enrute a la marca a través de una estrategia de implementación azul/verde.

En las secciones siguientes se describen los cambios que se deben implementar, siempre que sea posible, a través de CI/CD.

Cambios en la aplicación

Todos los cambios en el código de la aplicación se deben implementar a través de CI/CD. El código debe compilarse, analizarse con lint y probarse para detectar regresiones. Las dependencias de la aplicación, como el entorno en tiempo de ejecución o los paquetes, deben supervisarse, con las actualizaciones implementadas a través de CI/CD.

Cambios en la infraestructura

La infraestructura debe modelarse y aprovisionarse como código. Esta práctica se conoce normalmente como Infraestructura como Código (IaC). Todos los cambios en la IaC deben implementarse a través de las canalizaciones de CI/CD. Las actualizaciones de la infraestructura, como la aplicación de revisiones al sistema operativo, también se deben administrar a través de canalizaciones de CI/CD.

Cambios de configuración

Los cambios de configuración son una causa común de interrupciones de la aplicación. Para combatir estas interrupciones, la configuración de la aplicación o la infraestructura debe capturarse como código. Esta práctica se conoce como Configuración como Código (CaC). Los cambios en CaC deben implementarse a través de canalizaciones de CI/CD.

Actualizaciones de biblioteca y SDK

En el caso de las aplicaciones críticas, es fundamental que el código fuente y las dependencias se actualicen cuando las nuevas versiones estén disponibles. El enfoque recomendado es aprovechar el proceso de cambio de administración de configuración en el repositorio de código fuente. Debe configurarse para crear automáticamente pull requests para actualizaciones de varias dependencias, como:

Paquetes NuGet de .NET
Paquetes del Administrador de paquetes de nodos de JavaScript
Proveedor de Terraform

El siguiente escenario es un ejemplo de automatización de actualizaciones de biblioteca mediante dependabot en un repositorio de GitHub.

Dependabot detecta actualizaciones de bibliotecas y SDK usados en el código de la aplicación
Dependabot actualiza el código de la aplicación en una rama y crea una solicitud de incorporación de cambios (PR) con esos cambios en la rama principal. La solicitud de incorporación de cambios contiene toda la información pertinente y está lista para su revisión final.
Cuando se realizan la revisión de código y las pruebas, la PR se puede fusionar con la rama principal.

Para las dependencias dependabot no puede supervisar, asegúrese de que tiene procesos implementados para detectar nuevas versiones.

Rotaciones de claves, secretos y certificados

La rotación (renovación) de claves y secretos debe ser un procedimiento estándar en cualquier carga de trabajo. Es posible que los secretos deban cambiarse brevemente después de exponerse o regularmente como procedimiento de seguridad recomendado.

Dado que los secretos expirados o no válidos pueden provocar interrupciones en la aplicación (consulte Análisis de errores), es importante tener un proceso claramente definido y probado. En el caso de ser críticos para Azure, se espera que los stamps solo duren unas semanas. Por eso, la rotación de secretos de recursos de stamp no es un problema. Si los secretos de un sello expiran, la aplicación en su conjunto seguirá funcionando.

La gestión de secretos para acceder a recursos globales de larga duración es fundamental. Un ejemplo notable es las claves de API de Azure Cosmos DB. Si las claves de API de Azure Cosmos DB expiran, todos los stamps se ven afectados simultáneamente y provocan una interrupción completa de la aplicación.

El siguiente enfoque es un método crítico para la misión en Azure, probado y documentado, para realizar la rotación de las claves de Azure Cosmos DB sin causar tiempo de inactividad en los servicios que se ejecutan en Azure Kubernetes Service.

Actualice los stamps con la clave secundaria. De forma predeterminada, la clave de API principal de Azure Cosmos DB se almacena como un secreto en Azure Key Vault en cada stamp. Crea un PR que actualice el código de plantilla de IaC que utiliza la clave secundaria de la API de Azure Cosmos DB. Ejecute este cambio a través del procedimiento normal de revisión y actualización de PR para implementarlo como una nueva versión o como una corrección urgente.
(opcional) Si la actualización fue implementada como una corrección urgente en una versión existente, los pods recogerán automáticamente el nuevo secreto de Azure Key Vault después de unos minutos. Sin embargo, el código de cliente de Azure Cosmos DB no reinicializa actualmente con una clave modificada. Para resolver este problema, reinicie todos los pods manualmente mediante los siguientes comandos en los clústeres:
```
kubectl rollout restart deployment/CatalogService-deploy -n workload
kubectl rollout restart deployment/BackgroundProcessor-deploy -n workload
kubectl rollout restart deployment/healthservice-deploy -n workload
```
Los pods recién implementados o reiniciados ahora usan la clave de API secundaria para la conexión a Azure Cosmos DB.
Una vez que se reinicien todos los pods de todos los stamps o que se haya implementado un nuevo stamp, vuelva a generar la clave de API principal para Azure Cosmos DB. Este es un ejemplo del comando :
```
az cosmosdb keys regenerate --key-kind primary --name MyCosmosDBDatabaseAccount --resource-group MyResourceGroup
```
Cambie la plantilla de IaC para usar la clave de API principal para futuras implementaciones. Como alternativa, puede seguir usando la clave API secundaria y volver a la clave API principal cuando sea el momento de renovar la secundaria.

Alertas

Las alertas son clave para comprender si y cuándo hay problemas con el entorno. Los cambios en las alertas o grupos de acciones se deben implementar a través de canalizaciones de CI/CD. Para más información sobre alertas, consulte Modelado del mantenimiento y observabilidad de cargas de trabajo críticas en Azure.

Automatización

Muchas plataformas y servicios que se ejecutan en Azure proporcionan automatización para actividades operativas comunes. Esta automatización incluye el escalado automático y el control automatizado de claves y certificados.

Ampliación

Como parte del diseño de la aplicación, se deben determinar los requisitos de escalado que definen una unidad de escalado para el sello en su conjunto. Los servicios individuales dentro del stamp deben ser capaces de escalar horizontalmente para satisfacer la demanda máxima o reducir horizontalmente para ahorrar dinero o recursos.

Los servicios que no tienen recursos suficientes pueden mostrar diferentes efectos secundarios, incluida la siguiente lista:

Un número insuficiente de pods que procesan mensajes de una cola, tema o partición dará como resultado un número creciente de mensajes no procesados. Este resultado se conoce a veces como una profundidad de cola creciente.
Los recursos insuficientes en un nodo de Azure Kubernetes Service pueden dar lugar a que los pods no se puedan ejecutar.
El resultado siguiente da como resultado solicitudes limitadas:
- Unidades de solicitud (RU) insuficientes para Azure Cosmos DB
- Unidades de procesamiento (PU) insuficientes para una instancia premium de Event Hubs o unidades de procesamiento (TU) insuficientes para una instancia estándar
- Unidades de mensajería (MU) insuficientes para el nivel premium de Service Bus

Aproveche las ventajas de las características de escalado automático de los servicios, siempre que sea posible, para asegurarse de que tiene suficientes recursos para satisfacer la demanda. A continuación se muestran las características de escalado automático que puede aprovechar:

El escalado automático horizontal de pods permite aumentar o disminuir el número de pods que ejecutan cargas de trabajo, en función de la demanda.
El escalador automático de clústeres de AKS permite aumentar o disminuir el número de nodos del clúster, en función de la demanda.
Puede escalar verticalmente de forma automática las unidades de procesamiento de Azure Event Hubs (nivel estándar)
Puede actualizar automáticamente las unidades de mensajería de un espacio de nombres de Azure Service Bus.

Administración de claves, secretos y certificados

Use identidades administradas siempre que sea posible para evitar tener que administrar claves de API o secretos como contraseñas.

Cuando use claves, secretos o certificados, use las funcionalidades de la plataforma nativa de Azure siempre que sea posible. A continuación se muestran algunos ejemplos de estas funcionalidades de nivel de plataforma:

Azure Front Door tiene funcionalidades integradas para la administración y renovación de certificados TLS.
Azure Key Vault admite la rotación automática de claves.

Operaciones manuales

Hay actividades operativas que requieren intervención manual. Estos procesos deben probarse.

Mensajes fallidos

Los mensajes que no se pueden procesar se deben enrutar a una cola de mensajes fallidos con una alerta configurada para esa cola. Normalmente, estos mensajes requieren intervención manual para comprender y mitigar el problema. Debe compilar la capacidad de ver, actualizar y reproducir los mensajes fallidos.

Restauración de Azure Cosmos DB

Cuando los datos de Azure Cosmos DB se eliminan, actualizan o dañan involuntariamente, debe realizar una restauración a partir de una copia de seguridad periódica. La restauración desde una copia de seguridad periódica solo se puede realizar a través de un caso de soporte técnico. Este proceso debe documentarse y probarse periódicamente.

Aumentos de cuota

Las suscripciones de Azure tienen límites de cuota. Las implementaciones pueden producir errores cuando se alcanzan estos límites. Algunas cuotas son ajustables. Para las cuotas ajustables, puede solicitar un aumento en la página Mis cuotas en Azure Portal. Para las cuotas no ajustables, debe enviar una solicitud de soporte técnico. El equipo de soporte técnico de Azure funciona con usted para encontrar una solución.

Importante

Consulte Procedimientos operativos para cargas de trabajo críticas en Azure para conocer las consideraciones y recomendaciones de diseño operativo.

Colaboradores

Microsoft mantiene este artículo. Los colaboradores siguientes escribieron este artículo.

Autores principales:

Rob Bagby | Desarrollador principal de contenido: patrones y prácticas de Azure
Allen Sudbring | Desarrollador de contenido sénior

Para ver perfiles de LinkedIn no públicos, inicie sesión en LinkedIn.

Pasos siguientes

Implemente la implementación de referencia para obtener una comprensión completa de los recursos y su configuración usada en esta arquitectura.

Implementación: Crítica en línea