Agile Infrastruktur und Continuous Delivery in CoreMedia – Zero Downtime Deployment – Teil6

Alles was wir bis jetzt aufgesetz haben diente einem einzigen Zweck: Dem Continuous Delivery Paradigma – der Königs Diziplin. Continuous Integration ist vielen ein Begriff. Darin geht es darum, dass Code in einem Versionierungs System mit einem sogenannten CI Tools wie Jenkins gebaut und in einer Testumgebung gestartet wird. Das dient dem Zweck kontinuerlich zu prüfen, ob Code, repsektive die Features, die man gebaut hat im Gesamtsystem funktioniert, ob alle Komponenten zusammen noch funktionieren. Dieser Workflow soll helfen das Vertrauen aller Beteiligten in das System zu erhöhen und dadurch Releases schneller durchführen zu können. In der Software Entwicklung gibt es viele Abhängigkeiten von Libraries, Entwickler Code, Betriebssystem, Umgebung, Patches, Drittsystemen, etc. Mit CI soll die Integration all dieser Komponenten sicher gestellt werden.

Docker allein löst das Problem, weil Abhängigkeiten kontrolliert und reproduzierbar sind. Es gibt in dem Docker Paradigma gar keine Server Komponenten mehr die der Snow Flake Erosion unterliegen. Server werden von Deployment zu Deployment weggeworfen und neu gebaut, anhand einer deklarativen Sprache (in Files wie Yaml, Json) die Ihrerseits versioniert sind. Dadurch dass dieses Problem schon zum größten Teil gelöst ist kann man sich dem nächsten Schritt widmen: Continuous Delivery.

D.h. wie kann man Features schneller in Produktion überführen. Muss man wirklich lange Release Zyklen in Kauf nehmen? Wie entstehen lange Release Zyklen überhaupt? Die Antwort ist einfach: Komplexität! Durch Docker, Cluster Lösungen und Automatisierung wird die Komplexität in Tools und Methoden überführt, sodass ein Deployment im Grunde darin besteht ein Skript auszuführen, ganz gleich ob es sich um die Provisionierung einer Infrastruktur, einer CoreMedia Umgebung, das Bauen aus Git oder anderer Schritte dreht. Was wir in unserem Showcase dem Kunden vorführen führt regelmäßig zu Aha-Erlebnissen. Wir kennen die Schmerzen die mit Deployments verbunden sind, gerade in einer komplexen Umgebung mit vielen abhängigen Komponenten. Nach der Demo Vorführung sehen wir die großen, ungläubigen Augen und sind jedesmal selbst begeistert, was Technologie heute im Betriebsumfeld leisten kann. Ich kann nur jedem empfehlen sich der Container Technologie zu widmen, das ist die Zukunft der Infrastrukturen und DevOps Bewegung. Doch genug des Pathos: Let’s get to the beef:

Wer die Artikelserie verfolgt hat weiß, dass wir zum jetzigen Zeitpunkt ein CoreMedia Cluster am laufen haben (ich wiederhole: unter 25 Minuten aus dem Stand – ohne vorherige Server Infrastruktur). Das jetzige Ziel ist folgendes:

Wir ändern ein Template in der Entwicklungsumgebung, comitten und pushen die Änderungen. Nun erwarten wir, dass wenige Minuten später die Änderungen in der Preview CAE auf dem produktiven System sichtbar werden, und zwar ohne dass es zu einem Ausfall des Auftrittes kommt: Zero Downtime Deployment.

Ändern eines Templates in der Entwicklungsumgebung:

Nach dem Pushen greift wenige Sekunden später der Jenkins/Git trigger und Jenkins fängt an, das Projekt auszuchecken und zu bauen. Wenn das Projekt mit Maven auf Jenkins gebaut wurde, kommt jetzt der entscheidende Schritt: Es wird aus den generierten Artefakten ein Docker Image gebaut. Dieses ist wichtig für das Deployment auf Marathon. Wenn das Image gebaut worden ist, wird es in ein sogenanntes Docker Registry gepushed, damit es für Marathon zu Verfügung steht.

Wie wir am Ende des Screenshots sehen, hat Jenkins also das Image in die Docker Registry gepushed und das Marathon Deployment angestossen. Im nächsten Schritt werfen wir einen Blick auf das Marathon dashboard und sehen was dort nun passiert. An diesem Zeitpunkt sei betont, dass der HAProxy noch fleissig die alte Version der Preview CAE ausliefert:

Jetzt der Blick auf Marathon:

Wir haben intial zwei Instanzen der Preview CAE laufen. Marathon wird jetzt parallel zwei weitere Instanzen hoch fahren. Das sieht man im Screenshot anhand des Status „Staging“. Nachdem diese beiden neuen Instanzen in den Status „Healthy“ wechseln, wird Marathond die beiden alten Instanzen zerstören. Bis dahin routet HAProxy den Traffic nach wievor auf die alten Instanzen. Erst wenn die beiden neuen Instanzen Healthy sind wird der Traffic auf diese beiden neuen Instanzen geroutet und die beiden alten Instanzen gelöscht.

Jetzt sind alle 4 Instanzen „Healthy“ und Marathon routet den Traffic auf die neue Version und die alten Versionen entfernt:

Wenn wir uns jetzt die Preview CAE aufrufen ist die neue Version zu sehen. Während der ganzen Deploy Zeit war zu jedem Zeitpunkt die Webseite erreichbar.

Wenn Sie mehr wissen möchten über die Container Technologie, DevOps, Agile Infrastrukturen im CoreMedia Umfeld dann melden Sich sich zu einem unverbindlichen WebEx Meeting an oder vereinbaren einen Termin bei Ihnen vor Ort. Wir führen Ihnen die Vorteile und enormen Zeitgewinne gerne live und in Farbe vor.

Teilen:

Relevante Artikel

Advanced AI applications for the insurance domain

Advanced AI applications for the insurance domain

Has an automobile accident ever happened to you? You are probably aware of the difficulties associated with filing an auto insurance claim if you have

Framework für die Einführung von Generative AI

Framework für die Einführung von Generative AI

Der Leitfaden zur Einführung von Generative AI in Ihrem Unternehmen: Ein systematisches Framework In der Ära der digitalen Transformation ist Generative AI nicht mehr nur

Wie können Large Language Modelle wie GPT-4 Geschäftsprozesse optimieren?

Wie können Large Language Modelle wie GPT-4 Geschäftsprozesse optimieren?

Wussten Sie, dass KI-Modelle wie GPT-4, Gemini, LLama2, Mistral & Co. dabei helfen können, die Leistungsfähigkeit Ihres Unternehmens zu steigern? Diese großen Sprachmodelle sind revolutionäre