Aktualisieren

Eine Aktualisierung besteht aus vier Handgriffen: sichern, neuen Stand holen, die .env abgleichen, neu starten. Um die Datenbank muss man sich dabei nicht kümmern – Migrationen, Mandantentrennung, GoBD-Sperren und die Rechte des Anwendungsbenutzers spielt der Start der API von selbst ein.

Aus dem Quellcode

cd /opt/workoffice-pro
/usr/local/bin/workoffice-sicherung
git pull
scripts/env-abgleich.sh
docker compose -p workoffice -f docker-compose.selfhost.yml up -d --build

Der Reihe nach:

1. Sichern. Vor jeder Aktualisierung, ohne Ausnahme – mit demselben Skript wie in der Nacht (siehe Sicherung). Geht beim Start etwas schief, ist der Stand von eben der Rückweg.
2. git pull holt den neuen Stand.
3. scripts/env-abgleich.sh zeigt, welche Einträge die neue Fassung kennt, die in der eigenen .env noch fehlen (unten).
4. up -d --build baut die Abbilder neu und startet die Container, die sich geändert haben.

Freiwillig lassen sich Fassung und Commit mitgeben; sie erscheinen dann in der Betreiberübersicht, sofern der Server eine hat:

APP_VERSION=$(git describe --tags --always) APP_COMMIT=$(git rev-parse --short HEAD) \
  docker compose -p workoffice -f docker-compose.selfhost.yml up -d --build

Mit fertigen Abbildern

Wer die Abbilder des Herstellers nutzt (siehe Mit Docker betreiben), baut nichts:

cd /opt/workoffice-pro
/usr/local/bin/workoffice-sicherung
docker compose -p workoffice -f docker-compose.selfhost.yml -f docker-compose.kunde.yml pull
docker compose -p workoffice -f docker-compose.selfhost.yml -f docker-compose.kunde.yml up -d

pull lädt die neueste Fassung – oder die, die WORKOFFICE_VERSION in der .env festlegt. Wer eine bestimmte Fassung festgelegt hat, setzt dort die neue Nummer ein, bevor er pull aufruft. Fertige Abbilder bringen Fassung und Commit schon mit.

Die Compose-Dateien, die Skripte und die Vorlage .env.example stecken nicht im Abbild. Liegt das Verzeichnis als Git-Klon vor (wie unter Einrichten), holt ein git pull vor dem pull ihre neue Fassung; danach lohnt der Abgleich der .env.

Die .env abgleichen

Neue Fassungen bringen manchmal neue Einträge mit. Das Skript nimmt die Vorlage .env.example und setzt überall die Werte aus der bestehenden .env ein:

scripts/env-abgleich.sh              # nur anzeigen
diff .env .env.neu                   # nachsehen
scripts/env-abgleich.sh --schreiben  # übernehmen

• Ohne --schreiben ändert es nichts; das Ergebnis steht in .env.neu.
• Einträge der alten .env behalten ihren Wert. Neue kommen mit der Vorgabe der Vorlage dazu. Was die Vorlage nicht mehr kennt, geht nicht verloren, sondern landet am Ende in einem eigenen Abschnitt.
• Mit --schreiben ersetzt es die .env und legt die alte als .env.vorher-<Datum> daneben.
• Ausgegeben werden nur die Namen der Einträge, nie die Werte – die Ausgabe lässt sich gefahrlos weitergeben.

Eine geänderte .env wirkt erst nach up -d.

Nachsehen

docker compose -p workoffice -f docker-compose.selfhost.yml ps
curl -s http://127.0.0.1:3100/api/ready

Die API braucht nach dem Start einen Moment für die Migrationen; bis zu zwei Minuten gilt sie als im Aufbau. Danach muss bei api healthy stehen und /api/ready "mandantentrennung":"greift" melden. Dann anmelden und eine Rechnung öffnen.

Startet die API nicht, steht der Grund im Protokoll:

docker compose -p workoffice -f docker-compose.selfhost.yml logs api

Bricht sie mit „Row-Level-Security greift NICHT“ ab, stimmt etwas mit dem Anwendungsbenutzer nicht (siehe PostgreSQL). Hilft nichts, führt scripts/wiederherstellen-server.sh mit der Sicherung von eben zurück.

Was dabei nicht verloren geht

Datenbank und Dateiablage liegen in Volumes und überstehen den Neubau der Container. Nur docker compose down -v würde sie löschen – das gehört nicht zur Aktualisierung. Die Lizenz läuft weiter; ihre Kennung steckt in der Datenbank.

Das Programm für Windows und Mac

Die Oberfläche kommt vom Server und ist nach der Aktualisierung sofort für alle aktuell, auch im installierten Programm. Das Programm selbst aktualisiert sich davon unabhängig (siehe Programm verteilen).