Seit vielen Jahren entwickle und betreue ich Microservice Umgebungen beim Kunden vor Ort, wie auch in eigenen Umgebungen. Die Bereitstellung von Server und Services muss innerhalb von wenigen Minuten erfolgen um auf Anfragen schnell reagieren zu koennen. Dieses Dokument soll einen kleinen Ueberblick ueber unsere Tools aber auch die Verfahren geben.
Server stelleni ich mit Hilfe von terraform1 zur Verfuegung. Terraform ist ein cli Tool welches Server unter anderen2 in AWS, Azure, GCloud aber auch in VMWare VSphere3 aufbauen kann. Die Server beschreiben wir hierbei jeweils in Gruppen. D.h. alle Datenbank Server (oder Cluster Nodes, oder WebServer) sehen innerhalb der Gruppen von der Hardware Konfiguration gleich aus. Neben der Beschreibung der Server, wird hier ebenfalls Netzwerk, Storage und DNS konfiguriert.
Nach der Bereitstellung des Servers erfolgt die Vorkonfiguration nach einem fuer alle Server gueltigen Standard. Die Konfiguration erfolgt hierbei ueber ansible4. Nach der Vorkonfiguration startet die Installation und Konfiguration der oder des Services. Auch dies wird jeweils Standartisiert ueber Ansible durchgefuehrt.
Jede Server Konfiguration, jedes ansible und terraform Script, jede Aenderung eines Scriptes liegt in GIT um zu tracken wer was wann getan hat und um zu schauen wie die aktuelle gueltige Konfiguration aussehen soll.
Jedes Automatisierungsscript, egal ob via ansible oder terraform ist re-deploy faehig ohne den schon bestehenden und laufenden Service zu behindern. D.h. wir fuehren z.B. jedes ansible Script regelmaessig automatisiert aus um sicherzustellen das die Services und Server so aussehen wie im auslieferungszustand. Die Daten der Services werden dabei nicht angefasst oder veraendert. Jede manuell gemachte Aenderung einer Applikation wird hierbei jedoch ggfs. entfernt. Dies ist ein von mir gewolltes Verhalten, da jede Aenderung im Ansible Script enthalten sein soll.
Wir patchen keine Server! Wir bauen diese immer neu auf um immer ein sauberes System zu verfuegung zu haben. Hierbei wird wie folgt vorgegangen; in terraform geben wir einem Server oder einer ganzen Server Gruppe eine neues aktualisiertes Betriebssystem Image. Nach starten von terraform prueft dieser die bestehende Infrastuktur, erkennt die Differenz des Betriebssystems, zerstoert den betroffenden Server und baut diesen anschliessend neu auf. Das Datastorage wird nicht zerstoert und wird von terraform nach dem erfolgten Neuaufbau wieder an den Server gehaengt. Anschliessend erfolgen die Punkte aus der “Server Bereitstellung”. Hierbei erkennen die ansible Scripte jedoch das schon vorhandensein von Daten und ueberspringt die ggfs. initiale Erstellung dieser. Eine Downtime dauert (je nach Provider) und Aufwendigkeit der Installation ab 10 Minuten.
Hierbei unterscheiden wir Legacy, Container und CloudNative Systeme.
Legacy Systeme sind Services die weder als Container laufen sollten noch CloudNative sind. Diese Services werden ueber ansible aktualisiert. Hierbei kann entweder der Server ueber den Punkt “Server Aktualisierung” neu Aufgebaut werden oder man entscheidet sich lediglich fuer eine aktualisierung des Services. Dies erfolgt ueber ansible.
Container stellen eine sehr saubere Trennung zwischen Service und Server dar. Eine Aktualisierung des im Container befindlichen Services erfolgt ueber ein redeploy des Containers. Die Downtime liegt hierbei im Sekunden Bereich (sofern der Service im Container nicht erst automatisch gebaut wird). Die Daten des Services liegen in einem persistenten externen Storage und gehen nicht verloren. Das persistente Storage ist hierbei nicht abhaengig vom Server und kann an jedem anderen fuer Container vorbereiteten Server gemountet werden. Dieses vorgehen kann die Downtime des Services bei einer Server Aktualisierung erheblich reduzieren.
CloudNative Services laufen bei mir in einem Apache Mesos5 Ressourcen Cluster. Mesos stellt den unterschiedlichsten Services Ressourcen wie z.B. Storage, Netzwerk, CPU, RAM und sogar GPU zur Verfuegung. Hierbei spielt es keine Rolle ob es ein Container, ein Script (z.B. Python) oder eine komplexe Software wie elasticsearch ist. Mesos ist fuer grosse und komplexe Service Umgebungen ausgelegt und kann ueber mehrere globale Rechenzentren verteilt werden.
Eine Aktualisierung eines CloudNative Services erfolgt durch anpassen der Versionnummer und restarten des Services. Dies kann automatisch wie auch manuell erfolgen. Der Restart erfolgt dabei nach dem Blue/Green Prinzip. D.h. der alte Service wird erst beendet wenn der neue Service funktionsfaehig ist. Eine Downtime erfolgt dabei nicht.
Da ich die meisten meiner Services in Mesos5 betreiben, kann ich ganze RZ Umgebungen automatisiert aktualisieren oder re-deployen. Durch das Blue/Green Verfahren erfolgt dies nahezu ohne Downtime. Hierbei bauen wir parallel zur bestehenden Umgebung eine neue auf. Sind alle Komponenten (Server und Mesos Services) funktionsfaehig, werden die Services aus der alten Umgebebung in der neuen gestartet ohne diese in der alten Umgebung zu deaktivieren. Laufen auch hier alle Services, wird im Loadbalancer die neue Umgebung aktiviert. Sobald es keinen Traffic mehr auf die alte Umgebung gibt, wird diese beendet.
Unsere Server sind immer aktuell, unsere Services sind immer auf den neusten Stand, trotzdem kann ein Einbruch immer stattfinden. Hierbei ist die Container Technologie von grossem Vorteil gegenueber Legazy Systemen. Der Angreifer befindet sich im Container und nicht direkt auf dem Server, bei einem Container Neustart ist dieser weg und eine Aktualisierung des Containers ist in sekunden erledigt. Aber, es kommt hier sehr auf die Entwicklung des Containers (nicht nur des Services im Container) und der Umgebung an. Selbst viele offizielle Container Images sind unsicher aufgebaut und ermoeglichen ein Hijacking des Hostsystems. Wir haben viele schlechte Erfahrung mit Freelancern (Container sind hip also muss das im CV stehen) aber auch Firmen gemacht, die Container missverstanden oder nie richtige Produktive Umgebung damit betrieben oder betreut haben. Die Qualitaet eines Dienstleisters erkennt man nicht wenn selber kein tieferes Verstaendnis der Thematik vorhanden ist.
Selbstverstaendlich kann das Vorgehen weder das Menschliche- noch das Technische-Versagen unterbinden. Daher bilde ich viele Vorgaenge in Pipelines ab (Pipelines kennt man aus der Softwareentwicklung, man kann hier jedoch auch viele Administrative Taetigkeiten abbilden) um das “Vergessen” von Scripten oder das “Vergessen” des Nachpruefens auszuschliessen. Trotzdem ist nichts perfekt. So koennen bei Cloud Anbietern wie AWS und Azure auch schon mal keine Ressourcen zur Verfuegung stehen. Oder VSphere hat gerade API Probleme, oder in ansible sind Funktionen entfallen dessen Deprecated Meldung man die Monate zuvor ignoriert hat. Auch kann es vorkommen das ein Linux in einer neueren Version bestimmte Commands nicht mehr per default ausliefert. D.h. ein pruefen der Scripte, ein pruefen des Vorgehens ist unerlaesslich. Daher stellt diese Form von automatisierung selten ein Arbeitsverlust dar. Diese verlagert sich hauptsaechlich. Der Vorteil liegt trotzdem auf der Hand. Alle Server sind sauber, standartisiert, immer Aktuell und trotzdem dem Kunden gegenueber hoch flexibel. Der Support Richtung Endkunden reduziert sich auf ein minimum die Downtime wird minimiert. Wir haben kein Wildwuchs und koennen sehr schnell neue Umgebungen ausrollen oder schon bestehenden erweitern.
Bei allem muss man aber Fair sein. Ich bin ein einzel Personen Unternehmen. Meine “gewachsene” Umgebung konnte ich vor ein paar Jahren sehr schnell auf die neuen Verfahren umstellen. Daher ist es wichtig sich einen externen Partner mit entsprechenden Know-How und Erfahrungen zu suchen um gemeinsam eine langsame Migration zu starten.