Infraestructura como código (IaC): Terraform [Parte 1]

Luego de leer esta nota, vas a poder:

• Comprender lo básico de infraestructura como código (IaC)
• Ventajas de IaC
• Conocer Hashicorp Terraform para la implementación de IaC
• Cómo trabajar con Hashicorp Terraform
• Mejores prácticas con Terraform

¿Qué es Infraestructura como Código?

Infraestructura como código (IaC) es una combinación de estándares, prácticas, herramientas y procesos para aprovisionar, configurar, administrar y destruir una infraestructura utilizando un código.

Ventajas de Infraestructura como Código (IaC)

• Reutilización del código.
• Automatización, IaC facilita el aprovisionamiento y la aplicación de configuraciones de infraestructura, ahorrando tiempo. Estandariza los flujos de trabajo en diferentes proveedores de infraestructura (por ejemplo, VMware, AWS, Azure, GCP, etc.) mediante el uso de una sintaxis común en todos ellos.
• Control de versiones, nos permitirá tener seguimiento de cambios y total transparencia en nuestra documentación.
• IaC se puede aplicar durante todo el ciclo de vida, tanto en la construcción inicial como durante la vida útil de la infraestructura.

Hashicorp Terraform.

Terraform es una herramienta para construir, cambiar y versionar infraestructura de manera segura y eficiente. Terraform puede gestionar proveedores de servicios existentes y populares, así como soluciones internas personalizadas.

¿Cuáles son las características clave de Terraform?

Infraestructura como código: la infraestructura se describe mediante una sintaxis de configuración de alto nivel. Esto permite que un plano de su infraestructura sea versionado y tratado como lo haría con cualquier otro código. Además, la infraestructura se puede compartir y reutilizar.

Planes de ejecución: Terraform tiene un paso de “planificación” donde genera un plan de ejecución. El plan de ejecución muestra qué hará Terraform cuando llame a aplicar. Esto le permite evitar sorpresas cuando Terraform manipula la infraestructura.

Gráfico de recursos: Terraform crea un gráfico de todos sus recursos y paraleliza la creación y modificación de cualquier recurso no dependiente. Debido a esto, Terraform construye infraestructura de la manera más eficiente posible, y los desarrolladores obtienen información sobre las dependencias en su infraestructura.

Automatización de cambios: los conjuntos de cambios complejos se pueden aplicar a su infraestructura con una interacción humana mínima. Con el plan de ejecución y el gráfico de recursos mencionados anteriormente, usted sabe exactamente qué cambiará Terraform y en qué orden, evitando muchos posibles errores humanos.

¿Cuáles son las ventajas de Terraform?

• Agnóstico a la plataforma.
• Gestión de Estado.
• Compatible con diferentes soluciones en la nube.
• Función de almacenamiento e importación para arquitecturas existentes.
• Posibilidad de generar gráficos de dependencia.
• Puede ser versionado.

Principales Mejores prácticas para trabajar con terraform:

1. No hacer commit de el archivo .tfstate
2. Configurar un backend
3. Haga una copia de seguridad de su state
4. Mantenga sus backends de forma granular
5. Use un state por entorno
6. Configurar el bloqueo del state en el backend
7. Ejecute Terraform en una compilación automatizada
8. Manipular el state solo a través de comandos.
9. Usar variables
10. Utilice módulos (cuando sea necesario)

Según Hashicorp, para escribir un módulo de Terraform es recomendable utilizar tres ficheros para definir los recursos.

Main.tf

Cada proyecto Terraform está organizado en sus propios directorios. Al invocar cualquier comando que cargue el main.tf, Terraform carga todos los archivos de configuración dentro del directorio de trabajo en orden alfabético. Es importante tomar en cuenta esto al configurar recursos que pueden depender uno del otro.

El main.tf reúne todos los recursos o configuraciones que serán creados, desde ahí podremos invocar nuestros archivos que contengan variables y directorios módulos de terraform (locales o remotos). También es posible definir configuraciones y variables dentro del main.tf para desplegar recursos.

Variables Outputs

Variables outputs es una forma de organizar los datos para ser consultados fácilmente y mostrados al usuario de Terraform.

Los Outputs son una forma de decirle a Terraform qué datos son importantes. Estos datos se generan cuando se ejecuta el apply, y se pueden consultar utilizando el comando de terraform output

Para esto podríamos crear un archivo independiente llamado outputs.tf donde donde definiriamos todos los datos que queremos obtener de los recursos creados.

Variables

Las variables en Terraform son una excelente manera de empaquetar su configuración con datos fácilmente legibles. Al igual que con cualquier lenguaje de programación, las variables toman diferentes formas en función de la información que desea almacenar. Sin embargo, con los parámetros específicos del proveedor de nube, estos pueden ser difíciles de administrar. Por lo tanto, en lugar de llenar su archivo “main.tf” con definiciones variables, colóquelas en un archivo diferente. La consolidación de variables le permite compartir fácilmente las configuraciones y al mismo tiempo poder cambiar los valores cuando sea necesario. Para una personalización adicional, Terraform proporciona un par de formas de incluir archivos variables en su configuración.

Para permitir que Terraform cargue automáticamente las variables, el archivo debe denominarse terraform.tfvars o * .auto.tfvars y colocarse en el mismo directorio que el archivo de configuración de Terraform. Los archivos variables que se cargan automáticamente se realizarán en orden alfabético.

Ahora, para comenzar, cada directorio de proyecto de Terraform debe inicializarse, esto lo hacemos ejecutando:

Terraform init

Con esto Terraform configura el directorio para admitir los planes de implementación, como lo seria el main.tf o distintos archivos *.tf

El flujo de trabajo principal de Terraform tiene tres pasos:

1. Write — Infraestructura de autor como código.

2. Plan: vista previa de los cambios antes de aplicar.

3. Apply: — Provisión de infraestructura reproducible.

Provider: responsable de comprender las interacciones API y exponer recursos. Debido a que Terraform puede interactuar con cualquier API, puede representar casi cualquier tipo de infraestructura como un recurso en Terraform. Providers o proveedores pueden ser: AWS, Google, Azure, VMware, etc.

Terraform state: Terraform utiliza este estado para asignar recursos del mundo real a su configuración, realizar un seguimiento de los metadatos y mejorar el rendimiento de las grandes infraestructuras.

Mapping: Terraform requiere algún tipo de base de datos para asignar la configuración de Terraform al mundo real porque no puede encontrar la misma funcionalidad en todos los proveedores de la nube. Debes tener algún tipo de mecanismo para ser independiente de la nube

Metadata: Terraform también debe rastrear metadatos, como dependencias de recursos, configuración del proveedor que se utilizó más recientemente con el recurso en situaciones en las que hay múltiples proveedores con alias.

Performance: Al ejecutar un plan, Terraform debe conocer el estado actual de los recursos para determinar de manera efectiva los cambios que necesita realizar para alcanzar la configuración deseada.

Manejo del “state” de terraform:

Para el manejo del state de terraform usaremos el command state, se usa para la gestión avanzada del estado. A medida que su uso de Terraform se vuelve más avanzado, hay algunos casos en los que es posible que deba modificar el estado de Terraform.

Uso del command state

terraform state <subcommand> [options] [args]

Para listar recursos de un script terraform guardados en un estado ejecutamos:

Terraform state list

Para listar el estado de un recurso en específico ejecutamos:

Terraform state list <nombre del recurso>

Para mostrar los argumentos de un recurso ejecutamos:

Terraform state show ‘nombre del recurso’

Para descargar un estado remoto ejecutamos:

Terraform state pull

Para subir un estado local a un estado remoto ejecutamos:

Terraform state push

Backend: El “backend” en Terraform determina cómo se carga el estado y cómo se ejecuta una operación como apply. Esta abstracción permite el almacenamiento de estado de archivos no locales, la ejecución remota, etc.

Por defecto, Terraform usa el backend “local”, que es el comportamiento normal de Terraform.

Backend local: Almacena el estado en el sistema de archivos local, bloquea ese estado utilizando las API del sistema y realiza operaciones localmente.

// Example

terraform {

backend “local” {

path = “relative/path/to/terraform.tfstate”

}

}

Backend Remoto: permite que Terraform use un espacio de almacenamiento compartido para datos de estado, por lo que cualquier miembro de su equipo puede usar Terraform para administrar la misma infraestructura. El estado remoto se carga solo en la memoria cuando se usa.

terraform {

backend “s3” {

bucket = “mybucket”

key = “path/to/my/key”

region = “us-east-1”

}

}

¿Qué es el locking de terraform state?

Si su backend lo admite, Terraform bloqueará el terraform.state para todas las operaciones que podrían escribir en el state. Esto evita que otros adquieran el bloqueo y corrompan potencialmente su state.

El bloqueo de state ocurre automáticamente en todas las operaciones que podrían modificarlo. No verá ningún mensaje de lo que está sucediendo. Si el bloqueo del state falla, Terraform no continuará.

¿Cómo hacer un backup del state en el remote backend?

1. Al configurar un backend por primera vez (pasar de un backend no definido a una configuración explícita), Terraform le dará la opción de migrar su estado al nuevo backend. Esto le permite adoptar backends sin perder ningún estado existente.

2. Para tener más cuidado, siempre recomendamos hacer una copia de seguridad manual de su estado también. Puede hacerlo simplemente copiando su archivo terraform.tfstate a otra ubicación.

¿Qué son los Workspaces (Espacio de Trabajo)?

Cada configuración de Terraform tiene un backend asociado que define cómo se ejecutan las operaciones y dónde se almacenan los datos persistentes, como el estado de Terraform.

Los datos persistentes almacenados en el backend pertenecen a un espacio de trabajo. Inicialmente, el backend tiene un solo espacio de trabajo, llamado “default”, y por lo tanto solo hay un estado Terraform asociado con esa configuración.

Ciertos backends admiten múltiples espacios de trabajo con nombre, lo que permite asociar varios estados con una sola configuración.

Para listar los workspaces ejecutar:

terraform worspaces list

Para crear un nuevo workspace

terraform workspace new <name>

Para mostrar el workspace actual

terraform workspace show

Para cambiar de workspace:

terraform workspace select <workspace name>

Para borrar un workspace:

terraform workspace delete <workspace name>

¿Cuál es la diferencia entre entornos separados por directorios y workspaces?

Los entornos separados por directorio dependen de un código de Terraform duplicado, que puede ser útil si sus implementaciones necesitan ser diferentes, por ejemplo, para probar los cambios de infraestructura en el desarrollo. Pero pueden correr el riesgo de crear choque entre los entornos con el tiempo.

Los entornos separados por workspaces usan el mismo código Terraform pero tienen diferentes archivos de estado, lo cual es útil si desea que sus entornos se mantengan lo más similares posible, por ejemplo, si proporciona infraestructura de desarrollo a un equipo que quiere simular la ejecución producción.

Módulos

Un módulo Terraform es un conjunto de archivos de configuración de Terraform en un solo directorio. Incluso una configuración simple que consiste en un único directorio con uno o más archivos .tf es un módulo.

¿Para qué usar módulos?

• Organizar configuración
• Configuración encapsulada
• Reutilizar configuración
• Proporcionar consistencia y garantizar las mejores prácticas.

¿De qué maneras puedes cargar o llamar los módulos desde el main.tf?

Los módulos pueden ser llamados desde un directorio local o desde un recurso remoto, por ejemplo:

• Local paths
• Terraform Registry
• GitHub
• Generic Git, Mercurial repositories
• Bitbucket
• HTTP URLs
• S3 buckets
• GCS buckets

Mejores prácticas para trabajar con Módulos

1. Use módulos locales para organizar y encapsular su código. Incluso si no está utilizando o publicando módulos remotos, organizar su configuración en términos de módulos desde el principio reducirá significativamente la carga de mantener y actualizar su configuración a medida que su infraestructura crece en complejidad.
2. Comience a escribir su configuración con los módulos en mente. Incluso para configuraciones de Terraform (main.tf) modestamente complejas administradas por una sola persona, encontrará que los beneficios de usar módulos superan el tiempo que lleva usarlos.
3. Use el registro público de Terraform https://registry.terraform.io/ para encontrar módulos útiles. De esta manera, puede implementar su configuración de manera más rápida y segura confiando en el trabajo de otros para implementar escenarios de infraestructura comunes.
4. Publica y comparte módulos con tu equipo. La mayoría de la infraestructura es administrada por un equipo de personas, y los módulos son una forma importante de que los equipos puedan trabajar juntos para crear y mantener la infraestructura. Como se mencionó anteriormente, puede publicar módulos de forma pública o privada, en otro capítulo de la serie Terraform mostraré como publicar modulos.

¿Cómo definir Variables para un módulo?

La configuración que llama a un módulo es responsable de establecer sus valores de entrada o inputs variables, que se pasan como argumentos en el bloque del módulo. Aparte del source y la versión, la mayoría de los argumentos para un bloque de módulo definirán valores para las variables.

¿Cómo se accede a los outputs o variables de salida desde los módulos?

Se puede acceder haciendo referencia de la siguiente manera:

module.<MODULE NAME>.<OUTPUT NAME>

¿Dónde definimos las variables de salida o outputs del módulo?

Las salidas del módulo generalmente se pasan a otras partes de su configuración o se definen como salidas en su módulo raíz o main.tf

Sobre el autor:

System Engineer, over 15 years of infrastructure development, architecture and IT management, Linux lover since i was born, technology evangelist, especially open source. Now focused on new cloud/devops technologies and Infrastructure as Code.

In my free time i play Counter Strike and Valorant.