Migration document for domain-protect to terraform-aws-domain-protect

[nitrocode]

It would be good to create a migration document

I currently have the github actions deployment setup now and I'm planning to document the steps to migrate from an auto deployment workflow using domain-protect/domain-protect to a static terraform code workflow using domain-protect/terraform-aws-domain-protect.

[paulschwarzenberger]

Some people will just apply the latest version of domain-protect without realising that there's a major restructure. This would result in destruction and recreation of all resources. While this would mostly not matter, there are some resources which are important to keep, in particular the DynamoDB tables for vulnerabilities and IP addresses. The vulnerability table includes historic data used for monthly and yearly stats, the IP address table can contain manually added exceptions.

We may want to consider including a moved.tf file in the parent domain-protect repo, with Terraform moved statements for key resources, based on the defaults. In the case that someone is using the defaults, this would keep the DynamoDB tables intact.

If the user had replaced defaults with their own values, this would result in an error prompting the user to correct.

On the other hand, we'd want to ensure that including moved statements doesn't error in the case of a fresh install.

[nitrocode]

Yes exactly, this is where a moved.tf or migrations.tf file will come in handy. Since all the resources could move from the root directory to another module, we can use moved blocks for people.

https://developer.hashicorp.com/terraform/language/modules/develop/refactoring

e.g.

# domain-protect/domain-protect/migrations.tf
moved {
  from = module.lambda-role
  to   = module.domain_protect.module.lambda_role
}

# domain-protect/domain-protect/main.tf
module "domain_protect" {
  source = "git::https://github.com/domain-protect/terraform-aws-domain-protect.git?ref=main"

  # arguments
}

[nitrocode]

Some people will just apply the latest version of domain-protect without realising that there's a major restructure

While I understand that this is the current methodology of the github-actions-deploy-latest workflow, in my humble opinion, I don't think this is best practice. It's always better to pin versions and bump them in case there is a breaking change introduced.

One way we can "break" that pattern is by pinning the module reference, not to a branch (like in the above example), but instead to a ref like a version tag.

[paulschwarzenberger]

Agreed