Servidores

Tipos de servidor

Los servidores son infraestructura global de la instancia: añadir, editar y eliminar servidores e instalar Docker requieren el rol global Admin. Los Operator pueden ejecutar health checks.

Claves SSH

Desde la v0.3.0, las claves SSH viven en su propio catálogo en lugar de pegarse en cada servidor. Abre SSH Keys en la barra lateral (solo Admin) y haz clic en Add SSH Key. Puedes:

• Generar un nuevo par de claves — RSA 4096 o ED25519 — directamente en el diálogo
• Importar una clave propia pegando su clave privada (OpenSSH o PEM); la clave pública y la huella SHA256 se derivan automáticamente
• Ponerle un nombre y una descripción opcional a la clave para distinguir unas de otras

Copia la clave pública en el ~/.ssh/authorized_keys del usuario remoto y luego elige la clave al añadir el servidor. Una misma clave puede compartirse entre varios servidores.

# On the remote server, as the user DeployKit will connect with
mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA... deploykit" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

• La clave privada se muestra una sola vez, al crearla. Se cifra en reposo con AES-256-GCM y la API nunca la vuelve a devolver — descárgala desde el diálogo si quieres conservar una copia
• Solo se admiten claves RSA y ED25519. Las claves protegidas con passphrase se rechazan, porque DeployKit no puede desbloquearlas
• Una clave que sigue asociada a un servidor no se puede eliminar; el error indica los servidores de los que hay que desvincularla primero
• La creación, el renombrado y la eliminación de claves quedan registrados en el registro de auditoría

Añadir un servidor remoto

En la página Servers haz clic en Add Server y rellena:

• Server Name — un identificador descriptivo, p. ej. production-1
• Host / IP — dirección IP o nombre de host del servidor
• SSH Port — por defecto 22
• Username — por defecto root
• SSH Key — obligatoria; se elige del catálogo de SSH Keys (crea una primero si la lista está vacía)

Qué necesita el servidor remoto

• Acceso SSH desde el host de DeployKit, con la mitad pública de la clave en authorized_keys
• git — los repositorios se clonan en el propio servidor remoto
• Docker — o deja que DeployKit lo instale por ti (ver más abajo)
• O bien el usuario root, o un usuario que pueda ejecutar sudo sin pedir contraseña: para cualquier usuario distinto de root, DeployKit antepone sudo a sus comandos de Docker
• Disco suficiente para imágenes y contextos de build; los builds se ejecutan en /tmp/deploykit-builds y se limpian después

Health checks e información del servidor

Haz clic en Check health en la tarjeta de un servidor para probar la conexión SSH y Docker. El servidor se marca como connected (SSH y Docker funcionan), disconnected (SSH funciona, falta Docker) o error (SSH falló). Después, la tarjeta muestra el sistema operativo, los núcleos de CPU, la RAM y el disco totales, el número de contenedores, la versión de Docker y cuándo se comprobó el servidor por última vez, además de las aplicaciones y bases de datos desplegadas en él. Los health checks se ejecutan cuando tú los lanzas; no hay sondeo de servidores en segundo plano.

Instalación automática de Docker

Si el health check detecta que SSH funciona pero falta Docker, la tarjeta ofrece Install Docker. DeployKit ejecuta el script de instalación oficial de get.docker.com, habilita e inicia el servicio de Docker y añade a un usuario que no sea root al grupo docker. Necesita acceso root o sudo y puede tardar unos minutos. Ejecuta un health check después para verificarlo.

Despliegues remotos

Cuando una aplicación apunta a un servidor remoto, el worker de despliegue clona el repositorio en esa máquina por SSH, construye la imagen allí con docker build, inicia el contenedor y elimina el directorio de build. Los logs se envían al panel en tiempo real. Diferencias con los despliegues locales:

• Los builds remotos usan siempre el Dockerfile de la aplicación (ajuste Dockerfile path); los builds con Nixpacks y Buildpacks solo se ejecutan en el servidor local
• El análisis de vulnerabilidades de Trivy se omite, porque la imagen vive en el daemon remoto
• DeployKit no instala un reverse proxy en los servidores remotos — los contenedores reciben las mismas etiquetas de Traefik, pero enrutar dominios hacia ellos requiere una instancia de Traefik en ese host
• Los servidores de juegos solo se ejecutan en el servidor local

Limpieza de imágenes

Cada despliegue deja atrás una imagen deploykit/*. Cada noche a las 03:00, DeployKit las elimina en todos los servidores, conservando las imágenes de los últimos 3 despliegues exitosos por aplicación para que los rollbacks sigan funcionando. Los Admin también pueden ejecutarlo bajo demanda con Clean images en la página Servers, eligiendo cuántas imágenes conservar por aplicación (1–20) y, opcionalmente, haciendo antes una simulación (dry run) para previsualizar qué se eliminaría.

Eliminar un servidor

Eliminar un servidor de DeployKit no detiene ni borra lo que se ejecuta en él. Las aplicaciones, bases de datos, stacks y servidores de juegos que apuntaban a él se conservan, pero pierden su asignación de servidor. La clave SSH permanece en el catálogo y puede eliminarse por separado cuando ningún servidor la use.