Ich habe vor kurzem einen neuen Webserver geholt. Auf diesem neuen Server experimentiere ich ein wenig mit OpenLiteSpeed, was ich noch nie zuvor verwendet habe. Es bringt eine eigens Admin-Dashboard mit, um den Server zu verwalten. Aber alles wird in Konfigurations-Dateien gespeichert.
Manchmal möchte oder muss man diese Dateien aber manuell anpassen. Wenn nicht die von OpenLiteSpeed, dann aber vielleicht die SQL oder PHP Konfiguration. Wenn man dann nicht genau weiß, was man tut, macht man schnell Dinge kaputt.
Versionierung deiner Konfigurations-Dateien
Aus diesem Grund habe ich angefangen, meine Konfigurations-Dateien unter Versionsverwaltung zu stellen. Das hat einige Vorteile:
- Du kannst Dinge ausprobieren und rückgängig machen, wenn etwas kaputt geht
- Du hast ein „Backup“ deiner Konfiguration
- Du kannst die gleichen/ähnliche Konfigurations-Dateien auf allen deinen Servern verwenden und die synchronisieren
- Du siehst alle Änderungen, die von anderen Prozessen gemacht wurden – beispielsweise nach einem Update oder durch ein Konfigurations-Tool
Nur die wichtigsten Dateien versionieren und solche mit sensitiven Informationen ignorieren
Auf vielen Linux-Servern befinden sich alle Konfigurations-Dateien im /etc Ordner. Du könntest jetzt also auf die Idee kommen, einfach den gesamten Ordner zu versionieren. Aber das ist eventuell keine gute Idee, denn einige Dateien enthalten sensitive Daten und man kann auch schnell etwas kaputt machen. Ich habe beispielsweise einmal aus Versehen die /etc/passwd Datei gelöscht, was keine gute Idee war. ?
Ignorieren von nginx Konfigurations-Dateien
Auf meinem alten Server habe ich also nur die Ordner /etc/php und /etc/nginx in zwei separaten Git-Repositories versioniert. Für die nginx Konfigurationen habe ich dann die folgende .gitignore Datei verwendet:
# /etc/nginx/.gitignore
*param*.pem
sites-enabled/
modules-enabled/
modules-available/
In der zweiten Zeile ignoriere ich die dhparam-4096.pem Datei, welche für einen besseren Diffie-Hellman-Schlüssel verwendet wird. Ich ignoriere auch die *-enabled Ordner, die nur Symlinks auf die *-available enthalten. Ihr könnt diese aber auch versionieren, wenn ihr tracken wollt, welche Sites und Modules enabled wurden. Der modules-available Ordner hatte für mich auch keinen größeren Wert, weshalb ich ihn ausgelassen habe.
Ignorieren von OpenLiteSpeed Konfigurations-Dateien
Auf dem neuen Server bin ich immer noch dabei herauszufinden, wie die Konfigurations-Dateien strukturiert sind. Die OpenLiteSpeed Dateien befinden sich im Ordner /usr/local/lsws und aktuell sieht meine .gitignore wie folgt aus:
# /usr/local/lsws/.gitignore
# Ignore all files by default but decent into subfolders
*
!*/
# Allow just some files and subfolders
!.gitignore
!/conf/**
!/lsphp*/**
!/php/**
# Still ignore some files and folders in those subfolders
*.conf.bak
*.conf.dpkg
*.conf.txt
*.conf0
*.conf0,v
*.properties0
*.properties0,v
/lsphp*/bin/
/lsphp*/include/
/lsphp*/lib/
/lsphp*/share/man/
Da der /usr/local/lsws Order nicht nur die Konfiguration, sondern auch Binärdateien und Logfiles enthält, ignoriere ich erst einmal alle Dateien und Ordner. Dann füge ich nur die Ordner hinzu, die Konfigurations-Dateien enthalten, die ich versionieren möchte.
Nachdem ich einige Pakete aktualisiert habe, gab es viele „Backup-Konfigurations-Dateien“, also habe ich auch alle mit diesen Dateiendungen, in den zuvor erlaubten Ordner, ignoriert.
Ich werde diese Ignoriere-Liste in Zukunft vielleicht noch anpassen, aber für den Moment habe ich alle Dateien versioniert, die ich brauche.
Zu Remote-Repository pushen
Wie bereits in den Vorteilen erwähnt, könnt ihr diesen Ansatz auch verwenden, um ein „Backup“ eurer Konfigurations-Dateien zu erstellen. Auch wenn Git (oder jedes andere Versionsverwaltungstool) keine Alternative zu einem Backup ist, kann es doch vorteilhaft sein, das Repository auf einem externen Server zu haben. Da diese Konfiguration nicht unbedingt öffentlich sein sollte, verwende ich für meine ein privates Repository auf GitLab.com als Remote.
Das hat weiterhin den Vorteil, dass ich mir das Repository auf meinen Laptop klonen kann, um dann die Dateien einfacher in PhpStorm bearbeiten kann, als mit vim direkt auf dem Server. Ich kann auch sehr viel einfacher die Änderungen vergleichen und Commits rückgängig machen.
Änderungen automatisch versionieren
Ich mache die Commits (und Pushes) normalerweise manuell. Aber falls ihr häufig Änderungen an Dateien durch andere Prozesse habt, und jede Änderungen versionieren möchtet, dann könnt ihr einen Cron erstellen, der alle Änderungen commited. Dies ist ein Beispiel für einen Cron, der automatisch alle 30 Minuten alle Änderungen an der nginx Konfiguration commited:
30 * * * * cd /etc/nginx && git add -A && git commit -m "auto commit on `date`" && git push
Selbst neue und gelöschte Dateien werden versioniert. Einen solchen Cron zu haben, kann aber auch potenziell zu Problemen führen, wenn eure Ignorieren-Liste nicht richtig aufgesetzt ist, da vielleicht eine neue Datei eine Logdatei ist, die sich häufig ändert. Wenn ihr also einen solchen Cron einsetzt, solltet ihr die automatischen Commits regelmäßig prüfen.
Fazit
Ich liebe Git! Man kann es für so viele verschiedene Dinge verwenden. Das Versionieren meiner Konfigurations-Dateien hat mir schon viel Zeit gespart, wenn ich versucht habe herauszufinden, wieso Dinge auf einmal kaputt waren. Aber auch, wenn ich Änderungen an mehreren Dateien auf einmal machen wollte (bei der lokalen Bearbeitung in PhpStorm).
Verwendet ihr einen ähnlichen Ansatz und möchtet diesen gerne hier teilen? Oder verwendet ihr Git noch für ganz andere Dinge? Dann schreibt es gerne in einen Kommentar.