Terraform desde las Trincheras (Buena práctica ‘Agrupación de capas lógicas’)
En el dia a dia cuando uno implementa la Infraestructura como Código (IaC) con Terraform es a veces un poco difícil reservar un tiempo para ponerse a pensar si la forma de trabajo actual es la mejor o si existen buenas prácticas que podemos ir aplicando para resolver problemas y/o mejorar en nuestras implementaciones, permitiendo que en nuevos proyectos se aplique ello desde el inicio.
En Internet existe bastante información de calidad que trata sobre las buenas prácticas de IaC con Terraform y compartimos en este artículo las que hemos podido utilizar en nuestros proyectos de Azure esperando que faciliten una curva de aprendizaje para aquellos que aún no las aplican.
Si no se tiene conocimiento básico de IaC con Terraform recomendamos revisar estos enlaces de forma previa para no tener complicaciones en la lectura del artículo:
Como ejemplo, utilizaremos un proyecto de referencia llamado Pisco que tiene la siguiente arquitectura cloud en Azure:
En el diagrama anterior se muestra una vista de la arquitectura cloud donde se está usando un estilo arquitectural Hub & Spoke debido a que tenemos 2 entornos (DEV-PRE y PROD) que compartirán componentes y configuraciones comunes que están en la sección Hub y luego están los componentes y configuraciones propios de cada entorno que están en la sección Spoke de DEV-PRE y PROD.
La aplicación del proyecto Pisco solo consta de componentes backend a nivel de software: Microservicio en Java desplegado sobre un App Service y una Base de Datos desplegada sobre un Azure PostgreSQL, ambos con private endpoints que protegen y restringen su acceso.
El Application Gateway + WAF cumple el rol de balanceador de aplicación y brinda seguridad que evita los riesgos OWASP, además permiten el acceso desde Internet con dominios personalizados para la aplicación del proyecto Pisco.
Agrupación de capas lógicas
Esta buena práctica consiste en identificar sobre la arquitectura cloud: ¿cómo agrupamos los componentes cloud?, para que luego se implementen de manera conjunta en IaC con Terraform permitiendo realizar un mantenimiento al código de una manera eficaz y eficiente.
El punto de partida para la agrupación es tomar en cuenta los entornos y según la arquitectura cloud del proyecto Pisco tenemos 2 entornos; sin embargo, la parte común de ambos también se puede considerar como un entorno y luego de analizar en este primer nivel de agrupación nos da el resultado que se tendrá 3 agrupaciones lógicas principales: SHARED, DEV-PRE y PROD como se muestra en la siguiente imagen:
Ahora seguimos con el segundo nivel de agrupación y seleccionamos cada agrupación lógica principal y analizamos ¿cómo agrupamos los recursos cloud dentro de cada una de ellas?; un criterio es tomar en cuenta el orden de creación, lo cual da el resultado que los primeros recursos cloud que debemos crear son los relacionados a las redes y en este caso serían las Virtual Network y las Subnet (se asume que ya se tiene definido los rangos de IP que se usarán en toda la arquitectura cloud). Todos esos recursos cloud formarían la primera capa lógica que llamaremos networking y la tendrá cada entorno tal como se muestra en la siguiente imagen:
Continuando con la iteración ahora seguimos con la siguiente capa lógica tomando en cuenta cuáles deberían ser los siguiente recursos cloud que debemos crear para seguir con el aprovisionamiento de la arquitectura cloud y en ese caso son los Peering. A esta capa lógica la llamaremos peering y la ventaja de tenerlo separada de la capa lógica networking es que brinda la flexibilidad de no crearla si aún no existen la capa lógica anterior en los demás entornos, ya que ello es un requisito y si tuviéramos ese recurso cloud en la capa lógica networking tocaría comentar el código Terraform para que no de error cuando se quiera crear dicha capa lógica. La capa lógica peering se muestra en la siguiente imagen:
Los siguientes recursos cloud que son necesarios dependen de los componentes backend de la aplicación donde existe un orden de dependencia el cual indica que primero se requiere la Base de Datos que será usada por el Microservicio en Java. Entonces la siguiente capa lógica la llamaremos database y tendrá el Azure Database for PostgreSQL, el Private EndPoint para el Azure Database for PostgreSQL y el Private DNS Zone del Azure Database for PostgreSQL (que de manera implícita se asume que estará en el entorno SHARED y no está en el diagrama de arquitectura cloud). Dicha capa lógica se muestra en la siguiente imagen:
La siguiente capa lógica involucra a los recursos cloud que permiten desplegar al Microservicio en Java y son el App Service Plan, el App Service, el Private EndPoint del App Service, el Key Vault, el Private EndPoint del Key Vault y el Private DNS Zone del App Service y Key Vault (los cuales de manera implícita se asumen que estarán en el entorno SHARED y no están en el diagrama de arquitectura cloud). A esta capa lógica la llamaremos backend y se muestra en la siguiente imagen:
Una vez que hemos terminado de identificar los recursos cloud de las capas lógicas necesarias para los componentes backend de la aplicación faltan aquellos que ven aspectos globales en la arquitectura cloud, los cuales son la seguridad y monitoreo. Tomando en cuenta lo anterior la siguiente capa lógica la llamaremos security y tendrá los recursos cloud de Network Security Group que se aplicarán a cada Virtual Network de cada entorno. Dicha capa lógica se muestra en la siguiente imagen:
Y el siguiente aspecto que es el monitoreo lo abarca los recursos cloud de Log Analytics Workspace y Azure Monitor. Estos recursos cloud formarán parte de la capa lógica que llamaremos monitoring y se muestra en la siguiente imagen:
Entonces como resumen, indicamos las capas lógicas que hasta el momento hemos definido para el proyecto Pisco:
| Capas lógicas por Entorno | Capas lógicas según orden de ejecución |
|
|
Esta agrupación de capas lógicas en carpetas antes de agregar el código Terraform quedaría como se muestra en la siguiente imagen:
En el siguiente artículo explicaremos la buena práctica de IaC con Terraform llamada «Definición de nomenclatura».