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.
Further details
Use cases:
- 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
toml
configuration file - 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
Proposal
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 (closed)
- (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 happens when the
installed
key for the application in.gitlab/managed-apps/config.yaml
isfalse
.
- Potentially, most of the functionality will actually be implemented in a docker image which
.gitlab-ci.yml
will call. So.gitlab-ci.yml
is envisioned to be rarely needed to be updated.
We will start first with the ingress
application. Other applications are tracked in &2103
Documentation
See https://docs.gitlab.com/ee/user/clusters/applications.html#install-using-gitlab-ci-alpha
original proposal
Proposal
- Allow user to upload custom
values.yml
per chart to be installed- When file is present, create and use dedicated
kubernetes
repo for relevant instance/group/project (for instance when the Kubernetes integration is enabled GitLab creates a dedicated repository, accessible viahttps://gitlab.example.com/namespace/project.kubernetes_runner.git
(for runner),https://gitlab.example.com/namespace/project.kubernetes_prometheus.git
(for prometheus)- 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
install
orupdate
for 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.yml
file 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.yml
will not automatically trigger an upgrade/update
Links / references
- extracted from #5254 (closed)
- Recording of team meeting discussing this issue
Development log
Follow-up
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.