Skip to main content

Migration d'equinix/migration vers equinix/equinix

Equinix Metal (anciennement Packet) est maintenant complètement intégré à la plateforme Equinix, ce qui entraîne une modification du fournisseur Terraform. Ce dernier (terraform-provider-equinix, fournisseur equinix/equinix) est le fournisseur actuel des différents services disponibles sur la plateforme Équinix et gérables via Terraform.

Si vous utilisez terraform-provider-metal et souhaitez utiliser une version plus récente pour gérer les ressources dans Equinix Metal, vous devrez modifier les références dans vos fichiers HCL. Vous n'avez qu'à renommer les ressources, par exemple de metal_device à equinix_metal_device. Ça devrait fonctionner, mais les ressources metal_device seront détruites et remplacées par de nouvelles ressources equinix_metal_device. La recréation des ressources peut être indésirable ; ce guide explique comment migrer vers des ressources equinix_metal_ sans les recréer.

Avant de commencer la migration de vos modèles Terraform, veuillez effectuer la mise à niveau.

  • fournisseur equinix/métal à la dernière version (3.2.1)
  • Terraform à la version au moins v0.13

Migration rapide avec remplacement-provider et sed​

Tout comme les modèles HCL de Terraform, l'état Terraform est un fichier contenant les noms des ressources et leurs attributs sous forme de texte structuré. On peut tenter la migration comme une tâche de substitution de texte, en remplaçant metal_ par equinix_metal_ partout où c'est possible et en corrigeant la référence à la source du fournisseur.

Il est conseillé de sauvegarder l'intégralité du répertoire Terraform avant de procéder.

Étant donné que nous avons une infrastructure créée à partir du modèle suivant:

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"
}

On peut tout d'abord modifier le fournisseur dans le fichier d'état Terraform (terraform.tfstate) avec la sous-commande replace-provider terraform state:

terraform state replace-provider equinix/metal equinix/equinix

Ensuite, on remplace la référence au fournisseur dans les modèles HCL. Procédez ainsi pour chaque fichier où figure cette référence:

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

Ensuite, on remplace simplement toutes les chaînes metal_ par equinix_metal_ dans les fichiers HCL de Terraform.

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

…c'est un peu risqué, alors vérifiez votre git diff après. Il devrait remplacer tous les préfixes metal_ ainsi que la clé du bloc required_providers.

Ensuite, remplacez metal_ par equinix_metal_ dans le fichier d'état Terraform:

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

Le modèle d'exemple ressemblerait désormais à ceci:

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"
}

Il faut ensuite installer le fournisseur equinix/equinix en exécutant terraform init. Nos modèles devraient alors correspondre à l'état Terraform et aux ressources en amont dans Equinix Metal. Vous pouvez vérifier le résultat en exécutant terraform plan.

Si le plan n'est pas vide, cela signifie que certaines ressources ne peuvent pas être simplement lues en amont, ou que des attributs ont changé entre votre version du fournisseur equinix/metal et la version actuelle du fournisseur equinix/equinix.

Migrer une ressource à la fois​

On peut utiliser terraform state et terraform import pour réaliser la transition sans détruire les ressources existantes.

Infrastructures existantes​

Nous supposons qu'une infrastructure a été créée avec le fournisseur equinix/metal, comprenant un périphérique et une réservation d'adresse IP. La liste de compatibilité matérielle (HCL) se présente comme suit:

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 des ressources​

Pour passer au fournisseur equinix/equinix, nous devons identifier les UUID de toutes les ressources à migrer, à savoir metal_reserved_ip_block.example et metal_device.example. On peut utiliser terraform state pour trouver ces UUID.

Pour le bloc d'adresses IP réservé:

$ 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"
  [...]
}

Pour l'appareil:

$ terraform state show metal_device.example

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

Modèle migré​

Une fois que nous aurons trouvé les UUID des ressources à migrer, nous devrons modifier le modèle HCL:

  • le bloc required_providers pour exiger equinix/equinix
  • les noms des ressources aux ressources correspondantes du fournisseur equinix/equinix: sed 's/metal_/equinix_metal_'
  • toutes les références des ressources metal_ vers les ressources equinix_metal_

Le modèle modifié ressemblera alors à ceci:

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"
  }
}

Migration de l'état Terraform​

Une fois le modèle modifié en conséquence, on peut supprimer les anciennes ressources metal_ de l'état Terraform et importer les nouvelles en tant que ressources equinix_metal_ par leurs UUID.

En vérifiant l'état précédent, on se rappelle que l'UUID de metal_device.example est 8eb3bc10-0e1a-476a-aec2-6dc699df9c1c et que l'UUID de metal_reserved_ip_block.example est e689072f-aa6e-4d51-8e37-c2fbe18b4ff0.

Dans les commandes d'état et d'importation de Terraform, nous utilisons le type et le nom de la ressource, séparés par un point:

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

Il faut ensuite installer le fournisseur equinix/equinix en exécutant terraform init. Nos modèles devraient alors correspondre à l'état Terraform et aux ressources en amont sur Equinix Metal. La migration peut être vérifiée en exécutant terraform plan, ce qui devrait indiquer que l'infrastructure est à jour.

Résolution des problèmes de migration​

Lors de l'exécution de terraform plan pour vérifier la réussite de la migration, Terraform peut signaler que certains attributs de ressources des modèles ne correspondent pas à l'état importé. Cela s'explique par le fait que tous les attributs de ressources ne peuvent pas être calculés ; par exemple, les blocs ip_address dans metal_device sont définis par l'utilisateur et généreront une différence non vide par rapport à l'état importé téléchargé.

Dans le cas de ip_address, un terraform apply consécutif mettra à jour l'état local sans modifier la ressource en amont, mais si un attribut provoque une mise à jour en amont, vous devrez le résoudre manuellement, soit en modifiant votre modèle, soit en laissant Terraform modifier la ressource en amont.

Cette page vous a-t-elle été utile ?