Hace años que trabajo como Ingeniero DevOps y la mejor forma de trabajar en equipo es ponerse de acuerdo. Además, en una empresa mediana grande, ya se automatizan los deploys de terraform con pipelines y uno ya deja de tocar a mano, o también si usa terraform Cloud. En mi experiencia, nadie crea infraestructura a mano, porque si ocurre un drift, lo que no está en código se borra en la siguiente ejecución del pipeline. Los tfstates deberían estar acotados a un proyecto y es muy útil tener workspaces en función del entorno. Otra cosa que puedo aportar es que los proyectos de terraform van bien con la estrategia trunk-based de git, ya que se suelen tener varios archivos de tfvars asociados a los entornos, todo esto si no se usa terragrunt. No estoy de acuerdo con tener tfstates por todos lados, porque se aumenta el riesgo de desorganización y se hace inmantenible, más que nada cuando usas pipelines.
Todo el video pensando en Terragrunt y justo al final lo mencionais ☺ Llevo solo un año en este mundillo SRE, pero estoy aprendiendo muchísimo con este tipo de contenido. Muchas gracias
Yo uso el directorio "common" en lugar de "base" en la raíz y ahí suelo meter network, roles y policies. Con terragrunt apply run-all en la raiz te ejecuta todos los directorios recursivamente, pero es verdad que no se usa mucho porque al final siempre estás operando sobre algo limitado. Lo veo interesante para un producto que tienes muy trillado y que despliegues en infras de cliente como churros. Pero creo que es el escenario menos común.
Vale, apenas estoy empezando con terraform pero la manera tan cool como están explicando me hizo ver y entender todo, muchas gracias por estos aportes!
Hola, el drift no es un problema como tal de terraform sino mas bien un problema del equipo de trabajo. Si se esta gestionando la infra como codigo con terraform nadie deberia estar haciendo cambios manuales y si se realizan esos cambios manuales a modo de pruebas deberian normalizarse en el codigo terraform para que el plan quede consistente.
No queda muy clara la diferencia entre la infra de Kubernetes y la infra de los servicios como tal, si por ejemplo se busca desplegar esos microservicios dentro de Kubernetes?
Ok muy bien todo, me surge una duda con respecto a los backends de cada tfstate, ya que es buena practica siempre mantener ese archivo en remoto por cualquier eventualidad en el storage de tu local (si llegases a formatear tu pc, se arruina el disco,etc.), tendrias que irlos almacenando en un S3 por cada tfstate o en una sola ubicacion (un solo bucket S3 para todos los tfstate) ?
Te recomiendo leer el artículo "Keep your remote state configuration DRY" y utilizar por supuesto terragrunt, el cual te resuelve todos los problemas de gestión de estados
Separar un primer nivel por entorno no lo veo práctico. En general los entornos suelen estar alineados, a excepción a veces del dimensionamiento de recursos específicos. En su lugar, personalmente, prefiero usar las mismas plantillas para todos los entornos, aplicándolos en diferentes stages, utilizando un fichero de variables diferente por cada entorno.
¿Qué buenas prácticas aplicas usando Terraform?
🪐 Curso completo de Terraform: bit.ly/curso-terraform-codely
Mi buena práctica es llamarlo templatizar en lugar de plantillear 😂
Me ha encantado la performance de Lobezno, un puntazo!!
Hace años que trabajo como Ingeniero DevOps y la mejor forma de trabajar en equipo es ponerse de acuerdo. Además, en una empresa mediana grande, ya se automatizan los deploys de terraform con pipelines y uno ya deja de tocar a mano, o también si usa terraform Cloud. En mi experiencia, nadie crea infraestructura a mano, porque si ocurre un drift, lo que no está en código se borra en la siguiente ejecución del pipeline. Los tfstates deberían estar acotados a un proyecto y es muy útil tener workspaces en función del entorno. Otra cosa que puedo aportar es que los proyectos de terraform van bien con la estrategia trunk-based de git, ya que se suelen tener varios archivos de tfvars asociados a los entornos, todo esto si no se usa terragrunt. No estoy de acuerdo con tener tfstates por todos lados, porque se aumenta el riesgo de desorganización y se hace inmantenible, más que nada cuando usas pipelines.
Es justo el caso de uso que tengo, muchas gracias!
Todo el video pensando en Terragrunt y justo al final lo mencionais ☺ Llevo solo un año en este mundillo SRE, pero estoy aprendiendo muchísimo con este tipo de contenido. Muchas gracias
Yo uso el directorio "common" en lugar de "base" en la raíz y ahí suelo meter network, roles y policies. Con terragrunt apply run-all en la raiz te ejecuta todos los directorios recursivamente, pero es verdad que no se usa mucho porque al final siempre estás operando sobre algo limitado. Lo veo interesante para un producto que tienes muy trillado y que despliegues en infras de cliente como churros. Pero creo que es el escenario menos común.
Vale, apenas estoy empezando con terraform pero la manera tan cool como están explicando me hizo ver y entender todo, muchas gracias por estos aportes!
El título del vídeo dice evitar drift pero no he visto ninguna propuesta en este vídeo, me he perdido algo?
Una pregunta, este tipo de problemas con drift no lo soluciona Crossplane? que desplegaria lo nuevo + lo editado?
Hola, el drift no es un problema como tal de terraform sino mas bien un problema del equipo de trabajo. Si se esta gestionando la infra como codigo con terraform nadie deberia estar haciendo cambios manuales y si se realizan esos cambios manuales a modo de pruebas deberian normalizarse en el codigo terraform para que el plan quede consistente.
No queda muy clara la diferencia entre la infra de Kubernetes y la infra de los servicios como tal, si por ejemplo se busca desplegar esos microservicios dentro de Kubernetes?
Qué le ha pasado en el pelo?
Ok muy bien todo, me surge una duda con respecto a los backends de cada tfstate, ya que es buena practica siempre mantener ese archivo en remoto por cualquier eventualidad en el storage de tu local (si llegases a formatear tu pc, se arruina el disco,etc.), tendrias que irlos almacenando en un S3 por cada tfstate o en una sola ubicacion (un solo bucket S3 para todos los tfstate) ?
Te recomiendo leer el artículo "Keep your remote state configuration DRY" y utilizar por supuesto terragrunt, el cual te resuelve todos los problemas de gestión de estados
Separar un primer nivel por entorno no lo veo práctico. En general los entornos suelen estar alineados, a excepción a veces del dimensionamiento de recursos específicos. En su lugar, personalmente, prefiero usar las mismas plantillas para todos los entornos, aplicándolos en diferentes stages, utilizando un fichero de variables diferente por cada entorno.
Es un craá