La teva infraestructura és codi (Capítol 9), i com tot codi, pot tenir errors. En aquest capítol aprendràs a provar la teva infraestructura per detectar problemes abans que arribin a producció. Comencem per les comprovacions més bàsiques i barates: fmt i validate, executades automàticament en CI. Són la primera línia de defensa de la qualitat.

Un error en el teu codi Terraform pot provocar des d’una errada tonta (una clau mal tancada) fins a un desastre seriós (un Security Group que deixa la teva base de dades oberta a internet). Igual que proves el codi d’una aplicació abans de llançar-lo, has de provar la teva infraestructura. La bona notícia és que hi ha diversos nivells de proves, de les més simples a les més completes:

Comencem pels dos primers, que són els més fàcils i els que sempre hauries de tenir.

Abans de seguir, un concepte clau: CI (Continuous Integration, Integració Contínua). És un sistema automàtic que, cada vegada que algú proposa un canvi de codi (un Pull Request, subcapítol 12.5), executa una sèrie de comprovacions automàticament. Si alguna falla, avisa i bloqueja el canvi fins que s’arregli.

Analogia: el CI és com un control de qualitat automàtic en una fàbrica. Cada producte (canvi de codi) passa per una cinta on unes màquines l’inspeccionen. Si alguna cosa no compleix els estàndards, s’aparta abans de sortir al mercat. Ningú ha de revisar a mà cada peça: el sistema ho fa sol, sense cansar-se ni oblidar-se.

Veurem el CI a fons al Capítol 22; per ara, queda’t amb que és on s’executen automàticament aquestes proves.

Recorda fmt del subcapítol 11.4: formateja el codi Terraform amb un estil uniforme (indentació, alineació). En CI s’utilitza en mode comprovació, per verificar que el codi està ben formatat, sense canviar-lo:

Per què comprovar el format en CI? Perquè tot el codi de l’equip tingui el mateix estil, sempre. Sense això, cada persona formatejaria a la seva manera i el codi seria un caos d’estils barrejats. Amb la comprovació en CI, ningú pot fusionar codi mal formatat: és un estàndard automàtic que elimina discussions d’estil.

Recorda validate del subcapítol 11.4: comprova que el codi és vàlid (sense errors de sintaxi ni referències trencades), sense connectar-se a AWS ni crear res. En CI s’executa així:

Per què validar en CI? Per caçar errors bàsics a l’instant, abans que ningú intenti aplicar el codi. Si algú escriu malament el nom d’un argument o referencia un recurs que no existeix, validate ho detecta en segons, i el CI bloqueja el canvi. És molt millor descobrir-ho aquí que quan intentes desplegar.

Juntant ambdós, un pipeline de CI bàsic per Terraform comença així:

Si fmt o validate fallen, el procés s’atura aquí: no té sentit seguir amb codi mal formatat o invàlid. Només si passen aquestes comprovacions bàsiques es continua amb les altres.

fmt i validate són la base del testing d’infraestructura per dues raons:

• Són baratíssims: s’executen en segons, no necessiten credencials d’AWS ni creen res. No costa res tenir-los.
• Cacen els errors més comuns: molts errors del dia a dia són de format o de sintaxi, i aquests dos comandaments els eliminen d’arrel.

Consell pràctic: encara que no tinguis encara un pipeline de CI complet, configura almenys fmt -check i validate des del primer dia. És el mínim esforç amb el màxim retorn en qualitat. Les proves més avançades (seguretat, integració) les afegeixes després.

• La infraestructura és codi, i com a tal pot tenir errors; cal provar-la abans que arribi a producció, en nivells de menys a més complets: fmt → validate → seguretat → integració.
• El CI (Integració Contínua) és un sistema automàtic que executa comprovacions cada vegada que es proposa un canvi (un PR) i bloqueja els que fallen. Com un control de qualitat automàtic en una fàbrica.
• terraform fmt -check verifica que el codi tingui un format consistent, garantint un estil uniforme a tot l’equip.
• terraform validate comprova que el codi sigui vàlid (sintaxi i referències), caçant errors bàsics a l’instant, sense tocar AWS.
• Són la base del testing: baratíssims (segons, sense credencials) i cacen els errors més comuns. Configura’ls des del primer dia.

Al següent subcapítol pujarem un nivell: l’anàlisi de seguretat estàtica amb Checkov i tfsec, que detecten configuracions perilloses abans de desplegar-les.