source: Klonkt/deploy/klonkt@.service

main
Last change on this file was 2dd1dc4, checked in by Robin <roboburr@…>, 6 weeks ago

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@…>

  • Property mode set to 100644
File size: 1.3 KB
Line 
1# Klonkt: one service per instance, one shared copy of the code.
2#
3# Install as /etc/systemd/system/klonkt@.service, then start an instance with
4# its slug:
5#
6# systemctl enable --now klonkt@boiert
7#
8# %i is the slug. Code is shared and read-only at runtime; everything the
9# instance writes lives under /var/lib/klonkt/<slug>/. Adding an instance is
10# therefore a directory plus an .env file, nothing else.
11
12[Unit]
13Description=Klonkt (%i)
14Documentation=https://github.com/roboburr/klonkt
15After=network-online.target
16Wants=network-online.target
17
18[Service]
19Type=simple
20User=klonkt
21Group=klonkt
22
23# Shared code. Never instance specific, never written to at runtime.
24WorkingDirectory=/opt/klonkt
25
26# All configuration for this instance. Port, domain, secret and the data paths
27# live here, which is what keeps instances apart.
28EnvironmentFile=/var/lib/klonkt/%i/.env
29Environment=NODE_ENV=production
30
31ExecStart=/usr/bin/node src/server.js
32Restart=always
33RestartSec=3
34
35# The whole filesystem is read-only to this process except its own data
36# directory. An instance therefore cannot write into the code, nor into another
37# instance's data, even if something goes wrong inside the app.
38NoNewPrivileges=true
39ProtectSystem=strict
40ProtectHome=true
41PrivateTmp=true
42ReadWritePaths=/var/lib/klonkt/%i
43
44[Install]
45WantedBy=multi-user.target
Note: See TracBrowser for help on using the repository browser.