Wiki

Desplegar con Docker

El servidor uVersion y PostgreSQL en contenedores, llave en mano: descargar la imagen, cargarla, configurar .env, arrancar. Ubicación de los datos y la base de datos configurable.

Una alternativa al paquete .deb: el servidor uVersion y su base de datos PostgreSQL se ejecutan en contenedores, arrancados por un solo docker compose up. Ideal si prefiere un despliegue en contenedores, o para probarlo rápidamente.

Requisitos: Docker Engine 20.10+ con el plugin Compose v2 (docker compose version) y una clave de licencia de uVersion. El servidor se niega a arrancar sin una clave válida y firmada: obténgala en su cuenta (o solicite una desde la página de registro).

Podman también funciona Reemplace docker por podman en todos los comandos de esta página: podman compose pull, podman load -i, podman compose up -d. El docker-compose.yml que se entrega ya etiqueta sus montajes para SELinux (el control de acceso activado por defecto en Red Hat, Rocky, Alma y Fedora), con el sufijo :z. Sin esa etiqueta, al contenedor se le deniega el acceso a los directorios montados, y el mensaje se parece más a una base de datos corrupta que a un problema de permisos.

Instalar

1. Obtener el compose y la plantilla de entorno

Dos archivos, en una carpeta nueva que pasará a ser la de la pila: el docker-compose.yml y la plantilla .env.

mkdir uversion && cd uversion
wget -N -O docker-compose.yml https://uversion.io/downloads/server/docker/docker-compose.yml
wget -N -O .env https://uversion.io/downloads/server/docker/env.example

2. Obtener la imagen

En línea, el registro basta:

docker compose pull

Sin acceso a Internet (red aislada), descargue en su lugar el archivo y cárguelo: lleva el mismo nombre de imagen que el compose, así que el arranque la encuentra sin descargar nada.

wget -N https://uversion.io/downloads/server/docker/uversion-server_latest_docker.tar.gz
docker load -i uversion-server_latest_docker.tar.gz

3. Rellenar `.env`

Dos valores son obligatorios: UVERSION_LICENCE__KEY (su clave de licencia, la larga cadena firmada recibida por correo) y POSTGRES_PASSWORD (una contraseña robusta para la base de datos incluida).

nano .env

El secreto que firma las sesiones se genera en el primer arranque y se conserva en el directorio de datos. No tiene que introducir nada. Forma parte de la copia de seguridad: si desaparece, cada uno tendrá que volver a iniciar sesión una vez, no se pierde nada. Si prefiere fijar el suyo (32 caracteres como mínimo), rellene UVERSION_SECURITY__JWT_SECRET en .env: sí se transmite al contenedor, que lo usa entonces en lugar de generar uno.

Elija esta contraseña de una vez por todas POSTGRES_PASSWORD solo se aplica al crear la base de datos, cuando su directorio está vacío. Cambiarla después en .env no cambia nada del lado de PostgreSQL, que conserva la antigua, mientras el servidor presenta la nueva: la conexión se rompe sin que el mensaje lo explique. Para cambiarla de verdad, cámbiela en ambos lados:

# Changer reellement le mot de passe de la base
docker compose exec db psql -U uversion -c "ALTER USER uversion PASSWORD 'nouveau-mot-de-passe'"

# Puis reporter la MEME valeur dans POSTGRES_PASSWORD (.env) et relancer
docker compose up -d

Respalde .env junto con sus datos Contiene la clave de licencia y la contraseña de la base de datos, y vive junto al docker-compose.yml, no en los volúmenes. Perder la máquina conservando los discos de datos deja una base de datos que nadie puede direccionar y una licencia por volver a pedir: el código de activación recibido en el registro es de un solo uso y ya está consumido, solo la clave de licencia que produjo es reutilizable, y es la que está aquí. Trate este archivo como un secreto: chmod 600, y en la misma copia de seguridad que la base de datos y los chunks (los fragmentos de archivos, lo que ocupa el espacio).

4. Arrancar la pila

docker compose up -d

El servidor queda entonces accesible en https://YOUR-HOST:8443. No se requiere ningún dominio ni certificado de Let’s Encrypt: el modelo TOFU se encarga, es decir, la confianza en el primer contacto, como SSH cuando le hace validar la huella de una máquina la primera vez.

5. Anotar la huella del servidor

Se reescribe en los registros en cada arranque:

# L'empreinte du serveur, reecrite dans les journaux a chaque demarrage
docker compose logs server | grep -i "TLS fingerprint"

Es la huella del servidor (SHA-256 de su certificado): el servidor sirve HTTPS autofirmado en el puerto 8443, y cada cliente la confirma en la primera conexión. Compártala con su equipo (véase Huella TLS). No la confunda con una suma de comprobación, que sirve para verificar un archivo descargado: esta identifica su servidor.

6. Anotar la contraseña de administrador inicial

Inicie sesión como admin con esta contraseña y luego cámbiela. El archivo se elimina en cuanto la cambia.

# Le mot de passe admin initial (le fichier disparait des que vous le changez)
docker compose exec server cat /data/initial-admin-password

Para seguir el arranque en directo, docker compose logs -f server sirve, pero no lo ponga en medio de una secuencia de comandos: el -f sigue los registros indefinidamente y no devuelve nunca el control (Ctrl + C para salir).

Datos y base de datos

Todo el estado del servidor (almacén de chunks, certificado TLS y por tanto la huella, identidad del servidor) vive en un directorio del host, y la base de datos PostgreSQL en otro. Ambos se ajustan en .env:

# Dans .env : placer les donnees et la base sur un disque large et sauvegarde
UVERSION_DATA_DIR=/srv/uversion/data      # chunks, cert TLS, identite serveur
UVERSION_DB_DIR=/srv/uversion/db          # PostgreSQL fourni

Para un despliegue real, apunte UVERSION_DATA_DIR a un disco amplio y respaldado: los chunks binarios de un proyecto Unreal pueden ser voluminosos. El contenedor ajusta por sí mismo los permisos del directorio montado (arranca como root solo el tiempo de corregir la propiedad, y luego desciende a un usuario sin privilegios), así que no tiene que hacer chown de nada de antemano.

Primer arranque más largo si SELinux está activo El motor reetiqueta entonces recursivamente los directorios montados, una sola vez. Es instantáneo en un despliegue nuevo, pero cuente con varios minutos en un repositorio ya voluminoso. Los arranques siguientes no vuelven a pagar ese coste.

Para usar un PostgreSQL externo ya existente, rellene UVERSION_DATABASE__URL en .env, y luego elimine el servicio db y el bloque depends_on en docker-compose.yml.

# Dans .env : brancher un PostgreSQL existant
UVERSION_DATABASE__URL=postgres://user:motdepasse@db.interne:5432/uversion

Mover los datos y la base de datos

El caso más simple es poner las dos variables antes del primer up: todavía no existe nada, no hay nada que copiar. Si la pila ya está en marcha, hay que detenerla y copiar los directorios a mano, preservando los propietarios.

1. Detener la pila

Nada debe escribir durante la copia:

docker compose down

2. Copiar los dos directorios

Es el -a el que preserva propietarios y permisos:

sudo rsync -a ./data/server/ /srv/uversion/data/
sudo rsync -a ./data/db/     /srv/uversion/db/

3. Apuntar `.env` a la nueva ubicación

# Dans .env, LES DEUX lignes, pas une seule
UVERSION_DATA_DIR=/srv/uversion/data
UVERSION_DB_DIR=/srv/uversion/db

4. Reiniciar

docker compose up -d

Mueva los dos, o ninguno La base de datos no contiene sus archivos: contiene los metadatos que designan los chunks (los fragmentos de archivos) por su huella. Mover los datos sin la base de datos, o al revés, deja una base de datos que referencia chunks imposibles de encontrar. Y un UVERSION_DB_DIR que apunta a un directorio vacío da una base de datos en blanco: PostgreSQL la inicializa sin inmutarse, y usted obtiene un almacén de chunks lleno asociado a una base de datos sin metadato alguno.

Tres trampas de ruta, todas encontradas:

Una ruta relativa se resuelve respecto al archivo compose, no respecto al directorio desde el que ejecuta el comando. ./data/server designa siempre el vecino del docker-compose.yml.
Un recurso compartido de red (NFS, CIFS, un recurso compartido de Windows) rechaza por lo general el chown que el contenedor efectúa al arrancar. El contenedor sale entonces de inmediato, con un error de permisos que no menciona ni uVersion ni el almacenamiento. Use un disco local o un volumen de bloque.
rsync -a es lo que preserva propietarios y permisos. Una copia hecha con cp sin opciones, o desde un explorador de archivos, lo reasigna todo a la cuenta actual, y PostgreSQL se niega entonces a arrancar sobre su propio directorio.

Operación

Respaldar: la base de datos

Lleva los metadatos: archivos, revisiones, usuarios, bloqueos.

docker compose exec db pg_dump -U uversion uversion > uversion-db.sql

Respaldar: los datos del servidor

Es el directorio del host designado por UVERSION_DATA_DIR. Ambas copias cuentan: una sin la otra no restaura nada.

# .env n'est pas charge dans votre shell, chargez-le pour reutiliser la variable
set -a; . ./.env; set +a
DATA_DIR="$UVERSION_DATA_DIR"
[ -n "$DATA_DIR" ] || DATA_DIR=./data/server      # valeur par defaut

tar czf uversion-data.tar.gz -C "$DATA_DIR" .

Actualizar

Los datos y la base de datos no se tocan, las migraciones se aplican al arrancar.

docker compose pull
docker compose up -d   # les migrations s'appliquent au demarrage

En una red aislada, cargue en su lugar un archivo más reciente:

wget -N https://uversion.io/downloads/server/docker/uversion-server_latest_docker.tar.gz
docker load -i uversion-server_latest_docker.tar.gz
docker compose up -d

Detener

docker compose stop detiene los contenedores, docker compose down los retira. En ambos casos sus datos permanecen en su sitio.

down -v no borra nada aquí El compose publicado no usa ningún volumen con nombre: sus datos y su base de datos están en los dos directorios del host designados por .env. Ni down ni down -v los toca. Para empezar realmente desde cero, hay que eliminar esos directorios usted mismo. Es importante saberlo: el reflejo, tras un fallo de autenticación, es lanzar down -v y luego up, y eso vuelve exactamente al mismo error, con la misma base de datos y la misma contraseña.