Here I am wishing that CloudFormation had one killer feature that would have allowed us to use it at work: the ability to adopt existing resources into a CF stack. When we were starting on the path of "hey maybe all our infra shouldn't be pointy clicky", we chose between CloudFormation, Terraform, and making something in-house. Out of those three, Terraform was the clear winner for us at the time, but it has not been without issues.
Nobody else in this whole thread seems to be complaining about state management. I think it's insane that Terraform encodes where a given resource is in your filesystem / module hierarchy into the state JSON structure. (Unless something has changed since I last looked,) if you want to move things around in your .tf source, terraform can only apply that by tearing down the old resource and recreating it.
For our large setup, in order to adopt Terraform, we've had to spend a ton of time upfront thinking very hard about how all of our .tf sources are going to look, and it's delayed our deployment by months.
Terraform allows you to make modifications to the state file yourself, both with terraform commands like terraform state mv, or manually if you're brave enough to edit the JSON. It requires confidence in using the tool, of course. But it also encourages you to create your cloud resources in a way where it's safe to let Terraform destroy and re-create most of it at any time.
`terraform state mv` is indeed the trick. It took me a while to understand it, but this blog post helped. [1] It leads you through refactoring some resources into a module.
The key takeaway for me was "we really only need to consider the nodes that map to the physical resources of our infrastructure when we are planning our state surgery. This means we can ignore all of the nodes that correspond to data sources, variables, and providers."
So after a refactor, this is what I do now: (1) run plan to get the names of everything terraform wants to delete and recreate; (2) pair all the resource nodes manually and translate them to state mv commands; (3) re-run plan and verify that terraform is now convinced there is nothing to do.
It would be nice if terraform could do this for me, of course, but I find that it is generally possible to avoid delete and recreate if all I've done is a refactoring.
I'm not so sure about this. My experience has been limited, but so far, Terraform has been a treat to work with. I didn't think Terraform cared about where the resources were defined in a the plan step. I'd love for someone with further experience to weigh in here.
Also, Terraform state on the file system? Do you have the luxury of solo development without the need for a Terraform remote backend?
I think the complaint is that you define a resource in some module, then do a bunch of refactoring with the result that the very same resource is now defined in another module, terraform will need to be explicitly told that it's still the same resource or else it will destroy and recreate it on application.
That is, it's about the file system layout of the .tf tree, not the state.
i heard this third hand, but apparently cfn was slated to get this feature but it was nixed because of concerns with increased support requests. the official stance from amazon now is that you should be able to trivially destroy/recreate resources and cfn isn't going to adopt anything that makes it easier to create stateful deployments
it does suck to have to copy the contents of an s3 bucket just to move a bucket inside of a template tho, for sure
Nobody else in this whole thread seems to be complaining about state management. I think it's insane that Terraform encodes where a given resource is in your filesystem / module hierarchy into the state JSON structure. (Unless something has changed since I last looked,) if you want to move things around in your .tf source, terraform can only apply that by tearing down the old resource and recreating it.
For our large setup, in order to adopt Terraform, we've had to spend a ton of time upfront thinking very hard about how all of our .tf sources are going to look, and it's delayed our deployment by months.