Terraform keeps the remote state of the infrastructure.
It stores in a file called terraform.tfstate
There is also a backup of the previous state in terraform.tfstate.backup.When you execute terraform apply, a new terraform.tfstate and backup is written.
This is how terraform keeps track of the remote state. If the remote state changes and you hit terraform apply again, terraform will make changes to the correct remote state again.
Eg: you terminated an instance that is managed by terraform, after terraform it will be started again. You can keep the terraform.tfstate in version control.
Eg: git
It gives you a history of your terraform.tfstate file (which is just a big JSON file) It allows you to collaborate with other team members. Unfortunately you can get conflicts when 2 people work at the same time.
Local state works well in the beginning, but when your project becomes bigger, you might want to store your state remote.
The terraform state can be saved remotely, using the backend functionality in terraform. The default backend is the ‘local backend’(the terraform.state file is gonna be saved locally).
Other backends include:
S3(with a locking mechanism using DynamoDB)
Consul (with locking mechanism)
Terraform Enterprise(the commercial solution)
Using the backend functionality definitely has benefits:
Working in team: it allows for collaboration, the remote state will always
be available for the whole team. The state file is not stored locally anymore. Possible sensitive information is now only stored in the remote state.
There are 2 steps to configure remote state:
It avoids having to commit and push the terraform.tfstate to version control.
How to achieve?
- Create a S3 bucket with versioning enabled.
- Configure aws locally.
- Sudo apt-get update
- Sudo apt-get install awscli
- aws configure
- AWS Access Key ID [None]:
- AWS Secret Access Key [None]:
- Default region name [None]: ca-central-1
- Default output format [None]:
- These credentials are stored in the file ~/.aws/credentials