4 ms·
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 pro
by raffraffraff 4y ago
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 to auto-compose Terraform code and store it in git.
Pros:
* You have the options of writing code, using the console or using a script or binary to perform a complex setup
* You have 100% code coverage once Terraform compared code with reality and forced you to choose
Cons:
* Auto-generated code is shitty.
* Slooooooow without caching (which is only one of the functions of state)
To make these concepts work without a remote state you pretty much have to run your infrastructure tool as a service, and implement things like:
1. Polling of providers on an interval
2. Alerting when something changes
3. Eventually consistent cache that can be forcibly updated in the UI or during sensitive operations
4. "Infrastructure Composer" UI, like a vastly simplified IaaS console that only shows deployed infrastructure and lets you group infrastructure by service, and let you define code-level modules
5. Show discovered dependencies and ordering, and allow you to explicitly set them (these should be stored as tags on the actual infrastructure components where possible)
6. Use some hot AI to group code-level resources, compare their configurations and generate config data to apply to resources/modules using for_each loops, while respecting service boundaries and offering advice on when to refactor.
- jillesvangurp 4y agoSounds like a plan for a next generation cloud provider. They all have internal state about your account and what's running there; they just don't really expose it in a standardized way. Nor do they provide standardized ways to update that (other than a lot of cli tools and REST APIs). We keep coming up with these layers of abstractions around stuff that at the bottom is essentially already stateful but just not in a useful way. Doing it right from the ground up might help. Of course, left to the usual suspects, this would just turn into another Frankenstein blackhole of devops time. The usual suspects are billion dollar corporations that thrive on layers of complexity.
- InvaderFizz 4y agoOracle Cloud does this. You can export Terraform for a Compartment[0] (think LDAP OU). This is how we do our initial terraform for new projects. We build up what is missing by hand, then export the terraform to save time and effort in building our own internal templates. We throw away most of it, but it is very useful for not having to look up how every aspect is named and what options are needed. 0: https://docs.public.oneportal.content.oci.oraclecloud.com/en-us/iaas/developer-tutorials/tutorials/tf-resource-discovery-setup/01-summary.htm https://docs.public.oneportal.content.oci.oraclecloud.com/en...
- sockpuppet_12 4y agoAzure terrafy
- janosdebugs 4y agoThis could partially work, but not for everything. For example, think of the userdata script that provisions the inside of a VM. Often, that needs to be generated based on something, for example certificates that are dynamically created. I believe, Terraform needs a mode that removes unmanaged resources, but that's quite the big ask and would result in yet another API / SDK change that providers would need to implement.
- roguas 4y agoYes - was thinking about exact same thing some time ago.
- maciekmm 4y agoThat approach wouldn't work if your infrastructure is spread between multiple Terraform workspaces. (as is often done).
- raffraffraff 4y agoI think that my imagining of the tool is sufficiently different to think that it isn't the same tool at all, and different workspaces wouldn't even be a thing. The composer UI in this case would provide a way to logically separate infra into different code bases but it would still have to know about all of them. Edit: and actually, without a state there is no concept of a remote state. All codebases talk to the same "service" so circling a bunch of infrastructure and saving it to a specific git project would be easier than connecting to a bunch of remote states and reading specific resource days from them. Even if you're code repo doesn't declare a resource, the omniscient IAC service "knows all"
- mountainriver 4y agoTF workspaces are one of the most complained about features at my company, hopefully a new tool would do something better