Skip to content

Support of templating tools (kustomize, kpt, helm)

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.

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.

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: ?

Proposal

Assuming the following directory layout:

/apps
├── shared # some shared config, used by all apps
│   ├── kustomization.yaml
│   └── config.yaml
├── app1
|   ├── base
|   │   ├── deployment.yaml
|   │   ├── kustomization.yaml # refers to "../../shared"
|   │   └── service.yaml
|   └── overlays
|       ├── dev
|       │   ├── kustomization.yaml
|       │   └── patch.yaml
|       ├── prod
|       │   ├── kustomization.yaml
|       │   └── patch.yaml
|       └── staging
|           ├── kustomization.yaml
|           └── patch.yaml
├── app2
    ├── base
    │   ├── deployment.yaml
    │   ├── kustomization.yaml # refers to "../../shared"
    │   └── service.yaml
    └── overlays
        ├── dev
        |   └── ...
        ├── prod
        |   └── ...
        └── staging
            └── ...

The following Agent configuration

gitops:
  applications:
  - path: apps/app1/overlays/prod
  - path: apps/app2/overlays/prod

Is parsed as follows:

  • Check if root is given. If yes, use it as the package root. If not, go to the next step.
  • Check that there is path/kustomization.yaml file in the repo. If no, then simply send all *.yaml/*.yml/*.json files from that directory recursively. If yes, go to next step.
  • Start looking for Krmfile/Kptfile in path directory and it's parent directories to locate the root? Once the package magic file is found, the whole package is sent to the agent.
  • If it's not there, then simply send all *.yaml/*.yml/*.json files from that directory recursively, and log a warning.

Where

  • root means the top directory that is sent to the agent
  • magic file is one of
    • Krmfile or Kptfile is present, (somehow) apply setters appropriately
    • kustomization.yaml is present, use kustomize
    • Chart.yaml is present, use helm

The project key

The project key defaults to the agent configuration project.

gitops:
  applications:
  - path: apps/app1/overlays/prod
  - path: apps/app2/overlays/prod

is equivalent to

gitops:
  applications:
  - project: project/slug/to/current/project
    path: apps/app1/overlays/prod
  - project: project/slug/to/current/project
    path: apps/app2/overlays/prod

The root key

The root key can be specified, but it is optional. If it is not specified, follow the logic described above.

The following is valid:

gitops:
  applications:
  - project: project/slug/to/current/project
    path: apps/app1/overlays/prod
    root: apps
  - project: project/slug/to/current/project
    path: apps/app2/overlays/prod

Iterations

  1. Set project to default to the Agent configuration project
  2. ???

Success metrics

  • collect metrics about the final tool used
Edited by Viktor Nagy (GitLab)