Einführung in Continuous Deployment, Teil 1 Continuous Delivery mit Blue/Green-Deployments

Software in Form von Continuous Deployment bereitzustellen, erfordert besondere Strategien und Technologien. So genannte „Blue Green Deployments“ sind zwar nicht neu, entfalten ihre Stärken aber erst in modernen Cloud-Umgebungen wie AWS, da die zugrundeliegenden Konzepte erst mit Cloud-Technologie praktikabel umsetzbar sind.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Allgemein bezeichnet man mit Blue/Green-Deployment eine Strategie für das Bereitstellen und Veröffentlichen von Software. Zentrale Idee des Konzepts ist es, zwei separate, aber für sich voll produktionsfähige Umgebungen bereitzuhalten, von denen jede fähig ist, die jeweiligen Applikationen bereitzustellen.

Die einzelnen Umgebungen sind identisch oder weitgehend identisch und werden meist in „Blue“ und „Green“ unterschieden. Zu jedem Zeitpunkt aktiv ist nur die als Blue bezeichnete Umgebung, sie nimmt sämtliche Anfragen an die produktiven Anwendungen oder Systeme entgegen. Für das „Umschalten“ sorgt z.B. ein Load Balancer vor den Endpunkten der jeweiligen Umgebung, der den Datenverkehr zur jeweils gerade aktiven Umgebung leitet.

Usecase eCommerce

Der Blue/Green-Ansatz kommt unter anderem im eCommerce-Umfeld zur Umsetzung eines Continuous Deployments für neue Shop-Releases zum Einsatz. Bei vielen großen Webshops werden Updates oder neue Funktionen nicht mehr quartalsmäßig eingespielt sondern per Continuous Delivery.

Gerade in der eCommerce-Branche steht der messbare Erfolg nämlich oft im direkten Zusammenhang mit den Release-Zyklen. Statische Shops mit wenigen Releases-Updates gibt es immer weniger. Erfolgreich sind vor allem Shops, die binnen weniger Tage oder gar Stunden neue Funktionen und Angebote zu integrieren in der Lage sind.

CD und Microservices

Continuous Deployment ist vor allem in Microservice-Architekturen sinnvoll. Beide Konzepte profitieren voneinander bzw. bedingen einander. Unter Microservices versteht man bekanntlich

• ein Architekturmodell für Software-Services oder komplexe Multi-Tier-Anwendungen,

• bei dem die Anwendungssoftware aus mehreren kleinen, voneinander unabhängigen Prozessen zusammengestellt wird,

• von denen jeder über seinen eigenen unabhängig Service-Stack verfügt und

• die untereinander über sprachunabhängige Programmierschnittstellen kommunizieren.

Die einzelnen Services sind dabei möglichst klein, so weit wie möglich voneinander entkoppelt und jeder Einzelne nur für eine kleine, spezielle Aufgabe bestimmt. In Summe erlauben Microservices somit ein modulares und serviceorientierten Erstellen komplexer Anwendungssoftware.

Das Modell ist in der Informatik ebenfalls nicht neu, entfaltet aber sein Potenzial im Kontext von Containern und Cloud-Umgebungen, in denen Software-definierte Konzepte für Netzwerke und Storage das Erstellen von Service-Stacks begünstigen. Microservice-Architekturen bieten eine Reihe von Vorteilen gegenüber klassischen Architekturen, allen voran eine einfachere und zielgerichtetere Skalierung, weil Microservices unabhängig voneinander skalieren.

Im Hinblick auf unser eigentliches Thema besteht aber einer der wichtigsten Vorteile von Microservices darin, dass Microservices von kleinen Teams unabhängig voneinander verteilt werden können, eine wichtige Voraussetzung für agile Entwicklungsprozesse. Aufgrund ihrer geringen Größe lassen sie sich zudem einfach weiterentwickeln.

In der Konsequenz ist eine Continuous Delivery-Strategie mit Microservices einfacher realisierbar. Da zur Zeit zahlreiche Unternehmen im Zuge der digitalen Transformation an einer Überführung ihrer klassischen Anwendungs-Tiers in eine Microservice-Architektur arbeiten, gelangt auch das Thema Coninuous Delivery in deren Fokus.

Warum überhaupt Continuous Delivery ?

Die Frage ist also eigentlich gar nicht, ob CD Vorteile bringt, denn begrüßenswert sind „Verbesserungen“ in Form neuer Releases eigentlich immer. In traditionellen Umgebungen stellt CD allerdings immense Anforderungen, sodass die Umsetzung in Cloud-Umgebungen oder mit Cloud-nativen Apps, bzw. in Microservice-Architekturen eher machbar ist.

So ist es im Prinzip jeder kleine Bugfix und jede kleine Konfigurationsänderung wert, so zeitnah wie möglich in Produktion genommen zu werden. Begreift man sogar jeden kleinen Bugfix in einer Microservice-Architektur als „verteilungswürdig“, kommen in großen Unternehmen durchaus schnell hunderte Deployments pro Woche zusammen, wenn etwa jeder Entwickler in einem Team ein bis dreimal täglich eine Verbesserung fertigstellt.

Continuous Delivery unter der Lupe

Nicht jeder Fix muss dabei unmittelbar zu einem neuen Feature führen. Trotzdem ist der Aufwand für CD auch in Cloud- und Microservice-Architekturen nur durch ausgeklügelte Automatisierung stemmbar. Dabei sollte z. B. jede Neuerung in einem „Version Control System“ (VCS, Versionskontrollsystem) festgehalten werden, damit sie ohne manuelle Eingriffe in Produktion genommen werden kann.

So muss zum kein Entwickler oder Admin ein Deployment manuell anstoßen. Zudem erübrigt sich damit auch eine manuelle Release-Dokumentation, denn eine solche wird durch die Schritte der Deployment-Pipeline z. B. mittels standardisierter Commit-Messages automatisiert. Außerdem kann man mit CD sogar auf eine manuelle Qualitätssicherung verzichten, setzt man beispielsweise automatisierte UI-Tests ein, zumal jedes einzelne Deployment „klein“ und damit meist relativ risikofrei ist.

Auf CD spezialisierte Frameworks wie etwa Jenkins leisten hierbei wertvolle Unterstützung. Jenkins ist selbst eine Java-Anwendung und unterstützt diverse Build-Tools wie Apache Ant, Maven und Gradle, sowie Versionsverwaltungssysteme wie CVS, Subversion oder Git und auch eine Reihe automatische Testverfahren wie JUnit. Plugins erlauben sogar das Ansteuern anderer Compiler, sodass Jenkins neben Java auch Projekte mit PHP-, Ruby- oder .NET unterstützt. Jenkins ist eines der meistgenutzen Werkzeuge zur kontinuierlichen Integration.

FOSDEM – Continuous Delivery Pipelines

Jenkins erhält deklarative Pipeline-Syntax

CD mit Blue-Green-Deployment

Allerdings lassen sich Continuous Deployment und Continuous Delivery oft nicht so einfach implementieren, wie es sich liest – allein wenn man die hohen Anforderungen an die Zahl der Releases und die Veröffentlichungsfrequenz betrachtet. Eine Deployment-Strategie, die solchen Anforderungen genügt, ist das Blue/Green-Deployment.

Neue Software-Releases werden zunächst in der nicht aktiven Umgebung (Green) bereitgestellt. Aus Sicht des Blue/Green-Deployments diese eine Art finale Bereitstellungsumgebung und bildet die produktive Umgebung so nah wie möglich ab. Zudem lässt sich das Green-Deployment auch für das finale Testing heranziehen.

Wurde das neue Release ausreichend getestet und als stabil eingestuft, kann diese bisherige „Staging-Umgebung“ als produktive Version bereitgestellt werden, wozu Datenverkehr ab diesem Zeitpunkt an die grüne Umgebung geleitet wird. Die vorherige blaue Umgebung wird damit inaktiv und jetzt zur neuen „Staging-Umgebung“.

Die vormals verwendete Software-Version ist jetzt zwar nicht mehr aktiv, aber trotzdem noch verfügbar, sollten sich mit der neuen Version wider Erwarten doch Probleme ergeben. Der alte Stand lässt sich dann durch eine einfache Neukonfiguration des Load Balancers wiederherstellen.

Server-Trashing

Das Konzept von Blue/Green-Deployments ist keineswegs neu, sondern in der professionellen Softwareentwicklung seit langem bekannt. Es gewinnt aber wie erwähnt insbesondere im Kontext von Cloud-Computing und Microservices an Bedeutung , da sich eine virtuelle Infrastruktur viel schneller und einfacher bereitstellen lässt.

Mit dem ebenfalls im Cloud-Kontext entstandenen „Trash your Servers“-Konzept ist es sogar möglich, die vormals verwendeten virtuellen Server gar nicht zu behalten, sondern für jedes Deployment neue Server zu provisionieren, sodass die jeweils aktuelle inaktive Umgebung stets auf einer neuen virtuellen Server-Umgebung aufbaut, um die jeweils neuste Software-Version bereitzustellen.

Wird diese aktiv geschaltet, lassen sich die Server der vorherigen produktiven Umgebung wieder entsorgen. Beiden Konzepten – also Blue/Green und Trash your Servers – liegt die Idee einer Hot-Standby-Umgebung für das Continuous Deployment von Software-Releases zugrunde. Im zweiten Teil dieser Beitragsreihe gehen wir praxisnah auf Blue/Green-Deployments ein.

Einführung in Continuous Deployment, Teil 2

Blue/Green-Deployment in AWS

(ID:44523045)