Migración de packethost/packet a equinix/equinix

[Equinix Metal (antes Packet), se ha integrado totalmente en la plataforma Equinix y, por tanto, el proveedor de terraformación también cambia. Este (terraform-provider-equinix, provider equinix/equinix) es el proveedor actual de los distintos servicios disponibles en la Plataforma Equinix que pueden gestionarse mediante Terraform.

Si ha estado utilizando terraform-provider-packet y desea utilizar una versión de proveedor más reciente para gestionar recursos en Equinix Metal, tendrá que cambiar las referencias en sus archivos HCL. Puede simplemente cambiar los nombres de los recursos, por ejemplo de packet_device a equinix_metal_device. Eso debería funcionar, pero hará que se destruyan los packet_device y se creen nuevos equinix_metal_device en su lugar. La recreación de los recursos podría ser indeseable, y esta guía muestra cómo migrar a recursos equinix_metal_ sin la recreación.

Antes de comenzar a migrar sus plantillas Terraform, actualice

packethost/proveedor de paquetes a la última versión (3.2.1)
Terraform a la versión al menos v0.13

Migración rápida con sustituto-proveedor y sed

Al igual que las plantillas HCL de Terraform, el estado de Terraform es un archivo que contiene los nombres de los recursos y sus atributos en texto estructurado. Podemos intentar la migración como una tarea de sustitución de texto, básicamente sustituyendo packet_ por equinix_metal_ siempre que sea posible, y fijando la referencia de origen del proveedor.

Es una buena idea hacer una copia de seguridad de todo el directorio Terraform antes de hacer esto.

Considerando que tenemos una infraestructura creada a partir de la siguiente plantilla:

terraform {
  required_providers {
    packet = {
      source = "packethost/packet"
    }
  }
}

resource "packet_project" "example" {
  name = "example"
}

resource "packet_vlan" "example" {
  project_id  = packet_project.example.id
  facility    = "sv15"
  description = "example"
}

Primero podemos cambiar el proveedor en el archivo de estado de Terraform (terraform.tfstate) con el subcomando terraform state replace-provider:

terraform state replace-provider packethost/packet equinix/equinix

A continuación, sustituimos la referencia del proveedor en las plantillas HCL. Haga esto para cada archivo donde tenga la referencia:

sed -i 's|packethost/packet|equinix/equinix|g' main.tf

A continuación, simplemente sustituimos todas las cadenas packet_ por equinix_metal_ en los archivos HCL de Terraform.

sed -i 's/packet_/equinix_metal_/g' main.tf

.. esto es un poco peligroso, así que compruebe su git diff después. Debería reemplazar todos los prefijos packet_ y también la clave del bloque required_providers.

A continuación, sustituya packet_ por equinix_metal_ en el archivo de estado de terraformación:

sed -i 's/packet_/equinix_metal_/g' terraform.tfstate

La plantilla de ejemplo tendría ahora el siguiente aspecto

terraform {
  required_providers {
    equinix = {
      source = "equinix/equinix"
    }
  }
}

resource "equinix_metal_project" "example" {
  name = "example"
}

resource "equinix_metal_vlan" "example" {
  project_id  = equinix_metal_project.example.id
  facility    = "sv15"
  description = "example"
}

A continuación, debemos instalar el proveedor equinix/equinix ejecutando terraform init. Después de eso, nuestras plantillas deberían estar en comprobación con el estado de Terraform y con los recursos upstream en Equinix Metal. Puede verificar el resultado ejecutando terraform plan.

Si el plan no está vacío, significa que algunos recursos no pueden leerse de forma sencilla desde el upstream, o que los atributos han cambiado entre su versión del proveedor packethost/packet y la versión actual del proveedor equinix/equinix.

Migrar un recurso a la vez

Podemos utilizar terraform state y terraform import para lograr la transición sin destruir los recursos existentes.

Infraestructura existente

Suponemos tener una infraestructura creada con el proveedor packethost/packet con un dispositivo y una reserva IP. El HCL tiene el siguiente aspecto:

terraform {
  required_providers {
    packet = {
      source = "packethost/packet"
      version = "3.2.1"
    }
  }
}

resource "packet_reserved_ip_block" "example" {
  project_id = local.project_id
  facility   = "sv15"
  quantity   = 2
}

resource "packet_device" "example" {
  project_id       = local.project_id
  facilities       = ["sv15"]
  plan             = "c3.medium.x86"
  operating_system = "ubuntu_24_04"
  hostname         = "test"
  billing_cycle    = "hourly"

  ip_address {
    type            = "public_ipv4"
    cidr            = 31
    reservation_ids = [packet_reserved_ip_block.example.id]
  }

  ip_address {
    type = "private_ipv4"
  }
}

UUID de recursos

Para realizar la transición al proveedor equinix/equinix, necesitamos averiguar los UUID de todos los recursos que queremos migrar. En este caso packet_reserved_ip_block.example y packet_device.example. Podemos utilizar terraform state para averiguar los UUID.

Para el bloque IP reservado:

$ terraform state show packet_reserved_ip_block.example

# packet_reserved_ip_block.example:
resource "packet_reserved_ip_block" "example" {
  [...]
    id = "e689072f-aa6e-4d51-8e37-c2fbe18b4ff0"
  [...]
}

Para el dispositivo:

$ terraform state show packet_device.example

# packet_device.example
resource "packet_device" "example" {
  [...]
    id = "8eb3bc10-0e1a-476a-aec2-6dc699df9c1c"
  [...]

Plantilla migrada

Una vez que averigüemos los UUID de los recursos a migrar, en la plantilla HCL, tenemos que cambiar:

el bloque required_providers para requerir equinix/equinix
los nombres de los recursos a los recursos correspondientes del proveedor equinix/equinix: sed 's/packet_/equinix_metal_'
todas las referencias de packet_ recursos a equinix_metal_ recursos

La plantilla modificada tendrá entonces el siguiente aspecto

terraform {
  required_providers {
    equinix = {
      source = "equinix/equinix"
    }
  }
}

resource "equinix_metal_reserved_ip_block" "example" {
  project_id = local.project_id
  facility   = "sv15"
  quantity   = 2
}

resource "equinix_metal_device" "example" {
  project_id       = local.project_id
  facilities       = ["sv15"]
  plan             = "c3.medium.x86"
  operating_system = "ubuntu_24_04"
  hostname         = "test"
  billing_cycle    = "hourly"

  ip_address {
    type            = "public_ipv4"
    cidr            = 31
    reservation_ids = [equinix_metal_reserved_ip_block.example.id]
  }

  ip_address {
    type = "private_ipv4"
  }
}

Migrar el estado de Terraform

Una vez que hemos cambiado la plantilla en consecuencia, podemos eliminar los antiguos recursos packet_ del estado de Terraform e importar los nuevos como recursos equinix_metal_ por sus UUID.

De la comprobación del estado anterior, recordamos que el UUID del packet_device.example es 8eb3bc10-0e1a-476a-aec2-6dc699df9c1c, y el UUID del packet_reserved_ip_block.example es e689072f-aa6e-4d51-8e37-c2fbe18b4ff0.

En los comandos terraformar estado e importar, utilizamos el tipo de recurso y el nombre, separados por puntos:

terraform state rm packet_reserved_ip_block.example
terraform import equinix_metal_reserved_ip_block.example e689072f-aa6e-4d51-8e37-c2fbe18b4ff0
terraform state rm packet_device.example
terraform import equinix_metal_device.example 8eb3bc10-0e1a-476a-aec2-6dc699df9c1c

A continuación, debemos instalar el proveedor equinix/equinix ejecutando terraform init. Después de eso, nuestras plantillas deberían estar en comprobación con el estado de Terraform y con los recursos ascendentes en Equinix Metal. Podemos verificar la migración ejecutando terraform plan, debería mostrar que la infraestructura está actualizada.

Resolver los problemas de migración

Cuando ejecutamos terraform plan para verificar que la migración se ha realizado correctamente, terraform puede advertir de que algunos atributos de recursos de las plantillas no están alineados con el estado importado. Esto se debe a que no todos los atributos de recursos pueden ser computados, por ejemplo los bloques ip_address en packet_device son definidos por el usuario y resultarán en un diff no vacío contra el estado importado descargado.

En el caso del ip_address, un terraform apply consecuente actualizará el estado local sin cambiar el recurso aguas arriba, pero si un atributo causa una actualización aguas arriba, tendrá que resolverlo manualmente, ya sea cambiando su plantilla, o dejando que Terraform cambie el recurso aguas arriba.

Migración rápida con sustituto-proveedor y sed​

Migrar un recurso a la vez​

Infraestructura existente​

UUID de recursos​

Plantilla migrada​

Migrar el estado de Terraform​

Resolver los problemas de migración​