https://platformengineering.org logo
Join Slack
Powered by
Feeling adventurous?... Wish to plugin existing te...
# general
c
Feeling adventurous?... Wish to plugin existing terraform code into native kubernetes and enjoy all the benefits of kubernetes. Check out this repo https://github.com/alustan/terraform-controller I just bootstrapped over the weekend. Make contributions. Let's explore together.
c
Hey @Chichi! Two things - this looks more like it belongs in #platform-toolbox or #terraform and where is the difference between your approach and something like https://developer.hashicorp.com/terraform/cloud-docs/integrations/kubernetes?
a
@Clemens Jütte isn't the terraform cloud operator only a controller for terraform cloud ? Not a terraform controller 'per se' ? Maybe I missed something but it's how I understood it
r
c
@Alan Longuet you’re right that it needs TF cloud for a few operations but not for all. Also I must confess I didn’t investigate very deeply. But Ricardo already posted another one, which is OSS and much more mature, so the question prevails - why another one?
c
Hi @jay Haven gone through the documentation a little bit. These are my inferences; They both aim to integrate terraform with kubernetes but differ significantly in scope, implementation and use case
1.Execution envrionment: index project: kubernetes Terraform cloud operator: terraform cloud/Enterprise. 2.State management; index project: custom (AWS, vault) terraform cloud operator: terraform cloud/Enterprise 3.CRD; Index project; custom resources for terraform config. Terraform cloud operator; crd for terraform workspaces. 4.Policy enforcement; custom logic (if implemented) terraform cloud operator; sentinel policies in terraform cloud. 5.Flexibility; highly customizable terraform cloud operator; limited to features provided by terraform cloud. 6.Target users; developers needing custom integration; terraform cloud provider; users of terraform cloud/enterprise
a
Well there's multiple solutions in the open-source world for every needs, it helps getting better tools in my mind if we'd follow this only one tool for one usage we would not have argocd and fluxcd for example
I've been working on something similar to what @Chichi posted and I find it worthy to see another take on this peculiar problem
c
I totally agree @Alan Longuet! But there’s almost always a reason for “another one” and that’s the interesting part. Sometimes it’s not even a technical reason but rather differences in license (TF vs. Tofu) or even project philosophy/scope. It’s really hard to uncover that sometimes. so I’d rather ask - after all debate is what a community is there for 🙂
a
To me there's a real spot to take in the open-source world for a fully fledged TACoS (Terraform Automation and Collaboration Software), the tofu-controller is really good but it does look like a plugin to flux and not an IAC tool such as Spacelift / Env0 / Terraform Cloud
c
Interesting take thinking
I think that making the Tofu controller a plugin for Flux is really smart. It eliminates the whole interface question with “Gitops and done” - also it solves the question of interaction pattern - git push is the trigger. It also solves the question of how to work with drift - Flux does. So you get a ton of things that would need to be built in a custom way around the TF controller experience for free and can work just on that. Caveat - like whenever you inherit context, you need to be okay with it’s opinions.
a
Yes that was a really good idea to use flux to introduce a similar experience between yaml manifests and HCL "manifests" I'm convinced it's the way to go !
7 Views
Open in Slack
PreviousNext
Powered by