Terraform v0.10.6
Terraform is configured to store state file remotely.
terraform {
backend "s3" {
bucket = "gfg-s3-private-bucket.example.com"
key = "terraform/terraform.tfstate"
region = "ap-southeast-1"
shared_credentials_file = "../keys/aws.credentials"
}
}
N/A
N/A
Terraform init should not touch my local terraform.tfstate if the state file is configured to be stored on S3.
Terraform init creates a backup of local terraform.tfstate (backup file: terraform.tfstate.backup), and make my local file empty (terraform.tfstate has 0 bytes)
terraform.tfstate there for reference purpose because the actual state file is configured to be stored remotely.terraform initterraform.tfstate is empty. New file is created terraform.tfstate.backup.N/A
N/A
Hi @icy
This is the expected behavior. The terraform.tfstate file is controlled by terraform, and it's moved into a backup location in an attempt prevent issues with using the incorrect state. Also, if there was content in the state file, init should have prompted you about migrating the state to the new backend. If there's an existing local state file, terraform can't determine if the migration has been completed previously, and reconfiguring the backends could lead to the migration of the wrong state.
It might be possible in the future if we make backend configuration a requirement, and remove the default usage of ./terraform.tfstate, but for now it's better to assume terraform owns that file.
Not only do I get this behaviour with the s3 backend in 0.10.6 but terraform does not ask to move the local terraform.tfstate to the s3 bucket, resulting in a loss of state.
I'm having to script putting terraform.tfstate.backup in place instead.
@jbardin
I see. Thanks for your explanation.
I also have the same problem when my state is already migrated to remote bucket. In my company, developer has a feature branch and when they push to Github, Jenkins will start a terraform plan command. At that time terraform init doesn't see any local .terraform/terraform.tfstate file, hence it expects a migration step as you said, doesn't it? It will try to rename the good state file terraform.tfstate to a backup version, and create new empty state file. I think this assumption is wrong: It's because terraform can't detect the state at its early stage, it's not because the state file is not ready on remote bucket.
Does it make sense to commit the file .terraform/terraform.tfstate and distribute them to developers? Do you think that it helps to resolve me problem?
No, the .terraform directory specifically is not supposed to be commit to VCS. Nothing in there is guaranteed to be stable or safe to commit.
I guess I'm misunderstanding the reason for your terraform.tfstate file in the first place. If that isn't a valid state to start with, it shouldn't be put in the terraform owned file where it expects to find its state. Is it possible for you to use another file name? (It also not recommended to commit state files themselves anyway, since they can contain sensitive information.)
Most helpful comment
Hi @icy
This is the expected behavior. The
terraform.tfstatefile is controlled by terraform, and it's moved into a backup location in an attempt prevent issues with using the incorrect state. Also, if there was content in the state file,initshould have prompted you about migrating the state to the new backend. If there's an existing local state file, terraform can't determine if the migration has been completed previously, and reconfiguring the backends could lead to the migration of the wrong state.It might be possible in the future if we make backend configuration a requirement, and remove the default usage of
./terraform.tfstate, but for now it's better to assume terraform owns that file.