terraform-provider-argocd
terraform-kubernetes-manifests
| terraform-provider-argocd | terraform-kubernetes-manifests | |
|---|---|---|
| 2 | 2 | |
| 361 | 0 | |
| 1.1% | - | |
| 7.3 | 0.0 | |
| 8 days ago | about 2 years ago | |
| Go | HCL | |
| Mozilla Public License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
terraform-provider-argocd
-
Is using an argocd provider for terraform an anti-pattern? Why not just use helm provider?
I'm looking at projects like https://github.com/oboukili/terraform-provider-argocd and wondering if using this project would be an anti-pattern? For context I have a repo hosted with DigitalOcean that looks like atlantis provisioning terraform code folder -> atlantis code -> argocd -> pritunl. I'm thinking I want my initial terraform code to provision atlantis, then have atlantis provision an argocd server, then have argocd provision a custom pritunl helm chart. Just wondering if I should use Terraform to manage the argocd provisioning aspect of it or not and if it makes sense?
-
How to allow dynamic Terraform Provider Configuration
I'll use the example of the Argo CD provider. In a single Terraform run, we would like to:
terraform-kubernetes-manifests
-
Is it normal to get by Terraform's Local Exec?
tfk8s definitely needs some manual finagling. I like to use it to translate small hand managed yaml from an example into tf. I'm not a fan of helm, but where it's the only option I'll use the helm provider. And when I get a large multi-document yaml file as the release artifact, I'll use the kubectl provider but the charts have to be split out and namespace deployed first - here's an example.
-
Is using an argocd provider for terraform an anti-pattern? Why not just use helm provider?
I've made a repo with terraform modules that handle all of these that fits my needs - https://github.com/e91e63/terraform-kubernetes-manifests/tree/main/modules
What are some alternatives?
devops-stack - 🌊 An all-in-one Kubernetes ☸ stack using Argo CD 🐙 and Terraform as base components
tfk8s - A tool for converting Kubernetes YAML manifests to Terraform HCL
terraform-provider-aws - Terraform AWS provider [Moved to: https://github.com/hashicorp/terraform-provider-aws]
amazon-cloudwatch-container-insights - CloudWatch Agent Dockerfile and K8s YAML templates for CloudWatch Container Insights.
terraform-provider-google - Terraform Provider for Google Cloud Platform
terraform - Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.