Lizz-compatible application

A Lizz-compatible application is an application that can be added with the lizz add command. There are some concepts and requirements which are explained on this page.

Tenant repository

As explained previously, Lizz follows the multi-tenant structure and each application is associated with a tenant. Concretely, this means that an application is a Git repository. The repository contains the application manifests which can be any Kubernetes resources (Deployment, Pod, HelmRelease, etc...). It only needs to contain a Kustomization resource that points to the other resources. A good example of a tenant repository structure can be found here.

For example, the repository structure of the Nextcloud application is the following:

├── base
│   ├── certificate.yaml
│   ├── kustomization.yaml
│   ├── release.yaml
│   ├── secret.yaml
│   └── source.yaml
├── default
│   └── kustomization.yaml
└── lizz.yaml

The base folder contains the manifests of the application and a Kustomization resource. The default folder contains the default Kustomization resource that simply points to the base folder without any kustomization of the manifests. It is possible to add other folders with other Kustomization resources depending on the use cases, for example, a specific configuration of the application for a specific cloud provider. The lizz.yaml file is the Lizz configuration file which is explained later on this page.

Application template

A Lizz-compatible application is automatically configured according to the cluster in which it will be added. This mechanism works similarly to Helm chart template mechanism.

The lizz.yaml file defines values that can be used in the manifests of the application. Lizz uses the standard template library of Go enhanced with template functions from the Sprig library.

Values

There are multiple types of values, each one serves a different purpose.

type Values struct {
    ApplicationDependencies []ApplicationDependency `json:"applicationDependencies,omitempty"`
    UserValues              []UserValue             `json:"userValues,omitempty"`
    ClusterValues           []ClusterValue          `json:"clusterValues,omitempty"`
    ApplicationValues       []ApplicationValue      `json:"applicationValues,omitempty"`
    ApplicationSecrets      []ApplicationSecret     `json:"applicationSecrets,omitempty"`
    Passwords               []Password              `json:"passwords,omitempty"`
}

The detail of the available values to an application can be found in the Values page.

Templates

The values are passed to the templates as a map (map[string]interface{}) and can be accessed in the template as follows:

{{ index . "<Name of the value>" }}

It is possible to create complex flow as described in the Helm documentation. Here is an example with the beginning of the release.yaml file of the Homer application:

base/release.yaml

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: homer
  namespace: {{ index . "namespace" }}
spec:
  serviceAccountName: {{ index . "serviceAccountName" }}
  releaseName: homer
  chart:
    spec:
      chart: homer
      version: "8.0.2"
      sourceRef:
        kind: HelmRepository
        name: k8s-at-home
  interval: 30m
  install:
    remediation:
      retries: 3
  test:
    enable: false
  values:
    ingress:
      main:
        {{- if and (index . "isNginxInstalled") (index . "isDomainInstalled") }}
        enabled: true
        annotations:
          kubernetes.io/ingress.class: nginx
        hosts:
          - host: homer.{{ index . "domain"}}
            paths:
              - path: "/"
                pathType: Prefix
        {{- else }}
        enable: false
        {{- end }}
        {{- if and (index . "isNginxInstalled") (index . "isDomainInstalled") (index . "isCertManagerInstalled") }}
        tls:
          - secretName: homer-cert
            hosts:
              - homer.{{ index . "domain"}}
        {{- end }}
[...]