75a3cd2534
An advantage of this method over the previous one is that any edits to the ConfigMap yaml file will also trigger a rolling update. It also keeps knowledge of what the ConfigMap contains inside its yaml file instead of the Deployment needing to know which variables to hash.
2.2 KiB
Kontemplate tips & tricks
Table of Contents
Update Deployments when ConfigMaps change
Kubernetes does not currently have the ability to perform rolling updates
of Deployments and other resource types when ConfigMap or Secret objects
are updated.
It is possible to make use of annotations and templating functions in Kontemplate to force updates to these resources anyways.
For example:
# A ConfigMap that contains some configuration for your app
---
kind: ConfigMap
metadata:
name: app-config
data:
app.conf: |
name: {{ .appName }}
foo: bar
Now whenever the appName variable changes or we make an edit to the
ConfigMap we would like to update the Deployment making use of it, too. We
can do this by adding a hash of the parsed template to the annotations of the
created Pod objects:
---
kind: Deployment
metadata:
name: app
spec:
template:
metadata:
annotations:
configHash: {{ insertTemplate "app-config.yaml" | sha256sum }}
spec:
containers:
- name: app
# Some details omitted ...
volumeMounts:
- name: config
mountPath: /etc/app/
volumes:
- name: config
configMap:
name: app-config
Now any change to the ConfigMap - either by directly editing the yaml file or
via a changed template variable - will cause the annotation to change,
triggering a rolling update of all relevant pods.
direnv & pass
Users of pass may have multiple different password stores on their machines.
Assuming that kontemplate configuration exists somewhere on the filesystem
per project, it is easy to use direnv to switch to the correct
PASSWORD_STORE_DIR variable when entering the folder.