Use Cases¶
Typische Einsatzszenarien und Best Practices für ohMyHelm.
1. Rapid Prototyping¶
Szenario: Sie müssen schnell eine Test-Umgebung für eine neue Anwendung aufsetzen.
Lösung:
# Helm Repository hinzufügen
helm repo add ohmyhelm https://gitlab.com/ayedocloudsolutions/ohmyhelm
# Direkt deployen mit inline values
helm install my-test ohmyhelm/ohmyhelm --set chart.enabled=true \
--set chart.container.image=nginx:latest \
--set chart.container.ports[0].name=http \
--set chart.container.ports[0].containerPort=80 \
--set chart.service.type=LoadBalancer
Vorteile: - Kein eigenes Chart erstellen nötig - Deployment in Minuten statt Stunden - Ideal für Proof-of-Concepts
2. Standardisierte Microservices¶
Szenario: Ihr Team entwickelt viele ähnliche Microservices, die alle gleich deployed werden sollen.
Lösung: Erstellen Sie ein Template-Chart mit ohMyHelm, das Sie für alle Services wiederverwenden:
# Chart.yaml (Template für alle Microservices)
apiVersion: v2
name: microservice-template
version: 1.0.0
dependencies:
- name: ohmyhelm
alias: service
repository: https://gitlab.com/ayedocloudsolutions/ohmyhelm
version: 1.13.0
# values.yaml (anpassbar pro Service)
service:
chart:
enabled: true
fullnameOverride: "{{ .Release.Name }}"
container:
image: registry.example.com/{{ .Values.serviceName }}:{{ .Values.version }}
ports:
- name: http
containerPort: 3000
livenessProbe:
httpGet:
path: /health
port: http
readinessProbe:
httpGet:
path: /ready
port: http
service:
type: ClusterIP
ports:
- port: 80
targetPort: http
autoscaling:
enabled: true
minReplicas: 2
maxReplicas: 10
targetCPUUtilizationPercentage: 80
resources:
limits:
cpu: 1000m
memory: 1Gi
requests:
cpu: 100m
memory: 256Mi
Vorteile: - Konsistente Deployments über alle Services - Einfache Wartung (nur ein Chart zu pflegen) - Reduzierter Konfigurationsaufwand
3. GitOps mit ArgoCD/Flux¶
Szenario: Sie möchten GitOps für Ihre Deployments einsetzen.
Lösung: ohMyHelm ist perfekt für GitOps, da die gesamte Konfiguration deklarativ in YAML definiert ist:
gitops-repo/
├── apps/
│ ├── frontend/
│ │ ├── Chart.yaml
│ │ ├── values-dev.yaml
│ │ ├── values-staging.yaml
│ │ └── values-prod.yaml
│ ├── backend/
│ │ ├── Chart.yaml
│ │ └── values-prod.yaml
│ └── database/
│ ├── Chart.yaml
│ └── values-prod.yaml
ArgoCD Application:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: frontend-prod
namespace: argocd
spec:
project: default
source:
repoURL: https://git.example.com/gitops-repo.git
targetRevision: main
path: apps/frontend
helm:
valueFiles:
- values-prod.yaml
destination:
server: https://kubernetes.default.svc
namespace: production
syncPolicy:
automated:
prune: true
selfHeal: true
Vorteile: - Versionskontrolle aller Deployments - Automatische Synchronisation - Rollback durch Git-Revert
4. Multi-Tenancy Deployments¶
Szenario: Sie müssen dieselbe App für mehrere Kunden/Tenants deployen.
Lösung:
# Chart.yaml
apiVersion: v2
name: multi-tenant-app
version: 1.0.0
dependencies:
- name: ohmyhelm
alias: tenant-a
repository: https://gitlab.com/ayedocloudsolutions/ohmyhelm
version: 1.13.0
- name: ohmyhelm
alias: tenant-b
repository: https://gitlab.com/ayedocloudsolutions/ohmyhelm
version: 1.13.0
- name: ohmyhelm
alias: tenant-c
repository: https://gitlab.com/ayedocloudsolutions/ohmyhelm
version: 1.13.0
# values.yaml
tenant-a:
chart:
enabled: true
fullnameOverride: "app-tenant-a"
container:
image: myapp:latest
env:
- name: TENANT_ID
value: "tenant-a"
- name: DATABASE
value: "tenant_a_db"
ingressSimple:
enabled: true
host: tenant-a.example.com
tenant-b:
chart:
enabled: true
fullnameOverride: "app-tenant-b"
container:
image: myapp:latest
env:
- name: TENANT_ID
value: "tenant-b"
- name: DATABASE
value: "tenant_b_db"
ingressSimple:
enabled: true
host: tenant-b.example.com
tenant-c:
chart:
enabled: true
fullnameOverride: "app-tenant-c"
container:
image: myapp:latest
env:
- name: TENANT_ID
value: "tenant-c"
- name: DATABASE
value: "tenant_c_db"
ingressSimple:
enabled: true
host: tenant-c.example.com
Vorteile: - Ein Chart für alle Tenants - Individuelle Konfiguration pro Tenant - Einfaches Hinzufügen neuer Tenants
5. Legacy Applications ohne offizielle Charts¶
Szenario: Sie müssen eine Drittanbieter-Software ohne offizielles Helm Chart deployen.
Beispiel: Self-hosted GitLab Runner
# Chart.yaml
apiVersion: v2
name: gitlab-runner
version: 1.0.0
dependencies:
- name: ohmyhelm
alias: runner
repository: https://gitlab.com/ayedocloudsolutions/ohmyhelm
version: 1.13.0
# values.yaml
runner:
secrets:
- name: gitlab-runner-secret
namespace: gitlab
values:
REGISTRATION_TOKEN: "your-registration-token"
configs:
- name: gitlab-runner-config
namespace: gitlab
values:
config.toml: |
concurrent = 4
check_interval = 0
[session_server]
session_timeout = 1800
[[runners]]
name = "kubernetes-runner"
url = "https://gitlab.example.com/"
executor = "kubernetes"
chart:
enabled: true
fullnameOverride: "gitlab-runner"
container:
image: gitlab/gitlab-runner:latest
command: ["gitlab-runner"]
args: ["run", "--config=/etc/gitlab-runner/config.toml"]
env:
- name: REGISTRATION_TOKEN
valueFrom:
secretKeyRef:
name: gitlab-runner-secret
key: REGISTRATION_TOKEN
deploymentVolume:
volumeMounts:
- name: config
mountPath: /etc/gitlab-runner
- name: docker-sock
mountPath: /var/run/docker.sock
volumes:
- name: config
configMap:
name: gitlab-runner-config
- name: docker-sock
hostPath:
path: /var/run/docker.sock
resources:
limits:
cpu: 2000m
memory: 2Gi
requests:
cpu: 500m
memory: 512Mi
Vorteile: - Schnelles Deployment ohne Chart-Entwicklung - Volle Kontrolle über Konfiguration - Wartbar durch Standard-Patterns
6. CI/CD Pipeline Integration¶
Szenario: Automatisches Deployment aus CI/CD Pipeline.
GitLab CI Beispiel:
# .gitlab-ci.yml
stages:
- build
- deploy
build:
stage: build
script:
- docker build -t registry.example.com/myapp:$CI_COMMIT_SHA .
- docker push registry.example.com/myapp:$CI_COMMIT_SHA
deploy-staging:
stage: deploy
script:
- helm repo add ohmyhelm https://gitlab.com/ayedocloudsolutions/ohmyhelm
- helm upgrade --install myapp-staging ./chart \
--set app.chart.container.image=registry.example.com/myapp:$CI_COMMIT_SHA \
--set app.ingressSimple.host=staging.example.com \
--namespace staging \
--create-namespace
only:
- develop
deploy-production:
stage: deploy
script:
- helm upgrade --install myapp-prod ./chart \
--set app.chart.container.image=registry.example.com/myapp:$CI_COMMIT_TAG \
--set app.ingressSimple.host=app.example.com \
--set app.autoscaling.enabled=true \
--set app.autoscaling.minReplicas=3 \
--namespace production
only:
- tags
when: manual
Vorteile: - Automatisierte Deployments - Environment-spezifische Konfigurationen - Integriert in bestehende Pipelines
7. Infrastructure as Code Setup¶
Szenario: Basis-Infrastruktur-Komponenten als Code verwalten.
# infrastructure-chart/Chart.yaml
apiVersion: v2
name: kubernetes-infrastructure
version: 1.0.0
dependencies:
- name: ohmyhelm
alias: infra
repository: https://gitlab.com/ayedocloudsolutions/ohmyhelm
version: 1.13.0
# infrastructure-chart/values.yaml
infra:
# Namespaces erstellen
namespaces:
setPreInstallHook: true
spaces:
- name: production
- name: staging
- name: development
- name: monitoring
- name: logging
- name: ingress-nginx
# Registry Secrets für alle Namespaces
imageCredentials:
- name: registry-credentials
namespace: production
registry: https://registry.example.com
username: "{{ .Values.registryUsername }}"
accessToken: "{{ .Values.registryToken }}"
- name: registry-credentials
namespace: staging
registry: https://registry.example.com
username: "{{ .Values.registryUsername }}"
accessToken: "{{ .Values.registryToken }}"
# TLS Wildcard Certificate
tlsSecrets:
- name: wildcard-tls
namespace: ingress-nginx
values:
tls.crt: |
{{ .Values.tlsCert | indent 10 }}
tls.key: |
{{ .Values.tlsKey | indent 10 }}
# Shared ConfigMaps
configs:
- name: cluster-info
namespace: default
values:
cluster.yaml: |
name: "{{ .Values.clusterName }}"
region: "{{ .Values.region }}"
environment: "{{ .Values.environment }}"
Vorteile: - Zentrale Verwaltung der Basis-Infrastruktur - Wiederholbare Setups - Versionierte Infrastruktur
8. Development zu Production Workflow¶
Szenario: Konsistenter Workflow von Development bis Production.
Struktur:
myapp/
├── Chart.yaml
├── values-common.yaml # Gemeinsame Werte
├── values-development.yaml # Dev overrides
├── values-staging.yaml # Staging overrides
└── values-production.yaml # Prod overrides
values-common.yaml:
app:
chart:
enabled: true
fullnameOverride: myapp
container:
image: registry.example.com/myapp
# Tag wird pro Environment gesetzt
service:
type: ClusterIP
resources:
requests:
cpu: 100m
memory: 256Mi
values-development.yaml:
app:
chart:
container:
image: registry.example.com/myapp:dev-latest
ingressSimple:
enabled: true
host: myapp-dev.example.com
replicaCount: 1
resources:
limits:
cpu: 500m
memory: 512Mi
values-production.yaml:
app:
chart:
container:
image: registry.example.com/myapp:v1.2.3 # Fixed version
ingressSimple:
enabled: true
host: myapp.example.com
tlsSecretName: myapp-tls
autoscaling:
enabled: true
minReplicas: 3
maxReplicas: 20
resources:
limits:
cpu: 2000m
memory: 2Gi
Deployment:
# Development
helm upgrade --install myapp . \
-f values-common.yaml \
-f values-development.yaml \
--namespace development
# Staging
helm upgrade --install myapp . \
-f values-common.yaml \
-f values-staging.yaml \
--namespace staging
# Production
helm upgrade --install myapp . \
-f values-common.yaml \
-f values-production.yaml \
--namespace production
Vorteile: - DRY (Don't Repeat Yourself) - Environment-spezifische Anpassungen - Einfache Promotion zwischen Environments
Best Practices¶
1. Verwenden Sie fullnameOverride¶
2. Pinnen Sie Versions in Production¶
# Development: latest
chart:
container:
image: myapp:latest
# Production: feste Version
chart:
container:
image: myapp:v1.2.3
3. Implementieren Sie Health Checks¶
chart:
container:
livenessProbe:
httpGet:
path: /health
port: http
readinessProbe:
httpGet:
path: /ready
port: http