Sie sind hier:
Cloud, Allgemein
Container Hosting erfreut sich immer größerer Beliebtheit. Es ist einfach und schützt vor Fehlern. Die herkömmliche Variante zum Hosten von Anwendungen und Websites ist aber in Unternehmen oft eine klassische Infrastruktur. Dabei kommt ein Cloud Server zum Einsatz. Auf dem Server wird ein Webserver bzw. ein Applikationsserver mit einer Datenbank (3-Tier Architektur) betrieben. In der Regel funktionieren Cloud-Server sehr gut und bieten viele Vorteile im Vergleich zu on-premise Servern. Allerdings sind Cloud Server auch nicht wartungsfrei und in regelmäßigen Abständen müssen z.B. Updates eingespielt werden. Das ist logischerweise eine häufige Quelle von Fehlern und Problemen.
Falls Sie Ihre Anwendungen mittels Containern Hosting betreiben möchten, müssen Sie zuerst die dazu notwendigen Container provisionieren. Anschließend wird die Storage damit verbunden. Im Grunde ist das Setup gleich wie bei einer klassischen Infrastruktur. Allerdings kommen dazu noch ein dynamischer Loadbalancer und ein SSL-Zertifikat.
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 können Sie eine Ressourcenerweiterung durch das Aufsetzen eines weiteren Cloudservers erreichen. Auch hier müssen die Daten am 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 Container Hosting 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 nehmen. 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.
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.
Beim Container Hosting geschieht eine Aktualisierung auf eine neue Version auf Knopfdruck. Sie müssen lediglich ein Re-Deploy initiieren. Die neuersten Container-Images werden dann hinunter geladen, 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 kann sofort wieder hergestellt werden. 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.
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 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.
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 sie kann genau gleich wieder hergestellt werden. Mit den Pfaden zur Storage sind die Daten sofort verfügbar. Die Konfiguration an sich wird in Kubernetes gespeichert und kann exportiert werden.
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.
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.
Aus unserer Erfahrung heraus können wir sagen, dass Container Hosting so viele Vorteile besitzt, dass es 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.
Falls Sie Fragen haben, wenden Sie sich bitte an sales@timewarp.at oder finden Sie mehr Information unter https://timewarp.at/docker/ und https://timewarp.at/kubernetes-as-a-service/
TIMEWARP Newsletter
Möchten Sie über Neuigkeiten immer gleich informiert werden? Dann melden Sie sich hier zum Newsletter an:
