Klassisches Deployment vs. Container Deployment

Tom Feb 19, 2018
Klassisches Deployment vs. Container Deployment

Die klassische Deployment-Methode ist ein Risiko- und Change Management-Prozess, bei dem der Erfolg daran gemessen wird, ob Service und Stabilität ohne Unterbrechungen gewährleistet sind. Der genaue Prozess kann verschiedenartig sein, aber die meisten verlaufen folgendermaßen oder ähnlich.

  • Schlimmstenfalls → Das neue Feature wird fertiggestellt, der Code an das operative Team übergeben, man hofft darauf, dass das Change Board die Genehmigung erteilt und dass das Deployment durch das Operations Team erfolgreich verläuft.
  • Besser → Es gibt einen manuellen Change-Prozess, bei dem Sie den Code auf den Server hochladen und zusätzlich ein paar Upgrade-Schritte erledigen.
  • Bestenfalls → Sie arbeiten in einer virtuellen Maschine, eine CI/CD Pipeline liefert Ihren Code an einen Server, Sie ändern Einstellungen in Ihren Server Management Tools, loggen sich per SSH ein und starten die Anwendung neu oder erledigen ggf. andere manuelle Schritte.

Die bekannte Deployment-Methode

Vermutlich ist die Anwendung fest an ihre Umgebung gebunden. Doch die Umgebung ist auch leicht veränderbar, da Personen SSH Zugang gewährt wird. Darüber hinaus sieht diese Umgebung vermutlich nicht so wie die Entwicklungsumgebung aus und möglicherweise haben Ihre Entwickler nicht einmal Kontrolle darüber, wie die Live-Umgebung sich verhält. Zudem ist es sehr wahrscheinlich, dass Deployments mehrere manuelle Prozesse beinhalten, die, um erfolgreich zu sein, auf ganz bestimmte Weise erfolgen müssen. All diese Faktoren erschweren den Change erheblich und aufgrund der hohen Kosten werden das Experimentieren und die Kreativität unterbunden.

Da ist es wenig erstaunlich, dass der Deployment-Prozess als hohes Risiko angesehen wird. Es gibt zahlreiche Stellen, an denen nicht-nachvollziehbare Änderungen auftreten können. Die oben beschriebenen Prozesse sollten eigentlich Risiken minimieren. In Tat und Wahrheit rufen Sie Angst vor neuen Releases hervor und stehen dem Erfolg im Weg. Deswegen werden Change Management sowie das Ausbleiben von Serviceausfällen als die wichtigsten Erfolgsfaktoren angesehen. Bei diesem Szenario ist es extrem schwierig, Change zu ermöglichen, aber sehr leicht möglich, alles kaputt zu machen!

Wie man es vereinfachen kann

Containerisierte Deployment-Strategien setzen hingegen auf Geschwindigkeit als Hauptkennzahl. Es geht darum, in möglichst kurzer Zeit einen möglichst hohen Mehrwert für die Stakeholder zu schaffen. Hierbei gilt es, die vorhandenen Mauern zwischen Entwicklung und Operations einzureißen, damit Entwickler selbst (kontrollierte) Änderungen an der Infrastruktur vornehmen können. Dafür werden einige neue Design- und Entwicklungs-Konzepte benötigt.

In der Container-Technologie verwalten Sie Ihre Dienste nie per SSH. Stattdessen konfigurieren Sie ihre Umgebungen mit Konfigurationsdateien und deployen Gruppen von Diensten über eine Deployment Pipeline, getriggert von Ihrem Versionskontrollsystem. Der schnelle und automatisierte Prozess brennt das Deployment-Konzept in das „Herz“ des Anwendungsdesigns, dies bedarf aber auch einer komplett neuen Denkweise.

Infrastructure as a code

Indem man die Infrastruktur als etwas ansieht, das versioniert, streng abgegrenzt und deploybar ist, sind Änderungskontrollen und Rollbacks leicht durchführbar und Anwendungen laufen fast überall. Das Ziel ist, dadurch eine Berechenbarkeit für Runtime-Umgebungen zu erlangen und instabilen Server-Setups vorzubeugen, indem man (virtuell) die gleiche Umgebung entwickelt, die man live ausrollt und die Umgebung nach und nach (täglich/stündlich) wieder aufbaut. Docker beispielsweise ermöglicht es, dass dieser Prozess extrem leichtgewichtig und flexibel ist, wobei die Zeit für den Aufbau im Vergleich zu virtuellen Maschinen (VM) erheblich verringert werden kann.

Gesamtverantwortung

Weil Container so leichtgewichtig, einfach zu entwickeln und auszurollen sind, können Sie das Single-Responsibility-Prinzip auf Ihre Applikationen ausweiten. Jeder Container ist für nur eine Aufgabe verantwortlich. Durch diese Unabhängigkeit können Sie zielgerichtet auf aktuelle Bedingungen eingehen und nach Bedarf skalieren - Sie müssen das System nur dort anpassen, wo es nötig ist.

Automatisierung ist der Schlüssel

Der gesamte Build-Prozess sollte automatisiert ablaufen, im Idealfall komplett ohne menschliches Zutun (in einer Produktionsumgebung kann jedoch ein manueller Auslöser sinnvoll sein). Jede Änderung an ihrem Source Code (oder Container) Repository sollte eine Reihe von automatischen Tests auslösen und ein Deployment auf eine Umgebung, die möglichst der Produktionsumgebung entspricht.

Somit wird klar, dass dies allein schon dazu beiträgt, Ängste abzubauen, die im Zusammenhang mit Deployments bestehen. Was könnte Ihnen mehr Sicherheit geben als die Tatsache, dass die notwendigen Schritte für den Deployment-Prozess zuvor schon hundertfach erfolgreich durchgeführt wurden?

Diese Automatisierung bringt weitere Vorteile mit sich - wenn korrekt angewendet, können sich Container eigenständig reparieren. Falls Ihr Container abstürzt, startet sofort eine neue Instanz. Das Skalieren ist einfach, da Container-Plattformen wie Kubernetes oder OpenShift bei Bedarf eine Auto-Skalierung zulassen, unveränderbare Runtime Images die Informationssicherheit unterstützen und vertrauliche Informationen zur Laufzeit in einem temporären Dateisystem untergebracht werden können.

Und was ist mit der Plattform?

All diese Ideen führen zu einer wichtigen neuen Problemdomäne...

  • ... Wie kann man eine Anwendung bauen oder eine existierende Anwendung anpassen, um diese für Container passend zu machen und um einfache Skalierung zu unterstützen?
  • ... Wie kann die Komplexität gesteuert werden?
  • ... Wer kümmert sich um die Systeme, die den Workflow rund um das Development unterstützen?

Laut der fünften, jährlich von RightScale durchgeführten Umfrage war mangelnde Erfahrung mit Abstand die größte (39 %) Herausforderung für Firmen, die derzeit noch nicht auf die Nutzung von Containern zurückgreifen. Es ist daher sehr wichtig, dass Sie mit einem Partner zusammenarbeiten, der Sie zu der für Sie idealen Anwendung führt, dabei sicherstellt, dass Ihre Anwendung problemlos läuft und eine persönliche Deployment-Strategie für Sie entwickelt.

Welchen Einfluss haben Docker und OpenShift auf Dev-Prozesse? Dies und mehr können Sie im neuen Whitepaper nachlesen.

Whitepaper Container-Virtualisierung und ihre Verwendung

Jetzt Whitepaper herunterladen