Self-Hosting – Ideen und Möglichkeiten

Gefühlt hat der Begriff „Self-Hosting“ in den letzten paar Wochen wieder einen gewaltigen Boost bekommen. Ich will hier mal ein paar sehr generische Tipps und Ideen aufschreiben, wie man sein „Self-Hosting-Game“ verbessern könnte. Das ganze ist subjektiv und funktioniert für mich so gut. Für jemand anderen ist vielleicht ein anderer Ansatz besser…

Früher™ habe ich Dienste nativ auf meinen Rechnern (meist vHosts oder ein Raspberry Pi) installiert – also z. B. einen LAMP-Stack (Linux/Apache/MySQL/PHP) aufgebaut und darauf etwa Nextcloud oder WordPress installiert. Das ist relativ aufwändig und hat ein paar Nachteile, wie etwa die etwas eingeschränkte Portabilität der Installation oder die etwas erschwerte Sicherung von Konfiguration und Daten. Heute nutze ich stattdessen Docker und einen Reverse Proxy.

Docker ist — grob gesagt — ein Tool, das Dienste in sogenannten Containern (denke: „leichtgewichtige virtuelle Maschine“, auch wenn das technisch gesehen nicht ganz korrekt ist) kapseln kann. Anstatt z. B. MySQL per apt nativ auf dem Server zu installieren, besorgt man sich ein MySQL-Image und startet dieses.

Mit Hilfe einer docker-compose.yml Datei (siehe Beispiel unten) lassen sich leicht mehrere Dienste zu etwas Größerem kombinieren, z. B. ein Apache mit php auf dem Nextcloud installiert ist, MySQL, Redis usw. Beispiele für docker-compose-Dateien finden sich zuhauf im Netz. Mein Beispiel unten stammt aus dem Nextcloud Repository. Einen komplizierten Dienst zu installieren kann also so einfach sein, wie sich eine passende docker-compose.yml zu besorgen, die ein bisschen anzupassen und die Konfiguration per docker-compose up -d zu starten.

services:
  db:
    image: mariadb:10.11
    restart: always
    volumes:
      - ./db:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=
      - MYSQL_PASSWORD=
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud

  redis:
    image: redis:alpine
    restart: always

  app:
    image: nextcloud
    restart: always
    ports:
      - 8081:80
    depends_on:
      - redis
      - db
    volumes:
      - ./nextcloud:/var/www/html
    environment:
      - MYSQL_PASSWORD=
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_HOST=db

Ein — für mich — besonderer Vorteil von Docker ist, dass man alle Dateien, die zu einem Dienst gehören, in einem Verzeichnis „unterbringen“ kann. Damit meine ich die docker-compose.yml, die Dateien der Datenbank, ggf. vom Nutzer hochgeladene Dateien, Konfigurationen usw. Dieser Ordner lässt sich leicht sichern oder auf einen anderen Server verschieben. Backups oder die Migration des Servers werden so zur Sache von wenigen Minuten. Zerschießt man seine Installation, stellt man den letzten Snapshot in Sekunden wieder her und weiter geht’s.

Ein Nachteil dockerisierter Dienste ist, dass man eventuell mehrere Instanzen eines Dienst in verschiedenen Containern gleichzeitig auf dem System laufen hat. Performancemäßig ist das allerdings meist kein Problem. Eine mäßig performanter vHost oder ein Raspberry Pi 4 sind in der Lage, zwei Nextcloud-Instanzen, Matrix, Pi-hole und was weiß ich noch gleichzeitig und dockerisiert auszuführen. Wichtig ist nur, dass ausreichend Speicher vorhanden ist. Und man sollte auch nicht erwarten, dass der Pi mit dutzenden Nutzern klar kommt… Aber das tut er auch ohne Docker nicht.

Die zweite Konsequenz ist technischer Natur: Wer sich ein wenig mit Linux auskennt, weiß, dass nicht mehrere Prozesse (z.B. Web Server) gleichzeitig auf demselben Port lauschen können. Ebenso möchte man nicht, dass Nextcloud z. B. über http://domain.tld:8080 und WordPress über http://domain.tld:8080 von außen erreichbar ist. Genau hier kommt ein Reverse Proxy ins Spiel. Ein Reverse Proxy lauscht — grob gesagt — auf Port 80 (bzw. 443 für HTTPS) und leitet von außen eingehende Verbindungen an die passenden internen Ports weiter. Eine Anfrage an blog.domain.tld wird z. B. an Port 8080 durchgereicht, eine Anfrage an nextcloud.domain.tld an Port 8081.

Als Reverse Proxy nutze ich seit Kurzem Caddy. Die Konfiguration ist im Vergleich zu Nginx oder Apache ein Kinderspiel. Zudem hat Caddy den entscheidenden Vorteil, dass es automatisch von Let’s Encrypt Zertifikate für alle Dienste bezieht und die Dienste per HTTPS absichert. Und HTTPS wollen wir, weil andernfalls unsere Verbindungen manipuliert oder mitgelesen werden können. Ich neige nicht zur überschwänglichen Euphorie, aber: Caddy ist super!

Eine weitere Hürde bei Self-Hosting können Subdomains sein, da viele günstige Registrare ihren Kunden nur sehr eingeschränkte DNS-Funktion bieten; so kann es z.B. sein, dass man keine Subdomains einzurichten kann. Blöd. Was meiner Beobachtung nach jedoch meist funktioniert, ist, beim Registrar einzustellen, dass das DNS der Domain von einem externen DNS-Anbieter (Nameserver) verwaltet werden soll.

desec.io ist ein solcher DNS-Anbieter. Der Dienst ist kostenlos, und es werden mehr oder weniger alle Features unterstützt, die man von DNS erwarten kann. Mit desec.io kann man sehr einfach Subdomains konfigurieren, per CAA Record das Recht zum Erstellen von Zertifikaten auf Let’s Encrypt einschränken – und last, not least: desec.io „kann“ auch Dyndns. So kann auch ein Heimserver mit dynamischer IP per Domain oder Subdomain erreichbar sein… Nice, oder?

Wie gesagt: Das ist kein Tutorial, sondern nur eine in zehn Minuten heruntergeschriebene Liste an Ideen und Möglichkeiten…