Saltar a contenido

Migración de Cloudflare provider v4 → v5

Migración de terraform/cloudflare/ del provider cloudflare/cloudflare ~> 4.0 al ~> 5.0. El provider v5 (Plugin Framework) reestructura y renombra recursos, por lo que la migración combina cambios de HCL + migración de estado.

Referencia oficial: version-5-upgrade y version-5-migration.

Cambios aplicados en HCL

v4 v5
cloudflare_record cloudflare_dns_record (+ name ahora FQDN completo)
cloudflare_zone_settings_override 12 × cloudflare_zone_setting
cloudflare_zone (account_id/zone/plan) account = { id } + name (+ type; plan read-only)
cloudflare_zero_trust_access_policy (app-scoped) policies inline en cloudflare_zero_trust_access_application (por id)
IdP config { } (bloque) config = { } (atributo)
cloudflare_zero_trust_tunnel_cloudflared secret tunnel_secret
tunnel config { ingress_rule { } } (bloque) config = { ingress = [ ] } (atributo)
cloudflare_pages_domain domain name
cloudflare_ruleset/email-routing rules/matcher/action (bloque) lista de objetos
Registros MX (route1/2/3.mx.cloudflare.net) fuera de Terraform (gestionados por Email Routing)

Otras particularidades de v5:

  • warp_routing deja de ser gestionable (se omite; el valor en la API queda).
  • Email Routing: matcher/action pasan a matchers/actions (plural).
  • cloudflare_zero_trust_tunnel_cloudflared ya no expone tunnel_token: se quitó el output homelab_tunnel_token. Si hay que regenerarlo, usar cloudflared tunnel token homelab.
  • cloudflare_zero_trust_access_application.http_only_cookie_attribute por defecto es true en v5; se fija false para preservar el comportamiento.
  • cloudflare_email_routing_settings.support_subaddress se fija a false explícito (bug "inconsistent result" del provider si queda null).
  • cloudflare_dns_record.include_shadow_metadata (atributo nuevo, query param) se ignora vía lifecycle { ignore_changes } para no forzar PUTs.

Migración de estado (ya aplicada)

  • cloudflare_record → cloudflare_dns_record: se hizo con bloques moved (id de API sin cambios) que se borraron tras el apply (eran de un solo uso).
  • cloudflare_zero_trust_access_policy (app-scoped): bloque removed (destroy = false) + policy inline por id en la aplicación (misma UUID).
  • cloudflare_zone_settings_override: terraform state rm (el provider v5 no tiene schema para esa entrada). El paso State migration de los workflows se quitó tras el apply.
  • Registros MX: bloque removed (destroy = false) → fuera de Terraform.
  • Resto (schema de atributos): lo migraron los state upgraders del provider.

Incidencias del primer apply (resueltas)

  • MX (error 1046 "managed by Email Routing") → se sacaron de Terraform.
  • modified_on / support_subaddress "inconsistent result" (bug del provider v5) → se evitó ignorando include_shadow_metadata y fijando support_subaddress.

Rollback

  • El estado remoto en R2 se puede restaurar del historial; no se destruye nada en Cloudflare porque los moved/removed usan destroy = false y el state rm solo quita entradas de estado.

Verificación

  • El último terraform apply terminó con 0 added, 0 changed, 0 destroyed.
  • Revisar en el dashboard de Cloudflare que DNS, túneles, Access y settings siguen iguales.