Storing State Files
1. Storing State Files
Now that you’re familiar with state files and their purpose, let’s transition to state file storage. Terraform, by default, saves local state files in the current working directory with a . tfstate extension, so they don’t require additional maintenance. Local states work well when there’s only one developer working on a project. The default configuration can get tricky when multiple developers run Terraform simultaneously and each machine has its own understanding of the current infrastructure. If you’re working in a team where multiple developers are writing code to manage the infrastructure, then you should store state files remotely in a central location. That way when your infrastructure is changed, your Terraform state file is updated and synced, and your team will always be working with up-to-date infrastructure. Let’s examine some issues you may face when using local states for team environments. Local states do not have shared access. To update your infrastructure using Terraform, each member of your team needs access to the same state files. That means that those files must be stored in a shared location. You can’t lock local state files. If two team members are running Terraform at the same time, they might encounter RACE conditions because multiple Terraform processes are making updates to the state files. These conditions can lead to conflicts, data loss, and state file corruption. Local state files are not confidential. The information is in plain text, often exposing sensitive data such as database credentials. Now let’s observe how storing the state file in a remote location addresses these issues. First, when stored remotely, the state file is automatically updated. Once you configure a remote backend, Terraform will automatically load the state file from the backend every time you run the plan or apply commands. It will also automatically store the state file in that backend after each apply, so there’s no chance of manual error. Remote Cloud Storage buckets natively support state locking. The file can be locked so that if multiple developers run terraform apply simultaneously, it won’t be corrupted by simultaneous updates. Remote file storage is also more secure than local. Cloud Storage buckets natively support encryption in transit and encryption on disk. In addition, Cloud Storage includes several ways to configure access permissions, so you can control who has access to your state files. For example you can use IAM policies with a bucket. Though Cloud Storage buckets are encrypted at rest, you can use customer-supplied encryption keys to provide an added layer of protection. You can provide an extra layer of protection with the GOOGLE_ENCRYPTION_KEY environment variable. Even though secrets shouldn’t be in the state file to start with, always encrypt the state as an extra measure of defense. Let’s walk through how to store a Terraform state remotely in a Cloud Storage bucket. First, add the google_storage_bucket resource to a Terraform configuration file, such as main.tf. In the code snippet, the location field is hardcoded to US, meaning a multi-region bucket in the US will be created. You can change this field to a location of your choice. After you’ve added the code, run terraform apply to create the storage bucket. Next, add the code to a new Terraform configuration file called backend.tf. Ensure that the bucket name is updated to match the name of your new Cloud Storage bucket. Run terraform init to configure your Terraform backend. Terraform detects that you already have a state file locally and prompts you to copy it to the new Cloud Storage bucket. Enter yes. After you run terraform init, your Terraform state is stored in the Cloud Storage bucket. Terraform pulls the latest state from this bucket before running a command, and pushes the latest state to the bucket after running it. Here is a snippet of the state file from the Cloud Storage bucket. The state includes the metadata of the resources created, such as the resource type, resource name and the provider name.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.