Ir para o conteúdo principal

Migrando de packethost/packet para equinix/equinix

O [Equinix Metal (anteriormente Packet) foi totalmente integrado à Platform Equinix e, portanto, o provedor Terraform também mudou. Este (terraform-provider-equinix, provedor equinix/equinix) é o provedor atual dos diversos serviços disponíveis na Platform Equinix que podem ser gerenciados usando o Terraform.

Se você estiver usando o terraform-provider-packet e você usar uma versão mais recente do provedor para gerenciar recursos no Equinix Metal, você alterar as referências nos você arquivos HCL. Você pode simplesmente alterar os nomes dos recursos, por exemplo, de packet_device para equinix_metal_device. Isso deve funcionar, mas fará com que o recurso packet_device seja destruído e um novo recurso equinix_metal_device seja criado em seu lugar. A recriação dos recursos pode ser indesejável, e este guia mostra como migrar para recursos equinix_metal_ sem a necessidade de recriá-los.

Antes de começar a migrar seus modelos do Terraform, atualize-os.

  • packethost/provedor de pacotes para a versão mais recente (3.2.1)
  • Terraform para versão pelo menos v0.13

Migração rápida com replace-provider e sed​

Assim como os modelos HCL do Terraform, o estado do Terraform é um arquivo contendo nomes de recursos e seus atributos em texto estruturado. Podemos tentar a migração como uma tarefa de substituição de texto, basicamente substituindo packet_ por equinix_metal_ sempre que possível e corrigindo a referência da fonte do provedor .

É uma boa ideia fazer um backup de todo o diretório do Terraform antes de fazer isso.

Considerando que temos uma infraestrutura criada a partir do seguinte modelo:

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

Podemos primeiro alterar o provedor no arquivo de estado do Terraform (terraform.tfstate) com o subcomando terraform state replace-provider:

terraform state replace-provider packethost/packet equinix/equinix

Em seguida, substituímos a referência do provedor nos modelos HCL. Faça isso para cada arquivo onde houver essa referência:

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

Então, simplesmente substituímos todas as strings packet_ por equinix_metal_ nos arquivos HCL do Terraform.

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

...isto é um pouco perigoso, então verifique seu git diff depois. Ele deve substituir todos os prefixos packet_ e também a chave do bloco required_providers.

Em seguida, substitua packet_ por equinix_metal_ no arquivo de estado do Terraform:

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

O modelo de exemplo ficaria agora assim:

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

Em seguida, precisamos instalar o provedor equinix/equinix executando terraform init. Depois disso, nossos modelos devem estar em conformidade com o estado do Terraform e com os recursos upstream no Equinix Metal. Você pode verificar o resultado executando terraform plan.

Se o plano não estiver vazio, significa que alguns recursos não podem ser simplesmente lidos do upstream, ou que os atributos foram alterados entre a sua versão do provedor packethost/packet e a versão atual do provedorequinix/equinix.

Migrar um recurso de cada vez​

Podemos usar terraform state e terraform import para realizar a transição sem destruir os recursos existentes.

Infraestrutura existente​

Assumimos que a infraestrutura foi criada com o provedor packethost/packet, com um dispositivo e uma reserva de IP. A lista de compatibilidade de hardware (HCL) tem a seguinte aparência:

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

UUIDs de recursos​

Para fazer a transição para o provedor equinix/equinix, precisamos descobrir os UUIDs de todos os recursos que queremos migrar. Neste caso, packet_reserved_ip_block.example e packet_device.example. Podemos usar terraform state para descobrir os UUIDs.

Para o bloco de 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 o dispositivo:

$ terraform state show packet_device.example

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

Modelo migrado​

Após descobrirmos os UUIDs dos recursos a serem migrados, precisamos alterar o seguinte no modelo HCL:

  • o bloco required_providers para exigir equinix/equinix
  • os nomes dos recursos para os recursos correspondentes do provedor equinix/equinix: sed 's/packet_/equinix_metal_'
  • todas as referências de recursos packet_ para recursos equinix_metal_

O modelo modificado ficará então assim:

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

Migrando o estado do Terraform​

Depois de alterarmos o modelo de acordo, podemos remover os recursos packet_ antigos do estado do Terraform e importar os novos como recursos equinix_metal_ por seus UUIDs.

Verificando o estado anteriormente, lembramos que o UUID do packet_device.example é 8eb3bc10-0e1a-476a-aec2-6dc699df9c1c e o UUID do packet_reserved_ip_block.example é e689072f-aa6e-4d51-8e37-c2fbe18b4ff0.

Nos comandos terraform state e terraform import, usamos o tipo e o nome do recurso, separados por ponto:

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

Em seguida, precisamos instalar o provedor equinix/equinix executando terraform init. Depois disso, nossos modelos devem estar em conformidade com o estado do Terraform e com os recursos upstream no Equinix Metal. Podemos verificar a migração executando terraform plan, que deverá mostrar que a infraestrutura está atualizada.

Resolvendo problemas de migração​

Ao executarmos terraform plan para verificar se a migração foi bem-sucedida, o Terraform pode alertar que alguns atributos de recursos dos modelos não estão alinhados com o estado importado. Isso ocorre porque nem todos os atributos de recursos podem ser calculados; por exemplo, os blocos ip_address em packet_device são definidos pelo usuário e resultarão em um diff não vazio em relação ao estado importado baixado.

No caso de ip_address, um terraform apply subsequente atualizará o estado local sem alterar o recurso upstream, mas se um atributo causar uma atualização upstream, você precisará resolvê-lo manualmente, alterando seu modelo ou permitindo que o Terraform altere o recurso upstream.

Esta página foi útil?