Auf dem Weg zum Servercluster – Datenbank-Containerisierung

Teil 1: Die Anforderung
Teil 2: Die Ressourcen
Teil 3: Die Absicherung
Teil 4: Das Dateisystem
Teil 5: Datenbank-Containerisierung
Teil 6: Verschlüsselung

Music2Web.de benötigt neben PHP noch einen Webserver und eine MySQL-Datenbank.
Das Ziel ist es Music2Web.de so sicher, wie möglich zu hosten. Ein weiterer Schritt in Richtung Sicherheit ist Prozessisolierung. Dabei werden die Prozesse in eine eigene Umgebung gepackt. Kommt nun ein Angreifer sieht er nur diese Umgebung und nicht das komplette System. Natürlich kann ein Angreifer auch aus so einer Umgebung in das Host-System ausbrechen, es ist aber ungleich schwerer, als wenn er über ein Einfallstor in einem der benutzten Programme direkt in das Host-System kommt.
Modernerweise benutzt man Container. Und auch wenn es ein Servercluster ist und auch wenn hierfür Kubernetes derzeit das Non-Plus-Ultra ist. In Kubernetes arbeite ich mich gerade erst ein. Deswegen benutze ich erstmal Docker und da die Applikation mit allem, was dazu gehört auf allen Nodes einigermaßen gleich aussieht verpacke ich alles schön in eine docker-compose.yml und kann somit alle Programmteile quasi gleichzeitig auf dem Server hochfahren. Praktisch!

Aber für was habe ich mich nun entschieden. Wie gesagt: Die Hauptbestandteile sind neben dem Programmcode von Music2Web.de noch PHP, ein Webserver, Certbot für das Ausstellen von LetsEncrypt-Zertifikaten und eine MySQL-Datenbank.
Gerade bei letzterer wird es interessant, weswegen ich hier nur auf die Datenbankkonfiguration eingehen werde und nicht auf die restlichen Dinge. Nachzulesen, wie man Docker mit PHP und einem Webserver verwendet kann man beispielsweise hier und hier. Mittlerweile gibt es eine Hülle und Fülle an MySQL-kompatiblen Datenbanken und wir erinnern uns an die Anforderung. Skalierbar und replizierbar soll die Datenbank sein. Damit sind die Anforderungen eng umrissen.

Im Rennen waren MySQL Cluster, die Spider Storage Engine für MariaDB, Vitess und Pingcap TiDB.

1. MySQL Cluster
   Diese Software war quasi einer der Hauptkandidaten. Der Vorteil ist, es kommt von MySQL selber, ist stark verbreitet und gut dokumentiert. Einzig und allein mit einem verteilten Setup unter Docker gibt es noch nicht so viele Erfahrungswerte und im Endeffekt hat es dann auch nach etlichem Rumexperimentieren nicht funktioniert. Ein weiteres Problem ist die Anzahl der maximalen Nodes. Diese ist für die Data Nodes auf 48 begrenzt. Nicht, dass diese Zahl jemals erreicht wird, aber theoretisch kann alles passieren. Außerdem lässt sich die Datenbank nicht gut in einem im Dockerfile vorgegebenen Benutzer ohne Root-Rechte betreiben.
2. Spider Storage Engine
   Die Spider Storage Engine für MariaDB bietet leider nur Sharding auf Tabellenebene. Eine Tabelle kann auf Server A sein, eine zweite Tabelle auf Server B und die Storage Engine bringt das dann zusammen als würde man auf nur eine Instanz und nicht auf zwei Instanzen zugreifen.
   Das Problem hierbei ist die Skalierung. Platzt eine Tabelle aus den Servernähten war es das. Außerdem ist damit das Replizierungssystem nicht gelöst.
3. Vitess
   Vitess ist eine so genannte NewSQL-Datenbank. Die Datenbank übernimmt das Sharding der Daten und auch die Replizierung der Daten über einen Topology-Server. Die Speicherung der Daten findet dann in MySQL-Servern statt, die über ein Vitess-Programm VTTablet angesprochen werden. Die Applikation greift über ein VTGate auf die Datenbank zu. Tatsächlich entschied sich das Rennen zwischen Vitess und Pingcap TiDB. Die Dokumentation rund um Pingcap TiDB war zum Schluss hin einfach besser.
4. Pingcap TiDB
   Auch die TiDB von Pingcap ist eine NewSQL-Datenbank. Die Applikation greift über TiDB-Server auf den Datenbank-Cluster zu. Die Metadaten liegen auf PD-Servern, die dafür zuständig sind zu wissen, wo welche Daten liegen und die Daten auf die Storage-Server zu verteilen. Die Storage-Server sind TiKV-Server. Wobei das KV für einen Key-Value-Store steht. TiDB gibt es übrigens auch schon Kubernetes-Ready. Wenn also irgendwann mal der nächste Schritt folgt ist es vermutlich ein leichtes Music2Web.de von Docker auf Kubernetes umzuziehen.
   Rund um TiDB gibt es eine aktive Slack-Community und viel Dokumentation.

Tatsächlich wird einem vom Betreiben von TiDB mit Docker-Compose abgeraten. Möglich ist es aber dennoch, wenn auch dieser Weg so gut wie gar nicht dokumentiert ist, gibt es aber dennoch Single-Node-Beispiele, die auch in einer verteilten Umgebung gut funktionieren.

Und so sieht das Docker-Compose beispielhaft für einen Server aus für die Datenbank (Adressen und Ordner sind geändert). Für die anderen Server müssen einfach bloß die serverspezifischen Einstellungen geändert werden:

pd:
image: pingcap/pd:latest
ports:
– „2379:2379“
– „2380:2380“
volumes:
– ./db/config/pd.toml:/pd.toml:ro
– ./db/pddata:/data
– ./db/pdlogs:/logs
– /etc/localtime:/etc/localtime:ro
– /etc/timezone:/etc/timezone:ro
command:
– –name=server1
– –client-urls=http://0.0.0.0:2379
– –advertise-client-urls=http://stage1.eastus.cloudapp.azure.com:2379
– –peer-urls=http://0.0.0.0:2380
– –advertise-peer-urls=http://server1.music2web.de:2380
– –initial-cluster=server1=http://server1.music2web.de:2380,server2=http://server2.music2web.de:2380,server3=http://server3.music2web.de:2380,server4=http://server4.music2web.de:2380
– –data-dir=/data/pd
– –config=/pd.toml
– –log-file=/logs/pd.log
networks:
music2web:
ipv4_address: 10.1.0.2
restart: always
tikv:
image: pingcap/tikv:latest
ports:
– „20160:20160“
volumes:
– ./db/config/tikv.toml:/tikv.toml:ro
– ./db/tikvdata:/data
– ./db/tikvlogs:/logs
– /etc/localtime:/etc/localtime:ro
– /etc/timezone:/etc/timezone:ro
command:
– –addr=0.0.0.0:20160
– –advertise-addr=server1.music2web.de:20160
– –data-dir=/data/tikv
– –pd=server1.music2web.de:2379,server2.music2web.de:2379,server3.music2web.de:2379,server4.music2web.de:2379
– –config=/tikv.toml
– –log-file=/logs/tikv.log
depends_on:
– „pd“
networks:
music2web:
ipv4_address: 10.1.0.3
restart: always
tidb:
image: pingcap/tidb:latest
ports:
– „4000:4000“
– „10080:10080“
volumes:
– ./db/config/tidb.toml:/tidb.toml:ro
– ./db/tidblogs:/logs
– /etc/localtime:/etc/localtime:ro
– /etc/timezone:/etc/timezone:ro
command:
– –store=tikv
– –path=server1.music2web.de:2379,server2.music2web.de:2379,server3.music2web.de:2379,server4.music2web.de:2379
– –config=/tidb.toml
– –log-file=/logs/tidb.log
– –advertise-address=server1.music2web.de
depends_on:
– „tikv“
networks:
music2web:
ipv4_address: 10.1.0.4
restart: always

In der Applikation selber wird der SQL-Server aufgerufen über den Server tidb mit dem Port 4000.

Foto: Bethany Drouin / Pixabay