Helm in der Praxis: Chart-Repositories, Dependencies und CI/CD-Integration

TL;DR: Wer Helm produktiv nutzt, braucht mehr als helm install. Dieser Artikel zeigt, wie man Charts in OCI-Registries hostet, Dependencies sauber verwaltet, mit Helmfile mehrere Releases orchestriert, Secrets verschlüsselt und Charts automatisiert per GitHub Actions publiziert und via ArgoCD deployt.

Dieser Artikel baut auf den Grundlagen aus Helm Charts für Anfänger auf.

Chart-Repositories: Klassisch vs. OCI

Klassische Helm-Repositories

Traditionell sind Helm-Repos HTTP-Server mit einer index.yaml. Das funktioniert, hat aber Nachteile: eigener Webserver nötig, keine standardisierte Authentifizierung, separater Tooling-Stack.

# Klassisches Repo hinzufügen
helm repo add mein-repo https://charts.example.de --username deploy --password ${TOKEN}
helm repo update
helm search repo mein-repo/

OCI-Registries (der moderne Weg)

Seit Helm 3.8+ ist OCI-Support stabil. Charts lassen sich in jede OCI-kompatible Registry pushen -- also in dieselbe Registry, in der auch Container-Images liegen.

# Login bei einer OCI-Registry
helm registry login ghcr.io -u ${GITHUB_USER} -p ${GITHUB_TOKEN}

# Chart als OCI-Artefakt pushen
helm package ./meine-app
helm push meine-app-0.2.0.tgz oci://ghcr.io/meine-org/charts

# Chart direkt aus OCI-Registry installieren
helm install meine-app oci://ghcr.io/meine-org/charts/meine-app --version 0.2.0

Vorteile von OCI-Registries:

Eigenschaft	Klassisches Repo	OCI-Registry
Infrastruktur	Eigener HTTP-Server	Vorhandene Container-Registry
Authentifizierung	Repo-spezifisch	Standard-Docker-Auth
Signierung	Extern (GPG)	Cosign / Notation integriert
Caching	Manuell	Registry-Layer-Caching
Tooling	`helm repo add/update`	`helm push/pull` (kein `repo add` nötig)

Chart Dependencies verwalten

Die meisten Anwendungen brauchen Infrastruktur-Components: eine Datenbank, einen Cache, einen Message Broker. Statt diese separat zu deployen, lassen sie sich als Dependencies ins Chart einbinden.

Dependencies in Chart.yaml definieren

# Chart.yaml
apiVersion: v2
name: meine-app
version: 1.0.0
appVersion: '2.1.0'

dependencies:
  - name: postgresql
    version: '~15.5'           # SemVer-Range: 15.5.x
    repository: https://charts.bitnami.com/bitnami
    condition: postgresql.enabled

  - name: redis
    version: '~19.0'
    repository: https://charts.bitnami.com/bitnami
    condition: redis.enabled

  - name: common
    version: '~2.0'
    repository: oci://ghcr.io/meine-org/charts
    tags:
      - infrastructure

# Dependencies herunterladen
helm dependency update ./meine-app

# Prüfen, was installiert wird
helm dependency list ./meine-app

Dependencies konfigurieren

Die Werte für Sub-Charts stehen unter dem jeweiligen Chart-Namen in values.yaml:

# values.yaml -- Sub-Chart-Werte
postgresql:
  enabled: true
  auth:
    database: meineapp
    existingSecret: meine-app-db-credentials
  primary:
    persistence:
      size: 20Gi

redis:
  enabled: true
  architecture: standalone
  auth:
    existingSecret: meine-app-redis-credentials

Helmfile: Mehrere Releases deklarativ verwalten

Wer mehr als ein Chart in einem Cluster deployt, stösst mit einzelnen helm install-Befehlen schnell an Grenzen. Helmfile löst das Problem.

helmfile.yaml Beispiel

# helmfile.yaml
repositories:
  - name: bitnami
    url: https://charts.bitnami.com/bitnami
  - name: ingress-nginx
    url: https://kubernetes.github.io/ingress-nginx
  - name: prometheus-community
    url: https://prometheus-community.github.io/helm-charts

environments:
  staging:
    values:
      - environments/staging.yaml
  production:
    values:
      - environments/production.yaml

releases:
  - name: ingress
    namespace: ingress-nginx
    chart: ingress-nginx/ingress-nginx
    version: 4.10.0
    values:
      - values/ingress.yaml

  - name: monitoring
    namespace: monitoring
    chart: prometheus-community/kube-prometheus-stack
    version: 62.3.0
    values:
      - values/monitoring.yaml
    needs:
      - ingress-nginx/ingress    # erst Ingress, dann Monitoring

  - name: meine-app
    namespace: app
    chart: oci://ghcr.io/meine-org/charts/meine-app
    version: 1.0.0
    values:
      - values/meine-app.yaml
      - values/meine-app-{{ .Environment.Name }}.yaml
    needs:
      - monitoring/monitoring

# Alle Releases anwenden
helmfile apply

# Nur Diff anzeigen (was würde sich ändern?)
helmfile diff

# Nur ein bestimmtes Release
helmfile -l name=meine-app apply

# Environment-spezifisch
helmfile -e production apply

Secrets verschlüsseln mit helm-secrets

Helm Charts brauchen oft sensible Werte: Datenbank-Passwörter, API-Keys, TLS-Zertifikate. Diese dürfen nicht im Klartext ins Git.

helm-secrets verschlüsselt Werte-Dateien mit SOPS (unterstützt AWS KMS, Azure Key Vault, GCP KMS, age, PGP).

# Plugin installieren
helm plugin install https://github.com/jkroepke/helm-secrets

# SOPS-Konfiguration anlegen
cat > .sops.yaml << 'EOF'
creation_rules:
  - path_regex: .*secrets.*\.yaml$
    age: age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p
EOF

# Secrets-Datei erstellen und verschlüsseln
cat > secrets.yaml << 'EOF'
dbPassword: mein-geheimes-passwort
apiKey: sk-1234567890abcdef
EOF

sops -e -i secrets.yaml

# Verschlüsselte Datei bei helm install verwenden
helm secrets install meine-app ./meine-app \
  -f values.yaml \
  -f secrets://secrets.yaml

Die verschlüsselte Datei kann sicher ins Git eingecheckt werden. Entschlüsselung erfolgt zur Deployment-Zeit.

CI/CD: Chart automatisch bauen und publizieren

GitHub Actions Workflow

Ein Workflow, der bei Änderungen am Chart automatisch versioniert, testet und in eine OCI-Registry pusht:

# .github/workflows/helm-publish.yml
name: Helm Chart Publish

on:
  push:
    branches: [main]
    paths:
      - 'charts/**'

permissions:
  packages: write

jobs:
  lint-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: azure/setup-helm@v4
        with:
          version: v3.16.0

      - name: Lint Chart
        run: helm lint charts/meine-app

      - name: Template testen
        run: helm template test charts/meine-app --debug

  publish:
    needs: lint-and-test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: azure/setup-helm@v4
        with:
          version: v3.16.0

      - name: Registry Login
        run: |
          echo "${{ secrets.GITHUB_TOKEN }}" | \
            helm registry login ghcr.io -u ${{ github.actor }} --password-stdin

      - name: Package und Push
        run: |
          helm dependency update charts/meine-app
          helm package charts/meine-app
          helm push meine-app-*.tgz oci://ghcr.io/${{ github.repository_owner }}/charts

Deployment mit ArgoCD

ArgoCD ist der De-facto-Standard für GitOps auf Kubernetes. Es kann Helm Charts nativ deployen und hält den Cluster-State automatisch synchron mit dem Git-Repository.

ArgoCD Application für ein Helm Chart

# argocd/meine-app.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: meine-app
  namespace: argocd
spec:
  project: default
  source:
    chart: meine-app
    repoURL: ghcr.io/meine-org/charts
    targetRevision: 1.0.0
    helm:
      releaseName: meine-app
      valueFiles:
        - values-production.yaml
      parameters:
        - name: image.tag
          value: 'abc1234'
  destination:
    server: https://kubernetes.default.svc
    namespace: app
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Helm Charts testen

# Statische Analyse
helm lint ./meine-app

# Unit-Tests mit helm-unittest Plugin
helm plugin install https://github.com/helm-unittest/helm-unittest
helm unittest ./meine-app

# Integration-Test: installieren, testen, aufräumen
helm install test-release ./meine-app --namespace test --create-namespace
helm test test-release --namespace test
helm uninstall test-release --namespace test

Security Best Practices

Massnahme	Umsetzung
Charts signieren	`helm package --sign` oder Cosign für OCI
Provenance prüfen	`helm install --verify`
Supply Chain	Nur Charts aus vertrauenswürdigen Quellen
Secrets	Nie im Klartext in `values.yaml` -- immer helm-secrets oder External Secrets Operator
RBAC	Helm-Service-Account mit minimalen Rechten in CI/CD
Audit	Chart-Versionen und Deployments in Git nachvollziehbar halten

Mehr zum Thema Security: Kubernetes Security Hardening

Zusammenfassung

Helm wird in produktiven Umgebungen erst durch das richtige Tooling um ihn herum wirklich effektiv:

OCI-Registries ersetzen klassische Repos und vereinfachen das Hosting
Dependencies halten zusammengehörige Services in einem Chart
Helmfile orchestriert mehrere Charts deklarativ
helm-secrets schützt sensible Werte
GitHub Actions automatisiert das Publizieren
ArgoCD sorgt für GitOps-konforme Deployments

Weiterführende Artikel:

Sie möchten Ihre Helm-Workflows professionalisieren oder eine GitOps-Pipeline mit ArgoCD aufsetzen? Wir unterstützen Sie bei Architektur, Implementierung und Schulung -- Sprechen Sie uns an.

Helm fortgeschritten: OCI-Registry, Helmfile und CI/CD