Dzisiaj szybki wpis na temat Terraform. Załóżmy, że masz konto AWS, a na nim kilka projektów, w których używasz IaC. Utworzyłeś mnóstwo zasobów, ale postanowiłeś zrobić porządek w kodzie i kilka bucketów S3 przenieść do innego modułu. Porządkujesz kod, ale co zrobić, żeby zasoby pozostały w AWS i jednocześnie były przeniesione do innego modułu?
Gdy tylko zmienisz nazwy albo przesuniesz zasoby w inne miejsce w kodzie, to terraform będzie chciał usunąć zasoby i dodać na nowo. Jeśli w bucketach masz pełno plików, to raczej nie chcesz ich usuwać, tylko chcesz je zachować w nienaruszonym stanie.
Za pomocą polecenia terraform state mv możesz sprawić, że stan się zmieni, a zasoby zostaną w AWS nienaruszone. Na początku zalecam wykonanie backupu, tak na wszelki wypadek. Możesz też wykonać dry-run. Przykład znajdziesz poniżej:
# backup
terraform state pull > backup.tfstate
# list resources
terraform state list
# mv dry-run
terraform state mv -dry-run \
'module.s3.module.aws_s3_bucket["my-s3-bucket"].bucket_s3.this[0]' 'module.s3.module.aws_s3_bucket["project1-s3-bucket"].bucket_s3.this[0]'
# mv
terraform state mv \
'module.s3.module.aws_s3_bucket["my-s3-bucket"].bucket_s3.this[0]' 'module.s3.module.aws_s3_bucket["project1-s3-bucket"].bucket_s3.this[0]'terraform state mv [options] SOURCE DESTINATION
Gdy manipulujesz stanem, upewnij się, że nikt inny w tym czasie nie będzie dodawał zmian pomiędzy twoją zmianą konfiguracji a poleceniem terraform state mv. W przeciwnym razie ktoś mógłby przypadkowo utworzyć plan, który zniszczy stary obiekt i utworzy nowy pod nowym adresem.
Więcej na temat refaktoryzacji znajdzie w moim artykule na dev_to Power of Terraform Code Refactoring.
Więcej informacji znajdziesz w dokumentacji terraforma Command: state mv | Terraform | HashiCorp Developer
Jeśli spodobał Ci się artykuł daj znać to postaram się dodać w najbliższym czasie jeszcze kilka fajnych porad dotyczących terraforma
.