Zum Inhalt springen

Into Cloud 2.0

Weiterentwicklung einer bestehenden Cloud-Infrastruktur: Containerisierung weiterer Dienste, Einfuehrung von Infrastructure as Code und Ausbau der Automatisierung fuer schnellere Bereitstellungszyklen.

2018

Projektjahr

Enterprise

Branche

Docker / K8s

Plattform

DevOps

Rolle

Ausgangslage

Nach einer ersten Cloud-Migration, die grundlegende Dienste in eine Cloud-Infrastruktur überführt hatte, stand nun die zweite Phase an. Weitere Anwendungen und Dienste sollten containerisiert und in die bestehende Cloud-Plattform migriert werden. Die Erfahrungen aus der ersten Phase hatten gezeigt, dass nicht alle Anwendungen ohne Anpassung in eine Container-Umgebung überführt werden konnten.

Ziel von „Into Cloud 2.0″ war die systematische Containerisierung weiterer Dienste, die Weiterentwicklung der CI/CD-Pipelines und die Optimierung der bestehenden Cloud-Infrastruktur auf Basis der Erkenntnisse aus der ersten Phase.

Herausforderung & Ansatz

Herausforderung

  • Legacy-Anwendungen, die nicht für Container-Betrieb ausgelegt waren
  • Abhängigkeiten zwischen bereits migrierten und noch klassisch betriebenen Diensten
  • Weiterentwicklung der CI/CD-Pipelines für heterogene Anwendungen
  • Sicherstellung der Betriebsstabilität während der Migration

Ansatz

  • Cloud-Readiness-Assessment für jede Anwendung
  • Refactoring kritischer Legacy-Komponenten vor der Migration
  • Erweiterung der CI/CD-Pipelines um Multi-Stage-Builds
  • Blue-Green-Deployments für risikoarme Umstellungen

Umsetzung

Cloud-Readiness-Assessment

Jede Anwendung wurde anhand eines definierten Kriterienkatalogs bewertet: Stateless-Fähigkeit, externe Abhängigkeiten, Konfigurierbarkeit über Umgebungsvariablen, Log-Verhalten und Health-Check-Mechanismen. Auf Basis der Bewertung wurde entschieden, ob eine Anwendung direkt containerisiert, vorher refaktorisiert oder als Ausnahme weiterhin klassisch betrieben werden sollte.

Containerisierung und CI/CD

Die Containerisierung folgte einem standardisierten Prozess: Erstellung eines Dockerfiles mit Multi-Stage-Build, Definition der Kubernetes-Manifeste (Deployment, Service, Ingress, ConfigMap) und Integration in die CI/CD-Pipeline. Die Pipelines wurden um automatisierte Security-Scans der Container-Images, Integrationstests und Performance-Tests erweitert.

Migration und Cutover

Die Migration einzelner Dienste erfolgte über Blue-Green-Deployments. Beide Versionen liefen parallel, bis die neue Container-Version alle Akzeptanztests bestanden hatte. Der Traffic wurde dann schrittweise umgeleitet, zuerst für interne Nutzer, dann für einen Prozentsatz des produktiven Traffics und schließlich für alle Nutzer. Ein automatischer Rollback-Mechanismus stellte sicher, dass bei Problemen sofort auf die alte Version zurückgewechselt werden konnte.

Kenntnisse

Cloud & Container

  • Docker
  • Kubernetes
  • Multi-Stage-Builds

CI/CD

  • GitLab CI/CD
  • Blue-Green-Deployment
  • Security-Scans

Ergebnis & Fazit

Ergebnis

  • Weitere Dienste erfolgreich in die Cloud-Plattform migriert
  • Erweiterte CI/CD-Pipelines mit Security-Scans und Integrationstests
  • Risikoarme Migration durch Blue-Green-Deployments
  • Standardisierter Cloud-Readiness-Bewertungsprozess

Fazit

Die zweite Phase einer Cloud-Migration ist oft anspruchsvoller als die erste, weil die einfach zu migrierenden Dienste bereits überführt sind. Die systematische Bewertung der Cloud-Readiness, das gezielte Refactoring kritischer Komponenten und die risikoarme Migration über Blue-Green-Deployments ermöglichten eine erfolgreiche Fortsetzung der Cloud-Strategie ohne Beeinträchtigung des laufenden Betriebs.