Warum Container-Technologie in den meisten Fällen die klassische Cloud-Infrastruktur schlägt

Die Ausgangssituation in Unternehmen ist oft eine klassische Infrastruktur: Das Publizieren einer Website oder das Bereitstellen von Cloud-Anwendungen gelingt in den meisten Unternehmen mit einem Server, auf dem ein Webserver, ein Applikationsserver plus einer Datenbank läuft (3-Tier Architektur). Auf dem Server befindet sich ein Bereich, wo die Daten liegen. Das alles zusammen ist ein Cloudserver. In der Regel funktionieren Cloud-Server sehr gut und bieten viele Vorteile im Vergleich zu on-premise Varianten. Allerdings sind in regelmäßigen Abständen immer wieder Wartungsaufgaben nötig wie z.B. den Webserver zu aktualisieren. Upgrades können zu Inkompatibilitäten mit der Anwendung führen und damit den Betrieb stören.

Wie funktioniert die Containertechnologie im Detail?

Falls Sie Ihre Anwendungen mittels Containern hosten möchten, müssen Sie zuerst die notwendigen Container provisionieren und die Storage anschließend damit verbinden. Im Grunde ist das Setup gleich wie bei einer klassischen Infrastruktur. Allerdings kommen dazu noch ein dynamischer Loadbalancer und das SSL-Zertifikat.

Einfachere Skalierung mit Containern

In dieser, einfachen Dimensionierung funktionieren beide Varianten sehr gut. Ein entscheidender Unterschied entsteht aber, wenn es um Skalierung geht. In einer herkömmlichen Cloud Umgebung bewerkstelligen Sie eine Ressourcenerweiterung durch das Aufsetzen eines weiteren Cloudservers. Auch hier müssen die Daten im zweiten Webserver verfügbar sein (eine Lösung für den Datenabgleich muss installiert werden) und der Zugriff auf die Datenbank von jedem Cloud Server aus ermöglicht werden. Damit haben Sie Ihr System um einen weiteren Webserver skaliert aber nicht Ihre Datenbank. Im Vergleich dazu geht die Skalierung mit Containern denkbar einfach und schnell: Sie duplizieren die Container und haben damit Ihre Ressourcen verdoppelt. Durch das eingebaute Loadbalancing braucht es keine weiteren Eingriffe, um die zusätzlichen Container in Betrieb zu nenhmen. So skaliert das Gesamtsystem nahezu linear nach oben. Dieser Vorgang kann auch automatisiert erfolgen, wenn das Monitoring erkennt, dass die Last steigt und die bestehenden Container zu sehr ausgelastet sind.

Schnelle Upgrades ohne Komplikationen

Bei einem normalen Cloudserver ist es ab und zu nötig Updates einzuspielen. Im Normalfall läuft das unproblematisch ab, dauert aber lange. Wollen Sie einen Webserver updaten, dann ziehen Sie einen Snapshot vom Cloudserver. Ist der Server erfolgreich upgedatet, kann der Snapshot gelöscht werden. In vielen Unternehmen funktioniert das händisch, in manchen automatisiert. Oft wird für diesen Prozess ein ganzer Arbeitstag benötigt, um testen zu können, ob die neue Version funktioniert. Das ist der Grund, warum Updates unnötig verzögert werden und zu selten stattfinden, was wiederum die Sicherheit gefährden kann.

Im Containerbereich geschieht eine Aktualisierung auf eine neue Version auf Knopfdruck. Sie müssen lediglich ein Re-Deploy initiieren. Die neuersten Container-Images werden dann hinuntergeladen, die alten gestoppt und die neuen hochgefahren. Das dauert in der Regel ein paar Minuten. Anschließend erfolgt ein Test. Wenn dieser vollzogen ist, wird der Deploy bestätigt oder Sie können ein Roll-Back (löschen der neuen Container und hochfahren der alten) machen. Dadurch besteht kein Risiko, denn jede Version ist sofort wieder herstellbar. Dieser Prozess ist automatisierbar und kann wöchentlich stattfinden, ohne dass dafür extra Arbeitszeit bereitgestellt werden muss. Damit sind auch immer die neuersten Security-Patches vorhanden.

Cloud-unabhängig durch .yaml-Datei

Das Setup des Containers ist in einer .yaml-Datei beschrieben. Darin sind alle wichtigen Infos enthalten, wie z.B. wie viele Container es gibt, welche Storage gemappt wird, welche Verlinkungen es zur Datenbank gibt usw. Mit dieser Datei können Sie genau dieses Setup jederzeit bei einem anderen Anbieter von Kubernetes in Minuten duplizieren. Anschließend werden die Daten migriert. Ein weiterer Vorteil ist die saubere Trennung der Systeme: Ein Container liefert die Website aus und andere Container dienen z.B. als Datenbank.

Container erfordern Umdenken bei der Datenanalyse

Container sind vergänglich. Im Vergleich zu Webservern, wo Daten für immer bestehen bleiben bis sie aktiv gelöscht werden, können Container jederzeit destroyed werden. Damit werden die Daten gelöscht, außer Sie binden eine Storage in den Container ein. Deshalb ist die Entscheidung wichtig, welche Daten persistent sind und welche Daten flüchtig. Um das feststellen zu können, analysieren wir zu Beginn eines Projekts die Daten.

Ein weiterer entscheidender Punkt sind die benötigten Images. Viele davon sind schon vorhanden, es gibt aber auch Möglichkeiten, welche zu bauen. Wir erstellen auf Basis von Standardimages oft für Kunden angepasste Images. Das ist leicht möglich durch Abänderungen und verfügt über einen großen Vorteil: Wenn der Hersteller des Images seine Version aktualisiert und Sie Ihr eigenes Image neu bilden, dann erhalten Sie automatisch die neue Version, auf die die eigenen Änderungen angewendet werden.

Geringer Speicherverbrauch mit Containern

Für Containertechnologie wird wesentlich weniger Speicher benötigt als in klassischer Infrastruktur. Denn bei Cloudservern wird das Betriebssystem direkt am Server installiert oder setzt auf den Hypervisor auf, was hohe RAM und CPU Kapazitäten benötigt. Jede Anwendung kann so auf einem eigenen Betriebssystem aufsetzen.

Ein weiterer Vorteil der Containertechnologie ist, dass wesentlich weniger Daten gesichert werden müssen und damit auch viel weniger Speicher und Zeit benötigt wird. Beim Cloudserver muss der gesamte Server inkl. Betriebssystem, aller Daten und Prozesse gespeichert werden. Das braucht sehr viel RAM und CPU. Schnell kommen dann 100 GB zusammen wovon ungefähr 1 GB Nutzdaten sind. Im Vergleich dazu werden in diesem Beispiel bei einem Container lediglich 1 GB Nutzdaten gespeichert.

Wir verwenden ein All-Flash-System von Pure Storage zur Bereitstellung der Daten. Das ist ein absolutes High-End-Produkt mit dem Sie hohe Datendurchsätze bei geringen Latenzzeiten bekommen. Für Backups bei klassischen Cloudservern als auch bei der Sicherung der externen Datenbanken, die mit den Containern verbunden sind, setzen wir auf Rubrik.
Container müssen nicht gebackuped werden. Die können Sie jederzeit zerstören und neu anlegen. Durch die .yaml-Datei ist die Konfiguration der Infrastruktur beschrieben und genau gleich wieder herstellbar, mit den Pfaden zur Storage sind die Daten sofort verfügbar. Die Konfiguration an sich wird in Kubernetes gespeichert und kann exportiert werden.

Aufbau eines Kubernetes Clusters

Ein Cluster kann z.B. aus vier (Worker) Nodes bestehen auf denen hunderte Container laufen. Jeder Node entspricht einem Cloud- oder Root- Server. Wichtig ist ein Zugang vom Cluster zu Daten auf einer shared Storage. Fällt ein Node aus, dann werden automatisch die ausgefallenen Container auf einem anderen Node wieder hochgefahren. Die Auswirkungen auf den Betrieb sind dabei minimal.
Auch virtuelle Maschinen können geclustert werden. Die Wiederherstellung nach einem Ausfall ist aber komplexer. Beispielsweise können nach dem Ausfall eines Cloud-Servers in einem Cluster die Daten auf einem zweiten, physischen Server wieder hochgefahren werden. Das entspricht einem Reboot und dauert je nach Technologie entsprechend lange.

Sehr schnelles, sicheres Deployment

Durch Standardisierung und Automatisierung sind Continues Integration/Continues Delivery/Continues Deployment (CI/CD) keine unerreichbaren Ziele mehr. Änderungen können dadurch sehr schnell implementiert, getestet und ausgerollt werden. CI/CD sind nicht nur sehr Ressourcen-schonend, sondern auch sehr sicher. Der Ablauf ist klar strukturiert und in jeder Phase konfliktfrei reversibel. Zu Beginn pflegt der Entwickler die Änderungen in die Sourcecode -Verwaltung ein (commit). Anschließend werden automatisch Prozesse getriggert wie z.B. Build, Test, Deploy. Das vollautomatische Deploy kann weitere Prozesse wie z.B. Redeploy anstoßen. Dadurch werden Container automatisch aktualisiert. Damit kann durch das alleinige Einpflegen einer Änderung vollautomatisch eine Änderung im Produktivsystem erreicht werden. Auch bei herkömmlichen Cloudservern ist es möglich zu automatisieren, allerdings ist der Prozess viel aufwendiger und die Änderungen sind nicht so leicht rückgängig zu machen. Damit ist eine aufwendige und zeitraubende Fehlersuche in vielen Fällen vorprogrammiert.

Warum stellt nicht jedes Unternehmen auf Container um?

Aus unserer Erfahrung heraus können wir sagen, dass Containertechnologie so viele Vorteile besitzt, dass sie für unsere Kunden meist die bevorzugte Variante ist. Warum nicht alle Unternehmen gleich auf Container umsteigen, lässt sich hauptsächlich mit einem Mangel an Know-How und generell mit Zeit- und Personalmangel erklären. Um sich mit neuen Technologien vertraut machen zu können, braucht man ausreichend zeitliche und personelle Ressourcen. Diese sind in vielen Unternehmen Mangelware. Deshalb haben wir uns dazu entschlossen, Container as a Service anzubieten. Unsere Kunden können damit auf ein leistbares, schnell umsetzbares Service zurückgreifen und vom Know-How Transfer profitieren.

Mehr Informationen zu Containern und Kubernetes finden Sie hier https://timewarp.at/kubernetes-as-a-service/

Für persönliche Beratung steht Ihnen Rainer Schneemayer gerne zur Verfügung rs@timewarp.at.