Helm am Bibliothek-Chart

Voraussetzung: ein Cluster mit oc login, die helm-CLI im PATH, und das Repo LAB-WIP-MAVEN-Bibliothek-Enterprise ausgecheckt (der Chart liegt unter infra/helm/). Namespace library muss existieren: oc new-project library oder oc project library. Optional das Plugin helm-diff (helm plugin install https://github.com/databus23/helm-diff).

1 Der Chart: ein Ordner

Ein Chart ist kein laufendes Ding – nur ein Ordner mit einer festen Struktur.

Laptop · Bash

infra/helm/
├─ library-service/          <- der generische Chart (ein Chart fuer alle 8 Dienste)
│  ├─ Chart.yaml            name, version (Chart-Version), appVersion (App-Version)
│  ├─ values.yaml           die Vorgaben - alle Knoepfe mit Default
│  └─ templates/
│     ├─ deployment.yaml    Manifest mit {{ .Values.image.repository }} usw.
│     ├─ service.yaml
│     └─ _helpers.tpl       wiederverwendbare Schnipsel (Labels, Namen)
└─ values/
   ├─ catalog-service-values.yaml   die Knopf-Stellungen fuer EINEN Dienst
   ├─ loan-service-values.yaml
   └─ env/okd-values.yaml           das Overlay fuer die SNO (DB-Hosts, Ressourcen)

Die Bibliothek nimmt einen Chart (library-service) und füllt ihn pro Dienst mit einer eigenen Werte-Datei. Ergebnis: acht getrennte Releases im Namespace library, jedes unabhängig upgrade- und rollback-bar.

Datei	ist	ändert sich
`Chart.yaml` → `version`	Version des Charts (der Schablone)	wenn du die Templates änderst
`Chart.yaml` → `appVersion`	Version der App dahinter	bei jedem App-Release – nur Info, wird nicht erzwungen
`values.yaml`	die Vorgaben, tiefste Prio	selten – hier stehen sinnvolle Defaults
`values/<dienst>-values.yaml`	die Knopf-Stellungen je Dienst	oft – Image-Tag, Replicas, Ressourcen

2 `helm template` – erst lesen

Nie blind installieren. helm template rendert lokal, fässt nichts an, und zeigt dir genau die YAML, die gleich in den Cluster geht.

Laptop · Bash

helm template catalog-service ./infra/helm/library-service \
  -n library \
  -f infra/helm/values/catalog-service-values.yaml \
  -f infra/helm/values/env/okd-values.yaml

Lies das Ergebnis von oben nach unten und finde die drei Sorten Ersetzung:

aus Valuesimage: {{ .Values.image.repository }}:{{ .Values.image.tag }} → wird zur echten Image-Zeile mit dem Tag aus der Werte-Datei

aus .Releasename: {{ .Release.Name }} und die Labels → darum rendert dasselbe Chart je Release anders

Logik{{- if .Values.autoscaling.enabled }} lässt einen HPA-Block ganz weg, {{- range .Values.env }} baut eine env-Liste

Reihenfolge der Werte, später schlägt früher: values.yaml im Chart → erstes -f → zweites -f → --set key=val auf der Kommandozeile. Alles zu einem Baum verschmolzen, im Template als .Values.x.y.

Wenn das Rendern schon scheitert (nil pointer, function "foo" not defined), ist es ein Template-Fehler – noch nichts im Cluster passiert. helm template --debug zeigt mehr.

3 `helm install` – was entsteht

Laptop · Bash

helm install catalog-service ./infra/helm/library-service \
  -n library \
  -f infra/helm/values/catalog-service-values.yaml \
  -f infra/helm/values/env/okd-values.yaml

Helm nimmt die gerenderte YAML von Schritt 2 und wendet sie an – als du, mit deinem kubeconfig-Token, begrenzt durch deine RBAC. Danach:

Befehl	zeigt
`helm list -n library`	das Release `catalog-service`, Revision 1, Status `deployed`
`oc get all -n library -l app.kubernetes.io/instance=catalog-service`	das `Deployment`, das `ReplicaSet`, die `Pods`, den `Service` – ganz normale Objekte, kein „Helm“ dran
`oc get secret -n library -l owner=helm`	ein Secret `sh.helm.release.v1.catalog-service.v1` – das ist das Release

Der Punkt: nach install ist kein Helm mehr im Spiel. Die Objekte gehören dem Cluster. Helm merkt sich nur im Secret, was es angelegt hat.

4 Das Release ansehen

Das Release-Secret ist base64 und gzip – nicht direkt lesbar. Dafür gibt es die helm get-Befehle.

Befehl	Antwort
`helm get values catalog-service -n library`	die zusammengeführten Werte, die dieses Release benutzt hat (mit `-a` auch die Defaults)
`helm get manifest catalog-service -n library`	die fertige YAML, die gerade installiert ist – gegen `oc get deploy/catalog-service -o yaml` vergleichen
`helm history catalog-service -n library`	der Verlauf: Revision, Datum, Status, welche Chart-/App-Version
`helm get notes catalog-service -n library`	die `NOTES.txt` des Charts (die Hinweise nach dem Install)

Web-Konsole: Developer-Perspektive → Helm → Releases → catalog-service – dieselben Daten (Values, Resources, Revision history) zum Klicken.

5 Einen Wert ändern

Ändere in catalog-service-values.yaml etwas Harmloses – replicaCount: 1 → 2.

Laptop · Bash

# erst sehen, was sich aendert (Plugin helm-diff):
helm diff upgrade catalog-service ./infra/helm/library-service \
  -n library -f infra/helm/values/catalog-service-values.yaml \
  -f infra/helm/values/env/okd-values.yaml

# dann anwenden - der CI-taugliche Aufruf:
helm upgrade --install catalog-service ./infra/helm/library-service \
  -n library -f infra/helm/values/catalog-service-values.yaml \
  -f infra/helm/values/env/okd-values.yaml \
  --atomic --timeout 5m

Flag	macht
`--install`	installiert, falls das Release noch nicht existiert – ein Befehl für beide Fälle, idempotent
`--atomic`	schlägt das Upgrade fehl, wird automatisch auf die vorige Revision zurückgerollt – kein halber Zustand
`--timeout 5m`	wie lange Helm auf `Ready` wartet, bevor es `--atomic` auslöst
`--wait`	(bei `--atomic` automatisch) wartet, bis die Pods wirklich laufen – sonst meldet Helm „fertig“, während der Pod noch startet

Danach: helm history catalog-service -n library zeigt Revision 2. helm get manifest zeigt jetzt replicas: 2.

6 Ein kaputtes Upgrade

Setz absichtlich einen falschen Image-Tag: image.tag: gibtsnicht.

Laptop · Bash

helm upgrade --install catalog-service ./infra/helm/library-service \
  -n library -f infra/helm/values/catalog-service-values.yaml \
  -f infra/helm/values/env/okd-values.yaml \
  --set image.tag=gibtsnicht --atomic --timeout 2m

Der neue Pod bleibt in ImagePullBackOff. Nach 2 Minuten schlägt --atomic zu: Helm rollt auf Revision 2 zurück, der Pod läuft wieder. helm history zeigt Revision 3 mit Status failed, Revision 4 als der Rollback (Status deployed).

Von Hand: helm rollback catalog-service 2 -n library – wendet die Manifeste der Revision 2 neu an, als neue Revision.

Was ein Rollback nicht tut: Daten in einem PVC anfassen. Hooks (annotierte Jobs, z. B. eine DB-Migration pre-upgrade) laufen ausserhalb der Release-Manifeste – ein Rollback macht sie nicht rückgängig. Eine Migration, die eine Spalte löscht, ist nach dem Rollback immer noch gelöscht.

7 Drift – wo Helm aufhört

Der wichtigste Unterschied zu einem Operator. Skalier von Hand:

Laptop · Bash

oc scale deploy/catalog-service -n library --replicas=5
helm get manifest catalog-service -n library | grep replicas    # sagt weiter: 2
helm list -n library                                            # Status: deployed - Helm merkt nichts

Helm hat keinen Agenten im Cluster. Es sieht deine Handarbeit nicht. Erst beim nächsten helm upgrade vergleicht es (3-Wege-Merge: alte Manifeste, neue Manifeste, Live-Zustand) und setzt replicas zurück auf 2 – wenn das Feld im Template steht. Felder, die das Template nicht setzt, lässt Helm in Ruhe.

Helmkorrigiert Drift nur beim nächsten upgrade, das du selbst auslöst

Argo CDvergleicht laufend Git gegen Cluster und kann automatisch zurücksetzen (selfHeal) – das ist Atlas-Block E3

Operatorreagiert auf jede Änderung sofort, weil Betriebslogik dahinter steckt (Failover, Backup) – Atlas-Block D

8 `helm uninstall` – was bleibt

Laptop · Bash

helm uninstall catalog-service -n library
oc get all,pvc,secret -n library -l app.kubernetes.io/instance=catalog-service

weg	bleibt
Deployment, ReplicaSet, Pods, Service – alles aus `templates/`	PVCs, wenn sie ein `StatefulSet`-`volumeClaimTemplate` waren oder eine `helm.sh/resource-policy: keep`-Annotation haben
das Release-Secret `sh.helm.release.v1.catalog-service.*`	Objekte, die ein Hook angelegt hat (die gehören nicht zum Release)
–	CRDs aus `crds/` – die fasst Helm bei `uninstall` und `upgrade` nie an

helm uninstall --keep-history lässt die Release-Secrets stehen – dann kann man das geloeschte Release noch mit helm rollback wiederbeleben.

9 Wie Jenkins es aufruft

Genau derselbe Befehl – nur für alle acht Dienste, mit dem pipeline-ServiceAccount statt deinem Token.

Jenkinsfile · Prod-Stage (sinngemäss)

for svc in catalog loan member fine notification reservation gateway config; do
  helm upgrade --install $svc ./infra/helm/library-service \
    -n library \
    -f infra/helm/values/${svc}-service-values.yaml \
    -f infra/helm/values/env/okd-values.yaml \
    --set image.repository=$OKD_INTERNAL_REGISTRY/$svc \
    --set image.tag=$GIT_SHA \
    --atomic --timeout 3m
done

Entscheidung im Projekt	warum
ein Release je Dienst, kein Umbrella-Chart	die 8 Dienste sind lose gekoppelt (eigene DB, eigenes Tempo) – ein kaputter Dienst blockiert die anderen sieben nicht. Preis: keine dienstübergreifende Atomarität
der Image-Tag kommt per `--set image.tag=$GIT_SHA`	der auslösende Wert ändert sich je Build, nicht in einer Datei – die Werte-Datei bleibt stabil
der `pipeline`-SA (Atlas A5/A6) begrenzt, was `helm upgrade` darf	Helm handelt als der SA – er hat `admin` in `library`, sonst nichts
der nächste Schritt wäre Argo CD (Atlas E3)	dann rendert Argo den Chart selbst aus Git und hält den Zustand laufend nach – kein `helm upgrade`-Aufruf mehr

+ Die Kurzfassung

1Chart = Ordner (Chart.yaml, values.yaml, templates/). Läuft nirgends.

2helm template rendert lokal – immer zuerst lesen.

3helm upgrade --install --atomic wendet an, rollt bei Fehler zurück.

4Das Release ist ein Secret im Namespace. helm get manifest / values / history.

5Helm korrigiert Drift nur beim nächsten Upgrade, rührt keine Daten an, lässt CRDs und Hook-Objekte liegen. Ab hier: Argo CD (E3) oder ein Operator (D).

1 Der Chart: ein Ordner

2 helm template – erst lesen

3 helm install – was entsteht

4 Das Release ansehen

5 Einen Wert ändern

6 Ein kaputtes Upgrade

7 Drift – wo Helm aufhört

8 helm uninstall – was bleibt

9 Wie Jenkins es aufruft

+ Die Kurzfassung

2 `helm template` – erst lesen

3 `helm install` – was entsteht

8 `helm uninstall` – was bleibt