Support for state management and execution via Terraform OSS

aareet commented 4 years ago

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Syncing Kubernetes workspaces to Terraform Cloud provides a first-class Kubernetes interface for updating infrastructure managed by Terraform Cloud by re-executing updates to infrastructure configuration and Terraform Cloud non-sensitive variables. The functionality depends on Terraform Cloud to ensure consistent approaches to state locking, state storage, and execution.

If you would like to see the functionality of the operator include the execution and state management capabilities of open source Terraform, please document your use case below.

References

Documentation

jrhouston commented 4 years ago

Rancher has a project that does something very similar to this here https://github.com/rancher/terraform-controller

iAnomaly commented 4 years ago

Our governance and security requirements mandate private network access for reaching the resources managed by Terraform. Because Terraform Cloud requires that target resources have Internet accessibility and uses a shared run environment model, in order to adopt the Kubernetes Terraform Operator at our organization we either need (inclusive OR):

The ability to host our own Terraform Cloud runners
Terraform Operator's support for open source (self-hosted) Terraform

Thank you!

andre-taveira commented 4 years ago

Hey everyone,

As a platform engineer I'm looking for a way to give developers freedom to provision infrastructure without needing to contact central teams. That said I'm looking at wide variety of use cases and scenarios from Ops and Dev perspective so its worth to breakdown at least by personas.

Ops team:

Provide global modules that can be used by anyone in the cluster ( all namespaces). These are curated safe modules to be used across the board.
Scope modules to namespaces. Its very common to scope namespaces to teams or, in the case of SaaS providers , to Customer Instances. Some customer instances or user namespaces might require some extra infra that you don't want to make broadly available so you want some scoping there. This is nice for governance. Something like GoDaddy External secrets does. You add an annotation to the namespace which can dictate which modules that namespace has access to.
Access to modules via git. This binds to the previous point. What I look for is an option to set the operator at cluster scope and tell it something like: "Here are the private and public repos that contain modules that anyone can use". Another thing you want to potentially have is some capability on the CR to say: " Here is a private git repo and some keys (ref to a k8s secret) to AWS/GCP/Whatever...make the infra happen !" . This gives users as well flexibility to bring their own modules and cloud provider accounts providing some cool isolation.
Support the most common remote backends which is I'd guess is S3. Locking is a very important aspect here

DEV teams

Need access to cloud resources that will be used by their apps (RDS, S3 ,etc.) and don't want to figure out all the details on how to provision those. Most companies are developing general purpose CI pipelines to reconcile what's in Git with the deployed infra (some form of GitOps) and that's costing a lot of effort. Kubernetes and Operators offer the best breed of reconciliation loops and developers are used to kubernetes resources. It's the perfect match.
EKS , GKE, KIAM , Kube2IAM and a few others provide mechanisms to give specific access to cloud resources but that's still not enough since you give the engineers the pain of managing the lifecycle of provisioning their cloud resources and in the end they just want to create a K8s resource that deploy what they need and start using it.
GitOps all the way. I've been using ArgoCD for GitOps application deployment in K8s and developers love it. We already use K8s Service catalog with AWS service brokers but the experience is super bad. I'd like to have our helm charts declaring references to terraform CR's for modules and job's done.

Thoughts ? Me and some other folks were willing to start something fresh on this domain since its quite urgent for our day to day work but if we can collaborate over here it would be perfect ! Just need the directions on how to start :)

redeux commented 3 years ago

@iAnomaly once https://github.com/hashicorp/terraform-k8s/pull/82 is released, you'll have the ability to host your own Terraform Cloud Agents (Runners) and leverage them with this Operator.

iAnomaly commented 3 years ago

Thanks @redeux. I was super excited to see this but then read the fine print that Terraform Cloud Agents require Terraform Cloud for Business which has non-transparent pricing.

Would love to either see Cloud Agents supported on lower plans and/or support for Terraform OSS.

Obsecurus commented 2 years ago

Any updates on supporting this in the OSS? Looking into using https://github.com/isaaguilar/terraform-operator and would prefer to take the Hashicorp developed route but not looking for Terraform Cloud Enterprise/Business.

jrhouston commented 2 years ago

We are going to close this issue as we wont add support for Terraform OSS in this project. The scope of this project is to provide a Kubernetes management layer on top of Terraform Cloud. I would recommend contributing to one of the other mentioned open source projects that are trying to implement an operator for Terraform OSS:

hashicorp / terraform-k8s