CODEWITHSUNDEEP
terraform
sdot257
sdot257

Reputation: 10366

Multiple developers and Terraform state files

I've been managing our Terraform code by myself for a few months. Now that there are additional team members in my group, I would like them to learn TF and build things using the existing code I have. The state files are stored in S3. For each environment, I ran the following command.

terraform init -backend=true \
    -backend-config="bucket=acme-dev-tfstates" \
    -backend-config="key=frontendapp.tfstate" \
    -backend-config="region=us-east-1" \
    -backend-config="encrypt=true"

So let's say my coworker wants to contribute to the code. He checks out the code from Github, does he need to run the above command again?

Upvotes: 5

Views: 2786

Answers (4)

stobiewankenobi
stobiewankenobi

Reputation: 704

I would highly recommend you look at terragrunt. https://github.com/gruntwork-io/terragrunt

With this tool you can define a file like terraform.tfvars that has all the information about remote state, lock tables, etc, without having to run extra commands. This will handle it for you transparently.

Terragrunt is pretty much a requirement imo to run Terraform correctly.

Upvotes: 0

Tommy Nguyen
Tommy Nguyen

Reputation: 3643

I think You could define the remote state inside main.tf, no need to specify via command line. See:

terraform {
  backend "s3" {
    bucket         = "<s3-bucket>"
    key            = "<state-name>"
    region         = "<aws-region>"
    encrypt        = true
  }
}

Upvotes: 1

mcfinnigan
mcfinnigan

Reputation: 11638

one rule we have is that if you break state files in nonproduction systems, you own the problems and the joys of fixing them. One experience of this makes people quite keen to avoid a repeat experience ;)

For production changes we only ever run terraform from our CI servers to try to mitigate against this issue. So far it's worked.

Upvotes: 1

ydaetskcoR
ydaetskcoR

Reputation: 56877

Yes, you'll all need to make sure you're properly configuring state so that no one accidentally makes changes without pulling and pushing state from S3.

You should also consider using state locking (with DynamoDB for the S3 state backend) so you don't have multiple people attempt to make changes to the same resources at the same time, potentially corrupting your state files.

It may be helpful to write helper scripts that automatically handle the state configuration and pulling modules etc so that it's impossible to not configure state in normal operation.

Upvotes: 0

Related Questions