Improved integration between Terraform and GitOps providers

[bryantbiggs]

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

What is the outcome that you are trying to reach?

Better integration between Terraform and GitOps providers. There are infrastructure resources that are dynamically created by Terraform, and I wish to keep creating those resources in Terraform, but I need to pass their generated values (IDs, ARNs, etc.) over to my GitOps provider for downstream addons/applications to consume those values

Describe the solution you would like

In a perfect world, Terraform does not need to authenticate to the EKS cluster nor access inside the cluster. Terraform creates the necessary AWS infrastructure components, and passes those dynamically generated values over to my GitOps provider.

In addition, I would also like the ability to have the ability to choose between ArgoCD, FluxCD, or any other GitOps providers that may come along. To scope the current problem space - we will focus only on ArgoCD and FluxCD support.

Describe alternatives you have considered

None - this is an improvement over the current setup

Additional context

We often hear feedback from users that they wish to pass more values from Terraform to the GitOps provider via the associated *_helm_config variable. This request is tangentially related in that any dynamically generated values, as well as user provided values, can be passed over to the GitOps provider

• Reference [ADDON] - Flux #26
• Reference Support for helm valueFiles #40
• Reference Add an EKS cluster to an existing argocd #58
• Reference [FEATURE] Support for passing *_helm_config to ArgoCD #59
• Reference [FEATURE] Specify destination namespace in ArgoCD application config #60
• Reference Various GitOps flags don't appear to be respected. #104
• Reference how inject helm values for addons if argocd_manage_add_ons=true / add_on_application=true #119
• Reference ArgoCD: create applications with custom plugins #127
• Reference Can I add an ArgoCD application via chart and not via git repo? terraform-aws-eks-blueprints#1583
• Reference How can I pass custom values to an ArgoCD application? terraform-aws-eks-blueprints#1579
• Reference targetRevision not being set by config for ArgoCD terraform-aws-eks-blueprints#1587
• Reference Passing HELM values file overrwrite some settings from addon terraform-aws-eks-blueprints#1609

[bryantbiggs]

We would like to hear any and all feedback on this topic from the community - please feel free to leave your comments and feedback below - thank you!

[dtherhtun]

We are anticipating the integration of ArgoCD Projects and Applications, similar to v4 blueprints.

[shazib-summar]

Hi, thank you for working on this and considering community input. Do we have a roadmap regarding the next release/iteration?

[bryantbiggs]

You track activity related to the EKS Blueprints projects here https://github.com/orgs/aws-ia/projects/11/views/1?query=is%3Aopen+sort%3Aupdated-desc

[csantanapr]

I made some progress in the integration of Terraform and GitOps
You can give it a try here, and provide feedback

• https://github.com/gitops-bridge-dev/gitops-bridge/tree/main/argocd/iac/terraform/examples/eks
• https://github.com/gitops-bridge-dev/gitops-bridge-argocd-control-plane-template/tree/main/bootstrap/control-plane/addons/aws

Please fork the repos as we are doing braking changes incorporating feedback from the community

[Almenon]

Just ran into this issue. The lack of integration is a problem when it comes to upgrading EKS blueprints to v5 from v4, as in v4 you could define argocd_applications to specify a helm repo to bootstrap argocd, but there is no equivalent parameter in v5.

Our setup looks like this:

Terraform code: initializes eks_addons and enable_<chart> charts that should be in all clusters. Also creates argocd and links it to bootstrap git repository.
Helm code: bootstrap git repository points here. We put custom charts here that may not go in every cluster.

[jmreicha]

I recently was tasked with deploying and managing EKS clusters and started reading up on blueprints and how it all works. When I got everything figured out and working in v4 I heard about the v5 release.

From an outsiders perspective from somebody that just wants a cluster and an Argo install that I can plug my baseline infrastructure charts into, this refactor is incredibly confusing.

Are there any guides/tutorials planned for how to do this? Apologies if I have missed anything but I have searched through docs and find myself going in circles it seems like searching for the relevant information.

[Almenon]

Here is my current understanding:

• We can set create_kubernetes_resources to False to have EKS Blueprints only create the AWS resources. The helm charts will not be deployed. We have to manually configure our argocd resources (helm charts/kustomize/jsonnet/etc.) given the output, or figure out a way to automatically parse the output and and automatically inject that into our argocd resources.
• We can't point argocd to a bootstrap repo
• We can't have blueprints and argocd both deploy helm charts, it has to be one or the other.

So we've made progress ~ bullet point 1 is completed by #209. I'll open up a issue for the second two bullet points.

[Almenon]

Actually, looks like #226 would solve the last two bullet points.