hace 2 años
En el dinámico mundo de la gestión de la infraestructura en la nube, la elección de las herramientas adecuadas es crucial para la eficiencia, la fiabilidad y la escalabilidad. Tradicionalmente, AWS CloudFormation ha sido una opción popular para la gestión de la configuración dentro del ecosistema de Amazon Web Services. Sin embargo, con la evolución de las necesidades y la aparición de alternativas más flexibles, muchas organizaciones están reconsiderando sus estrategias de infraestructura como código (IaC). En este artículo, exploraremos las razones detrás de la decisión de abandonar CloudFormation en favor de Terraform, un sistema de gestión de configuración moderno y multi-nube. Analizaremos las limitaciones inherentes a CloudFormation, destacaremos las ventajas que ofrece Terraform y guiaremos a través del proceso de migración, proporcionando una hoja de ruta clara para aquellos que buscan optimizar su gestión de infraestructura en la nube.
¿Por qué un sistema de gestión de configuración?
Aunque los proveedores de nube como AWS ofrecen interfaces web intuitivas para administrar cuentas y recursos (bases de datos, máquinas virtuales, registros DNS, etc.), la gestión manual a través de estas interfaces puede volverse rápidamente ineficiente y propensa a errores, especialmente en entornos complejos o a gran escala. Es aquí donde entran en juego los sistemas de gestión de configuración, también conocidos como Infraestructura como Código (IaC). La IaC revoluciona la forma en que se gestiona la infraestructura, tratándola como código en lugar de una configuración manual. Este enfoque ofrece numerosas ventajas:
- Ahorro de tiempo: La automatización de la configuración permite replicar entornos de forma rápida y sencilla, ya sea para diferentes clientes o para entornos de desarrollo, prueba y producción.
- Consistencia: Al definir la infraestructura en código, se garantiza que cada despliegue sea idéntico, eliminando las inconsistencias que pueden surgir de la configuración manual.
- Análisis previo: Antes de aplicar cualquier cambio, la IaC permite analizar la configuración, prever costes, identificar posibles errores y minimizar riesgos.
- Trazabilidad mejorada: Todos los cambios en la infraestructura se registran en el código, facilitando la auditoría, la reversión a versiones anteriores y la identificación de la causa de posibles problemas.
El proceso de IaC es conceptualmente simple: en lugar de configurar manualmente a través de una interfaz gráfica, se define la infraestructura deseada en un conjunto de instrucciones, típicamente archivos de texto, que son interpretados por un sistema de gestión de configuración.
Las limitaciones de AWS CloudFormation
CloudFormation, el servicio de gestión de configuración nativo de AWS, opera en torno al concepto de "stacks" o pilas. Al actualizar una pila, se envía una nueva plantilla a AWS, el servicio compara esta plantilla con la versión anterior y aplica las diferencias a la infraestructura. Todos los recursos asociados a la pila se gestionan exclusivamente a través de IaC.
Si bien CloudFormation es un servicio fiable, presenta algunas deficiencias que motivan la migración hacia otras soluciones:
Reaplicación completa de la pila
Uno de los principales inconvenientes de CloudFormation es que cada actualización de una pila implica la reaplicación completa de la misma. Incluso un cambio menor, como la adición de un registro DNS, requiere regenerar toda la plantilla. Esto puede llevar a la creación de plantillas complejas y difíciles de mantener a largo plazo. Además, este enfoque incrementa el riesgo de errores con un impacto significativo. Por ejemplo, la recreación accidental de una base de datos podría resultar en la pérdida de datos, o la reconfiguración de la VPC (Virtual Private Cloud) podría interrumpir la conectividad a la cuenta.
Fallo único, reversión total
CloudFormation no secuencia la aplicación de cambios. Si una sola modificación falla durante la actualización de una pila, CloudFormation intenta revertir todos los cambios, incluso aquellos que se habían aplicado correctamente. Esto puede resultar en la pérdida de trabajo y en un estado inconsistente de la infraestructura.
Aplicación ciega de cambios
CloudFormation compara la nueva plantilla con la anterior y aplica las diferencias, pero no detecta modificaciones manuales realizadas fuera de la gestión de IaC. Cualquier cambio manual se ignora y se revierte durante la siguiente actualización de la pila, lo que puede generar confusión y problemas de configuración.
Plantillas extensas y complejas
Las plantillas de CloudFormation se definen en formato JSON, un formato declarativo que puede resultar verbose y difícil de escribir. Incluso un pequeño error de sintaxis, como una coma faltante, puede invalidar toda la plantilla. Aunque existen herramientas para simplificar la generación de plantillas, como la librería Troposphere y el CDK (Cloud Development Kit) de AWS, la complejidad inherente a JSON persiste.
¿Por qué elegir Terraform?
Terraform, desarrollado por HashiCorp, es una herramienta de línea de comandos para IaC lanzada en 2014. Una de sus principales ventajas es su agnosticismo respecto al proveedor de nube, permitiendo gestionar infraestructura en AWS, Azure, Google Cloud y otros, utilizando la misma herramienta y lenguaje de configuración. Terraform se basa en plugins que se conectan con los servicios específicos de cada proveedor, como AWS o Datadog.
La filosofía de Terraform es similar a CloudFormation, pero la configuración aplicada se almacena en un "Terraform State" (un archivo de texto, a menudo almacenado en un bucket S3) en lugar de en una pila de CloudFormation.
En la práctica, Terraform ofrece varias ventajas:
Plantillas más concisas y sencillas
Las plantillas de Terraform se escriben en HCL (HashiCorp Configuration Language), un lenguaje declarativo diseñado para ser más legible y conciso que JSON. Esto facilita la escritura y el mantenimiento de las plantillas.
Modularidad y reutilización
Terraform fomenta la modularidad, permitiendo dividir la configuración en módulos reutilizables. Un cambio en un módulo no afecta necesariamente a toda la configuración, reduciendo el riesgo de efectos secundarios inesperados.
Verificación sistemática
Terraform realiza una verificación sistemática de la configuración contra el estado actual de la infraestructura antes de aplicar cualquier cambio. Esto permite detectar posibles inconsistencias y previsualizar los cambios que se van a realizar.
Reconocimiento preciso de cambios
Terraform identifica la naturaleza exacta de cada cambio que se va a aplicar, proporcionando una mayor visibilidad y control sobre el proceso de actualización de la infraestructura.
Gestión multi-proveedor
Terraform puede gestionar recursos en múltiples proveedores de nube simultáneamente. Por ejemplo, puede crear una base de datos RDS en AWS y configurar monitores relacionados en Datadog en una sola operación.
La principal diferencia técnica radica en que CloudFormation es una API única que gestiona los cambios en todos los servicios de AWS, mientras que Terraform utiliza las APIs específicas de cada servicio de AWS para realizar los cambios.
Migración de CloudFormation a Terraform: Paso a Paso
La migración de CloudFormation a Terraform es un proceso delicado que requiere planificación y cuidado. A continuación, se detallan los pasos a seguir para realizar la migración de forma segura y gradual:
Paso 1: Inventario de recursos existentes
Comienza por inventariar todos los recursos gestionados por la pila de CloudFormation que deseas migrar. En la consola de AWS, en la pestaña "Recursos" de la pila de CloudFormation, obtén una lista completa de los recursos. Crea una hoja de cálculo con las siguientes columnas: "Tipo", "DeletionPolicy", "Deprecated from CFN", "Imported via Terraform", y "Reapplied via Terraform". Para cada recurso, añade una fila en la hoja de cálculo.
Examina la plantilla de CloudFormation asociada a la pila. Extrae todas las propiedades de cada recurso y añádelas a la hoja de cálculo. Recuerda que algunas propiedades, como las suscripciones a temas SNS, no se listan como recursos separados, sino como propiedades del recurso principal.
Analiza las relaciones entre los objetos dentro de la cuenta (por ejemplo, un rol IAM asociado a una política de EC2) y con recursos externos a la cuenta (por ejemplo, una cola SQS externa suscrita a un tema SNS).
Con toda esta información, crea un diagrama exhaustivo que represente cada recurso, sus propiedades y relaciones. Este diagrama será una referencia valiosa durante el proceso de migración y para futuras consultas sobre la infraestructura. Herramientas como Draw.io o Miro pueden ser útiles para crear este diagrama, ya que incluyen símbolos para objetos de AWS.
Paso 2: Dividir la migración en porciones pequeñas
Observando el diagrama, identifica bloques autónomos de recursos que no estén interconectados. Enumera estos bloques (por ejemplo, una base de datos RDS con sus políticas de seguridad asociadas). Migra estos bloques de forma individual, uno a la vez. Esto facilita la identificación y resolución de problemas en caso de que algo salga mal.
Comienza con los bloques más pequeños para familiarizarte con el proceso de migración y ganar confianza antes de abordar los bloques más grandes y complejos. Los siguientes pasos se repetirán para cada bloque de infraestructura que se vaya a migrar.
Paso 3: Actualizar DeletionPolicy en CloudFormation
Por defecto, al eliminar un recurso de una pila de CloudFormation, el recurso se elimina también de la cuenta de AWS. Sin embargo, en el proceso de migración, el objetivo es eliminar la pila de CloudFormation sin eliminar los recursos subyacentes. Para lograr esto, es necesario actualizar la propiedad "DeletionPolicy" de cada recurso a "Retain". Esto indica a CloudFormation que debe conservar el recurso al eliminarlo de la pila.
Para cada recurso listado en la hoja de cálculo (identificado por la propiedad "Type" en la plantilla de CloudFormation), actualiza la plantilla para incluir "DeletionPolicy": "Retain". Publica la plantilla actualizada en CloudFormation. Una vez completado este paso para todos los recursos, marca la columna "DeletionPolicy" en la hoja de cálculo.
Este paso es crucial. Si experimentas una "deriva" (diferencia) entre la configuración real y la plantilla, no te preocupes. Siempre y cuando solo modifiques la propiedad "DeletionPolicy", los cambios afectarán únicamente a la configuración interna de la pila y no a la infraestructura. Para asegurarte de que no se realizarán cambios en la infraestructura, puedes crear un "Change Set" en CloudFormation, que debería confirmar que no hay cambios ("No Change").
Paso 4: Eliminar recursos de la plantilla de CloudFormation
Realiza una copia de la plantilla original de CloudFormation. En la copia, elimina los bloques JSON correspondientes a los recursos que se van a migrar. Antes de aplicar los cambios, compara la plantilla original con la plantilla modificada para asegurarte de que solo se han eliminado los recursos deseados.
Es posible que los recursos en la plantilla utilicen parámetros definidos en la sección "Parameters" de la plantilla. Estos parámetros se referencian con la función `Ref`. No elimines los parámetros de la plantilla en este paso. CloudFormation te indicará si un parámetro ya no es necesario más adelante.
Publica la plantilla modificada en CloudFormation. Verifica que la cantidad de recursos gestionados por la pila haya disminuido en la misma cantidad de recursos que se han eliminado. En la pestaña "Eventos" de la pila, los recursos eliminados deberían tener el estado "DELETE_SKIPPED".
¡Los recursos han sido liberados de la pila de CloudFormation! Ahora es el momento de importarlos a Terraform.
Paso 5: Importar recursos a Terraform
Existen dos métodos para importar recursos a Terraform: importación directa o mediante módulos. La importación directa es más sencilla para recursos individuales, pero si los recursos se repiten en varios entornos, se recomienda utilizar módulos.
Paso 5a: Importación directa (sin módulo)
Abre un proyecto de Terraform donde desees importar los recursos. Crea o edita un archivo Terraform y añade un bloque de recurso básico que coincida con el tipo de objeto que se va a importar. Asigna un nombre de Terraform al recurso, pero no es necesario añadir ninguna especificación.
resource "aws_rds_instance" "my_imported_database" { # Intentionally empty } Ahora, la configuración está lista para importar una instancia RDS. Ejecuta el comando `terraform import` en la línea de comandos, especificando el tipo de recurso, el nombre del recurso en Terraform y el ID del recurso en AWS (por ejemplo, el nombre de la instancia RDS).
terraform import aws_rds_instance.my_imported_instance customers_db La instancia RDS se ha añadido al estado de Terraform, sin realizar cambios en la infraestructura. Para sincronizar la configuración con el estado de Terraform, ejecuta `terraform show`. Esto mostrará la configuración actual del recurso importado.
terraform show | less Copia los detalles del estado y pégalos en el bloque de recurso vacío que se añadió al archivo de configuración. Intenta aplicar el proyecto Terraform (`terraform apply`). Si se producen errores, revisa los mensajes de error, elimina las líneas problemáticas y vuelve a aplicar los cambios hasta que no haya errores.
Si has utilizado este método, salta directamente al Paso 6.
Paso 5b: Importación mediante módulos
La ventaja de utilizar módulos es que puedes definir una gran cantidad de parámetros de recursos dentro del módulo y manipular archivos más sencillos dentro de los proyectos. También garantiza la consistencia entre tipos de recursos similares, ya que solo se ajustan los valores a través de las variables del módulo.
Comienza creando un archivo de módulo simple que contenga el tipo de objeto que se va a importar.
resource "aws_rds_db" "customers_db" { name = var.db_name } En el proyecto Terraform, invoca el módulo en el archivo Terraform:
module "custom_rds" { source = "../../modules/custom_rds.tf" } Importa el recurso al estado de Terraform, utilizando el comando `terraform import`, especificando la ruta al módulo, el tipo de recurso dentro del módulo, el nombre del recurso y el ID del recurso en AWS.
terraform import module.custom_rds.aws_rds_db.customers_db customers_db Terraform importa los recursos de la cuenta de AWS al estado de Terraform, vinculándolos al módulo. Una vez finalizada la importación, estás listo para el paso final.
Paso 6: Aplicar cambios con Terraform
Se recomienda realizar la aplicación final mediante un `terraform plan`. Esto permite verificar que los cambios no afectarán la infraestructura. Terraform mostrará cualquier diferencia entre la configuración actual y la declaración del módulo. Es posible que debas ajustar algunos parámetros dentro del módulo para sincronizar la configuración.
Una vez que todo esté sincronizado, aplica los cambios con `terraform apply`.
El recurso se ha importado a Terraform sin cambios inesperados en la infraestructura.
> terraform apply No changes. Your infrastructure matches the configuration. Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed. Apply complete! Resources: 0 added, 0 changed, 0 destroyed > Conclusión
La migración de sistemas de gestión de configuración es un trabajo meticuloso que requiere precisión, pero también ofrece la oportunidad de inventariar partes heredadas de la infraestructura, diseñar diagramas actualizados (muy útiles para la resolución de problemas) y detectar y limpiar recursos que ya no se utilizan. El cambio de CloudFormation a Terraform puede aportar mayor flexibilidad, eficiencia y control sobre la infraestructura en la nube, especialmente en entornos multi-nube o complejos.
Espero que hayas disfrutado de este artículo. No dudes en contactarme si tienes alguna pregunta.