Actualizar, copias de seguridad y rollback

Actualizar

Las actualizaciones llegan como un nuevo archivo de distribución. Hay dos formas de aplicar una.

El nodo la obtiene

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

El nodo obtiene el manifiesto de publicación, lo compara con la versión instalada y, si hay una más nueva, la descarga, verifica su suma de comprobación, la extrae y vuelve a ejecutar el instalador del nuevo archivo. No necesita terminal, así que la puedes programar.

La conexión es solo saliente — el nodo obtiene, central nunca se conecta hacia dentro — así que esto funciona detrás de un cortafuegos. La firma del manifiesto se comprueba antes de confiar en cualquier campo de él, porque la vía de actualización extrae un archivo sobre la raíz de instalación en marcha y vuelve a ejecutar su instalador como root. --force reinstala incluso cuando el nodo ya está al día.

Aplicas un archivo a mano

Te dan dos archivos: el tarball y un sidecar de suma de comprobación.

# 1. Verifica el archivo antes de tocar nada
sha256sum -c trusted-codes-operator-<versión>-<sha>.tar.gz.sha256

# 2. Extrae sobre el árbol existente, en su sitio. No borres el directorio
#    primero — los contenedores en marcha montan rutas dentro de él.
sudo tar -xzf trusted-codes-operator-<versión>-<sha>.tar.gz -C /opt/trusted-codes

# 3. Vuelve a ejecutar la instalación. --archive conserva esta construcción para poder volver a ella.
cd /opt/trusted-codes
sudo scripts/tc-operator/tc-operator install --config operator.yaml \
  --archive ~/trusted-codes-operator-<versión>-<sha>.tar.gz

Qué hace la nueva ejecución

Se conserva sin tocar: tu operator.yaml, todo bajo /etc/trusted-codes — secretos, identidad mTLS, copias de seguridad — y todos los datos de la base de datos. Los secretos se reutilizan en una nueva ejecución, nunca se rotan.

Se aplica: solo las migraciones nuevas, ya que las aplicadas se omiten; los datos de referencia se vuelven a aplicar; el runtime de funciones se reinicia para que sirva el código nuevo; las superficies se reconstruyen y se vuelven a generar; la información publicada del nodo se vuelve a firmar; el README de la máquina se regenera.

Se registra: la construcción, visible en status y en la cabecera del README de la máquina. Con --archive, el tarball se guarda bajo /etc/trusted-codes/archives — los últimos cinco — así un rollback no necesita volver a descargar nada.

Se rechaza: instalar un archivo más antiguo sobre un nodo más nuevo aborta, porque eso revertiría el código. --allow-downgrade continúa si eso es deliberado, y rollback lo fija por ti.

No hace falta: finalize-tls. El proxy sirve los archivos regenerados desde disco de inmediato. Ejecútalo de nuevo solo si cambiaste de dominio.

Comprueba tc-operator status después de cada actualización. Imprime la construcción que se está ejecutando ahora.

Hacer rollback

scripts/tc-operator/tc-operator rollback                    # lista las construcciones conservadas
sudo scripts/tc-operator/tc-operator rollback --to <versión|sha>

Vuelve a extraer esa construcción y vuelve a ejecutar la instalación, y te pide que escribas el destino para confirmar.

Rollback revierte solo el código — funciones de borde, superficies, scripts del instalador. No revierte el esquema de la base de datos. Las migraciones solo avanzan, así que el código antiguo se ejecuta contra el esquema actual. Eso está bien para una versión que solo añadió cosas. No está bien para una que eliminó o renombró algo que el código antiguo lee.

Un rollback completo de verdad es una restauración desde un volcado de la base de datos, no una nueva extracción de código.

Copias de seguridad

El instalador toma un volcado de la base de datos automáticamente en exactamente un caso: cuando desinstalas. Un nodo en marcha necesita tu propio calendario.

Necesitas las dos mitades

1. La base de datos — cuentas, conexiones, datos.
2. /etc/trusted-codes/secrets.env — la identidad del nodo y las claves de cifrado: la clave de firma de federación, el secreto JWT, la clave de cifrado de los datos personales, la contraseña de la base de datos.

Los datos restaurados son ilegibles sin la clave de cifrado original, y un nodo reconstruido sin este archivo obtiene una identidad de federación completamente nueva. Haz una copia de seguridad de él junto a cada volcado y guárdala fuera de línea. Un volcado por sí solo no es una copia de seguridad.

Tomar una

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

El contenedor es <proyecto>-db; en una instalación por defecto eso es tcnode-db, y docker ps lo muestra. Este es el mismo volcado que toma uninstall. Copia el resultado y un secrets.env actual fuera de la máquina, y prográmalo para cualquier despliegue real.

Restaurar en una máquina nueva

1. Aprovisiona la máquina y pon el archivo en ella.

2. Restaura primero tu secrets.env guardado, en /etc/trusted-codes/secrets.env, modo 0600. Esto conserva la identidad del nodo y la clave que descifra los datos. Sin el original, las filas restauradas son ilegibles.

3. Restaura tu operator.yaml y ejecuta tc-operator install. La pila arranca y reproduce el esquema. Todavía no hay datos de usuarios.

4. Carga el volcado:

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

El volcado es una instantánea lógica completa. Cargarlo sobre el esquema recién migrado imprime avisos inofensivos de “ya existe” para los objetos que también crearon las migraciones; las filas de datos son las que restauran a tus usuarios. Verifica con tc-operator status y un inicio de sesión de prueba.

Ensaya esto en una máquina desechable antes de tener que hacerlo de verdad. El paso que la gente hace mal es el segundo, y lo descubren en el peor momento posible.