Mein eigenes CMS liegt bei GitHub und läuft gleichzeitig auf meinem Server. Das ist bequem, wirft aber sofort eine wichtige Frage auf: Was passiert beim nächsten Update mit den bereits geschriebenen Beiträgen und den hochgeladenen Bildern? Ein unbedachtes git pull soll schließlich nicht das halbe Blogleben zurücksetzen.
Code und Inhalte sind zwei verschiedene Dinge
Im Git-Repository sollte hauptsächlich das stecken, was zur Anwendung gehört: Programmcode, Vorlagen, eine beispielhafte Compose-Datei und vielleicht Datenbankmigrationen. Persönliche Inhalte gehören nicht hinein. Beiträge liegen in der Datenbank, Bilder in einem Upload-Ordner und Passwörter beziehungsweise Schlüssel in der .env-Datei.
Damit diese Daten einen neu gebauten Container überleben, werden sie über Docker-Volumes oder Bind Mounts dauerhaft auf dem Host gespeichert. In der Compose-Datei erkenne ich das am Abschnitt volumes:. Entscheidend ist nicht nur, dass dort etwas steht, sondern welche Verzeichnisse eingebunden sind.
Vor dem Update: erst sichern, dann ziehen
Bevor ich produktive Daten anfasse, sichere ich die Datenbank und den Medienordner. Ein Git-Repository ist kein Backup für Beiträge oder Uploads. Auch die .env sichere ich geschützt, denn ohne Datenbankpasswort und andere Schlüssel lässt sich die Anwendung später nur schwer wiederherstellen.
Danach prüfe ich im Projektordner mit git status, ob lokale Änderungen vorhanden sind. Bei einem sauberen Arbeitsverzeichnis ziehe ich die neue Version mit git pull --ff-only. Die Option bricht ab, wenn Git die Änderung nicht einfach vorspulen kann. Das ist auf einem Server angenehmer als ein automatisch erzeugter Merge, den ich dort gar nicht erwartet habe.
Container neu bauen oder Images aktualisieren
Wie es weitergeht, hängt von der Compose-Datei ab. Werden fertige Images verwendet, passt häufig docker compose pull. Wird das CMS aus einem Dockerfile gebaut, nutze ich docker compose build --pull. Anschließend setzt docker compose up -d die geänderten Container neu auf.
Dabei bleiben korrekt eingebundene Volumes und Host-Ordner erhalten. Vorsicht gilt bei docker compose down -v: Das zusätzliche -v entfernt die zum Projekt gehörenden benannten Volumes. Genau deshalb gehört dieser Befehl nicht gedankenlos in eine normale Update-Routine.
Meine kurze Kontrolle danach
Nach dem Start schaue ich mit docker compose ps, ob alle Dienste laufen. Mit docker compose logs --tail=100 fallen Datenbank- oder Rechtefehler meist schnell auf. Dann öffne ich die Seite, melde mich an, kontrolliere einen älteren Beitrag und lade testweise ein Bild hoch. Ein grüner Containerstatus allein reicht mir nicht.
Das Prinzip gilt nicht nur für ein selbst entwickeltes CMS. Auch mein Beitrag WordPress mit Docker Compose und externem Nginx installieren trennt Anwendung und dauerhaft gespeicherte Daten. Genau diese Trennung macht spätere Updates beherrschbar.
Titelbild: James Harrison/Unsplash.
Wie ist deine Meinung?
Schreib gern einen Kommentar unter dem Artikel oder diskutiere mit anderen im Matrix-Kanal:
#dasnetzundich:matrix.org