A vegades necessites moure l'estat d'un lloc a un altre: passar d'estat local a remot, canviar de bucket, reorganitzar el teu projecte, o fusionar configuracions. La migració d'estat és una operació delicada però habitual, i convé saber fer-la bé per no perdre ni corrompre la teva «font de la veritat». En aquest subcapítol veurem com migrar l'estat de forma segura.

Recorda que l'estat és el registre de quina infraestructura existeix (Capítol 11). Hi ha diverses situacions reals en què necessites moure'l:

• De local a remot: vas començar amb estat local (al teu portàtil) i ara vols passar-lo a un backend S3 compartit (subcapítol 20.1) per treballar en equip. És el cas més comú.
• Canvi de backend: mous l'estat d'un bucket a un altre, o d'un sistema a un altre (per exemple, a Terraform Cloud, Capítol 22).
• Reorganització del projecte: divides un projecte gran en diversos de més petits, o en fusiones diversos en un, cosa que implica moure recursos entre estats.

Aquesta és la migració més freqüent i, afortunadament, Terraform la fa gairebé automàtica. El procés:

Quan executes terraform init després d'afegir el backend, Terraform és prou intel·ligent com per adonar-se que tens un estat local i oferir-te copiar-lo al nou destí:

Respones yes i Terraform copia l'estat al backend remot. A partir d'aquí, treballa des de S3.

Si ja tens un backend remot i vols canviar-lo (per exemple, un altre bucket), el procés és similar:

L'opció -migrate-state indica explícitament a Terraform que vols moure l'estat al nou backend, no començar de zero.

A vegades no vols moure tot l'estat, sinó recursos concrets d'un projecte a un altre (per exemple, en dividir un projecte gran). Per això existeix la comanda terraform state mv, que reubica un recurs dins de l'estat o cap a un altre:

Això li diu a Terraform: «aquest recurs ara viu en un altre lloc de l'estat, però és el mateix recurs real; no el destrueixis ni el recreïs, només actualitza el seu registre». És molt útil al refactoritzar (per exemple, en posar recursos solts dins d'un mòdul, Capítol 18).

Per què importa state mv: sense ell, si reorganitzes el teu codi i Terraform «perd» de vista un recurs, podria pensar que ja no existeix i voler destruir-lo i crear-ne un de nou. state mv evita aquesta destrossa: li dius «és el mateix, només ha canviat de nom/ubicació al codi».

La migració d'estat toca la teva «font de la veritat», així que la prudència és essencial. Segueix sempre aquestes regles:

Abans de qualsevol migració, guarda una còpia de l'estat actual. Si alguna cosa surt malament, pots restaurar-lo. Si el teu bucket S3 té versionat activat (subcapítol 20.1), ja tens aquest historial, però una còpia manual extra mai està de més.

Durant la migració, ningú més ha d'estar executant Terraform sobre aquest estat. Coordina't amb el teu equip (recorda el locking del subcapítol 20.2: la migració també necessita que l'estat no estigui en ús).

Després de la migració, executa terraform plan. Si la migració ha estat correcta, el plan ha de mostrar «sense canvis» (No changes): això confirma que el nou estat reflecteix exactament la infraestructura real, sense haver perdut ni alterat res.

L'arxiu d'estat és un JSON, però no l'editis manualment excepte en emergències extremes i sabent molt bé el que fas. Utilitza sempre les comandes de Terraform (state mv, state rm, init -migrate-state), que coneixen la seva estructura interna i eviten corrompre'l.

• Migrar l'estat (moure'l de lloc) és necessari en passar de local a remot, canviar de backend o reorganitzar el projecte.
• Local → remot: afegeixes el bloc backend i executes terraform init; Terraform detecta l'estat local i t'ofereix copiar-lo (respones yes). És gairebé automàtic.
• Remot → un altre remot: canvies la configuració i utilitzes terraform init -migrate-state.
• Per moure recursos concrets dins de l'estat (al refactoritzar), utilitza terraform state mv, que evita que Terraform destrueixi i recreï un recurs que només ha canviat d'ubicació al codi.
• Regles d'or: fes còpia de seguretat abans, avisa l'equip (ningú més treballant), verifica amb plan després (ha de dir «sense canvis») i no editis mai l'estat a mà.

A l'últim subcapítol del capítol veurem una operació molt relacionada i molt útil: terraform import, per portar a l'estat recursos que ja existeixen a AWS però que Terraform encara no gestiona.