Mises à jour, sauvegardes et retour en arrière

Mises à jour

Les mises à jour arrivent comme une nouvelle archive de distribution. Il y a deux façons d’en appliquer une.

Le nœud tire

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

Le nœud récupère le manifeste de version, le compare à la version installée et, s’il y en a une plus récente, la télécharge, vérifie sa somme de contrôle, l’extrait et relance l’installateur de la nouvelle archive. Ça n’a besoin d’aucun terminal, donc tu peux le planifier.

La connexion est sortante uniquement — le nœud tire, le central ne se connecte jamais en entrée — donc ça fonctionne derrière un pare-feu. La signature du manifeste est vérifiée avant que le moindre champ n’y soit approuvé, parce que le chemin de mise à jour extrait une archive sur la racine d’installation en marche et relance son installateur en tant que root. --force réinstalle même quand le nœud est déjà à jour.

Tu appliques une archive à la main

On te donne deux fichiers : l’archive tar et un fichier de somme de contrôle.

# 1. Vérifie l'archive avant de toucher à quoi que ce soit
sha256sum -c trusted-codes-operator-<version>-<sha>.tar.gz.sha256

# 2. Extrais par-dessus l'arborescence existante, en place. Ne supprime pas le
#    répertoire d'abord — les conteneurs en marche montent des chemins dedans.
sudo tar -xzf trusted-codes-operator-<version>-<sha>.tar.gz -C /opt/trusted-codes

# 3. Relance l'installation. --archive conserve cette version pour un retour en arrière.
cd /opt/trusted-codes
sudo scripts/tc-operator/tc-operator install --config operator.yaml \
  --archive ~/trusted-codes-operator-<version>-<sha>.tar.gz

Ce que fait le relancement

Préservés intacts : ton operator.yaml, tout sous /etc/trusted-codes — secrets, identité mTLS, sauvegardes — et toutes les données de la base de données. Les secrets sont réutilisés à un relancement, jamais renouvelés.

Appliqués : seulement les nouvelles migrations, puisque celles déjà appliquées sont sautées ; les données de référence réappliquées ; le moteur d’exécution des fonctions redémarré pour qu’il serve le nouveau code ; les surfaces reconstruites et remises en scène ; les informations publiées du nœud signées à nouveau ; le README sur la machine régénéré.

Enregistrés : la version, visible dans status et en tête du README sur la machine. Avec --archive, l’archive tar est conservée sous /etc/trusted-codes/archives — les cinq dernières — donc un retour en arrière n’a besoin d’aucune nouvelle récupération.

Refusé : installer une archive plus ancienne par-dessus un nœud plus récent abandonne, parce que ça reviendrait à reculer le code. --allow-downgrade poursuit si c’est délibéré, et rollback le règle pour toi.

Pas nécessaire : finalize-tls. Le proxy sert les fichiers remis en scène depuis le disque immédiatement. Relance-le seulement si tu as changé de domaines.

Vérifie tc-operator status après chaque mise à jour. Ça imprime la version en cours d’exécution.

Revenir en arrière

scripts/tc-operator/tc-operator rollback                    # liste les versions conservées
sudo scripts/tc-operator/tc-operator rollback --to <version|sha>

Ça réextrait cette version et relance l’installation, et te demande de taper la cible pour confirmer.

Le retour en arrière ne restaure que le code — fonctions edge, surfaces, scripts d’installation. Ça ne restaure pas le schéma de la base de données. Les migrations sont uniquement progressives, donc l’ancien code tourne contre le schéma actuel. C’est bien pour une version qui n’a fait qu’ajouter des choses. Ça ne va pas pour une version qui a supprimé ou renommé quelque chose que l’ancien code lit.

Un vrai retour en arrière complet est une restauration depuis un vidage de base de données, pas une réextraction de code.

Sauvegardes

L’installateur prend un vidage de la base de données automatiquement dans exactement un cas : quand tu désinstalles. Un nœud en marche a besoin de ton propre calendrier.

Il te faut les deux moitiés

1. La base de données — comptes, connexions, données.
2. /etc/trusted-codes/secrets.env — l’identité et les clés de chiffrement du nœud : la clé de signature de fédération, le secret JWT, la clé de chiffrement des données personnelles, le mot de passe de la base de données.

Les données restaurées sont illisibles sans la clé de chiffrement d’origine, et un nœud reconstruit sans ce fichier obtient une toute nouvelle identité de fédération. Sauvegarde-le à côté de chaque vidage et garde-le hors ligne. Un vidage seul n’est pas une sauvegarde.

En prendre une

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

Le conteneur est <projet>-db ; sur une installation par défaut, c’est tcnode-db, et docker ps le montre. C’est le même vidage que prend uninstall. Copie le résultat et un secrets.env à jour hors de la machine, et planifie-le pour tout déploiement réel.

Restaurer sur une machine neuve

1. Provisionne la machine et mets-y l’archive.

2. Restaure d’abord ton secrets.env sauvegardé, vers /etc/trusted-codes/secrets.env, mode 0600. Ça préserve l’identité du nœud et la clé qui déchiffre les données. Sans l’original, les lignes restaurées sont illisibles.

3. Restaure ton operator.yaml et lance tc-operator install. La pile monte et rejoue le schéma. Il n’y a pas encore de données utilisateur.

4. Charge le vidage :

   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

Le vidage est un instantané logique complet. Le charger par-dessus le schéma tout juste migré imprime des avis inoffensifs « already exists » pour les objets que les migrations ont aussi créés ; les lignes de données sont ce qui restaure tes utilisateurs. Vérifie avec tc-operator status et une connexion de test.

Répète ça sur une machine jetable avant d’avoir à le faire pour de vrai. L’étape que les gens ratent est la deuxième, et ils s’en aperçoivent au pire moment.