Cloud DevOps

Módulo 3
Terraform
HTML5: Fundamentos Web
Cloud DevOps

Terraform
Ya hicimos una breve introducción a Terraform,
en esta oportunidad haremos un repaso de los
archivos necesarios y de cómo es el proceso
completo desde que se desarrollan los recursos
hasta que los creamos y cómo podremos
reutilizar el código.

Además, analizaremos también sus beneficios y

algunas de sus desventajas.
Cloud DevOps

Terraform es una herramienta de Terraform por sí solo no es más que solo un

infraestructura creada por la organización esqueleto, necesitamos valernos de providers
Hashicorp y lanzada al público en julio de 2014. que agregarán funcionalidades para así poder
Es una herramienta que mediante el lenguaje crear los recursos que se deseen. Por ejemplo, si
propietario de Hashicorp, HCL (Hashicorp Coding trabajamos con AWS necesitaremos utilizar el
Language) nos permite crear distintos tipos de provider de AWS, lo mismo con Azure y con GCP.
recursos.
Cloud DevOps

Arquitectura Terraform

DevOps/Infra Terraform manifest Terraform Core State file (.tfstate)

Engineer files (.tf)

Providers
Terraform plan
Terraform apply Azure, GCP, AWS, VMWare, etc.

Provisioners
Cloud Service Providers
Remote-exec, Local-exec, etc.

Plugins
Cloud DevOps

Terraform core

Llamamos core al núcleo de Terraform, es decir, el binario

que utilizaremos para interactuar con la herramienta,
que cuenta con una parte que contiene la configuración de
Terraform (como por ejemplo, la del backend donde se
guarda el estado).
Cloud DevOps

Ejemplos

El siguiente bloque de código configura la El siguiente ejemplo configura el backend de

herramienta para utilizar el provider de AWS Terraform para que utilice un bucket de S3 (AWS)
descargado del registry de Terraform: para almacenar el estado (Es importante
destacar que el bucket de S3 debe ser
terraform { previamente creado. Terraform no lo creará):
required_providers {
aws = {
terraform {
source = "hashicorp/aws"
backend "s3" {
version = "~> 1.0.4"
bucket = "<nombre del bucket>"
}
key = "<path donde queremos almacenar
}
el estado dentro del bucket>"
}
region = "us-east-1"
}
}
Cloud DevOps

Terraform providers

También conocidos como plugins de Terraform

son componentes que podremos agregar al
código para agregar funcionalidades. Existen
distintos tipos, desde proveedores oficiales,
proveedores hechos por la comunidad hasta
incluso podremos desarrollar nuestros propios
proveedores customizados.

Con respecto al proveedor necesitamos 2 bloques

de código, uno que defina la versión y de dónde
lo descargaremos y uno que configure el
proveedor (ya sea con credenciales u otro tipo de
configuración, depende de cada proveedor).
Cloud DevOps

Ejemplo

Repetimos el ejemplo visto en el caso anterior Y en el siguiente bloque de código lo

para instalar el proveedor de AWS: configuraremos:

terraform { provider "aws" {

required_providers { region = "us-west-2"
aws = { access_key = "<my-access-key>"
source = "hashicorp/aws" secret_key = "<my-secret-key>"
version = "~> 1.0.4" }
}
}
}
(Tener en cuenta que esta no es la forma más
segura de configurar el provider ya que estamos
exponiendo las credenciales en texto plano).
Cloud DevOps

Estado

El estado de Terraform es uno de los Como buena práctica se recomienda trabajar con
componentes más importantes y delicados de un backend remoto, generalmente una opción de
toda la herramienta. Guardará una relación entre almacenamiento en la nube como S3 con AWS,
nuestros archivos de configuración de junto a un sistema de bloqueo para evitar que
Terraform con los recursos que creamos y la otra persona quiera escribir el estado mientras
infraestructura creada. En caso de perder, borrar uno está trabajando con él aplicando cambios.
o corromper este archivo, Terraform no manejara
más la infraestructura que fue creada en la nube
y tendremos que pasar a manejarla a mano (a
través de la consola o por terminal (API).
Cloud DevOps

Ejemplo

{
"version": 4,
"terraform_version": "1.2.3",
"serial": 1,
"lineage": "86545604-7463-4aa5-e9e8-a2a221de98d2",
"outputs": {},
"resources": [
{
"mode": "managed",
"type": "aws_instance",
"name": "example",
"provider": "provider[\"registry.terraform.io/...\"]",
"instances": [
{

…
Cloud DevOps

…
Este código fue recortado para
"schema_version": 1, mejorar su lectura pero se puede
"attributes": { ver como en formato json vemos
"ami": "ami-0fb653ca2d3203ac1",
"availability_zone": "us-east-2b",
los distintos recursos creados, qué
"id": "i-0bc4bbe5b84387543", proveedor fue utilizado, el tipo de
"instance_state": "running", recurso, sus atributos, etc.
"instance_type": "t2.micro",
"(...)": "(truncated)"
}
} Fuente: Blog.gruntwork.io
]
}
]
}
Cloud DevOps

Archivos de configuración

Si bien no son un componente en sí mismo sino Estos archivos están escritos en lenguaje HCL y
un conjunto que engloba a varios archivos tienen la terminación “.tf”. El nombre que le
(como parte del core y de los proveedores), son asignamos a los archivos es indistinto para la
los que utilizaremos para configurar distintos herramienta aunque, en reglas generales, se
aspectos de Terraform como así también definir suele trabajar con un archivo llamado “main.tf”.
los recursos que se crearán. En muchos casos, para mayor prolijidad, lo
dividiremos en varios archivos con funciones bien
divididas, como por ejemplo un archivo llamado
backend.tf donde tendremos toda la
configuración del backend, ya sea remoto o local,
o providers.tf donde configuraremos los
proveedores que se utilizarán para tenerlo
separado del código principal de nuestros
recursos.
Cloud DevOps

Similar a los archivos previos pero en este caso

tenemos de ejemplo un archivo de configuración
donde crearemos una instancia o máquina virtual
en AWS:

resource "aws_instance" "web" {

ami = “ami-0dcc1e21636832c5d”
instance_type = "t3.micro"

tags = {
Name = "Prueba"
}
Cloud DevOps

Terraform Registry
El registro de Terraform es su repositorio Los módulos son paquetes de código HCL que
principal de código, donde podremos encontrar se enfocan en una funcionalidad en específico,
tanto proveedores como módulos. Aunque no por ejemplo podremos encontrar módulos que se
solo encontraremos el código sino también encarguen de configurar una cuenta de AWS en
documentación de cómo usar los proveedores. base a ciertos parámetros. Nos ayudan a no
Como mencionamos antes, encontraremos repetir código en caso de que queramos crear
proveedores oficiales y proveedores múltiples instancias pero con distintos
desarrollados por la comunidad, lo mismo para argumentos de uno o más recursos.
los módulos.
Cloud DevOps

A nivel proveedores se suele trabajar con los proveedores

oficiales mientras que con respecto a los módulos las
organizaciones suelen desarrollar sus propios módulos y
distribuirlos de forma interna, estos los suelen almacenar
de forma privada en repositorios de código como Github.

Registro de Terraform
Cloud DevOps

Módulos de Terraform
Como bien ya vimos más arriba, los módulos De esta forma, podremos crear un ambiente de
básicamente son código de Terraform producción donde la instancia y la base de datos
estandarizado de forma tal que nos permite podamos pasar a través de variables el tipo de
parametrizarlo para que pueda ser fácilmente instancia para utilizar una que tenga más
reutilizable. recursos, mientras que en un ambiente de testing,
por ejemplo, utilizaríamos instancias más chicas
Por ejemplo
y de esta forma escribimos la mayoria del codigo
En caso de que nuestra aplicación principal conste de una
1 sola vez en el modulo y despues solamente lo
instancia EC2, una base de datos RDS y una VPC con sus
respectivas Subnets, podremos crear un módulo que instanciamos.
contenga todo esto y parametrizar.
Cloud DevOps

Terraform Workflow

</> Init Plan Apply

Practitioner Infraestructura
como código
Cloud DevOps

Para trabajar con Terraform tenemos un flujo de El paso del dry-run es opcional ya que por defecto el
terraform apply nos hace un plan y nos da la opción de
trabajo que consiste en cuatro pasos:
validarlo antes de aplicarlo sin preguntar.

1. Escribir el código.

2. Instalar los proveedores y módulos (Terraform

Init).

3. Hacer un dry-run (Terraform plan, este paso

es opcional).

4. Applicarlo (Terraform apply).

5. Y eliminar la infraestructura en caso de que

tengamos que borrarla (Terraform Destroy).
Cloud DevOps

Ventajas de Terraform
● Una de las principales, que ya mencionamos, ● Otra ventaja es que el código HCL permite que
es su capacidad de trabajar con cualquier gente de equipos de operaciones o
tipo de nube no solamente con AWS en infraestructura pueda utilizar esta herramienta
cuestión de cambiar el provider. No solo sin necesidad de contar con experiencia o
funciona para interactuar con la nube sino con conocimientos profundos del mundo del
muchos otros elementos y, en caso de no desarrollo de software.
haber un proveedor oficial, podremos utilizar
uno desarrollado por la comunidad y en el
peor de los casos, desarrollarlo nosotros en
caso de que no exista.
Cloud DevOps

● Al ser una de las herramientas más populares

(por no decir la más popular) para lo que es
Infraestructura como código, cuenta con una
comunidad gigante que está constantemente
aportando. Además Hashicorp cuenta con
planes Enterprise con distintas opciones para
organizaciones que requieran un nivel de
soporte o ciertas características específicas de
estos planes.
Cloud DevOps

Desventajas de Terraform
● Si bien el HCl es sencillo, al mismo tiempo es ● Si bien en muchas ocasiones el manejo del
una gran limitación ya que en muchos casos estado puede ser visto como una ventaja ya
se nos quedará corto en caso de que que nos da la libertad de manejarlo a nuestro
tengamos alguna necesidad complicada que gusto, es una carga operacional muy grande
tengamos que solucionar con Terraform. Al que para equipos inexpertos en la herramienta
mismo tiempo, no contamos con todas las puede ser un problema.
capacidades de un lenguaje de programación
convencional como lo es Python, JavaScript, ● Tiene una curva de aprendizaje que puede ser
C#, etc, como podríamos utilizar con CDK o un poco empinada para equipos inexpertos en
Pulumi. el uso correcto de los módulos con respecto a
la estructura de directorios y variables.
¡Sigamos
trabajando!