0
votes

I would like to version control my cloud resources initially before using it to apply through Terraform. Is there anyway I can run a single command and store the current state of my cloud?

I have tried to use Terraform's import command:

terraform import ADR ID

But this takes a long time to identify all the resources and import them.

I have tried terraforming but this also needs a resource type to import:

terraforming s3

Is there any tool that can help in importing all existing resources?

2
Why would you want to do this all in one go? If I had a lot of non Terraformed infrastructure I'd work on things piecemeal, slowly moving more things into being managed by Terraform and taking that as an opportunity to learn more about how it works rather than a big bang migration that could easily end badly.ydaetskcoR
I do not want to suddenly migrate the team to terraform. At the same time, I do not want to loose track of what is going across in the account manually. Just keeping a version control of its moving parts while we migrate to terraform.Kannaiyan
How would the tool know the best way to structure this across the multiple state files and directories you'll want for something as complex as a full account? This isn't something that can really be done automatically and I'd honestly say even something like terraforming is a bad idea that leads to bad practices and will end up hurting you longer term. Think about blast radiuses and what things are related to what, structure them that way and then put the time in to slowly move things over piece by piece that fits that structure.ydaetskcoR
Atleast as a start, how would I import everything and start making changes through terraform?Kannaiyan
That would give you a huge blast radius where a singe mistake could wipe out everything in your account. It's a really bad idea and I'd advise strongly against doing it.ydaetskcoR

2 Answers

2
votes

While this doesn't technically answer your question I would strongly advise not to try and import an entire existing AWS account into Terraform in a single way even if it was possible.

If you look at any Terraform best practices an awful lot of it comes down to minimising blast radius of things so only things that make sense to be changed at the same time as each other are ever applied at the same time. Charity Majors wrote up a good blog post about this and the impact it had when that wasn't the case.

Any tool that would mass import things (eg terraforming) is just going to dump everything in a single state file. Which, as mentioned before, is a bad idea.

While it sounds laborious I'd recommend that you being your migration to Terraform more carefully and methodically. In general I'd probably say that only new infrastructure should use Terraform, utilising Terraform's data sources to look up existing things such as VPC IDs that already exist.

Once you feel comfortable with using Terraform and structuring your infrastructure code and state files in a particular way you can then begin to think about how you would map your existing infrastructure code into Terraform state files etc and begin manually importing specific resources as necessary.

Doing things this way also allows you to find your feet with Terraform a bit better and understand its limitations and strengths while also working out how your team and/or CI will work together (eg remote state and state file locking and orchestration) without tripping over each other or causing potentially crippling state issues.

1
votes

I'm using terraformer to import my existing AWS infrastructure. It's much more flexible than terraforming and has no issues mentioned in answers.