A workflow is the sequence of steps one takes to use and maintain a configuration.
In this workflow, all configuration files are owned by the user. No content is incorporated from version control repositories owned by others.
git init ~/ldap
2) create a base
mkdir -p ~/ldap/base
In this directory, create and commit a kustomization file and a set of resources.
3) create overlays
mkdir -p ~/ldap/overlays/staging mkdir -p ~/ldap/overlays/production
Each of these directories needs a kustomization file and one or more patches.
The staging directory might get a patch that turns on an experiment flag in a configmap.
The production directory might get a patch that increases the replica count in a deployment specified in the base.
4) bring up variants
Run kustomize, and pipe the output to apply.
kustomize build ~/ldap/overlays/staging | kubectl apply -f - kustomize build ~/ldap/overlays/production | kubectl apply -f -
In this workflow, all files are owned by the user and maintained in a repository under their control, but they are based on an off-the-shelf configuration that is periodically consulted for updates.
2) clone it as your base
The base directory is maintained in a repo whose
upstream is an OTS configuration, in this case
some user's ldap repo:
mkdir ~/ldap git clone https://github.com/$USER/ldap ~/ldap/base cd ~/ldap/base git remote add upstream [email protected]:$USER/ldap
3) create overlays
As in the bespoke case above, create and populate an overlays directory.
The overlays are siblings to each other and to the base they depend on.
mkdir -p ~/ldap/overlays/staging mkdir -p ~/ldap/overlays/production
The user can maintain the overlays directory in a
distinct repository.
4) bring up variants
kustomize build ~/ldap/overlays/staging | kubectl apply -f - kustomize build ~/ldap/overlays/production | kubectl apply -f -
The user can periodically rebase their base to capture changes made in the upstream repository.
cd ~/ldap/base git fetch upstream git rebase upstream/master