Deployen, Log ansehen, Dienst schalten und fragen was laeuft waren vier verschiedene Beschwoerungen, drei davon von Hand als ssh + systemctl. Jetzt: remote backend deploy|upload|setup|install-jdk|reset-password remote backend start|stop|restart|status|enable|disable remote backend log|info|documents|backup remote frontend deploy|preview|info remote ssh Die Skripte unter scripts/ bleiben die Implementierung und einzeln aufrufbar; tools/remote bringt nur mit, wofuer es bisher nichts gab. Wo ein Schalter noetig war, kam er ins Skript statt ins Werkzeug: --unit-only in deploy-backend.sh (sonst kennte eine zweite Stelle die Unit-Platzhalter) und --dry-run in deploy-prod.sh, das die Befoerderung ausdruecklich mit abschaltet. Neu ist die Sicherung: H2 haelt die Datei offen, also anhalten, holen, wieder starten (gemessen ~8 s Auszeit) - und das Archiv lesen, bevor der Befehl es behaelt. Gegenprobe von Hand: lokal ausgepackt, Backend mit --werkbaum.data-dir dagegen gestartet, es liefert genau die Dokumente des Servers. .envrc legt tools/ auf den PATH (direnv), 217 Plan-Knoten, 0 Warnungen.
17 lines
641 B
Bash
17 lines
641 B
Bash
# direnv-Konfiguration.
|
|
#
|
|
# Legt `tools/` auf den PATH, solange man in diesem Verzeichnisbaum steht — dann
|
|
# genügt `remote backend deploy` statt `tools/remote backend deploy`. Wirkt nur
|
|
# hier und darunter, die globale Shell-Konfiguration bleibt unangetastet.
|
|
#
|
|
# Einmal pro Arbeitskopie freizugeben (direnv lädt eine Datei erst, wenn man ihr
|
|
# traut) — und erneut, sobald sich diese Datei ändert:
|
|
#
|
|
# direnv allow
|
|
#
|
|
# Bewusst `tools` und nicht `scripts`: Auf dem PATH hieße der Befehl sonst
|
|
# `deploy-prod.sh`. Die Skripte bleiben, wo sie sind, und einzeln aufrufbar;
|
|
# `tools/remote` ist die Vordertür davor.
|
|
|
|
PATH_add tools
|