Anpassungen an der Konfiguration von Fulda.social

In meinem neuesten Artikel möchte ich auf ein Thema eingehen, das vielen Betreibern von Mastodon-Instanzen, wie beispielsweise Fulda.social, bekannt vorkommen dürfte: das Timing-Problem beim Starten der Dienste innerhalb eines Docker-Compose-Setups. Speziell geht es um die Herausforderung, dass die Datenbank oft länger zum Starten benötigt als andere Container, was zu unerwünschten 502-Fehlern nach einem Update führen kann. Ich werde erläutern, wie man dieses Problem durch Anpassungen in der docker-compose.yml Datei angehen kann und einen Blick auf die geplanten Tests für das kommende Update werfen, einschließlich eines möglichen Updates der Datenbankversion.

Die Herausforderung

In Docker-Compose-Umgebungen, insbesondere bei komplexen Anwendungen wie Mastodon, besteht eine häufige Herausforderung darin, dass bestimmte Dienste, wie Webserver oder Hintergrundprozesse, abhängig von anderen Diensten sind – typischerweise Datenbanken. Bei Fulda.social wurde beobachtet, dass nach einem Mastodon-Update die übrigen Container schneller starten als die PostgreSQL-Datenbank, was zu 502-Fehlern führt, da die Anwendung versucht, auf eine Datenbank zuzugreifen, die noch nicht vollständig hochgefahren ist.

Die Lösung: Anpassungen in der docker-compose.yml

Um dieses Problem zu lösen, habe ich die docker-compose.yml Datei von Fulda.social angepasst, um die Startreihenfolge besser zu kontrollieren und sicherzustellen, dass alle Dienste erst dann vollständig hochfahren, wenn die Datenbank bereit ist. Dies wurde durch die Verwendung der depends_on-Anweisung in Kombination mit Healthchecks erreicht.

Schritt 1: Definieren von Healthchecks

Für den PostgreSQL-Datenbankcontainer wurde ein Healthcheck definiert, der Docker Compose anweist, den Gesundheitszustand des Containers zu überprüfen, bevor andere abhängige Dienste gestartet werden. Der Healthcheck verwendet den Befehl pg_isready, um zu überprüfen, ob die Datenbank bereit ist, Verbindungen anzunehmen.

services:
  db:
    image: postgres:14-alpine
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5

Ebenso wurde auch ein Healthcheck für andere Dienste wie Elasticsearch eingebaut.

Schritt 2: Anwendung der depends_on-Anweisung

Für andere Dienste wie Webserver und Hintergrundarbeiter wurde die depends_on-Anweisung mit der Bedingung service_healthy verwendet. Dies stellt sicher, dass diese Dienste erst gestartet werden, nachdem der Healthcheck des Datenbankcontainers erfolgreich war.

web:
  depends_on:
    db:
      condition: service_healthy

Geplante Tests und Datenbank-Update

Beim kommenden Update von Fulda.social wird diese angepasste Konfiguration getestet. Ziel ist es, die Stabilität und Zuverlässigkeit des Systems zu verbessern und die 502-Fehler, die nach Updates auftraten, zu eliminieren. Zusätzlich wird in Erwägung gezogen, die Datenbankversion von postgres:14-alpine auf eine neuere Version zu aktualisieren. Diese Änderung könnte zusätzliche Performance-Verbesserungen und neue Funktionen mit sich bringen, erfordert aber sorgfältige Tests, um Kompatibilitätsprobleme zu vermeiden.

Fazit

Durch gezielte Anpassungen in der docker-compose.yml Datei lässt sich das Problem von Diensten, die zu früh starten, effektiv angehen. Die Implementierung von Healthchecks und die kluge Nutzung von depends_on sorgen für eine geordnete Startreihenfolge, die insbesondere nach Updates die Stabilität des Gesamtsystems verbessert. Das kommende Update von Fulda.social wird nicht nur diese Verbesserungen testen, sondern auch die Möglichkeit eines Datenbank-Updates bieten, das das Potenzial hat, die Systemleistung weiter zu steigern.