:bulb: **Please, provide your feedback as a comment to this epic.** :speech_balloon: As we released the initial version of [Helm support](https://docs.gitlab.com/ee/user/clusters/agent/gitops/helm.html), we would like to hear your feedback on the [known issues](https://docs.gitlab.com/ee/user/clusters/agent/gitops/helm.html#known-issues) and missing requirements. You can read more about the [planned iteration](https://gitlab.com/groups/gitlab-org/-/epics/7938#iterations "Support of templating tools (kustomize, kpt, helm)") below. In your feedback, please mention `@nagyv-gitlab` to ensure your comment won't get lost. ## Problem Statement As an Application Operator, in order to focus on business problems, I want to use the tools I already know when I set up my deployments. As an Application Operator, in order to minimize efforts, I want to re-use public helm charts with minimal extra effort. As an Application Operator, in order to support multiple environments, I want to chain `helm` and `kustomize` in my deployments. As an Application Operator, in order to fulfil my requirements, I want to support Helm charts with [Helm functions](https://helm.sh/docs/chart_template_guide/functions_and_pipelines/). As an Application Operator, in order to automate deployments, I want to specify `semver` ranges for image versions. As an Application Operator, in order to minimize my DevOps work, I want to use GitOps+AutoDevOps Helm charts. <details> <summary>RICE score</summary> ## Reach: 10 - Helm is used by the overwhelming majority of interviewed users - Kustomize is used relatively often, sometimes together, sometimes without Helm - Vanilla manifests are used by experienced teams mostly, but even they prefer to have Kustomize support ## Impact: 1.5 - Experienced users don't mind to switch from Helm, but Kustomize is requested by them to keep DRY - Unexperienced users just default to Helm, and are afraid of switching ## Confidence: 100% This topic was asked on all the interviews in the past year, and the responses were very consistent. ## Effort: ? </details> ## Proposal ### Configuration based idea We extend the agent config yaml with references to the Helm and Kustomize resources. ### Helm support We borrowed the idea from Flux to integrate directly with the Helm library. ### Kustomize support To be discussed ### Helm charts support We need to be able to retrieve a Helm chart from: * a public GitLab git repo :white_check_mark: * a private GitLab git repo * agent config repo :white_check_mark: * custom private repo :hourglass_flowing_sand: * a public helm chart registry :hourglass_flowing_sand: * a private helm chart registry :hourglass_flowing_sand: * URL with [chart archive](https://helm.sh/docs/glossary/#chart-archive) with and without authentication :hourglass_flowing_sand: * ~~a public non-GitLab git repo~~ * ~~a private non-GitLab git repo~~ We need to be able to retrieve a configuration for the chart from: - A `values.yaml` file in the chart directory :white_check_mark: - Encoded in the agent config :white_check_mark: - A URL - a public GitLab git repo (path to file in the repo) - a private GitLab git repo (path to file in the repo) - ~~a public non-GitLab git repo (path to file in the repo)~~ - ~~a private non-GitLab git repo (path to file in the repo)~~ We can learn a lot from the [Flux Helm source reference docs](https://fluxcd.io/docs/components/source/helmcharts/#source-reference). ## Iterations We can add support the these in iterations: ### MVC: start with one repository - should work with public repositories and the agent configuration project :white_check_mark: ### Provide basic "environments" support The first iteration requires the `values.yaml` to be part of the Helm chart. As a result, if the user want to deploy the same application into multiple environments, they need to duplicate all the code only to change the `values`. - add support for values as part of the agent configuration: https://gitlab.com/gitlab-org/gitlab/-/issues/372024+ - [add support for file-based values files](https://gitlab.com/gitlab-org/gitlab/-/issues/382082) where the file is either in the agent config repository or in a public repository ### Allow scaling to multiple repos A typical pattern we see is to have a single agent per cluster and multiple Helm repos located closer to the application code. - Could use the authorization logic from https://gitlab.com/groups/gitlab-org/-/epics/7704+ to access other projects than the agent configuration project - the `values.yaml` and the helm chart might be in separate repositories ### Registry support After having support for git repositories as a source of Helm charts, we want to add support to Helm registries 1. can start with public registry support 2. followed by private registries that require authentication - the authentication could be GitLab-integrated - the authentication could be using references to Secrets available in the cluster ### When possible We should document how to use the feature with the [default Auto Deploy chart](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/tree/master/assets/auto-deploy-app) ## Success metrics - number of agents that have Helm configured - monthly sync events of the Helm charts, not counting "ghost events" happening to avoid config drift ## Refernces - https://fluxcd.io/docs/components/source/helmcharts/ - https://medium.com/@michael.vittrup.larsen/replacing-helm-and-kustomize-with-krm-functions-a-new-approach-to-configuration-management-676212cc1332 - https://gitlab.com/gitlab-org/gitlab/-/issues/363113+ - [Auto DevOps chart customization in CI](https://docs.gitlab.com/ee/topics/autodevops/customize.html#custom-helm-chart) - [Default Auto Deploy chart](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/tree/master/assets/auto-deploy-app) - Helm Go SDK docs https://helm.sh/docs/topics/advanced/#go-sdk and https://pkg.go.dev/helm.sh/helm/v3 - https://docs.gitlab.com/ee/user/packages/helm_repository/