Helm am Bibliothek-Chart

Voraussetzung: ein Cluster mit oc login, die helm-CLI im PATH, und das Repo library-enterprise-platform 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.

Helm ist keine magische Deploy-Maschine. Es ist eine Textschablone plus eine Release-Verwaltung für ein Bündel Kubernetes-Manifeste. Kein Server im Cluster, keine laufende Überwachung. Der ganze Ablauf ist: Werte einsetzen → rendern → anwenden → das Ergebnis als Secret merken.

Schablone plus Verlauf, mehr ist Helm nicht. Ein Chart ist ein Ordner aus Chart.yaml, values.yaml und templates/. Die --set- und -f-Werte werden über die Vorgaben gemerged, die Go-Template-Engine rendert daraus fertige YAML (das zeigt helm template, ohne etwas anzufassen), und beim install entsteht ein Release – als Secret im Namespace, das den Verlauf trägt. Helm läuft mit deinem Token, hat keinen Cluster-Agenten und korrigiert Drift erst beim nächsten upgrade – genau da fängt ein Operator an.

Helm ist eine Textschablone plus Release-Verwaltung für ein Bündel Manifeste – kein Server im Cluster, keine laufende Überwachung
ein Chart ist ein Ordner: Chart.yaml (Metadaten, Versionen, Dependencies), values.yaml (die Knöpfe), templates/ (Manifeste mit {{ }}), charts/ (Subcharts)
die Werte haben einen Vorrang, später schlägt früher: values.yaml, dann -f meine-werte.yaml, dann --set key=val – alles zu einem Baum verschmolzen, im Template .Values.x.y
neben .Values gibt es .Release.Name, .Release.Namespace, .Chart.* und .Capabilities.* – darum rendert dasselbe Chart je Release anders
beim Rendern werden Chart und Werte zu fertiger YAML (helm template zeigt sie, ohne etwas zu ändern), danach wird sie intern angewendet
ein Release ist eine benannte, versionierte Installation in einem Namespace, gespeichert als Secret sh.helm.release.v1.<name>.v<n> (base64 und gzip)
Befehle sind helm install, upgrade, rollback, uninstall, list, history – nützliche Flags --dry-run, --atomic, upgrade --install
version ist die Chart-Version, appVersion die Version der App dahinter – zwei verschiedene Dinge
Helm handelt als du (mit deinem kubeconfig-Token) und kann nur, was deine RBAC erlaubt (A5) – seit Helm 3 kein Tiller mehr
Helm ist kein Operator: eine Abweichung am Cluster wird erst beim nächsten helm upgrade korrigiert, ein Rollback rührt keine Daten an (D1)
in OpenShift ist die helm-CLI unverändert – die Web-Konsole hat einen Helm-Katalog, die HelmChartRepository-CR listet Quellen
Bibliothek: ein Werteblock je Dienst (Image-Tag, Replicas, Ressourcen), fullnameOverride für stabile Namen. Jenkins ruft helm upgrade --install je Dienst auf (E1)
Alternativen: Kustomize (oc apply -k, patcht statt zu templaten), Argo CD rendert Charts selbst (E3), oc process für die alten OpenShift-Templates

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.

Eine Schablone, mehrere Wertedateien, ein Ergebnis – und die Stelle, an der ein Tippfehler wortlos verschluckt wird.

Zeichnung aus Diagramme: Hetzner & CRC (26).

Helm läuft auf deinem Rechner, nicht im Cluster. Es setzt Schablonen und Werte zu gewöhnlichem YAML zusammen und schickt nur das Ergebnis – plus eine Kopie davon als Secret, damit es später weiß, was es zuletzt getan hat. Alles, was Helm „kann“, ist Textersetzung und Buchführung.

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 außerhalb 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 gelöschte 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.

B11 war das Modell – hier der Alltag. Immer zuerst helm template lesen. Dann upgrade --install --atomic. helm history und rollback als Sicherheitsnetz. Hooks für DB-Migrationen, Dependencies für Subcharts – und ein paar Stellen, an denen Helm einfach nichts mehr tut.

Der Alltag mit Helm. Immer helm template zuerst, dann upgrade --install --atomic (idempotent, rollt bei Fehler zurück), helm history und rollback als Netz. Hooks (annotierte Jobs) machen DB-Migrationen, Dependencies ziehen Subcharts nach charts/. Wo Helm aufhört: verwaiste Objekte, nie ge-upgradete CRDs, kein Datenschutz beim Rollback, keine Drift-Korrektur – das übernimmt Argo CD (E3).

immer zuerst helm template – die gerenderte YAML lesen, bevor man installiert
Erst-Installation: helm install biblio ./chart -n library -f werte-sno.yaml – ein Chart, eine Werte-Datei je Umgebung
helm diff upgrade (Plugin) zeigt, was sich ändert, bevor es passiert
helm upgrade --install --atomic --timeout 10m – der CI-taugliche Aufruf (idempotent, rollt bei Fehler zurück)
helm history biblio + helm rollback biblio <rev> – ein Rollback wendet die Manifeste der alten Revision neu an, als neue Revision
Hooks: pre-install / post-upgrade als annotierte Jobs (helm.sh/hook, hook-weight, hook-delete-policy) – z. B. DB-Migration vor dem Rollout
Hooks laufen außerhalb der Release-Manifeste – ein Rollback macht sie nicht rückgängig
Dependencies: helm dependency update zieht Subcharts nach charts/, Chart.lock pinnt die Versionen, condition/tags schalten sie an/aus
wo Helm aufhört: verwaiste Objekte nach Template-Löschung, CRDs aus crds/ ohne Upgrade, kein Schutz der Daten-Volumes, keine Drift-Korrektur
Umbrella-Chart (ein Release, alles-oder-nichts) vs Einzelchart je Dienst (8 Releases, unabhängiger Rollback, keine dienstübergreifende Atomarität)
Bibliothek: je Dienst getrennt – die 8 Deploys sind lose gekoppelt (eigene DB, eigenes Tempo), Jenkins ruft upgrade --install je Dienst
der pipeline-SA (A5/A6) begrenzt, was helm upgrade anfassen darf
wo Helm aufhört und ein Operator anfängt (Block D): Betriebslogik, die laufend auf den Cluster-Zustand reagieren muss
nicht vergessen: helm get manifest biblio zeigt, was gerade installiert ist – gegen oc get vergleichen

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