The following example is Helmsman, but the same mechanism works for Helmfile also.
Using DRY principles, a single declaration of the application stack is used, and tokens applied for deplopy-time environment variations.
metadata:
scope: "cluster microservices"
maintainer: "Jules Clements"
namespaces:
%name_space%:
protected: false
apps:
pull:
name: "docker-registry-pull-secret"
description: "GitLab Registry Pull Secret"
namespace: "%name_space%"
enabled: true
chart: "pull-secrets-0.0.1.tgz"
version: "0.0.1"
valuesFile: "pods/docker-registry-pull-secret.yaml"
cdaf-ui:
name: "cdaf-ui"
description: "CDAF Published Site (Django)"
namespace: "%name_space%"
enabled: true
chart: "public-ingress-0.1.4.tgz"
version: "0.1.4"
valuesFile: "pods/cdaf-ui.yaml"
set:
dockerconfigjson: "$DOCKER_CONFIG_JSON"
The build-time process uses the declaration to determine the Helm charts that are required at deploy time. These are downloaded and included in the package, this has the advantage of not having to manage registry access at deploy time and ensures the charts are immutable within the release package.
helm repo add $repo_name https://kool-aid.gitlab.io/helm
IFS=$'\\n'
for chart in $(cat .cdaf/customRemote/${SOLUTION}.yaml | grep chart: | sort | uniq); do eval "${SOLUTIONROOT}/pull.sh $repo_name $chart"; done
There is no “compiled” output for the source files described above, so the self-contained release package capability of Continuous Delivery Automation Framework (CDAF) is used to produce a portable, re-usable deployment artefact, i.e. build once, deploy many.
The deployment uses an Environment argument is a symbolic link to the settings that need to be detokenised at deploy time, e.g.
./release.ps1 QA