absorb hello world configs

demos/data/helloWorld/configMap.yaml

@@ -0,0 +1,7 @@
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: the-map
+data:
+  altGreeting: "Good Morning!"
+  enableRisky: "false"

demos/data/helloWorld/deployment.yaml

@@ -0,0 +1,30 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: the-deployment
+spec:
+  replicas: 3
+  template:
+    metadata:
+      labels:
+        deployment: hello
+    spec:
+      containers:
+      - name: the-container
+        image: monopole/hello:1
+        command: ["/hello",
+                  "--port=8080",
+                  "--enableRiskyFeature=$(ENABLE_RISKY)"]
+        ports:
+        - containerPort: 8080
+        env:
+        - name: ALT_GREETING
+          valueFrom:
+            configMapKeyRef:
+              name: the-map
+              key: altGreeting
+        - name: ENABLE_RISKY
+          valueFrom:
+            configMapKeyRef:
+              name: the-map
+              key: enableRisky

demos/data/helloWorld/kustomization.yaml

@@ -0,0 +1,9 @@
+# Example configuration for the webserver
+# at https://github.com/monopole/hello
+commonLabels:
+  app: hello
+
+resources:
+- deployment.yaml
+- configMap.yaml
+- service.yaml

demos/data/helloWorld/service.yaml

@@ -0,0 +1,12 @@
+kind: Service
+apiVersion: v1
+metadata:
+  name: the-service
+spec:
+  selector:
+    deployment: hello
+  type: LoadBalancer
+  ports:
+  - protocol: TCP
+    port: 8666
+    targetPort: 8080

demos/helloWorld.md

@@ -1,5 +1,6 @@
 [base]: ../docs/glossary.md#base
 [config]: https://github.com/kinflate/example-hello
+[gitops]: ../docs/glossary.md#gitops
 [hello]: https://github.com/monopole/hello
 [instance]: ../docs/glossary.md#instance
 [instances]: ../docs/glossary.md#instance
@@ -34,23 +35,33 @@ Alternatively, use
 ## Clone an example
 
 Let's run the [hello] service.
-Here's an existing [config] for it.
 
-Clone this config to a directory called `base`:
+We'll first need a [base] configuration for it -
+the resource files we'll build on with overlays.
 
-<!-- @cloneIt @test -->
+To keep this document shorter, we'll copy them in
+(rather than declare them as HERE documents):
+
+<!-- @downloadBase @test -->
 ```
-git clone \
+BASE=$DEMO_HOME/base
-    https://github.com/kinflate/example-hello \
+mkdir -p $BASE
-    $DEMO_HOME/base
+
+exRepo=https://raw.githubusercontent.com/kubernetes/kubectl
+exDir=master/cmd/kustomize/demos/data/helloWorld
+
+curl -s "$exRepo/$exDir/{configMap,deployment,kustomization,service}.yaml" \
+    -o "$BASE/#1.yaml"
 ```
 
+Look at the directory:
+
 <!-- @runTree @test -->
 ```
 tree $DEMO_HOME
 ```
 
-Expecting something like:
+Expect something like:
 
 > ```
 > /tmp/tmp.IyYQQlHaJP
@@ -80,7 +91,6 @@ The `base` directory has a [kustomization] file:
 
 <!-- @showKustomization @test -->
 ```
-BASE=$DEMO_HOME/base
 more $BASE/kustomization.yaml
 ```
 

docs/glossary.md

@@ -73,6 +73,18 @@ A base has no knowledge of the overlays that refer to it.
 A base is usable in isolation, i.e. one should
 be able to [apply] a base to a cluster directly.
 
+For simple [gitops] management, a base configuration
+could be the _sole content of a git repository
+dedicated to that purpose_.  Same with [overlays].
+Changes in a repo could generate a build, test and
+deploy cycle.
+
+Some of the demos for [kustomize] will break from this
+idiom and store all demo config files in directories
+_next_ to the `kustomize` code so that the code and
+demos can be more easily maintained by the same group
+of people.
+
 ## bespoke configuration
 
 A _bespoke_ configuration is a [kustomization] and some
@@ -104,6 +116,12 @@ of k8s clusters.
    specific languages, etc., frustrating the other
    goals.
 
+## gitops
+
+Devops or CICD workflows that use a git repository as a
+single source of truth and take action (e.g., build,
+test or deploy) when that truth changes.
+
 ## instance
 
 An _instance_ is the outcome, in a cluster, of applying