Qué ocurre en una actualización de stack de CloudFormation - Lo que hay detrás de los change sets, el rollback y el reemplazo
Explicamos el flujo de procesamiento interno cuando CloudFormation actualiza un stack, a partir de la detección de diferencias de los change sets, la lógica de decisión entre actualizar, reemplazar o eliminar recursos y el mecanismo de rollback.
Detección de diferencias en la plantilla - Cómo se determina qué ha cambiado
Cuando indica a CloudFormation que actualice un stack, lo primero que se hace es detectar las diferencias entre la plantilla actual y la nueva plantilla. CloudFormation detecta los cambios de propiedades usando como clave el ID lógico (el nombre dentro de la plantilla) de cada recurso. Lo importante aquí es que lo que compara CloudFormation son «las propiedades descritas en la plantilla», y no «el estado actual del recurso real». Es decir, las propiedades que se cambian manualmente desde la consola de AWS o la CLI no se detectan como diferencias si no se reflejan en la plantilla de CloudFormation. Este «drift» (la brecha entre la plantilla y el estado real) es uno de los problemas a los que hay que prestar atención en la operación de CloudFormation. Con la función de detección de drift puede detectar la brecha, pero no se corrige automáticamente. Un change set es una función que permite previsualizar qué recursos van a cambiar y de qué manera antes de ejecutar realmente la actualización. Al crear un change set, CloudFormation analiza las diferencias y muestra para cada recurso una de las acciones «añadir», «modificar» o «eliminar».
Actualización, reemplazo y eliminación - Comportamientos de actualización distintos según el recurso
La actualización de recursos de CloudFormation tiene tres patrones. La «actualización sin interrupción» (Update with No Interruption) cambia las propiedades sin detener el recurso. Por ejemplo, cambiar las variables de entorno de una función de Lambda o añadir etiquetas a un bucket de S3 corresponde a este patrón. En la «actualización con cierta interrupción» (Update with Some Interruption), el recurso deja de estar disponible temporalmente. Cambiar el tipo de instancia de una instancia EC2 implica detener y reiniciar la instancia. El «reemplazo» (Replacement) elimina el recurso existente y crea un recurso nuevo. Cambiar el motor (Engine) de una instancia de base de datos de RDS o la clave de partición de una tabla de DynamoDB supone un reemplazo. El reemplazo es, de los tres, un patrón de gran impacto. Si se reemplaza un recurso que contiene datos (RDS, DynamoDB), es posible que se pierdan los datos. La documentación de CloudFormation indica, para cada propiedad de cada tipo de recurso, el comportamiento al cambiarla (sin interrupción / interrupción temporal / reemplazo). Es información que conviene comprobar antes de actualizar un stack.
Resolución de dependencias y orden de actualización
CloudFormation analiza automáticamente las dependencias entre los recursos de la plantilla y ejecuta las actualizaciones en el orden correcto. Las dependencias se deducen de la función Ref, la función Fn::GetAtt y el atributo DependsOn. Por ejemplo, si una función de Lambda hace referencia a un rol de IAM, primero se actualiza el rol de IAM y después la función de Lambda. CloudFormation ejecuta las actualizaciones en paralelo en la medida de lo posible. Los recursos sin dependencias se actualizan al mismo tiempo, lo que acorta el tiempo de actualización. Sin embargo, la actualización en paralelo también tiene riesgos. Si actualiza al mismo tiempo un grupo de seguridad y una instancia EC2, es posible que las reglas del grupo de seguridad queden temporalmente en un estado incoherente. Las dependencias circulares (el recurso A hace referencia al recurso B y el recurso B hace referencia al recurso A) las detecta CloudFormation como error en la fase de validación de la plantilla. Para eliminar una dependencia circular, es necesario cambiar el diseño de la plantilla, por ejemplo revisando la dirección de las referencias entre los recursos.
El mecanismo de rollback - Hasta dónde se vuelve atrás cuando algo falla
Si falla la creación o el cambio de un recurso durante la actualización de un stack, CloudFormation inicia automáticamente un rollback. El rollback es el proceso que devuelve el stack al estado anterior a la actualización. Sin embargo, hay que prestar atención a las actualizaciones que reemplazan recursos y al rollback. En un reemplazo, CloudFormation crea primero el recurso nuevo, cambia las referencias hacia él y, de forma predeterminada, elimina después el recurso antiguo. Si quiere conservar el recurso antiguo en un reemplazo, establezca UpdateReplacePolicy en Retain, y no DeletionPolicy. También hay casos en los que el propio rollback falla. Por ejemplo, cuando se ha cambiado manualmente un recurso durante la actualización o cuando el estado al que se vuelve infringe los límites actuales del servicio. Si el rollback falla, el stack pasa al estado UPDATE_ROLLBACK_FAILED y es necesaria una intervención manual. Con la API ContinueUpdateRollback puede omitir los recursos problemáticos y continuar el rollback, pero después es necesario comprobar el estado de los recursos omitidos. Como la recuperación desde este estado requiere esfuerzo, también se considera la opción de volver a crear el stack.
Medidas prácticas para actualizar stacks de forma segura
Hay cuatro medidas para evitar accidentes en las actualizaciones de stacks de CloudFormation. La primera es revisar el change set. En lugar de la actualización directa (UpdateStack), cree un change set, previsualícelo y ejecútelo después de comprobar que no hay reemplazos ni eliminaciones no deseados. La segunda es configurar una política de stack. La política de stack es una política que prohíbe o restringe la actualización de recursos concretos. Si configura una política de stack en las instancias de RDS o las tablas de DynamoDB del entorno de producción y prohíbe el reemplazo y la eliminación, resulta más fácil evitar la pérdida de datos por errores en la plantilla. La tercera es configurar DeletionPolicy. Si configura DeletionPolicy: Retain en los recursos importantes, el recurso se conserva al eliminar el stack, y si configura UpdateReplacePolicy: Retain, se conserva en un reemplazo. La cuarta es activar la protección de terminación. Para evitar la eliminación accidental del propio stack, active la protección de terminación en los stacks del entorno de producción. Combinando estas medidas, puede reducir el riesgo de accidentes en las actualizaciones de CloudFormation.
Referencias (recursos oficiales de AWS)
Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.
Si esta página y la documentación oficial difieren, prevalece la documentación oficial.