tofu-controller VS atlantis

We stumbled upon a project for maintaining Terraform with CRDs that we could deploy with Helm. That project is now called Tofu-Controller - another WeaveWorks project, so it integrated great with our existing Flux setup.

https://github.com/weaveworks/tf-controller/issues/1166#issu...

Weave's TF-Controller, which also has fewer bugs, much better adoption, and it looks like it's actually being developed by someone. But requires a weird argocd <-> flux interop boilerplate. It's a "controller for flux" and not a Kubernetes controller, and I don't really get such ambiguous targeting , but meh...

Wrt tools, I wanted to integrate terraform with Flux thanks to their tf-controller. Conciling the core gitops features with terraform would be great imho.

I'm using Flux instead of Argo which has support for running terraform from a given Git Repo or OCI artifact so essentially I still fall back on Terraform when needed and it's applied via GitOps.

tf-controller which is integrated with Flux GitOps and reconciles Terraform files in a control loop

While searching for alternatives for running Terraform using Kubernetes, I found several controllers and operators, but none that I felt had as much potential as the tf-controller from Weaveworks. We are already using Flux as our GitOps tool, and the tf-controller works by utilizing some of the core functionality from Flux, and has a custom resource for Terraform deployments. The source controller takes care of fetching our modules, the kustomize controllers apply the Terraform resources, and then the controller spin up static pods (called runners) that runs your Terraform commands.

For us, GitOps is a vital part of how we operate, and it is the magic sauce that fuels our platform offering. Not only do we use it for application deployments, but by utilizing the Weaveworks tf-controller, we can create services using Terraform to automate our infrastructure deployments.

Some further research brought me to Weaveworks' TF-Controller which appears to be able to do what I want at least for the initial deployment step. Flux CD (also by Weaveworks) integrates with KEDA now, so it would be great if it could also integrate with KEDA to manage terraform-deployed Azure resources.

None of these are a replacement of Terraform Cloud (recently rebranded to HCP Terraform). For example, when you create a PR, it could affect multiple workspaces. The new experimental version of TFC/TFE (I refuse to call it HCP!) implements Stacks, which is something like a workflow, and links one workspace output to other workspace inputs. None of the open-source solutions, including the paid Digger [0], support this - only the paid one, such as Spacelift [1] (which is the closest to TFC if you ask me). Having a monorepo of Terraform is a common design pattern, so, if I change an embedded module, it could trigger changes it many workspaces. As far as I know, Atlantis [2] can't really help in this case.

By the way, the reason I singled-out Spacelift is due to its quality, and the great Terraform provider it has. Scalr [3], for example, has a really low-quality Terraform provider. I extensively use the hashicorp/tfe provider to manage TFC itself.

[0]: https://digger.dev/

[1]: https://spacelift.io/

[2]: https://www.runatlantis.io/

[3]: https://www.scalr.com/

Atlantis is a pull request automation tool that works well with plain Terraform right away. But what if we're already using Terramate to generate Terraform code?

Atlantis automates reviewing and deploying Terraform via pull requests, streamlining collaboration and ensuring consistency across Terraform deployments.

For example, Atlantisgo for Terraform, Zapier’s Kubechecks for Argo CD, Quizlet’s GitHub action all do something similar to this. But a generic, extensible tool for IaC providers doesn’t seem to exist. Additionally, many of them require exposing your Kubernetes cluster or other infrastructure to third-party access, webhooks, etc.

Our first attempt was to introduce other engineering teams to Terraform - the Platform team was already using it extensively with Terragrunt, and using Atlantis to automate plan and apply operations in a Git flow to ensure infrastructure was consistent. We'd written modules, with documentation, and an engineer would simply need to raise a PR to use the module and provide the right values, and Atlantis (once the PR was approved by Platform) would go ahead and set it up for them.

Alternatively, you can look at solutions like Atlantis or spacelift.

Atlantis: https://www.runatlantis.io/

Looking at the commits at https://github.com/runatlantis/atlantis, it looks like 1.6.5. Am I right?

We use Atlantis [0] for CI/CD automation of Terraform pull requests to a centralized repository. It's pretty good too, especially for a self-hosted solution. I can't see how Terraform Cloud's costs would be justifiable for us without a custom contract.

[0] https://www.runatlantis.io/