Microtemplates with Helm
Context and problem
The ability to configure containers with external definitions is a key part of 12 factor apps. As organisations adopt containers these external definitions tend to travel as shell scripts included in the code repository. These shell scripts become unwieldy quickly and have to be rewritten when an organisation moves to an orchestration platform.
Solution
Adopt a template engine early in the modernization cycle can help mitigate the problem of shell scripts and prepare an organisation for the move towards kubernetes.
Issues and considerations
Helm as a dependancy may require additional training for the organisation.
When to use this scenario
Helm is useful from Replatform point of the journey onwards. This microtemplating option is targeting the developer loop and is especially useful at the start of the Replatform roadmap.
Example
apiVersion: v2
name: top-helm-app
type: application
version: 0.1.0
appVersion: "1.16.0"
- Create folder called
templates
and create file calledpod.yaml
with the following content
apiVersion: v1
kind: Pod
metadata:
labels:
app: top-helm-pod
name: top-helm-top-pod
spec:
restartPolicy: Never
containers:
- command:
- top
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
name: top-helm-container
resources: {}
- Create a file called
values.yaml
with the following content
image:
repository: docker.io/library/alpine
tag: "3.15.4"
-
Validate the pod template is generated correctly by running
helm template .
helm template . --- # Source: top-helm-app/templates/pod.yaml apiVersion: v1 kind: Pod metadata: name: top-helm-pod spec: containers: command: - top name: top-helm-container image: "docker.io/library/alpine:3.15.4"
Next steps
-
Run the file with podman
helm template . | podman play kube -
-
Delete the pod
podman pod stop top-helm-top-pod podman pod rm top-helm-top-pod