From 8110edc659bf81bf52f51d222ab114fae4499901 Mon Sep 17 00:00:00 2001 From: Nico Schottelius Date: Sun, 20 Jun 2021 09:19:48 +0200 Subject: [PATCH] ++readme for apps --- apps/README.md | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 apps/README.md diff --git a/apps/README.md b/apps/README.md new file mode 100644 index 0000000..06138d1 --- /dev/null +++ b/apps/README.md @@ -0,0 +1,50 @@ +## 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).