|
Scheid gebruikersdata van code voor self-hosters
Een instance bewaarde zijn database, uploads en .env binnen de checkout. Daardoor
bevatte de codemap levende gebruikersdata: opruimen bij een deploy kon uploads
raken, een back-up moest de data tussen de code vandaan vissen, en een tweede
site vroeg een tweede kopie van alles, inclusief node_modules, die apart
bijgewerkt moest worden.
Nu staat de code in /opt/klonkt en de data per instance in /var/lib/klonkt/<slug>.
De checkout is daarmee wegwerpbaar: weggooien en opnieuw klonen laat elke
instance intact. Een site toevoegen is een map plus een .env, zonder tweede
kopie van de code, en klonkt-update brengt ze in een keer allemaal naar de
nieuwe versie.
De systemd-template draait als de klonkt-gebruiker met ProtectSystem=strict en
ReadWritePaths op alleen de eigen datamap. Een instance kan dus niet in de code
schrijven en niet bij de data van een andere instance, ook niet als er in de app
iets misgaat.
Changed files:
scripts/install.sh
- KLONKT_DATA_ROOT en KLONKT_SLUG toegevoegd, slug afgeleid van het domein
- verse installatie zet data in /var/lib/klonkt/<slug> en start klonkt@<slug>
- bestaande installaties met een .env in de checkout blijven ongemoeid,
opnieuw draaien mag nooit een levende database verplaatsen
- weigert bij een database in de checkout zonder .env, te dubbelzinnig
- klonkt-update herstart voortaan elke instance, niet alleen klonkt.service
deploy/DEPLOY.md
- sectie 9b: meerdere zelfstandige Klonkts naast elkaar, met verwijzing
- onderscheid verduidelijkt met de bestaande multi-tenant sectie, die gaat
over sites binnen een instance
New file:
deploy/klonkt@.service
- systemd template-unit, een service per instance, gedeelde code
scripts/klonkt-migrate-data.sh
- zet een bestaande installatie om, met --dry-run en een rollback-pad
- weigert op code zonder src/config/paths.js, anders schrijft de app alsnog
naast zijn eigen code
scripts/klonkt-add-instance.sh
- nieuwe instance: datamap, .env met verse SESSION_SECRET en vrije poort,
service en Caddy-blok
deploy/MULTI-INSTANCE.md
- indeling, eigenaarschap en rechten, migratie, instances toevoegen,
updaten, back-up en verwijderen
Nog te doen: dit is getest op de fleet en met een lokale rooktest, maar de
verse-installatiestap zelf is nog niet op een schone VPS gedraaid.
-robo
Co-Authored-By: Claude Opus 5 <noreply@…>
|