The mono chart is comprised of multiple modules/features, that can be turned on by various “feature-flags” in the values yaml. For example, the

Deployment

resource is only optional, and can be turned on with the

deployment.enabled

value: https://github.com/cloudposse/charts/blob/master/incubator/monochart/templates/deployment.yaml#L1

So the chart is filled with conditional

if

sections, but also ranges. For example, you can define as many config maps as you need, with a section like this in your yaml values:

configMaps:
  my-first-config-map:
    key1: value1
    key2: value2
  my-second-config-map:
    key1: value1
    key2: value2

And that will generate multiple config maps with those keys/values using a range: https://github.com/cloudposse/charts/blob/master/incubator/monochart/templates/configmap.yaml#L2

Another neat pattern is that we can automatically pre-wire certain resources together, such as secrets that need to be referenced as env vars. You can define secrets in your values like so:

secrets:
  my-secrets:
    enabled: true
    env:
      ENV_VAR1: my secret 1
      ENV_VAR2: my secret 2

and that will both create the “my-secret”

Secret

resource here and make it’s content available as env vars in all payloads via a

secretRef

here.

This automatic wiring between resources is really what makes such a generic chart shine, as it simplifies the work of developers greatly.

Note that in our case, we are encrypting the individual values of secrets stored in the values yaml, so that we can commit them to git. To achieve that, we use https://github.com/bitnami-labs/sealed-secrets

That means that, in our own generic chart, we are not creating a regular kubernetes

Secret

resource, but rather a

<http://bitnami.com/v1alpha1/SealedSecret|bitnami.com/v1alpha1/SealedSecret>

resource, which gets picked-up by the sealed-secrets controller at run-time, which in turn produces the regular

Secret

. But we can pull the same trick of pre-wiring those secrets to all our payloads.

As for the higher-level complete recipes that I’m referring to in my talk, you won’t find such examples in Cloud Posse’s mono chart, but it follows the same kind of patterns, just much more tailored to the exact solutions we need to deploy over and over again. In our case, those recipes are: •

api

(our typical Go microservice) •

frontend

(our typical React front-end app) •

gateway

(our typical API Gateway written in Go with krakend)

The

api

module can be turned on and configured in the yaml values like so:

api:
  enabled: true
  database: true
  deployment:
    labels:
      my-label: "label"
    annotations:
      my-annotation: ...
    replicas: 2
    strategy:
      type: RollingUpdate

  container:
    command:
      - ...
    args:
      - ...
    port: 3000
    ...

Notice that

api.enabled

controls whether the

api

module is included or not and the

api.database

feature flag controls whether that api microservice needs an associated database.

Then everywhere in that module, we can include (or not) the database-specific configs, such as env vars:

env:
{{- if .Values.api.database }}
  - name: DB_NAME
    value: {{ $name }}
  - name: DB_USER
    valueFrom:
      secretKeyRef:
        key: username
        name: {{ $name }}-db-credentials
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        key: password
        name: {{ $name }}-db-credentials
{{- end }}