Version controlled GitLab Managed Apps with custom configuration
Problem to solve
At the moment users can install gitlab managed apps, but there is no way to pass custom configuration to any of these charts. Users at all levels require customization of the charts being deployed, for example, large enterprise customers may have policies that prevent default from being deployed and currently there is no way to customize.
- A cluster with node labels to differ between running as "on-demand" instance or "spot" instance on AWS. On-demand node instance has a taint, so no gitlab managed apps can run on them. Apps which should run on "on-demand" instances need to get a toleration and a node selector
- User needs to customize runner helm chart by passing
- User that need to upload a personal ssl certificate on an Ingress deployment
- User that need to edit Prometheus configuration, maybe to improve k8s monitoring
- User that need to manage storage in Prometheus deployment
- User needs to pass configuration file for use with crossplane
End state: Execute all helm operations as GitLab CI yml in the connected cluster repo (vs running on server)
- Allow user to connect a cluster to a GitLab repository (cluster repo)
- User creates a repo themselves and provides it at cluster install time #32810
- (follow-up) GitLab creates the repo automatically and populates (providing own optional)
If cluster has a connected cluster repo (alpha), we do not have single click installed apps.
- Create a GitLab CI yml template that will
- Install a cluster application, using Helmfile
- User can specify
.gitlab/managed-apps/<application-name>/values.yaml(exact location TBC) for customization of helm chart.
- Upgrade TBC
- Uninstall TBC
- Potentially, most of the functionality will actually be implemented in a docker image which
.gitlab-ci.ymlwill call. So
.gitlab-ci.ymlis envisioned to be rarely needed to be updated.
- Allow user to upload custom
values.ymlper chart to be installed
- When file is present, create and use dedicated
kubernetesrepo for relevant instance/group/project (for instance when the Kubernetes integration is enabled GitLab creates a dedicated repository, accessible via
- Each time the file is edited, uploaded, deleted, a matching commit is created.
- Users should be able to clone, change, commit locally and push changes.
- When user clicks
updatefor the relevant app, GitLab will check the relevant repo and if file is present, use it to customize chart installation prior to helm install/upgrade
- If GitLab decides there are configuration values that are not safe to change AND the user submits a
values.ymlfile which changes such values, GitLab will generate a failure and prevent the install/update of the relevant chart. For each of the application definitions we could define which "paths" (read: YAML structure paths, e.g.
runners.cache.cacheType) are disallowed.
- Preliminarily, updates to
values.ymlwill not automatically trigger an upgrade/update