Umstrukturierung meiner externen IT

Ich habe kürzlich mein E-Mail-Hosting umgestellt. Das war allerdings nur ein Teil eines größeren Umbaus meiner externen IT – also der Dienste, die nicht bei mir zuhause laufen.

Ausgangslage

Bislang hatte ich zwei vServer: einen bei Contabo, der mit KeyHelp eingerichtet war und hauptsächlich Web und Mail bereitstellte, und einen bei Webtropia, der als Mailgateway, Docker-Host und Reverse-Proxy diente. Das funktionierte insgesamt auch alles gut. Ich wollte aber die Kosten senken, den Contabo-Server samt KeyHelp ablösen und insgesamt weniger Wartungsaufwand haben. Keyhelp war für mich früher zum Management gut, heutzutage brauche ich diese Funktionalitäten aber nicht mehr.

Was sich geändert hat

Mailhosting

Das Mailhosting liegt inzwischen bei OVH und Migadu; Transaktionsmails laufen über Scaleway. Damit wäre der Punkt erledigt.

Weitere Container vom Hauptserver

Auf dem Contabo-Server lagen neben dieser Website nur noch einige interne oder ungenutzte PHP-basierte Anwendungen - die habe ich entweder abgeschafft oder zu Docker migriert. Außerdem liefen dort noch ein paar Container, die sich mit wenig Aufwand migrieren ließen.

Webhosting

Ich hatte bspw. noch eine Pterodactyl-Installation ohne Docker. Die habe ich schlicht durch Pelican in Docker ersetzt und Pterodactyl entfernt.

Spannender ist das neue Setup für SecretMine.de. Bisher habe ich über einen dedizierten Benutzer die Website-Dateien einfach per rsync auf den Webspace geschoben. Im neuen Setup übernimmt Caddy die Auslieferung der Website. Daneben läuft ein OpenSSH-Server für die Dateiübertragung per rsync über SSH. Beide Dienste sind in einem Docker-Compose-Stack zusammengefasst.

Die zugehörige Compose-Datei:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
services:
  openssh-server:
    image: lscr.io/linuxserver/openssh-server
    restart: unless-stopped
    environment:
      PUID: 1000
      PGID: 1000
      TZ: "Europe/Berlin"
      DOCKER_MODS: "lscr.io/linuxserver/mods:openssh-server-rsync"
      PUBLIC_KEY_FILE: "/sshd_authorized_keys/authorized_keys"
      SUDO_ACCESS: "false"
      PASSWORD_ACCESS: "false"
      USER_NAME: "sftp"
      LOG_STDOUT: "true"
    volumes:
      - ./sshd_authorized_keys:/sshd_authorized_keys
      - ./sshd_config:/config
      - ./www-data:/www-data
    ports:
      - 10.0.0.2:2222:2222
  caddy:
    image: caddy
    restart: unless-stopped
    user: 1000:1000
    ports:
      - 10.0.0.2:8023:80
      - 10.0.0.2:8024:81
    volumes:
      - ./caddy_data:/data
      - ./caddy_config:/etc/caddy
      - ./www-data:/usr/share/caddy/

Die Caddyfile bleibt dabei übersichtlich:

1
2
3
4
5
6
7
8
9
:80 {
        root * /usr/share/caddy/main
        file_server
}

:81 {
        root * /usr/share/caddy/staging
        file_server
}

Caddy lauscht also auf zwei Ports und liefert die Hauptseite getrennt von der Staging-Seite aus. HTTPS übernimmt eine vorgeschaltete Caddy-Instanz, die auch für andere Dienste als Reverse-Proxy dient und die Anfragen an diesen Stack weiterleitet.

Der SSH-Benutzer sftp und der Caddy-Prozess verwenden dieselbe UID und GID (1000:1000). Das Verzeichnis www-data gehört ebenfalls diesem Benutzer. Damit kann ich die Website-Dateien weiterhin einfach per rsync übertragen, habe meine Website aber trotzdem als kompakten Compose-Stack.

Alternativ könnte ich Caddy und die Website-Dateien gemeinsam als Container-Image ausliefern. Mit dem separaten Dateitransfer kann meine CI die Website jedoch aktualisieren, ohne bei jeder Inhaltsänderung ein neues Image bauen und den Container neu bereitstellen zu müssen. Die Aktualisierung der Container-Images bleibt davon unabhängig und ich kann einfach das normale Upstream Caddy-Image nutzen.

Ausblick: ein neuer vServer

In Kürze werde ich außerdem einen neuen vServer an einem für mich interessanten Standort mieten. Dazu gibt es dann einen eigenen Beitrag. Ich habe einen Anbieter gefunden, dessen Standort eine Verbindung mit niedriger Latenz zu meinem Homelab ermöglicht. Das ist für den Reverse-Proxy und ähnliche Dienste spannend.

Ob sich der neue Anbieter im Alltag bewährt, wird sich zeigen. Eine aussagekräftige Einschätzung ist für mich ohnehin erst nach einigen Monaten möglich.

Fazit

Das Mailhosting ist ausgelagert, und die Website läuft in einem übersichtlichen Compose-Stack. So habe ich weniger Wartungsaufwand, ohne meine bisherige CI-Pipeline für die Veröffentlichung der Website nennenswert ändern zu müssen.

Auch an meiner internen Infrastruktur wird sich einiges tun, aber dazu gibt es mehr, wenn es so weit ist.