Bijwerken, back-ups en terugrollen

Bijwerken

Updates komen als een nieuw distributiearchief. Er zijn twee manieren om er een toe te passen.

De node haalt het zelf op

sudo scripts/tc-operator/tc-operator update --config operator.yaml

De node haalt het release-manifest op, vergelijkt het met de geïnstalleerde versie en, als er een nieuwere is, downloadt hem, verifieert de checksum, pakt hem uit en draait de installer van het nieuwe archief opnieuw. Er is geen terminal voor nodig, dus je kunt het plannen.

De verbinding is alleen uitgaand — de node haalt op, centraal maakt nooit zelf verbinding — dus dit werkt achter een firewall. De handtekening van het manifest wordt gecontroleerd voordat een veld erin wordt vertrouwd, omdat het updatepad een archief over de levende installatieroot uitpakt en zijn installer opnieuw als root draait. --force installeert opnieuw, zelfs als de node al actueel is.

Je past een archief zelf toe

Je krijgt twee bestanden: de tarball en een checksum-sidecar.

# 1. Verifieer het archief voordat je iets aanraakt
sha256sum -c trusted-codes-operator-<versie>-<sha>.tar.gz.sha256

# 2. Pak uit over de bestaande boom, op zijn plek. Verwijder de map niet
#    eerst — de draaiende containers hebben paden erin bind-mounted.
sudo tar -xzf trusted-codes-operator-<versie>-<sha>.tar.gz -C /opt/trusted-codes

# 3. Draai install opnieuw. --archive bewaart deze build zodat je kunt terugrollen.
cd /opt/trusted-codes
sudo scripts/tc-operator/tc-operator install --config operator.yaml \
  --archive ~/trusted-codes-operator-<versie>-<sha>.tar.gz

Wat het opnieuw draaien doet

Blijft onaangeroerd: je operator.yaml, alles onder /etc/trusted-codes — geheimen, mTLS-identiteit, back-ups — en alle data in de database. Geheimen worden hergebruikt bij het opnieuw draaien, nooit geroteerd.

Wordt toegepast: alleen nieuwe migraties, want al toegepaste worden overgeslagen; referentiedata opnieuw toegepast; de functieruntime herstart zodat hij de nieuwe code aanbiedt; oppervlakken opnieuw gebouwd en klaargezet; de gepubliceerde informatie van de node opnieuw ondertekend; de README op de doos opnieuw gegenereerd.

Wordt vastgelegd: de build, zichtbaar in status en boven aan de README op de doos. Met --archive wordt de tarball bewaard onder /etc/trusted-codes/archives — de laatste vijf — zodat een terugrol geen nieuwe download nodig heeft.

Wordt geweigerd: een ouder archief over een nieuwere node installeren breekt af, omdat dat de code zou terugdraaien. --allow-downgrade gaat door als dat bewust is, en rollback zet dat voor je.

Niet nodig: finalize-tls. De proxy biedt de opnieuw klaargezette bestanden meteen vanaf schijf aan. Draai het alleen opnieuw als je domeinen hebt gewijzigd.

Controleer tc-operator status na elke update. Het print de build die nu draait.

Terugrollen

scripts/tc-operator/tc-operator rollback                    # toont bewaarde builds
sudo scripts/tc-operator/tc-operator rollback --to <versie|sha>

Het pakt die build opnieuw uit en draait install opnieuw, en vraagt je het doel te typen ter bevestiging.

Terugrollen herstelt alleen code — edge-functies, oppervlakken, installatiescripts. Het herstelt niet het databaseschema. Migraties gaan alleen voorwaarts, dus draait de oudere code tegen het huidige schema. Dat is prima voor een release die alleen dingen heeft toegevoegd. Het is niet prima voor een release die iets heeft verwijderd of hernoemd dat de oude code leest.

Een echte volledige terugrol is een herstel vanaf een databasedump, geen opnieuw uitpakken van code.

Back-ups

De installer maakt automatisch maar in precies één geval een databasedump: wanneer je uninstall draait. Een levende node heeft je eigen schema nodig.

Je hebt beide helften nodig

1. De database — accounts, verbindingen, data.
2. /etc/trusted-codes/secrets.env — de identiteit en versleutelingssleutels van de node: de federatie-ondertekeningssleutel, het JWT-geheim, de versleutelingssleutel voor persoonlijke data, het databasewachtwoord.

Teruggezette data is onleesbaar zonder de oorspronkelijke versleutelingssleutel, en een node die zonder dit bestand wordt heropgebouwd krijgt een gloednieuwe federatie-identiteit. Maak er een back-up van naast elke dump en bewaar hem offline. Een dump alleen is geen back-up.

Er een maken

source /etc/trusted-codes/secrets.env
docker exec -e PGPASSWORD="$POSTGRES_PASSWORD" tcnode-db \
  pg_dump -U supabase_admin -d postgres \
  | gzip > tc-backup-$(date -u +%Y%m%dT%H%M%SZ).sql.gz

De container heet <project>-db; bij een standaardinstallatie is dat tcnode-db, en docker ps toont hem. Dit is dezelfde dump die uninstall maakt. Kopieer het resultaat en een actuele secrets.env van de doos af, en plan dit voor elke echte inzet.

Herstellen op een verse doos

1. Zet de doos op en krijg het archief erop.

2. Herstel eerst je bewaarde secrets.env, naar /etc/trusted-codes/secrets.env, modus 0600. Dit bewaart de identiteit van de node en de sleutel die de data ontsleutelt. Zonder het origineel zijn de teruggezette rijen onleesbaar.

3. Herstel je operator.yaml en draai tc-operator install. De stack komt op en speelt het schema opnieuw af. Er is nog geen gebruikersdata.

4. Laad de dump:

   source /etc/trusted-codes/secrets.env
   gunzip -c tc-backup-<ts>.sql.gz \
     | docker exec -i -e PGPASSWORD="$POSTGRES_PASSWORD" tcnode-db \
         psql -U supabase_admin -d postgres

De dump is een volledige logische momentopname. Hem laden over het net gemigreerde schema print onschuldige “already exists”-meldingen voor objecten die de migraties ook al hebben aangemaakt; de datarijen zijn wat je gebruikers herstelt. Verifieer met tc-operator status en een testaanmelding.

Repeteer dit op een wegwerpdoos voordat je het in het echt moet doen. De stap die mensen verkeerd doen is de tweede, en ze komen daar op het slechtst denkbare moment achter.