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
    • this is just an example, we could support this indirectly through kustomize

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