Für die einzelnen Anwendungen habe ich jeweils eine docker-compose.yaml
erstellt, welche die
Docker-Konfiguration in puncto Volumes, Images und nun auch Ressourcen beinhaltet. Das reicht schon, um einen
Dienst relativ komfortabel via docker compose up -d
starten zu können. Allerdings gibt es
gelegentlich noch ein paar Handgriffe, die vorher erledigt werden müssen, insbesondere Volume-Verzeichnisse
müssen existieren und bestimmte Zugriffsrechte besitzen. Für diese Zwecke habe ich Shell-Skripte
gebaut, die zu bestimmten Zeitpunkten aufgerufen werden (z.B. direkt vor dem Start eines Containers, oder direkt
nach seiner Zerstörung). Damit man das nicht alles per Hand machen muss, habe ich ein Master-Skript
geschaffen, boxctl.sh
, das wie folgt aufgerufen wird:
boxctl.sh <command> [options] commands: cert create TLS certificate ls list known services up [service] docker compose up down [service] docker compose down logs [service] docker compose logs pull [service] docker compose pull status [service] show status
Die Liste der Dienste wird einfach durch einen Fileglob auf [^_]*
im Unterverzeichnis
services/
erzeugt, d.h. muss nicht manuell gepflegt werden. Die "Hintertür" mit dem
führenden Unterstrich hatte ich mir offengehalten, um einzelne Dienste aus der Alle-Dienste-Behandlung
ausnehmen zu können (inzwischen habe ich das anders gelöst, siehe unten). Wenn ein konkreter Dienst
angegeben wird, bezieht sich der Befehl nur auf diesen.
Der Startvorgang beinhaltet nun diese Schritte:
pre-up.sh
docker compose up -d
post-up.sh
Der Stoppvorgang symmetrisch dazu:
pre-down.sh
docker compose down
post-down.sh
Die Shell-Skripte sind optional und werden nur aufgerufen, wenn sie für den jeweiligen Dienst angelegt
wurden. Dies erlaubt eine relativ feingranulare Vor- und Nachbereitung, ohne zu unnötigem Overhead zu
führen. Der Unterbefehl certs
gießt im Wesentlichen die Befehlszeile für
openssl in Skriptform und ist irgendwie dazu gerutscht...
Die erste Version meines Backup-Skripts nutzte die Möglichkeit, die laufenden Dienste abzufragen, um
gezielt diese zu beenden und nach getaner Arbeit wieder zu starten. Außerdem hatte ich Hilfsdienste wie
mosquitto und portainer mit einem Unterstrich
versehen, damit sie nicht aus Versehen gestartet oder gestoppt werden. Später wurde für das Monitoring
jedoch noch mehr notwendig (manuelles Starten von Python-Programmen), sodass es irgendwie fummelig und dreckig
wurde, das an mehreren Stellen zu pflegen. Also habe ich noch zwei weitere Hilfsskripte für das Starten und
Stoppen hinzugefügt, die ihrerseits boxctl.sh
als Werkzeug nutzen.
Mit apps.sh
werden die Anwendungen gestartet und gestoppt:
usage: apps.sh <command> commands: start start application services stop stop application services
Mit observe.sh
werden die Monitoring-Dienste und -Skripte gestartet und gestoppt:
usage: observe.sh <command> commands: start start observation services stop stop observation services
Diese Skripte enthalten nun doch namentliche Aufzählungen von Diensten, die gestartet bzw. gestoppt werden sollen. Aber da es pro Anwendungsfall nur eine Stelle gibt, die gepflegt werden muss, hält sich die Hässlichkeit in Grenzen. Umgekehrt kann man auch als Vorteil sehen, dass die jeweils aktuelle Konfiguration (Zusammenstellung an Diensten) in einer Datei hinterlegt ist und sich nicht durch einen volatilen Laufzeitzustand ergibt.