Deployment, Container, Kubernetes & OpenShift
Vom JAR zum betriebenen Service: Images, Ressourcen, Probes, Config, Secrets und Rollouts.
Enterprise JavaBeispieleArchitekturOffline HTML
In dieser Datei
Container ist kein Deployment-Konzept allein
Ein Dockerfile macht noch kein betreibbares System. Enterprise Deployment braucht Versionierung, Konfiguration, Secrets, Ressourcen, Probes, Rollout-Strategien, Migrationsplan, Monitoring und Incident-Fähigkeit.
Schlankes Java Runtime Image
FROM eclipse-temurin:21-jre
WORKDIR /app
COPY target/order-service.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-XX:MaxRAMPercentage=75", "-jar", "app.jar"]
Kubernetes Deployment mit Probes und Ressourcen
apiVersion: apps/v1
kind: Deployment
metadata:
name: order-service
spec:
replicas: 3
selector:
matchLabels: { app: order-service }
template:
metadata:
labels: { app: order-service }
spec:
containers:
- name: app
image: registry.example.com/order-service:1.0.0
ports: [{ containerPort: 8080 }]
readinessProbe:
httpGet: { path: /actuator/health/readiness, port: 8080 }
livenessProbe:
httpGet: { path: /actuator/health/liveness, port: 8080 }
resources:
requests: { cpu: "250m", memory: "512Mi" }
limits: { cpu: "1", memory: "1024Mi" }
Konfiguration und Secrets
| Datenart | Wohin | Nicht tun |
|---|---|---|
| Normale Konfiguration | ConfigMap, Environment, Application Config | Nicht hart im Code verdrahten |
| Secrets | Secret Store / Kubernetes Secret / Vault | Nicht in Git oder Image bauen |
| Feature Flags | zentrales Flag-System oder sichere Konfig | Nicht heimlich Fachlogik per Profile duplizieren |
| DB-Migration | CI/CD oder kontrollierter Job | Nicht automatisch unkontrolliert bei jedem Pod-Start |
Rollout und Rückwärtskompatibilität
Rolling Updates bedeuten, dass alte und neue Versionen kurzzeitig gleichzeitig laufen. APIs, Events und Datenbankschema müssen dafür kompatibel sein. Eine Datenbankspalte entfernen ist fast nie ein einzelner Schritt; zuerst hinzufügen, doppelt schreiben/lesen, migrieren, dann später entfernen.