The article misses a key bit of information TF needs when making a plan: 4. The previous Terraform configuration This is effectively stored by state. We need this because if a resource is removed from the new config then Terraform needs to be able to delete the existing resource from the world. If we don’t have the state then Terraform must either: 1. Not delete it from the world 2. Or risk deleting something not man…
Terraform should have remained stateless
261–270 of 329 posts
Re: Terraform should have remained stateless
#262Earlier quoted context omitted.
yeah, but then you DO have to worry about scanning every single resource you control, every time you plan and run
I built pretty much the system you’re describing for my company (a stateless terraform alternative) and this scan that you cite as a negative happens in… 100ms in parallel? Roughly the same amount of time it would take to download a state file? Dunno about you but ensuring state is always accurate and in-sync is well worth the trade-off to me.
Is this tool private or available for us to try out?
Re: Terraform should have remained stateless
#263As every application developer knows, duplication of state is a primary source of bugs. To combat this, React/Flux type of architectures became extremely popular where state flows in one direction only. They dictate that, no you can't just cheat a little and use jQuery to modify some element, it _will_ get bulldozed on the next render. And a lot of Terraform headaches do come from this analogous reconciliation of what really is (our cloud env), what we want (our TF code) and this intermediate state of what TF thinks the cloud state is.
So, by saying that you cannot have resources outside those defined by TF there is actually a massive simplification with far reaching consequences possible.
How I imagine the experience would be:
- You could say that your Dev env is a shitshow and always will be, of manually created resources and only partially TFed. But your Production and Staging envs are opted in to "strict mode". This means that if there is a conflict you do only have two options: import the offender or destroy it, and the critical mindset change is that this is a good thing and will save us a lot of tears later on.
- Caching is an orthogonal concern. Terraform mixes these two together to its detriment, but the nature of a cache is such that you can safely blow it away and perhaps the next reconciliation will be slow, but it will be accurate. I also don't believe it would actually be that slow, tools like Cloudcraft map the entire metadata of your account in seconds.
- I find the excuse that some resources don't support tags intellectually lazy. Of the top of my head thinking about it for a minute, could you tag a parent resource with the child metadata you need? E.g. individual DNS records don't have tags, OK tag the Zone with childA=value. Same thing with tag length limits, you can work around it, concatenate values or whatever. However, in a truly strict mode you wouldn't even need metadata in tags because the TF code describes the entire target environment.
I hope Terraform would entertain such a strict stateless mode. Unfortunately it will probably take another tool, because the problem is not so much technical as it is an entire mindset change.
Re: Terraform should have remained stateless
#264Earlier quoted context omitted.
Yeah but then you don’t have to worry about the state getting out of sync which is one of the biggest problems. Also versioning is a pain
yeah, but then you DO have to worry about scanning every single resource you control, every time you plan and run
Re: Terraform should have remained stateless
#265Re: Terraform should have remained stateless
#266Earlier quoted context omitted.
That's not state information though, that's metadata.
If some state information is stored using metadata then we need that metadata to know the total state. The contents of TF state is more than what can be read from the provider APIs often.
Re: Terraform should have remained stateless
#267The article misses a key bit of information TF needs when making a plan: 4. The previous Terraform configuration This is effectively stored by state. We need this because if a resource is removed from the new config then Terraform needs to be able to delete the existing resource from the world. If we don’t have the state then Terraform must either: 1. Not delete it from the world 2. Or risk deleting something not man…
You can still store state but delegate it to a different system. One that is more robust and homogeneous like a kubernetes API. This is what crossplane does
Re: Terraform should have remained stateless
#268Earlier quoted context omitted.
I'll play devil's advocate (because I understand the need for a state): What if terraform was able to perform a complete audit of your environment for each provider and say "this is what you've got, mate", then give you options for each resource: 1. Accept (turns it into terraform code) 2. Reject (removes the resource) Taken further, this idea effectively means that manually creating something like EKS could be a way…
That approach wouldn't work if your infrastructure is spread between multiple Terraform workspaces. (as is often done).
Re: Terraform should have remained stateless
#269Earlier quoted context omitted.
I am starting on a journey to deploy resources in the big three cloud providers (AWS, Azure, Google) and could use your input. So far, we have been working with Ansible to provision our AWS resources. Because we find Ansible to be a pain to use, we are considering Terraform - especially when working with multiple cloud providers. Do you have any advice or best practices to properly deploy and manage instances using T…
I would suggest maybe bypassing terraform entirely and going to something like Pulumi or CDK.
Re: Terraform should have remained stateless
#270You couldn't do everything that Terraform does today without a local state, but perhaps that would be a good thing? Call it "Terraform strict mode". As every application developer knows, duplication of state is a primary source of bugs. To combat this, React/Flux type of architectures became extremely popular where state flows in one direction only. They dictate that, no you can't just cheat a little and use jQuery t…