Portainer und VDC im Einsatz innerhalb der Cloud-Architektur

Im Beitrag zum cloudtec Plattform-Stack ging es um den Aufbau in Ebenen. Hier schauen wir uns die unterste davon an: die Infrastruktur, auf der sämtliche Applikationen laufen.

Die Basis ist virtualisiert. Ressourcen werden zusammengezogen und über ein Netzwerk gemeinsam genutzt, statt pro Projekt eine eigene Maschine hinzustellen. Darauf laufen Linux, Webserver, MariaDB und PHP, ergänzt um Dienste aus anderen Ökosystemen. Die Volltextsuche etwa bringt ihre eigene Java-Umgebung mit. Statt bei einem Hyperscaler einzumieten, betreiben wir eine private Cloud und packen die Applikationen in Docker-Container.

Was unter den Containern liegt

Die Hardware gehört nicht uns: Sie steht bei einem Schweizer Anbieter in einem Rechenzentrum in der Schweiz. Darauf läuft unser Virtual Data Center (VDC), aufgeteilt in virtuelle Maschinen, die wir selbst einrichten und betreiben. Wie viel Arbeitsspeicher, Prozessorleistung und Plattenplatz eine Plattform bekommt, ist damit eine Konfiguration und kein Hardwarekauf.

Die Grundlage des VDC bildet OpenNebula, eine Open-Source-Plattform für Cloud-Computing. Darin laufen die virtuellen Maschinen, überwiegend Linux, über ein virtuelles LAN verbunden und zusammen ein Docker Swarm.

Davor steht die Netzwerksicherheit: Firewall und Web Application Firewall prüfen jede Anfrage gegen die definierten Regeln, dazu kommen Netzwerksegmentierung und VPN-Zugänge für den Betrieb. Was durchkommt, übernimmt der Reverse Proxy und verbindet die Anfrage mit dem zuständigen Container, inklusive SSL-Terminierung und Lastverteilung, wenn eine Plattform auf mehreren Instanzen läuft.

Ein Container pro Projekt

Docker trennt die Applikation von der Infrastruktur. Eine Anwendung läuft damit überall gleich: auf dem Notebook der Entwicklerin, auf Staging und auf Produktion. Das Betriebssystem wird containerisiert und abstrahiert, statt für jedes Projekt neu eingerichtet zu werden.

Ein Container bündelt die Softwareprozesse einer Anwendung: Webserver, Datenbank und die Programmiersprache. Bereitgestellt wird er über ein Image, das alle ausführbaren Bestandteile mitbringt.

Jedes Kundenprojekt hat mindestens einen eigenen Container. Die Daten sind dadurch isoliert und segmentiert, und die beteiligten Softwareteile sehen nur ihre eigene Applikation. Hilfsdienste wie Virenscanner oder PDF-Indexierung stellen wir ebenfalls als Container bereit; sie sprechen über virtuelle Netzwerke lokal mit den Projekt-Containern. Diese Netzwerke bestimmen auch, welcher Dienst welchen überhaupt sieht.

Die Zuteilung der Container zu den Hosts übernimmt Docker Swarm. Fällt ein Host aus, startet der Container automatisch auf einem anderen. Verwaltet wird das Ganze mit Portainer: Container zentral konfigurieren, orchestrieren, absichern und im Blick behalten, mit einer Weboberfläche statt ausschliesslich über die Kommandozeile.

Warum eigene Cloud statt fertiger Baukasten

Grosse Anbieter liefern fertige Bausteine, geben aber Release-Zyklen und Richtlinien vor. Bei unserer eigenen Architektur entscheiden wir, wann was aktualisiert wird, und können sie anpassen, wenn ein Projekt es verlangt. Durch die Containerisierung kommt ein neuer Dienst allen Projekten zugute, und Docker Swarm hält den Betrieb auch dann aufrecht, wenn ein Host wegbricht.

Unabhängig von unserem Aufbau gilt für eine private Cloud generell:

• volle Kontrolle über Zugriffsrechte
• Trennung von Ressourcen und Speicherort
• hoher Sicherheitsstandard inklusive Verschlüsselung
• hohe Bandbreite durch exklusiven Zugriff
• flexibel skalierbare Ressourcen

Der Preis dafür ist, dass wir den Betrieb selbst verantworten. Dafür baut und betreibt dasselbe Team die Plattform: bei einer Störung gibt es keine Ticket-Kette über drei Anbieter.