ohMyHelm & 15-Factor Apps¶

Überblick¶

ohMyHelm ist das Anwendungs-Paketierungswerkzeug der ayedo Software Delivery Platform, das Entwicklern und Architekten einen standardisierten, best-practice-basierten Weg bietet, ihre Anwendungen für cloud-native Umgebungen zu paketieren – konform mit den 15-Factor-App-Prinzipien und nahtlos integriert in das souveräne Ökosystem von ayedo.

Während Polycrate die infrastrukturelle und Plattform-seitige Portabilität sicherstellt (Kubernetes-Cluster, Netzwerk, Storage, Monitoring), fokussiert sich ohMyHelm auf die User-/Developer-Seite: standardisierte, portable Anwendungs-Deployments ohne proprietäre Abhängigkeiten.

graph TB
    subgraph "Developer Experience"
        App[Anwendungs-Code]
        OMH[ohMyHelm]
        App --> OMH
    end

    subgraph "Platform (Polycrate)"
        K8s[Kubernetes Cluster]
        Storage[Storage - Longhorn]
        Network[Networking - Cilium]
        Monitor[Monitoring - VictoriaMetrics]
        Ingress[Ingress - NGINX]

        K8s --> Storage
        K8s --> Network
        K8s --> Monitor
        K8s --> Ingress
    end

    OMH --> K8s

    subgraph "Compliance & Sovereignty"
        Factor15[15-Factor Principles]
        CSF[Cloud Sovereignty Framework]
        DataAct[Data Act Compliance]
    end

    OMH -.implements.-> Factor15
    K8s -.enables.-> CSF
    OMH -.ensures.-> DataAct
    K8s -.enforces.-> DataAct

    style OMH fill:#3498db,color:#fff
    style K8s fill:#326ce5,color:#fff
    style Factor15 fill:#27ae60,color:#fff
    style CSF fill:#e67e22,color:#fff
    style DataAct fill:#9b59b6,color:#fff

Die 15-Factor App¶

Die 15-Factor App erweitert die klassischen 12-Factor-Prinzipien von Heroku um drei moderne Cloud-Native-Anforderungen:

Faktoren 1-12 (Klassisch):

Codebase - Eine Codebase, viele Deployments
Dependencies - Explizit deklarieren und isolieren
Config - Konfiguration in der Umgebung
Backing Services - Als angehängte Ressourcen behandeln
Build, Release, Run - Strikte Trennung der Stages
Processes - Stateless Execution
Port Binding - Services via Port exportieren
Concurrency - Horizontal skalieren via Process Model
Disposability - Fast startup & graceful shutdown
Dev/Prod Parity - Umgebungen so ähnlich wie möglich
Logs - Als Event Streams behandeln
Admin Processes - Als One-Off Processes

Faktoren 13-15 (Moderne Erweiterungen):

API First - APIs vor Implementierung designen (OpenAPI/Swagger)
Telemetry - Observability durch Metriken, Traces, Events
Authentication & Authorization - Security in jedem Layer (OAuth2, OIDC, RBAC)

Wie ohMyHelm die 15 Faktoren unterstützt¶

Faktor 1: Codebase - Eine Codebase, viele Deployments¶

ohMyHelm-Ansatz: Ein Chart, mehrere Environments

# Chart.yaml - Einmal definiert
dependencies:
  - name: ohmyhelm
    alias: myapp
    repository: https://gitlab.com/ayedocloudsolutions/ohmyhelm
    version: 1.13.0

# Mehrere Deployments aus derselben Codebase
helm install myapp-dev . -f values-development.yaml
helm install myapp-staging . -f values-staging.yaml
helm install myapp-prod . -f values-production.yaml

✅ Ein Chart-Template für alle Environments

✅ Environment-spezifische Konfiguration via values.yaml

✅ Keine Duplikation von Deployment-Code

Faktor 2: Dependencies - Explizit deklarieren und isolieren¶

ohMyHelm-Ansatz: Helm Dependencies + Container Images

# Chart.yaml - Dependencies explizit deklariert
dependencies:
  - name: ohmyhelm
    alias: app
    version: 1.13.0  # Feste Version
  - name: postgresql
    repository: https://charts.bitnami.com/bitnami
    version: 12.5.6  # Feste Version

# values.yaml - Container-Image mit Digest
app:
  chart:
    container:
      image: registry.example.com/myapp@sha256:abc123...
      # Niemals :latest in Production!

✅ Helm-Dependencies mit Semantic Versioning

✅ Container-Images mit SHA256-Digests

✅ Keine Abhängigkeit von System-Paketen

Faktor 3: Config - Konfiguration in der Umgebung¶

ohMyHelm-Ansatz: Environment Variables + ConfigMaps + Secrets

# values.yaml
app:
  chart:
    container:
      # Umgebungsvariablen direkt
      env:
        - name: DATABASE_URL
          value: "postgres://db.example.com:5432/mydb"
        - name: LOG_LEVEL
          value: "info"

        # Secrets via valueFrom
        - name: DATABASE_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: password

        # ConfigMaps via envFrom
      envFrom:
        - configMapRef:
            name: app-config

# Secrets mit Auto-Generierung
secrets:
  - name: db-credentials
    namespace: production
    values:
      username: "app_user"
      password: ""  # Auto-generiert bei leerem Wert

✅ 12-Factor-konforme Environment Variables

✅ Secrets getrennt von Code

✅ ConfigMaps für nicht-sensitive Konfiguration

✅ Auto-Generierung von Secrets

Faktor 4: Backing Services - Als angehängte Ressourcen¶

ohMyHelm-Ansatz: Service-Referenzen via Environment Variables

# values.yaml
app:
  chart:
    container:
      env:
        # Backing Services als URLs
        - name: DATABASE_URL
          value: "postgres://postgres.database.svc.cluster.local:5432/mydb"
        - name: REDIS_URL
          value: "redis://redis.cache.svc.cluster.local:6379"
        - name: KAFKA_BROKERS
          value: "kafka.messaging.svc.cluster.local:9092"
        - name: S3_ENDPOINT
          value: "https://s3.example.com"

Wechsel eines Backing Service = Config-Änderung, kein Code-Change:

# Lokales Development
DATABASE_URL: "postgres://localhost:5432/dev"

# Staging
DATABASE_URL: "postgres://postgres-staging.db.svc:5432/staging"

# Production
DATABASE_URL: "postgres://postgres-prod.db.svc:5432/production"

✅ Backing Services als austauschbare Ressourcen

✅ Keine Hard-Coded Service-URLs

✅ Kubernetes Service Discovery via DNS

Faktor 5: Build, Release, Run - Strikte Trennung¶

ohMyHelm-Ansatz: CI/CD-Integration mit klaren Stages

# .gitlab-ci.yml
stages:
  - build    # Stage 1: Build
  - release  # Stage 2: Release
  - deploy   # Stage 3: Run

# Stage 1: BUILD - Container-Image erstellen
build:
  stage: build
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

# Stage 2: RELEASE - Helm Chart mit Image-Tag + Config
release:
  stage: release
  script:
    - helm package . --app-version $CI_COMMIT_SHA
    - helm push myapp-$CI_COMMIT_SHA.tgz oci://registry.example.com/helm

# Stage 3: RUN - Deployment mit Helm
deploy:
  stage: deploy
  script:
    - helm upgrade --install myapp oci://registry.example.com/helm/myapp \
        --version $CI_COMMIT_SHA \
        -f values-production.yaml

✅ Build produziert immutable Artefakte (Container-Image)

✅ Release kombiniert Build-Artefakt + Config (Helm Chart)

✅ Run deployed immutable Release in Kubernetes

Faktor 6: Processes - Stateless Execution¶

ohMyHelm-Ansatz: Kubernetes Deployment (default = stateless)

# values.yaml - Stateless App
app:
  chart:
    enabled: true
    # Deployment (nicht StatefulSet) = stateless
    statefulset: false  # Default

    # Horizontal Scaling möglich
    replicaCount: 3

    # Session-State in Redis/Memcached, nicht im Prozess
    container:
      env:
        - name: SESSION_STORE
          value: "redis"
        - name: SESSION_URL
          value: "redis://redis.cache.svc:6379"

Für Stateful Apps (Datenbanken, etc.):

app:
  chart:
    statefulset: true  # Explizit aktivieren
    statefulsetVolume:
      volumeClaimTemplates:
        - metadata:
            name: data
          spec:
            accessModes: ["ReadWriteOnce"]
            resources:
              requests:
                storage: 10Gi

✅ Default: Stateless Deployments

✅ StatefulSets nur wenn explizit benötigt

✅ Session-State in Backing Services

Faktor 7: Port Binding - Services via Port exportieren¶

ohMyHelm-Ansatz: Container Port + Kubernetes Service

# values.yaml
app:
  chart:
    container:
      # App bindet an Port (self-contained)
      ports:
        - name: http
          containerPort: 8080  # App hört auf :8080
          protocol: TCP

    # Kubernetes Service exponiert Port
    service:
      type: ClusterIP
      ports:
        - port: 80          # Externer Port
          targetPort: http  # -> containerPort 8080
          protocol: TCP

✅ App ist self-contained (kein externer Webserver nötig)

✅ Kubernetes Service als Abstraktion

✅ Port-Mapping flexibel konfigurierbar

Faktor 8: Concurrency - Horizontal skalieren via Process Model¶

ohMyHelm-Ansatz: Replica Count + Horizontal Pod Autoscaler

# values.yaml
app:
  chart:
    # Manuelle Skalierung
    replicaCount: 3

    # Automatische Skalierung
    autoscaling:
      enabled: true
      minReplicas: 2
      maxReplicas: 10
      targetCPUUtilizationPercentage: 70
      targetMemoryUtilizationPercentage: 80

Unterschiedliche Workload-Typen als separate Deployments:

# Chart.yaml - Mehrere Prozess-Typen
dependencies:
  - name: ohmyhelm
    alias: web      # Web-Server
  - name: ohmyhelm
    alias: worker   # Background Worker
  - name: ohmyhelm
    alias: cron     # Scheduled Jobs

✅ Horizontale Skalierung via Replicas

✅ Automatische Skalierung via HPA

✅ Unterschiedliche Workload-Typen getrennt

Faktor 9: Disposability - Fast startup & graceful shutdown¶

ohMyHelm-Ansatz: Liveness/Readiness Probes + Lifecycle Hooks

# values.yaml
app:
  chart:
    container:
      # Schneller Startup durch Readiness Probe
      readinessProbe:
        httpGet:
          path: /health/ready
          port: http
        initialDelaySeconds: 5
        periodSeconds: 5

      # Robustheit durch Liveness Probe
      livenessProbe:
        httpGet:
          path: /health/alive
          port: http
        initialDelaySeconds: 15
        periodSeconds: 10

      # Graceful Shutdown
      lifecycle:
        preStop:
          exec:
            command: ["/bin/sh", "-c", "sleep 15"]

    # Termination Grace Period
    terminationGracePeriodSeconds: 30

✅ Schnelle Startzeiten (Sekunden, nicht Minuten)

✅ Graceful Shutdown bei SIGTERM

✅ Health Checks für Robustheit

Faktor 10: Dev/Prod Parity - Umgebungen so ähnlich wie möglich¶

ohMyHelm-Ansatz: Environment-spezifische Values-Files

# values-common.yaml - Gemeinsame Konfiguration
app:
  chart:
    enabled: true
    fullnameOverride: myapp

    container:
      image: registry.example.com/myapp
      ports:
        - name: http
          containerPort: 8080

# values-development.yaml - Dev-Overrides
app:
  chart:
    container:
      image: registry.example.com/myapp:dev-latest
    replicaCount: 1
    resources:
      requests:
        cpu: 100m
        memory: 128Mi

# values-production.yaml - Prod-Overrides (minimale Unterschiede!)
app:
  chart:
    container:
      image: registry.example.com/myapp:v1.2.3  # Feste Version
    replicaCount: 3
    autoscaling:
      enabled: true
    resources:
      requests:
        cpu: 500m
        memory: 512Mi

Deployment:

# Dev
helm install myapp . -f values-common.yaml -f values-development.yaml

# Prod (fast identisch!)
helm install myapp . -f values-common.yaml -f values-production.yaml

✅ Minimale Unterschiede zwischen Environments

✅ Diesel Stack (Kubernetes, Ingress, Storage)

✅ Schnelles Deployment (Dev → Prod in Minuten)

Faktor 11: Logs - Als Event Streams behandeln¶

ohMyHelm-Ansatz: stdout/stderr → Aggregation durch Plattform

# values.yaml - App schreibt nach stdout/stderr
app:
  chart:
    container:
      # Keine Log-Files, nur stdout/stderr!
      env:
        - name: LOG_FORMAT
          value: "json"  # Strukturierte Logs
        - name: LOG_OUTPUT
          value: "stdout"

Log-Aggregation durch Plattform: - Logs werden von Kubernetes automatisch gesammelt - VictoriaLogs / Loki sammelt Logs cluster-weit - Grafana für Log-Visualisierung - Keine App-seitige Log-Rotation nötig

✅ App schreibt nur stdout/stderr

✅ Kubernetes sammelt Logs automatisch

✅ Zentrale Aggregation durch Plattform

✅ Strukturierte Logs (JSON) für besseres Parsing

Faktor 12: Admin Processes - Als One-Off Processes¶

ohMyHelm-Ansatz: Kubernetes Jobs + Init-Container

# values.yaml - Database Migration als Job
app:
  jobs:
    - name: db-migrate
      setPreInstallHook: true  # Vor App-Start ausführen
      restartPolicy: OnFailure
      container:
        image: registry.example.com/myapp:v1.2.3
        command: ["python"]
        args: ["manage.py", "migrate"]
        env:
          - name: DATABASE_URL
            value: "postgres://db.prod.svc:5432/myapp"

# Init-Container für Setup-Tasks
app:
  chart:
    initContainers:
      - name: wait-for-db
        image: busybox:latest
        command: ['sh', '-c', 'until nc -z postgres.db.svc 5432; do sleep 1; done']

Standalone Job für einmalige Tasks:

# REPL-Session als Job
kubectl run -it --rm debug \
  --image=registry.example.com/myapp:v1.2.3 \
  --restart=Never \
  -- python manage.py shell

✅ Admin-Tasks als Kubernetes Jobs

✅ Dieselbe Codebase + Config wie App

✅ Init-Container für Setup-Tasks

Faktor 13: API First - APIs vor Implementierung designen¶

ohMyHelm-Ansatz: OpenAPI/Swagger Integration

# values.yaml - Swagger UI als Sidecar
app:
  chart:
    sidecarContainers:
      - name: swagger-ui
        image: swaggerapi/swagger-ui:latest
        ports:
          - name: swagger
            containerPort: 8080
        env:
          - name: SWAGGER_JSON
            value: "/openapi/openapi.yaml"

    # OpenAPI Spec als ConfigMap
    deploymentVolume:
      volumeMounts:
        - name: openapi-spec
          mountPath: /openapi
      volumes:
        - name: openapi-spec
          configMap:
            name: api-spec

# ConfigMap mit OpenAPI Spec
configs:
  - name: api-spec
    namespace: production
    values:
      openapi.yaml: |
        openapi: 3.0.0
        info:
          title: My API
          version: 1.0.0
        paths:
          /users:
            get:
              summary: List users
              responses:
                '200':
                  description: Success

✅ OpenAPI/Swagger als Teil des Deployments

✅ API-Dokumentation neben der App

✅ Contract-First Development möglich

Faktor 14: Telemetry - Observability durch Metriken, Traces, Events¶

ohMyHelm-Ansatz: ServiceMonitor + Distributed Tracing

# values.yaml - Prometheus Metrics
app:
  chart:
    container:
      ports:
        - name: http
          containerPort: 8080
        - name: metrics
          containerPort: 9090  # Prometheus /metrics endpoint

# Automatisches Scraping via ServiceMonitor
serviceMonitor:
  - name: myapp-metrics
    namespace: production
    selector:
      matchLabels:
        app: myapp
    endpoints:
      - port: metrics
        interval: 30s
        path: /metrics

Distributed Tracing (OpenTelemetry):

app:
  chart:
    container:
      env:
        # OpenTelemetry Integration
        - name: OTEL_EXPORTER_OTLP_ENDPOINT
          value: "http://tempo.observability.svc:4317"
        - name: OTEL_SERVICE_NAME
          value: "myapp"
        - name: OTEL_TRACES_SAMPLER
          value: "always_on"

✅ Prometheus ServiceMonitor für Metriken

✅ OpenTelemetry für Distributed Tracing

✅ Strukturierte Events (JSON Logs)

✅ Integration mit VictoriaMetrics + Grafana

Faktor 15: Authentication & Authorization - Security in jedem Layer¶

ohMyHelm-Ansatz: OAuth2-Proxy + RBAC + TLS

# values.yaml - OAuth2-Proxy als Sidecar
app:
  chart:
    sidecarContainers:
      - name: oauth2-proxy
        image: quay.io/oauth2-proxy/oauth2-proxy:latest
        ports:
          - name: proxy
            containerPort: 4180
        env:
          - name: OAUTH2_PROXY_PROVIDER
            value: "oidc"
          - name: OAUTH2_PROXY_OIDC_ISSUER_URL
            value: "https://id.example.com"
          - name: OAUTH2_PROXY_CLIENT_ID
            valueFrom:
              secretKeyRef:
                name: oauth2-credentials
                key: client_id

    # Ingress mit TLS + Auth
    ingressSimple:
      enabled: true
      host: myapp.example.com
      tlsSecretName: myapp-tls
      annotations:
        nginx.ingress.kubernetes.io/auth-url: "https://$host/oauth2/auth"
        nginx.ingress.kubernetes.io/auth-signin: "https://$host/oauth2/start?rd=$escaped_request_uri"

    # RBAC für Kubernetes-Ressourcen
    serviceAccount:
      create: true
      name: myapp

    rbac:
      create: true
      rules:
        - apiGroups: [""]
          resources: ["configmaps"]
          verbs: ["get", "list"]

✅ OAuth2/OIDC Authentication

✅ TLS für alle Ingress-Verbindungen

✅ Kubernetes RBAC für Service-to-Service

✅ Secrets über Kubernetes Secrets API

Integration in das souveräne ayedo-Ökosystem¶

Polycrate vs. ohMyHelm: Komplementäre Werkzeuge¶

Aspekt	Polycrate	ohMyHelm
Fokus	Infrastruktur & Plattform	Anwendungen
Zielgruppe	Platform Engineers, Ops	Developers, Architects
Scope	Kubernetes-Cluster, Netzwerk, Storage, Monitoring	Anwendungs-Deployments
Technologie	Ansible, Terraform, bash	Helm, Kubernetes Manifests
Portabilität	Provider-Wechsel (AWS → Bare Metal)	Cluster-Wechsel (Cluster A → B)
Lifecycle	Cluster-Provisionierung, Day-2-Ops	App-Deployment, Updates, Rollbacks
Artefakte	Kubernetes-Cluster, Longhorn, Cilium	Helm Charts, Container Images

Zusammenspiel:

graph TB
    Dev[Developer]
    Ops[Platform Engineer]

    Dev -->|entwickelt| App[Anwendung]
    App -->|paketiert mit| OMH[ohMyHelm Chart]

    Ops -->|provisioniert mit| Poly[Polycrate]
    Poly -->|erstellt| Platform[Kubernetes Platform]

    OMH -->|deployed auf| Platform

    Platform -->|bietet| K8s[Kubernetes API]
    Platform -->|bietet| Storage[Storage - Longhorn]
    Platform -->|bietet| Network[Network - Cilium]
    Platform -->|bietet| Monitor[Monitoring - VictoriaMetrics]
    Platform -->|bietet| Ingress[Ingress - NGINX]
    Platform -->|bietet| Cert[TLS - cert-manager]

    OMH -.nutzt.-> K8s
    OMH -.nutzt.-> Storage
    OMH -.nutzt.-> Network
    OMH -.nutzt.-> Monitor
    OMH -.nutzt.-> Ingress
    OMH -.nutzt.-> Cert

    style OMH fill:#3498db,color:#fff
    style Poly fill:#e74c3c,color:#fff
    style Platform fill:#326ce5,color:#fff

Beispiel-Workflow:

Platform Engineer provisioniert mit Polycrate einen Kubernetes-Cluster inkl. Monitoring, Ingress, Storage
Developer paketiert Anwendung mit ohMyHelm als Helm Chart
Helm Chart wird auf Polycrate-provisionierte Platform deployed
Anwendung nutzt Plattform-Services (Storage, Ingress, Monitoring) automatisch

Cloud Sovereignty Framework & ohMyHelm¶

ohMyHelm unterstützt die Souveränitätsziele des Cloud Sovereignty Framework:

SOV-4: Operational Sovereignty - Exit-Fähigkeit

ohMyHelm-Charts sind vollständig portabel:

# Export Helm Chart
helm package myapp/

# Import in anderen Cluster
helm install myapp myapp-1.0.0.tgz --kubeconfig cluster-b.yaml

✅ Keine proprietären Helm-Extensions ✅ Standard Kubernetes-Manifests ✅ Kein Vendor-spezifisches Tooling

SOV-6: Technology Sovereignty - Offenheit

ohMyHelm ist 100% Open Source:

Quellcode: gitlab.com/ayedocloudsolutions/ohmyhelm
Apache 2.0 Lizenz
Keine proprietären Dependencies
Standard Helm 3.x

SOV-7: Security & Compliance - EU-basierte Operations

ohMyHelm unterstützt Security Best Practices:

# SecurityContext
app:
  chart:
    securityContext:
      runAsNonRoot: true
      runAsUser: 1000
      fsGroup: 1000
      capabilities:
        drop:
          - ALL

✅ Non-Root Container

✅ Read-Only Filesystems

✅ Capability Dropping

✅ Pod Security Standards

Data Act Compliance durch ohMyHelm¶

Der EU Data Act fordert Portabilität und Lock-in-Vermeidung – ohMyHelm liefert dies auf Anwendungsebene:

Portabilität:

# Standardisierte Helm Values
app:
  chart:
    container:
      image: registry.ayedo.cloud/myapp:1.0.0  # OCI Standard

# Export
helm get values myapp > values.yaml
helm get manifest myapp > manifests.yaml

# Import in anderen Cluster (< 1h)
helm install myapp . -f values.yaml --kubeconfig other-cluster.yaml

Keine proprietären APIs:

❌ Kein AWS CloudFormation
❌ Kein Azure ARM Templates
❌ Kein GCP Deployment Manager
✅ Standard Kubernetes API
✅ Standard Helm
✅ OCI Container Registry

Maschinenlesbare Formate:

✅ YAML (Kubernetes Manifests)
✅ JSON (Container Image Manifests)
✅ Helm Chart.yaml (Metadata)

Interoperabilität:

ohMyHelm-Charts laufen auf:

ayedo Managed Kubernetes
AWS EKS
Azure AKS
Google GKE
On-Premise Kubernetes
Lokal (k3s, kind, minikube)

→ Wechsel zwischen Plattformen = Config-Änderung, kein Code-Rewrite

Production-Ready Defaults¶

ohMyHelm bietet Production-Ready Defaults für alle 15 Faktoren:

# Minimal Config für Production-Ready App
app:
  chart:
    enabled: true
    fullnameOverride: myapp

    container:
      image: registry.example.com/myapp:v1.0.0
      ports:
        - name: http
          containerPort: 8080

    # Factor 9: Probes (automatisch aktiviert wenn Ports definiert)
    # Factor 8: Autoscaling
    autoscaling:
      enabled: true
      minReplicas: 2
      maxReplicas: 10

    # Factor 6: Resources (Limits vermeiden OOM)
    resources:
      requests:
        cpu: 100m
        memory: 256Mi
      limits:
        cpu: 1000m
        memory: 1Gi

    # Factor 7: Service
    service:
      type: ClusterIP

    # Factor 15: TLS Ingress
    ingressSimple:
      enabled: true
      host: myapp.example.com
      tlsSecretName: myapp-tls

    # Factor 14: Metrics
    serviceMonitor:
      enabled: true

Das obige Beispiel erfüllt automatisch:

✅ Faktor 6: Stateless (Deployment, nicht StatefulSet)

✅ Faktor 7: Port Binding (Service)

✅ Faktor 8: Concurrency (HPA)

✅ Faktor 9: Disposability (Probes + Graceful Shutdown)

✅ Faktor 14: Telemetry (ServiceMonitor)

✅ Faktor 15: Security (TLS Ingress)

Praktische Beispiele¶

Beispiel 1: Einfache Web-App (12-Factor)¶

# Chart.yaml
apiVersion: v2
name: simple-webapp
version: 1.0.0
dependencies:
  - name: ohmyhelm
    alias: webapp
    repository: https://gitlab.com/ayedocloudsolutions/ohmyhelm
    version: 1.13.0

# values.yaml
webapp:
  chart:
    enabled: true
    fullnameOverride: webapp

    container:
      image: registry.example.com/webapp:v1.0.0
      ports:
        - name: http
          containerPort: 3000

      # Faktor 3: Config via Env
      env:
        - name: NODE_ENV
          value: "production"
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: url

      # Faktor 9: Health Checks
      livenessProbe:
        httpGet:
          path: /health
          port: http
      readinessProbe:
        httpGet:
          path: /ready
          port: http

    # Faktor 8: Autoscaling
    autoscaling:
      enabled: true
      minReplicas: 2
      maxReplicas: 10

    # Faktor 15: TLS
    ingressSimple:
      enabled: true
      host: webapp.example.com
      tlsSecretName: webapp-tls

  # Faktor 11: Logs → stdout/stderr (automatic)
  # Faktor 14: Metrics
  serviceMonitor:
    - name: webapp-metrics
      selector:
        matchLabels:
          app: webapp
      endpoints:
        - port: http
          path: /metrics

Beispiel 2: Microservices mit API-First (Faktor 13)¶

# Chart.yaml
apiVersion: v2
name: microservices-stack
version: 1.0.0
dependencies:
  - name: ohmyhelm
    alias: api-gateway
  - name: ohmyhelm
    alias: user-service
  - name: ohmyhelm
    alias: order-service

# values.yaml
# API Gateway mit Swagger UI
api-gateway:
  chart:
    enabled: true
    fullnameOverride: api-gateway

    # Main Container
    container:
      image: registry.example.com/api-gateway:v1.0.0
      ports:
        - name: http
          containerPort: 8080

    # Faktor 13: Swagger UI als Sidecar
    sidecarContainers:
      - name: swagger-ui
        image: swaggerapi/swagger-ui:latest
        ports:
          - name: swagger
            containerPort: 8081
        env:
          - name: SWAGGER_JSON_URL
            value: "http://localhost:8080/openapi.json"

    # Ingress für API + Swagger
    ingress:
      enabled: true
      rules:
        - host: api.example.com
          http:
            paths:
              - path: /
                pathType: Prefix
                backend:
                  service:
                    name: api-gateway
                    port:
                      number: 8080
              - path: /docs
                pathType: Prefix
                backend:
                  service:
                    name: api-gateway
                    port:
                      number: 8081  # Swagger UI

# User Service
user-service:
  chart:
    enabled: true
    fullnameOverride: user-service
    container:
      image: registry.example.com/user-service:v1.0.0
      ports:
        - name: http
          containerPort: 8080
        - name: grpc
          containerPort: 9090

# Order Service
order-service:
  chart:
    enabled: true
    fullnameOverride: order-service
    container:
      image: registry.example.com/order-service:v1.0.0
      ports:
        - name: http
          containerPort: 8080

Beispiel 3: Observability Stack (Faktor 14)¶

# values.yaml - App mit vollständiger Telemetry
app:
  chart:
    enabled: true
    fullnameOverride: observability-app

    container:
      image: registry.example.com/app:v1.0.0
      ports:
        - name: http
          containerPort: 8080
        - name: metrics
          containerPort: 9090

      # OpenTelemetry Integration
      env:
        # Traces
        - name: OTEL_EXPORTER_OTLP_ENDPOINT
          value: "http://tempo.observability.svc:4317"
        - name: OTEL_SERVICE_NAME
          value: "myapp"

        # Metrics
        - name: PROMETHEUS_PORT
          value: "9090"

        # Logs (JSON)
        - name: LOG_FORMAT
          value: "json"

  # Prometheus ServiceMonitor
  serviceMonitor:
    - name: app-metrics
      selector:
        matchLabels:
          app: observability-app
      endpoints:
        - port: metrics
          interval: 30s
          path: /metrics

Zusammenfassung¶

ohMyHelm ist das Anwendungs-Packaging-Tool für das souveräne ayedo-Ökosystem, das:

✅ Alle 15-Factor-App-Prinzipien implementiert

✅ Cloud Sovereignty Framework auf Anwendungsebene unterstützt (SOV-4, SOV-6, SOV-7)

✅ Data Act-Compliance durch vollständige Portabilität gewährleistet

✅ Komplementär zu Polycrate arbeitet (Polycrate = Plattform, ohMyHelm = Apps)

✅ Production-Ready Defaults für sichere, skalierbare Deployments bietet

✅ 100% Open Source und vendor-unabhängig ist

Polycrate + ohMyHelm = Vollständige Souveränität vom Cluster bis zur Anwendung

Nächste Schritte¶

Erste Schritte - Ihr erstes ohMyHelm-Deployment
Beispiele - Praktische Anwendungsbeispiele
Use Cases - Typische Einsatzszenarien
Polycrate Dokumentation - Infrastruktur-Automatisierung
Cloud Migration - Von Hyperscalern zu souveräner Infrastruktur

Bereit für souveräne, portable Cloud-Native Applications?

Kontaktieren Sie ayedo für:

15-Factor-App Assessments - Analyse Ihrer Anwendungsarchitektur
ohMyHelm-Training für Teams - Hands-on Workshops und Schulungen
Migration bestehender Apps zu ohMyHelm - Beratung und Implementierung
Integration in Ihre CI/CD-Pipeline - DevOps-Automatisierung