FUUU

Neuer Rootserver – Zeit für was neues, auch im Techstack

Lange Zeit hatte ich zusammen mit meinem Kumpel einen Root Server bei Hetzner aus der Serverbörse. Mit einem betagten i7-3770k und zwei HDDs war die Leistung sehr Bescheiden. NextCloud war schon nicht mehr möglich wegen den Datenbankzugriffen um ein Beispiel zu nennen. So habe ich dann für jeden Dienst einen vServer gemietet. Es wurden dann immer wieder mehr mit Mailarchiv etc. so dass es dann sich doch lohnte auf den größeren Root Server von Hetzner zu gehen. Wie sorge ich aber dafür das die Dienste immer aktuell bleiben? An sehr vielen Stellen wurde auch Docker hoch gelobt, auch viele andere Dienste bieten bei Docker Hub voll automatisch Dienste an. Auf der Arbeit hatte ich dann auch mit Portainer zu tun. Also nahm ich die Chance und wollte all meine Dienste die im Internet verfügbar sind über Docker bereitstellen, um auch diese besser aktualisieren zu lassen.

Docker im LXC Container – nicht so einfach wie gedacht

Docker im LXC Container, also Container im Container, dass kann doch nur schief gehen, oder? Es steht fest, auch Proxmox empfiehlt bei Docker es in einer QEMU VM laufen zu lassen und nicht in LXC. Jedoch ist es möglich Docker in einem unpriviligiertem Container laufen zu lassen. Dabei ist es wichtig Nesting aktiviert zu haben. Praktisch ist, dass ab Proxmox PVE 7.1 Nesting automatisch aktiviert ist. Was ich zu dem Zeitpunkt noch nicht wusste, dass auch fuse aktiviert sein muss. Warum erfolgt in einem späterem Kapitel. Wenn man dieses aktiviert hat kann man ohne Probleme über die Docker Doku dann die Repos einfügen und installieren.

Docker compose – beim falschen Befehl verliert man die Daten!

Docker compose kann vieles einfach machen, aber wenn man die Befehle nicht versteht steht man mit Datenverlust da. Die docker-compose.yml ist eine YAML Datei, bei der dann Docker compose voll automatisch den Docker Container zusammenbauen kann. Natürlich gibt es persistente Daten, bleiben wir beim Beispiel der Nextcloud. Da sollen ja die Daten die zur Nextcloud gehören immer aktualisiert werden, aber die persistente Daten wie meine Bilder, Konfigurationsdateien sollen bleiben. Bei Nextcloud wird z. B. folgende docker-compose.yml als Beispiel angegeben:

version: '2'

volumes:
  nextcloud:
  db:

services:
  db:
    image: mariadb:10.5
    restart: always
    command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
    volumes:
      - db:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=
      - MYSQL_PASSWORD=
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud

  app:
    image: nextcloud
    restart: always
    ports:
      - 8080:80
    links:
      - db
    volumes:
      - nextcloud:/var/www/html
    environment:
      - MYSQL_PASSWORD=
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_HOST=db

Bei dieser Docker Compose wird also erstmal ein MariaDB Container erstellt und eine zweite (app) die dann NextCloud ist. Sehen wir uns Zeile 3 bis 5 an sehen wir die Reiter Volumes. Mit diesen Zeilen übergeben wir Docker die Verwaltung der Persistenten Daten. Wird also der Docker Container erstellt, erstellt der Docker Daemon an einem für sich passenden Ort einen Order, bei dem er Daten auch außerhalb des Container speichert.

Mit dem simplen Befehl docker compose up -d wird dann der Container erstellt und dann lacht einem ein funktionierendes Nextcloud an. Jetzt kann man annehmen, dass man den Befehlt docker compose down verwenden soll um den Container zu beenden. Dieses tat ich auch, ich nahm änderunden an der .yml Datei vor und startete dann den Container wieder. Was mich dann überrascht hatte, all meine Nextcloud Einstellungen waren weg. Was ist passiert? Mit docker compose down wird nicht nur der Container beendet, sondern komplett gelöscht! Dies bedeutet auch dass die Volumes mit gelöscht werden. Erst später stellte ich fest, dass docker compose stop einen Container nur beendet und docker compose start -d wieder startet. Jedoch war mir das zu gefährlich, ich möchte nicht dass ich in einer doofen Minute dann meine Daten lösche weil ich down anstatt stop verwendet hatte. Deshalb habe ich in der .yml Datei absolute Pfade angegeben für die persistenden Dateien. Sprich die Zeile

- nextcloud:/var/www/html
habe ich abgeändert in
- /home/docker/nc/data:/var/www/html

Jetzt bleiben auch bei einem compose down die Daten. Also Lessen learned.

Viel Hoffnung in Portainer, leider nicht das was ich dachte

Als ich bei meiner Arbeit mit Portainer gearbeitet hatte war ich erst begeistert! Durch deren Interface kann man dann wunderbar mit Docker arbeiten, bekommt einfachen Shell Zugriff, logs usw. So dachte ich mir auch dass ich mit Portainer mir ein Monitoring aufbauen konnte um eine Nachricht zu erhalten wenn ein Container down geht usw. Dem ist leider nicht so, auch über die API bekomme ich keine Informationen wenn Container down sind. Schade. Am Ende muss ich dann es doch über CheckMK lösen. Das ist über PiggyBack auch machbar. Glück gehabt 😅

und nochmal alle LXC Container anfassen – LXC auf ZFS mit Docker braucht optimierung!

Nach zwei Tagen war es irgendwie komisch, immer Morgens hatte ich kein DNS mehr … Ein Login in den LXC Container teilte mir dann mir, dass der docker daemon nicht mehr lief. Dieses passierte auch nach ein paar Tagen. Also frage ich im Docker Forum nach (https://forums.docker.com/t/docker-daemon-stops-from-time-to-time/134088). Zu wenig RAM für den Container war ein Problem, aber in den Logs wurde Metin auf was aufmerksam, nämlich der Storage Driver von Docker war vfs.

Kurz nachgesehen steht dick und fett, dass vfs für den Produktiven Betrieb nicht empfohlen wird, das ist auch nur die Fallback Lösung. Leider kommt der LXC Container nicht damit klar den ZFS Treiber zu verwenden, auch wenn wie in meinem Fall ZFS das Filesystem ist. Jedoch war ich nicht verloren, denn ich konnte overlay-fs zum laufen bekommen!

Beschrieben in https://forums.docker.com/t/docker-daemon-stops-from-time-to-time/134088/13?u=gamienator war eine Featureerweiterung im LXC Container notwendig, nämlich fuse, und das Paklet fuse-overlayfs zu installieren. Nach einer Woche durfte ich wieder jeden Container anfassen, als meine Backups failten.

PVE UI crashed komplett wegen Snapshot hängern

Nach ungefähr einer Woche bekam ich eine Mail von meinem Proxmox, dass ein Backup nicht erledigt werden konnte. Dachte ich mir prima, dann schauen wir mal nach was da los ist. Anschließend bekam ich einen kleinen Schock bei demn Anblick:

Über SSH war Proxmox noch erreichbar. Ein simpler Reboot hat geholfen, habe den Backupprozess nochmal angestoßen und es war wieder Container 107 der in diesen Lockup führte. Welche Änderung war es, ich habe in dem LXC Container Docker laufen. Container 107 habe ich mir dann nochmal genau angesehen und traute meinen Augen nicht, der Storage Driver vom Docker Daemon war ZFS und was dann passierte war einfach nur :troll:…

Bei der Backup Methode Snapshot hat es Zugriffsfehler gegeben. Anscheinend mögen sie die Kaskadierung nicht von OverlayFS im ZFS usw. Eine sichere Methode LXC Container zu backupen bei denen Docker läuft ist leider die STOP Methode.

Backup? Das muss ja auch noch sein. Dank Hetzner Storagebox

Um das alles zu backupen kann ich schlecht meine Heimleitung nutzen. Während der Download mit 250 MBit/s noch human ist wird im falle eines Desasters das Recovern Tage dauern! Deshalb dachte ich mir, man nehme eine 1 TB Hetzner Storage Box und binde diese ein. Leider ist die Performance der StorageBox alles andere als klasse. Schon kurz nach dem Einbdinden gab es diverse Timeouts beim erstellen eines Backups.

Dann doch noch eine VM mieten, wegen Proxmox Backup Server

Was ich aber dann feststellte, dass der Proxmox Backup Server stabiler ist. Also eine kleine VM bei der Hetzner Cloud gemietet um dann die StorageBox dort per SMB einzubinden. Die erste Einrichtung hat zwar über drei Stunden gedauert, aber dann war der Storage erreichbar und ich konnte erfolgreich Backups auf die Storage Box schieben. Projekt geglückt!

---

Filed under: Allgemein - @ 4. April 2023 14:00