Actualización de los servicios de la Infraestructura

8. Actualización de los servicios de la Infraestructura

Con la infraestructura en producción, en este capítulo describimos el proceso de actualización de cada servicio. Recomendamos siempre revisar las notas de lanzamiento antes de actualizar y realizar un respaldo previo.

8.1 Lightning Network Daemon (LND)

Para realizar cualquier actualización sobre el servicio LND, debemos saber que de no tener la frase semilla y el último respaldo del estado de los canales, corremos el riesgo de que si falla la actualización por algún error no tendremos forma de restaurar el nodo.

¿Dónde encontramos la frase semilla? La frase semilla la obtuvimos en el capítulo de Primeros Pasos, y solo se puede obtener una vez, así que no hay manera de recuperarla nuevamente.

¿Dónde encontramos el respaldo de los canales? Este se guarda por defecto dentro del directorio data del nodo, en nuestra infraestructura se localiza en app-data/lnd/data/chain/bitcoin/mainnet/chan-backup-archives/

Listamos el directorio chan-backup-archives/:

ls app-data/lnd/data/chain/bitcoin/mainnet/chan-backup-archives/

Imagen 1: Directorio de respaldo de canales en un LND.

Directorio de respaldo de canales LND
Nota: En caso de una falla grave en el nodo, solo necesitaremos el último archivo de respaldo. Podemos encontrar más información sobre cómo recuperar un nodo a partir de la frase semilla y el último estado de los canales aquí.

Es importante que debemos revisar las notas de lanzamiento de la nueva versión del nodo antes de actualizar, ya que en ocasiones hay que realizar cambios en la configuración para evitar fallas.

Nuestro nodo tiene la versión v0.19.3-beta y la vamos actualizar con la última versión v0.20.1-beta, tras revisar las notas de lanzamiento no hay nada que destacar por lo que solo necesitamos modificar el archivo docker-compose.yml

Nota: Tras la versión v0.19.3-beta se lanzó la v0.20.0-beta y luego la v0.20.1-beta; en este caso no hay cambios que obliguen a ir saltando de versión en versión. Si queremos sentirnos cómodos, podemos ir escalando poco a poco.

Para actualizar la versión editamos el archivo docker-compose.yml y nos desplazamos hasta el servicio lnd:

nano docker-compose.yml

El servicio lnd estaría compuesto por lo siguiente:

lnd:
  image: lightninglabs/lnd:v0.19.3-beta
  container_name: lightning-node-1
  restart: unless-stopped
  ports:
    - "9735:9735"
    - "10009:10009"
    - "8080:8080"
  volumes:
    - ./app-data/lnd:/root/.lnd
    - tor-data:/var/lib/tor:ro
  command:
    - --configfile=/root/.lnd/lnd.conf
  depends_on:
    - tor

En la línea image: es donde se declara la versión de la imagen que usará nuestro contenedor, como queremos subir la versión donde dice v0.19.3 ponemos v0.20.1 quedando de la siguiente manera:

lnd:
  image: lightninglabs/lnd:v0.20.1-beta
  container_name: lightning-node-1
  restart: unless-stopped
  ports:
    - "9735:9735"
    - "10009:10009"
    - "8080:8080"
  volumes:
    - ./app-data/lnd:/root/.lnd
    - tor-data:/var/lib/tor:ro
  command:
    - --configfile=/root/.lnd/lnd.conf
  depends_on:
    - tor

Guardamos y salimos del archivo ctrl+s y ctrl+x.

Recreamos el contenedor con el siguiente comando:

docker-compose up --force-recreate lnd -d

Este comando descarga la nueva imagen, elimina el contenedor anterior y lo recrea con la nueva imagen.

8.2 Actualizando LNbits

Advertencia: Antes de actualizar LNbits debemos detener primero el Mint de Cashu y luego LNbits. LND debe seguir corriendo para liquidar cualquier pago en vuelo. Si detenemos LNbits con una operación pendiente entre el Mint y LNbits (por ejemplo, un melt en proceso) y la migración falla, restaurar un respaldo anterior podría permitir a un usuario realizar un doble gasto con tokens que ya habían sido redimidos.

Orden recomendado antes de actualizar:
  1. docker-compose stop cashu
  2. docker-compose stop lnbits
  3. Esperar ~1 minuto para que los pagos en vuelo se liquiden.
  4. Realizar el respaldo (ver sección 8.2.1).
  5. Actualizar y recrear el contenedor. No interrumpir la migración de base de datos.
  6. Si la migración falla, restaurar el respaldo y recrear con la versión anterior.

Antes de realizar cambios en la versión de LNbits se recomienda realizar un respaldo de la base de datos. Esto se puede hacer desde la cuenta de superusuario de LNbits; si no la recordamos, podemos volver al capítulo de LNbits.

Tras iniciar sesión en LNbits vamos a los Settings y damos clic en el botón DOWNLOAD DATABASE BACKUP que nos aparece al lado del botón RESTART SERVER

Imagen 2: Respaldo de la Base de Datos.

El archivo zip descargado contiene un volcado de la base de datos, además una copia del directorio data de LNbits que incluye las extensiones y los log de la aplicación.

8.2.1 Respaldando la base de datos desde la CLI

Podemos respaldar la base de datos fácilmente ejecutando el siguiente comando:

docker exec -t postgres_lnbits pg_dump -U lnbits_user lnbits_db | gzip > lnbits_backup_$(date +%Y%m%d_%H%M%S).sql.gz

Esto creará el archivo en el directorio actual desde donde se ejecutó el comando.

Ya tenemos el respaldo. Vamos nuevamente al archivo docker-compose.yml y buscamos el servicio lnbits.

nano docker-compose.yml
lnbits:
  image: lnbits/lnbits:v1.4.0
  container_name: app_lnbits
  restart: unless-stopped
  volumes:
    - ./app-data/lnd/:/app/.lnd/:ro
    - ./app-data/lnbits/data/:/app/data
    - ./app-data/lnbits/.env:/app/.env

Vemos que la versión de la imagen que estamos usando es la v1.4.0 y hay una nueva versión v1.5.3 en el repositorio github del proyecto, siempre es recomendable ver las notas de lanzamiento de la nueva versión para saber si hay que realizar algún paso extra antes de actualizar.

Cambiamos la versión v1.4.0 por la v1.5.3 en la línea image:

lnbits:
  image: lnbits/lnbits:v1.5.3
  container_name: app_lnbits
  restart: unless-stopped
  volumes:
    - ./app-data/lnd/:/app/.lnd/:ro
    - ./app-data/lnbits/data/:/app/data
    - ./app-data/lnbits/.env:/app/.env

Guardamos y salimos del archivo ctrl+s y ctrl+x.

Recreamos el contenedor con el siguiente comando:

docker-compose up --force-recreate lnbits -d

Este comando descarga la nueva imagen, elimina el contenedor anterior y lo recrea con la nueva imagen.

8.3 Actualizando el Mint de Cashu

Advertencia: Antes de actualizar el Mint de Cashu debemos detener el servicio cashu. LND y LNbits deben seguir corriendo. Si hay un melt en vuelo (el usuario ya quemó los tokens pero el pago Lightning aún no confirmó) y la migración falla, restaurar un respaldo anterior podría permitir un doble gasto.

Orden recomendado antes de actualizar:
  1. docker-compose stop cashu
  2. Esperar ~1 minuto para que los pagos en vuelo se liquiden.
  3. Realizar el respaldo (ver a continuación).
  4. Actualizar y recrear el contenedor. No interrumpir la migración de base de datos.
  5. Si la migración falla, restaurar el respaldo y recrear con la versión anterior.

Antes de actualizar el Mint de Cashu debemos respaldar su base de datos. Al ser SQLite, el proceso es simple: solo copiamos el archivo mint.sqlite3.

Nos movemos hacia el directorio de cashu localizado en app-data/cashu/

cd app-data/cashu

Creamos un directorio backup en caso de no existir.

mkdir -p backup

Copiamos la base de datos del mint.

cp data/mint/mint.sqlite3 backup/

Luego de respaldar la base de datos vamos al archivo docker-compose.yml:

nano docker-compose.yml
cashu:
  image: cashubtc/nutshell:0.19.2
  container_name: app_cashu
  restart: unless-stopped
  volumes:
    - ./app-data/cashu/.env:/app/.env
    - ./app-data/cashu/data:/app/data
    - ./app-data/cashu/certs:/app/certs
    - ./app-data/cashu/certs/server_private.pem:/app/server_private.pem
    - ./app-data/cashu/certs/server_cert.pem:/app/server_cert.pem
    - ./app-data/cashu/certs/ca_cert.pem:/app/ca_cert.pem
    - ./app-data/cashu/certs/client_cert.pem:/app/client_cert.pem
    - ./app-data/cashu/certs/client_private.pem:/app/client_private.pem
    - ./app-data/cashu/backup:/app/backup
  command: ["poetry", "run", "mint"]
  depends_on:
    - lnbits

Vamos a migrar de la versión 0.19.2 a la 0.20.0, como hicimos en los anteriores servicios cambiamos la versión en la línea image: quedando de la siguiente manera:

cashu:
  image: cashubtc/nutshell:0.20.0
  container_name: app_cashu
  restart: unless-stopped
  volumes:
    - ./app-data/cashu/.env:/app/.env
    - ./app-data/cashu/data:/app/data
    - ./app-data/cashu/certs:/app/certs
    - ./app-data/cashu/certs/server_private.pem:/app/server_private.pem
    - ./app-data/cashu/certs/server_cert.pem:/app/server_cert.pem
    - ./app-data/cashu/certs/ca_cert.pem:/app/ca_cert.pem
    - ./app-data/cashu/certs/client_cert.pem:/app/client_cert.pem
    - ./app-data/cashu/certs/client_private.pem:/app/client_private.pem
    - ./app-data/cashu/backup:/app/backup
  command: ["poetry", "run", "mint"]
  depends_on:
    - lnbits

Guardamos y salimos del archivo ctrl+s y ctrl+x.

No olvidemos realizar el respaldo antes de continuar. Consultemos las notas de la versión: la imagen siguiente muestra un mensaje de aviso informando que hay cambios en la estructura de la base de datos tras la actualización, y que es necesario respaldarla para evitar corrupción de datos ante una actualización fallida.

Imagen 3: Mensaje de aviso sobre cambios en la estructura de la base de datos.

Cashu Backup Database Info

Solo nos queda ejecutar el comando:

docker-compose up --force-recreate cashu -d

Este comando descarga la nueva imagen, elimina el contenedor anterior y lo recrea con la nueva imagen.

8.4 Resto de los servicios de la infraestructura

Es posible que nos preguntemos por qué no cubrimos el resto de los servicios. La razón es que todos ellos (Tor, Lightning Terminal, Nginx Proxy Manager, Redis, Postgres y Orchard) son soporte de la infraestructura: añaden funcionalidades o permiten gestionar los demás servicios. El procedimiento es siempre el mismo: editar docker-compose.yml y cambiar la versión.

8.5 Solución de problemas

Se irán añadiendo en la medida que la comunidad los vaya reportando.

Anterior ← Orchard Siguiente Migración de Infraestructura →