El documento describe Terraspace, un framework para Terraform que proporciona una estructura organizada de directorios y convenciones para configuraciones. Terraspace sigue principios como DRY y genera automáticamente proyectos, módulos y stacks de Terraform. El framework también admite características como backends múltiples, variables de entorno, secrets, pruebas y despliegue de múltiples stacks.

1. Terraspace
The definitive Terraform framework
by @mario21ic

2. Una Infraestructura “chiquitita”
1. Un EC2 + EIP (zona publica) con el App de la empresa y RDS.
2. Un ELB para carga y EC2 en 2 zonas para HA.
3. Un VPC propio, EC2 y RDS en zonas privadas y ELB en zona publica.
4. Un par de SSM roles para evitar bastion e IPs en Security Groups.

3. 1.- Un EC2 + EIP (zona publica) con el App de la empresa y RDS.

4. 2.- Un ELB para carga y EC2 en 2 zonas para HA.

5. 3. Un VPC propio, EC2 y RDS en zonas privadas y ELB en zona publica.

6. 3. Un VPC propio, EC2 y RDS en zonas privadas y ELB en zona publica.

7. 4. Un par de SSM Roles para evitar bastion e IPs en Security Groups

8. 1. Desplegar lo mismo para:
a. Dev.- una aws account en especifico.
b. Test.- en otra account pues se elimina todo a fin de semana.
c. Stage.- en la región Oregon.
d. Prod.- region Virginia.
2. Desplegar lo mismo en la cuenta Aws del cliente.
Nuevos requerimientos

9. Algunas consideraciones
1. El código de la infraestructura debe ejecutarse en otra cuenta (backend s3).
2. El mismo Environment (qa, stage, dev, etc) en otra aws region.
3. DRY en variables, módulos, backends, providers, etc.
4. Manejo de Aws Secrets en el código.
5. Debemos agregar Tests de Integración y Unitarios.
6. Estandarizar la estructura de las carpetas.
7. Entender y graficar las dependencias.

10. ● Terraform Framework
● Provee una estructura organizada de directorios
● Convenciones sobre configuraciones (app/modules, app/stacks,
config/terraform)
● DRY
● Escrito en Ruby
● https://terraspace.cloud/
Terraspace

11. ● DRY (config, modules, stacks, helpers, hooks, etc)
● Generators (projects, modules, stacks, tfvars, etc)
● Multiple Environments (tfvars and layering)
● Deploy Multiple Stacks
● Secrets support
● Terrafile
● Configurable Hooks & CLI
● Testing
Terraspace Features

12. Don’t Repeat Yourself (DRY)

13. Modules & Stacks
Modules:
Son piezas de código reutilizables y génericos.
Stacks:
Usan los modules para generar infraestructura
de una solución en especifica.

14. Algunas soluciones propias
1. Dividir recetarios y guardar valores en Consul:
○ Network: vpc, subnets, acl, nat gateway, internet gateway, security groups, etc
○ IAM: users, roles, policies, etc
○ Components: elb, ec2, rds, k8s cluster, autoscaling, launch template, target group, etc
Inconvenientes:
● Necesitas desplegar Consul y mantenerlo.
● Codigo HCL para leer y escribir en Consul. Ademas de invocarlo en recetario.
● Outputs desperdiciados.
● Estados de cada componente en un S3 bucket y diferentes Keys (paths).

15. Backends
Generación automatica del backend.tf de
clouds como:
● Aws: S3 bucket y DynamoDB (locks)
● Azure Storage Account
● Google Cloud Storage (GCS)
Revisar config/terraform/backend.tf

16. Backends
Usando variables:
● Account Id
● Region
● Env

17. Locks
Para evitar colisiones en la actualización de
recursos se requiere de una tabla de “locks” en
Aws DynamoDB.
Revisar config/terraform/backend.tf

18. Algunas soluciones
1. Crear un script para reemplazar el Backend antes de cada terraform apply
Inconvenientes:
● Crear el script y testearlo.
● Se debe crear S3 bucket y DynamoDB para cada proyecto.

19. Tfvars Layering
Usar el mismo código para crear múltiples
Environments.
1. base.tfvars valores iniciales
2. dev.tfvars puede sobreescribir
valores.
3. region/dev.tfvars para una region
en especifico.
4. account/dev.tfvars para una cuenta
en especifico.

20. Algunas soluciones
1. Script a mano que lea un base.tfvars y haga un merge con el del entorno
dev.tfvars por ejemplo
Inconvenientes:
● Como validar que se están tomando los valores?
● Hacer test del script

21. Secrets Supports
Puedes leer datos desde:
● Aws Secrets Manager
● Aws SSM Parameter Store
● Azure Key Vault
● Google Secrets Manager

22. Algunas soluciones propias
1. Script para leer datos y luego reemplazar el codigo antes de hacer terraform
apply.
2. Usar Hashicorp Vault
Inconvenientes:
● Llenarte de scripts y parámetros
● Como testearias los scripts?
● Instalación de mas servicios y debes mantenerlos.
● Fija que un valor solo se saque de un cloud provider.

23. Multiples Stacks
Desplegar y Eliminar Multiples Stacks con un
solo comando:
● $ terraspace all up
● $ terraspace all down
Otros comandos:
● $ terraspace all init
● $ terraspace all plan
● $ terraspace all output
● $ terraspace all providers
● $ terraspace all refresh
● $ terraspace all validate

24. Algunas soluciones
1. Crear un script para que recorra cada carpeta y haga:
$ terraform init
$ terraform workspace select myenv
$ terraform plan -var-file=myenv.tfvars
$ terraform apply -var-file=myenv.tfvars
Inconvenientes:
● Manejo de Estados por cada carpeta y Backend en S3.

25. Terraform Modules centralizado
Se define en Terrafile como por ejemplo:
mod "sg", source:
"terraform-aws-modules/security-group/aws",
version: "3.10.0"
mod "vpc", source:
"terraform-aws-modules/vpc/aws", version:
"3.10.0", stack: "simple-vpc"
Instalacion y uso:
$ terraspace bundle
$ ls -la vendor/modules

26. Generators
Enfocarnos en el código y olvidarnos de las
estructuras. Usando el comando:
terraspace new
● project myproject
● module mymodule
● stack mystack
● helper myhelper
● hook myhook
● arg myarg
● test mytest
Nuevo Environment:
$ export TS_ENV=qa
$ terraspace seed mystack

27. Algunas soluciones
1. Tener plantillas para cada tipo de recurso: vars, outputs, module, etc
2. Crear un script para copiar las plantillas y pegarlas en cada carpeta.
Inconvenientes:
● Un script para cada cosa

28. Testing
● Concepto de Test Harnesses, copiar y
ejecutar en un nuevo directorio.
● Deploy de todo el Modulo o Stack y
Eliminar todo al terminar.
● Tests de Integración
● Tests Unitarios para Helpers

29. Configurable
Extender las funcionalidades de Modulos, Stacks,
etc mediante:
Hooks:
● $ terraspace new hook --type project hook1
● $ terraspace new hook --type module hook2
● $ terraspace new hook --type stack hook3
Args CLI:
● $ terraspace new arg --type project mpyarg
● $ terraspace new arg --type module mymarg
● $ terraspace new arg --type stack mysarg

30. Recomendaciones
1. Crear Terraform módulos propios solo cuando sea necesario y usar
preferentemente https://registry.terraform.io/
2. Siempre tener en cuenta DRY (Don’t Repeat Yourself)
3. Leer siempre la documentación (RTFM) https://terraspace.cloud/docs/intro/
4. A veces hacer una PoC puede evitar dolores de cabeza en el futuro.
5. No tool obsession, que la herramienta se adecue a la solución.
6. No existe la bala de plata.
7. Replique y modifique https://github.com/mario21ic/terraspace-demo