Terraform: AWS VPC Changes Rollback Strategy using Terraform

[praveen6311]

Hi,

I have created a VPC using terraform which is working fine.

Now my requirement is to have proper Change Management Process, can you let me know the rollback strategy for the same??

How could we revert back changes to previous versions?

Note:- My terraform scripts are committed in GIT and tfstate file kept on s3.

[Puneeth-n]

revert the code in git and terraform your environment again. Terraform should restore the previous state of your vpc.

[praveen6311]

This is the ideal case to be followed but in larger team supposedly if someone misses out to commit code before terraform apply -> is their any way to reuse s3 versioned tfstate file to restore or anything else.

[Puneeth-n]

@praveen6311 I'm guessing, you should download the previous state file from s3, disable remote state and apply the previous state file. I haven't tried it though coz we are Ideal :D

[apparentlymart]

Last week I answered a Stack Overflow question that covered similar ground, so the details there may be useful to you.

The short version is: Terraform doesn't _itself_ understand the concepts of "rolling forward" and "rolling back". Instead, it just knows what the world _currently_ looks like and what the config says it _should_ look like, and it devises a plan for changing the world to match the config.

We suggest, as @Puneeth-n noted, that version control be used to track configuration changes over time. In a collaborative environment, the common approach is a policy that any change must be committed and pushed before it is applied. This can either be managed manually -- which, as you noted, has the risk that someone will forget to do it -- or via some lightweight orchestration where terraform apply is run on a separate, managed system that is wrapped in a script that prevents applying anything other than what is on a particular branch in git.

Many organizations have their own home-grown wrapper scripts and/or other orchestration to deal with this. Alternatively, Hashicorp offers Terraform Enterprise as a pre-built solution to this, which includes a workflow for tracking changes to a git repo, applying them via a web-based approval page, and tracking who authored and approved each change.

[Puneeth-n]

@praveen6311 For ex: We do something unconventional where in we have a huge single repository for everything. All our micro services, scripts and the entire terraform config are in a single repo. if some developer introduces a new feature, they also change the terraform config and create a PR. if they forget to do the terraform changes and merge to master, the worst that happens is nothing changes on the infrastructure.

Plus We have Jenkins Github webhook integration (Poorman's Terraform Enterprise :D ) that validates the terraform configs.

[praveen6311]

thanks @Puneeth-n and @apparentlymart for inputs. @

[metmajer]

@Puneeth-n mind explaining what the terraform config validation in Jenkins though the webhook looks like? I am currently working on setting up an IaaS delivery process that's heavily based on Terraform. Validation of Terraform configs is done using a pre-commit hook. Any particular reason you're letting this run in Jenkins? E.g. are you running InSpec tests? Cheers!

[Puneeth-n]

@metmajer sorry was on vacation. Just got back today. We do Terraform plan on our production and staging environment as part of Jenkins and also check for formatting issues.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.