.. | ||
etherpadlite | ||
nginx-certbot | ||
nginx-certbot-helm | ||
README.md |
Apps
This directory contains test applications which are using kustomize or helm for testing. The objective of these apps is to create typical flows for adding apps into clusters.
Use case 1: common anchor
We want to achieve the following:
- have a common anchor to define the name of a service ("service1")
- That anchor steers generation of configuration files in config maps ("nginx config with hostname service1.$namespace.svc.$clusterdomain")
Best case: $clusterdomain can be queried from the cluster.
kustomize
It does not seem kustomize has a logical way to support this, as it does not have variables that can be injected into fields.
One can use the name-prefix or similar for modifying the service name, but that prefix is not automatically injected into the relevant configuration within a configmap.
helm
Helm seems to cope with the anchor case easily using values.yaml as the anchor.
Handling of configmap updates
Assuming one updates a configmap (new configuration), what happens to the old configmap? Is it left alone, is it deleted automatically?
kustomize
Kustomize usually generates the ConfigMaps and appends a hash to its name. Thus the referencing objects (Pods mostly) will also get updated and refer to a new configmap.
Untested, but the assumption is that kustomize will leave the old configmap behind.
helm
Helm does not have a concept of generating confimaps, so in theory it would update the same configmap (depending on how you named it).