Ir al contenido principal

Migración de equinix/metal 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-metal 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 limitarse a cambiar los nombres de los recursos, por ejemplo, de metal_device a equinix_metal_device. Eso debería funcionar, pero hará que se destruyan los metal_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

  • proveedor de equinix/metal 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 metal_ 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 {
    metal = {
      source = "equinix/metal"
    }
  }
}

resource "metal_project" "example" {
  name = "example"
}

resource "metal_vlan" "example" {
  project_id  = metal_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 equinix/metal 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|equinix/metal|equinix/equinix|g' main.tf

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

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

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

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

sed -i 's/metal_/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 equinix/metal 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 equinix/metal con un dispositivo y una reserva IP. El HCL tiene el siguiente aspecto:

terraform {
  required_providers {
    metal = {
      source = "equinix/metal"
      version = "3.2.1"
    }
  }
}

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

resource "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 = [metal_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 metal_reserved_ip_block.example y metal_device.example. Podemos utilizar terraform state para averiguar los UUID.

Para el bloque IP reservado:

$ terraform state show metal_reserved_ip_block.example

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

Para el dispositivo:

$ terraform state show metal_device.example

# metal_device.example
resource "metal_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/metal_/equinix_metal_'
  • todas las referencias de metal_ 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 metal_ 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 metal_device.example es 8eb3bc10-0e1a-476a-aec2-6dc699df9c1c, y el UUID del metal_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 metal_reserved_ip_block.example
terraform import equinix_metal_reserved_ip_block.example e689072f-aa6e-4d51-8e37-c2fbe18b4ff0
terraform state rm metal_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 metal_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.

¿Fue útil esta página?