Skip to main content

Migration de packethost/packet 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-packet et souhaitez utiliser une version plus récente du fournisseur 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 packet_device à equinix_metal_device. Ça devrait fonctionner, mais les ressources packet_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 packethost/packet à 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 packet_ 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 {
    packet = {
      source = "packethost/packet"
    }
  }
}

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

resource "packet_vlan" "example" {
  project_id  = packet_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 packethost/packet 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|packethost/packet|equinix/equinix|g' main.tf

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

sed -i 's/packet_/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 packet_ ainsi que la clé du bloc required_providers.

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

sed -i 's/packet_/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 packethost/packet 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 packethost/packet, 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 {
    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 des ressources​

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

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

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

Pour l'appareil:

$ terraform state show packet_device.example

# packet_device.example
resource "packet_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/packet_/equinix_metal_'
  • toutes les références des ressources packet_ 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 packet_ 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 packet_device.example est 8eb3bc10-0e1a-476a-aec2-6dc699df9c1c et que l'UUID de packet_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 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

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 packet_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 ?