Klassisches Deployment vs. Container Deployment

Wie genau Ihr Deployment abläuft, kann durchaus unterschiedlich aussehen, aber der Prozess sieht wahrscheinlich in etwa wie einer der folgenden aus:

• Albtraum → Nach abgeschlossener Entwicklung wird darauf gehofft, dass das Change Board diese genehmigt, und gibt dann den Code an das Betriebsteam ab, damit das Deployment durchgeführt werden kann. 
• Gefährlich → den Code direkt über SSH oder FTP auf den Server laden und Upgrades manuell durchführen.
• Kaum brauchbar → auf einer virtuellen Maschine arbeiten, während der Code per Automatisierung auf den Server geladen wird. Veränderungen werden im Voraus programmiert und die Konfiguration wird von der Umgebung bestimmt. Allerdings haben Sie vermutlich keinen Zugriff auf die Maschine und können daher auch ihren Zustand nicht überprüfen.
• Passabel → Sie arbeiten mit Containern und einer komplexen CI/CD-Pipeline, die für Sie das Testing und Deployment durchführt. Beim Deployment wird eine standardisierte IaC-Sprache wie etwa Terraform verwendet.

• Gut? -> Sie arbeiten mit Containern, verpacken Ihre Applikation (z.B mit Helm) und machen das Deployment über GitOps.

Antike Methoden

Vermutlich ist die Applikation fest in der Umgebung verankert, während die Umgebung selbst veränderbar ist, da mehrere Personen einen SSH-Zugang haben. Die Produktion sieht komplett anders aus als die Entwicklung. Der Server-Status lässt sich unter keinen Umständen überprüfen und das Aufsetzen eines neuen Servers zum testen ist ein bürokratischer Albtraum, welcher selbst Kafka zur Verzweiflung bringen würde. Deployments erfordern mehrmaliges manuelles Eingreifen, bei dem auch noch alles perfekt ablaufen muss, damit es gelingt. In der Folge muss jede Veränderung von einem Gremium genehmigt werden und ihr Deployment muss ganz genau geplant werden. Willkommen im Jahr 2001?

Sie wollen mehr zur Implementierung von Container-Technologien erfahren?
Wir haben für Sie die 20 meist gestellten Fragen in einem Dokument beantwortet:

Ist es verwunderlich, dass in diesem Szenario der Deployment-Prozess sowohl vom Management als auch von den Entwicklern als hohes Risiko angesehen wird? Änderungsprozesse wurden schon immer mit der Absicht entworfen, das Risiko zu minimieren. Dennoch gibt es schlicht und einfach keine Software, welche fehlerfrei ist – egal, wie gut Ihr Testing ist. Und Sie werden auch niemals alle Fehler finden, bevor die Software nicht in freier Wildbahn – und von echten Benutzern – angewendet wird. Wenn dieser Fakt akzeptiert wird, dann liegt die Schlussfolgerung nahe, dass es eigentlich darauf ankommt, so schnell wie möglich auf das Feedback dieses Live-Datenverkehrs (welches sich normalerweise in Form von Metriken und Benachrichtigungen zeigt) reagieren zu können. Anders gesagt: Am wichtigsten sind Deployment-Stabilität und -Geschwindigkeit.

Was Sie also nicht brauchen, ist ein schwergewichtiger Prozess, welcher für grosse Besorgnis bei allen sorgt – und zwar jedes Mal, wenn ein Release unmittelbar bevorsteht – und gleichzeitig verhindert, dass Mehrwert für den Kunden geschaffen werden kann. Stattdessen brauchen Sie einen automatisierten und flexiblen Ansatz, welcher eine schnelle Reaktion auf Änderungen ermöglicht.

Es sollte doch so einfach sein

Was Container-Plattformen und die dazugehörigen Best Practices versprechen ist, dass sie die Geschwindigkeit in den Mittelpunkt stellen. Das heisst, dass Änderungen so schnell wie möglich in der Produktionsumgebung landen. Um dies zu ermöglichen, müssen bestehende Barrieren zwischen den Entwicklern und dem Betriebsteam eingebrochen werden. Ausserdem müssen die Entwickler kontrolliert die Infrastruktur verändern können. Dazu benutzen sie weitgehend angewendete Konfigurationssprachen und Automatisierungs-Tools und konfigurieren Dateien, die im Version-Tracking gespeichert sind. Mit anderen Worten: DevOps.

Manche (nicht alle) der Hauptelemente von DevOps sind:

Wandlungsfähigkeit als Gegenmodell

In der Welt von DevOps kann nicht einfach per SSH eine Konfiguration geändert werden. Stattdessen findet ein erneutes Deployment der Applikation und ihrer Umgebung statt, wenn eine Veränderung gemacht werden soll. Das hilft dabei, zeitbedingte Abweichungen in der Konfiguration zu vermeiden. Ausserdem werden dadurch Veränderungen, welche die Applikation unbrauchbar machen, schneller erkannt. Die Informationssicherheit ist gegeben – denn vertrauliche Informationen werden in der Laufzeit-Umgebung auf temporären Dateisystemen gespeichert statt in der Anwendung verankert – und der sogenannte “Cattle over Pets”-Ansatz wird verfolgt. Dazu wird natürlich ein komplett anderer Deployment-Prozess als bei einem traditionellen Server benötigt! Tools wie Docker (und Container im allgemeinen) und Kubernetes eignen sich gut zur Anwendung dieses Modells.

Infrastruktur als Code

Wenn die Infrastruktur als etwas angesehen wird, das versioniert, streng abgegrenzt und deploybar ist, sind Änderungskontrollen und Rollbacks leicht gemacht und Anwendungen laufen fast überall. Runtime-Umgebungen werden berechenbar gemacht und instabilen Server-Setups wird vorgebeugt, indem die gleiche Umgebung zur Entwicklung und zum Deployment verwendet wird. Dazu wird diese Umgebung (täglich/stündlich) wieder neu aufgebaut und ihre Konfiguration wird in der Versionskontrolle abgespeichert. Dazu werden Konfigurationssprachen verwendet wie Terraform, welche die Infrastruktur bereitstellen, und Dockerfiles, welche Runtime-Umgebungen für Applikationen bieten.

Single Responsibility

Weil Container so leichtgewichtig sind und ihre Entwicklung und ihr Deployment so schnell gemacht sind, kann das Single-Responsibility-Prinzip auch auf die Runtimes der Applikation übertragen werden. Jeder Container ist nur für jeweils eine Aufgabe zuständig. Dementsprechend können Sie die Bedingungen Ihrer Runtime-Umgebung so anpassen, dass sie gezielt auf die Applikation und ihre Leistung, Skalierbarkeit, etc. abgestimmt ist. Dieses Modell hilft Ihnen ausserdem dabei, Deployments schneller durchzuführen, denn Sie müssen nur noch die Anwendungsteile neu programmieren und bereitstellen, die sich verändert haben. Gewissenhafte Entwickler sind für dieses Modell perfekt geeignet!

Selbstheilung und Auto-Skalierung

Wenn ein Container abstürzt, kann eine neue Instanz fast sofort gestartet werden. Container-Plattformen nutzen diese Tatsache, um sich einerseits selbst zu “heilen” und andererseits für die automatische Skalierung. Das Schöne am Ansatz von Kubernetes, welcher auf einer Abstimmungsschleife basiert, ist, dass ständig Entscheidungen aufgrund der eingehenden Daten bzw. des Status gemacht werden können. Das heisst, wenn Ihr Container nicht reagiert, kann Kubernetes ihn schnell stoppen und einen neuen starten. Gleichzeitig bedeutet es auch, dass Kubernetes sieht, wenn Ihr Container bald seine Ressourcenbeschränkung erreicht, und dementsprechend neue Instanzen je nach Bedarf starten (insofern es korrekt konfiguriert ist). Neben Kubernetes lassen sich auch unter anderem Openshift und Cloud Foundry für diesen Ansatz nutzen.

Applikationen verpacken

Einige der bereits genannten Modelle haben dazu geführt, dass sich eine Standardisierung beim Verpacken von Applikationen in der Cloud herauskristallisiert hat. Beim Cloud-nativen Deployment können Endbenutzer durch die Anwendung branchenüblicher Programmiersprachen, Tools und Paradigmen nicht nur Services zur Unterstützung der Applikation schnell bereitstellen, sondern Ihre Applikationen auch so verpacken, dass sie einfacher zu benutzen sind. Tools wie Helm, Kustomize und Jsonnet unterstützen dieses Modell.

An weiteren Informationen rund um die Container-Technologie und 
Cloud Computing interessiert? Dann abonnieren Sie jetzt unseren Blog: 

GitOps

Dies war einmal der Abschnitt des Artikels, in dem wir Ihnen geraten haben, alles zu automatisieren. Das hätte damals bedeutet, dass Sie Pipelines programmiert hätten, über die dann das Deployment Ihrer Applikation automatisch verlaufen wäre. Doch die Zeiten ändern sich, und was früher die besten Praktiken waren, ist heute Schnee von gestern. Im Jahr 2020 schauen wir uns deswegen stattdessen GitOps und Cloud-native Toolchains als noch bessere Deployment-Methode an. Eventuell fragen Sie jetzt: Warum von Pipelines auf etwas Neues umsteigen? Dazu sage ich Ihnen: Stellen Sie sich vor, Sie müssen so wie wir einige hundert Zeilen lange YAML-Dateien von Fehlern befreien, wenn unsere Pipelines kaputtgehen. Das klingt vielleicht wie ein Witz, aber es ist kein Zuckerschlecken, wenn versucht werden muss, Prozesse zu debuggen, die mit Konfigurationsdateien auf einem Remote-Server beschrieben werden. Üblicherweise wird dazu auch noch ein CI Runner verwendet, sodass der Zugriff noch weniger direkt ist. Die nötige Verwaltung der Konfigurationsdateien (k8s, helm, terraform, usw.) ist allein schon anstrengend genug, ohne sich auch noch um mehrere Deployment-Scripts – zu denen grossen Pipelines welche sich mittlerweile entwickelt haben – kümmern zu müssen. Das wahre Prinzip von IaC sollte sein, dass nur noch die deklarative Konfiguration geschrieben werden muss. GitOps kann allerdings eine Lösung bieten. Es verspricht ja, dass nur noch der Code gepusht werden muss, denn dann übernehmen ihn Webhooks und eine externe Software kümmert sich um Ihr Deployment. Das bedeutet effektiv, dass Sie nur noch sicherstellen müssen, dass die Verpackung Ihrer Applikation korrekt programmiert wurde, und die Software macht den Rest. Sobald der Deployment-Prozess “outgesourct” wurde, verbessern sich gleichzeitig die Features. Da einige Tools mitunter Blue/Green Deployment unterstützen, die Rückkehr zu einer Vorgängerversion (oder auch zu einer beliebigen Version), Canary Upgrades, Prometheus-Metriken und so weiter. Software-Tools wie etwa ArgoCD, Spinnaker und JenkinsX gehören dazu. Weiterführende Informationen zu ArgoCD und warum wir uns entschieden haben, es als Teil unseres Managed GKE-Produkts anzubieten, finden Sie in unserem Engineering Logbook.

Und was ist mit der Plattform?

Es sollte nun leicht zu verstehen sein, wie diese Modelle dazu beitragen, die Angst rund um Deployments zu vermindern. Was könnte das Vertrauen in einen Prozess mehr fördern, als ihn bereits selbst hunderte Male per Automatisierung durchgeführt zu haben, während gleichzeitig garantiert wird, dass zu jeder Zeit zu einer früheren Version zurück gekehrt werden kann? Allerdings ist Ihnen vermutlich beim Lesen auch klar geworden, dass Sie möglicherweise neue Kompetenzen benötigen, um den DevOps-Ansatz in vollem Umfang für sich nutzen zu können. Mittlerweile wird Container-Technologie zwar zu 76% auf dem Schweizer Markt verwendet (“VSHN DevOps in der Schweiz”-Report 2020). Unsere Erfahrung zeigt aber, dass die Komplexität, die sich durch die Nutzung dieser Technologien ergibt, immer noch eine der schwierigsten Hürden für die Einführung ist. Es ist daher sehr zu empfehlen, eine Kooperation mit einem Partner einzugehen, der die zugrundeliegende Plattform managen kann, Ihnen genau die Tools zur Verfügung stellt, die Sie zur Implementierung dieser Modelle brauchen, und mit Ihnen zusammen die Cloud-native Architektur für Ihre Applikation erarbeitet. Das Managed GKE-Produkt von nine umfasst alle DevOps- und GitOps-Tools, die Ihnen dabei helfen, schneller auf Cloud-native Technologien umzusteigen.

PS: Wenn Sie interessiert an weiteren Unterlagen zu den Grundlagen oder der Implementierung der Container-Technologie sind empfehlen wir Ihnen unsere Wissensseite rund um die Container-Technologie.