Guía para la gestión de Terraform en AWS: CI/CD y autoservicio

En la primera parte de este artículo hablamos sobre la organización, nomenclaturas y despliegues de terraform. En este artículo continuaremos con los siguientes aspectos a tener en cuenta.

CI/CD

Una vez definidos los tipos de repositorios, su función y como se despliegan, vamos a ver como establecemos pipelines para automatizar los procesos.

Repositorios sin state

Empezaremos viendo los repositorios sin state sobre los que aplicaremos un “trunk based development”:

  • Pipeline Build: Este pipeline se triggeará cada vez que haya un commit sobre la rama main del repositorio. Este proceso solamente hará tests y formateos del código. Para probar los nuevos desarrollos sin tener que liberar versión se deberá apuntar a la rama main del repositorio desde una estructura de terraform de orden superior.
  • Pipeline Release: Este pipeline se triggeará cuando se haga un tag sobre el repositorio. Este proceso hará test, formateos del código y acciones adicionales para liberar correctamente una nueva reléase del repositorio. Finalmente generará un tag identificativo de la versión para su uso desde estructuras de terraform de orden superior.

Repositorios con state

Para los repositorios con state, vamos a asumir una política de branching estilo Git-Flow con 2 ramas (main y develop). Hay que recordar que para estos repositorios también existe el repositorio de configuración con las variables de entorno, sobre el que implementaremos procesos:

  • Pipeline Build: Este pipeline se triggeará cada vez que haya un commit sobre la rama develop del repositorio de código. El proceso deberá aplicar test y validaciones y finalmente descargarse la rama poc del repositorio de configuración y aplicar la mezcla de ambos repositorios en el entorno de poc.
  • Pipeline Release: Este pipeline se triggeará cuando se haga commit sobre la rama main (tras incluir los cambios probados en develop) del repositorio de código. El proceso deberá aplicar test y validaciones y gestionar que se aplique la nueva versión de código en todos los entornos. Para ello una estrategia podría ser aplicarlo automáticamente y de forma progresiva en los entornos no productivos e incluir al final una aprobación manual para el despliegue a producción, pero todo ello en el mismo flujo.
  • Pipelines configuración: Este pipeline se triggeará cuando se haga commit sobre alguna de las ramas del repositorio de configuración. La idea es que si en algún momento cambiamos alguna variable de entorno haya un proceso que haga efectivo ese cambio sin tener que estar tocando el código de la IaC. Para ello este proceso deberá identificar sobre que rama se ha hecho el cambio y en base a eso descargarse la rama correspondiente del repositorio de código (develop o main) y aplicarlo en el entorno correspondiente.

Si optamos por una política de branching basada en tags como “trunk based development” el pipeline de build se triggearía sobre la rama main y el pipeline reléase cuando se hagan tags. El pipeline de configuración funcionará igual, pero hay que añadir un detalle y es que al no tener una rama en el repositorio de código que identifique la versión productiva debemos identificar de alguna forma que versión esta aplicada en cada entorno.

Para esto podemos tener 2 enfoques, el primer sería generar un tag adicional (latest) en el repositorio de configuración que referencie la última versión. El segundo sería guardar de alguna forma en cada rama el tag/versión aplicada en dicho entorno.

Credenciales

Los diferentes repositorios de IaC son susceptibles de desplegar recursos en múltiples cuentas de AWS en función de como sea la organización de la empresa, sin embargo, todos los procesos de CI/CD deberían estar centralizados en una sola cuenta/herramienta. Por ello deberemos establecer una arquitectura de identidades para la aplicación de terraform.

En la cuenta/herramienta de CI/CD debe existir una credencial central que se usará como identidad principal en todos los repositorios de terraform. Dicha Identidad debe tener permisos para interactuar con el backend de terraform.

En cada cuenta donde se vayan a desplegar recursos se debe crear un rol con permisos de administrador que debe ser asumible por la credencial central que hemos creado previamente.

En los repositorios de terraform debemos configurar los providers de AWS de tal forma que tengamos un provider principal asociado con la credencial central y varios providers con alias referenciando a las cuentas destino de los recursos a crear. Los providers con alias se deben configurar para usarse asunción de roles a partir de la credencial central.

Autoservicio

Con los despliegues automatizados el siguiente paso es proporcionar capacidades de autoservicio sobre los diferentes blueprints que tengamos construidos.

El concepto de autoservicio es que cada vez que se necesite aprovisionar una arquitectura funcional (lo que hemos llamado blueprint, es decir, microservicio, cluster de kubernetes, etc), el peticionario interactúe con un formulario que contenga todas las características configurables de dicho blueprint y eso por detrás ejecute todos los procesos de creación de forma automática.

Esto proporciona una gran mejora en tiempos de creación comparado con el modelo tradicional de abrir petición, gestionar la necesidad en reuniones y el aprovisionamiento manual por parte del equipo técnico.

Entrando más al detalle, la implementación de estos autoservicios será algo diferente en función de si tenemos repositorio de live o no.

Implementación sin repositorios live

Si no tenemos repositorios de live la implementación es más sencilla. Debemos tener un frontal web con un formulario que contenga todas las configuraciones personalizables del blueprint (básicamente las tfvars que serán variables de entorno). Cuando se envíe el formulario se debe triggear un proceso que:

  • Recoja los valores introducidos por el peticionario.
  • Descargue el repositorio de código del blueprint correspondiente.
  • Genere el workspace de terraform correspondiente.
  • Aplique el código con las tfvars proporcionadas.
  • Persista los valores de las tfvars en un repositorio de git (el repositorio de configuración del que hemos hablado previamente), el cual tendrá que ser creado si es el primer entorno que se crea para el identificador de la instanciación del blueprint.

Implementación con repositorios live

Si adoptamos una estrategia de uso de repositorio de live, el proceso es algo más engorroso. Debemos tener un frontal web con un formulario que contenga todas las configuraciones personalizables del blueprint (básicamente las tfvars que serán variables de entorno). Cuando se envíe el formulario se debe triggear un proceso que:

  • Recoja los valores introducidos por el peticionario.
  • Identifique el repositorio live en el que se va a incluir el blueprint.
  • Descargue la rama correspondiente del repositorio de código y del repositorio de configuración.
  • Incluya el código terraform para invocar el módulo. Para esto lo más sencillo es tener en el blueprint un fichero que contenga la invocación a dicho blueprint para que el pipeline simplemente copie el fichero.
  • Aplique el código terraform modificado con los nuevos recursos.
  • Persista los cambios haciendo un commit en el repositorio.

Internal Developer Platform

Hasta ahora hemos planteado toda la estrategia de la IaC y de autoservicios basándonos únicamente en repositorios de git, pero una opción más actual puede ser el uso de Internal Developer Platforms para gestionar el frontal con los formularios de entrada, su backend para gestionar los procesos de aplicación de la IaC y su base de datos para la persistencia de los valores introducidos en los formularios.

Para este caso de uso escogeríamos el modelo de organización sin repositorios de tipo live. La estructura general sería la misma, pero deberíamos eliminar los repositorios de configuración ya que esa información se persistiría en la bbdd. También habría que eliminar los pipelines de configuración ya esos procesos se gestionarían desde el frontal mediante la modificación de un blueprint creado previamente.

Descubre otras partes de este artículo que podrían interesarte:

Parte 1: Guía para la gestión de Terraform en AWS: Organización, nomenclaturas y despliegue
Parte 3: Guía para la gestión de Terraform en AWS: Obsolescencia, compliance y buenas prácticas

Referencias

https://developer.hashicorp.com/terraform/tutorials/cloud/no-code-provis...

webinar AWS

Tags

Guía de posibilidades profesionales sobre AWS
He leído y acepto la política de privacidad
Acepto recibir emails sobre actividades de recruiting NTT DATA