Multiservidor

Conecte otros servidores de su propiedad a una instalación de sh0 y ejecute en ellos parte de sus aplicaciones. El servidor principal conserva el panel, las compilaciones y el enrutamiento.

Requisitos

• Una licencia Business y el rol admin u owner: sin ellos, todas las rutas de nodos se rechazan.
• En el servidor remoto: Docker instalado y en marcha. sh0 no instala nada allí.
• Acceso SSH desde el servidor principal al remoto, con un usuario que pueda usar el socket de Docker (/var/run/docker.sock): root o un miembro del grupo docker.
• Una clave SSH registrada previamente en el panel (gestión de claves SSH), o la contraseña del usuario.

Funcionamiento

• El servidor principal conserva la base de datos, el panel y Caddy. Un nodo solo ejecuta contenedores; sh0 controla su Docker a través de un túnel SSH.
• Las imágenes se compilan siempre en el servidor principal y luego se transfieren al nodo (el despliegue muestra el paso transferring).
• Los dominios siguen apuntando al servidor principal. Su Caddy reenvía cada solicitud al contenedor del nodo mediante un relé que viaja por el mismo túnel SSH.
• Los nombres internos (my-api.internal) solo resuelven dentro de un mismo servidor: una aplicación en un nodo no alcanza por ese nombre un servicio del mismo proyecto situado en otro servidor. El registro de compilación lo advierte cuando un proyecto abarca varios nodos.

Agregar un nodo

1. En el panel, abra Nodos y luego Agregar nodo.
2. Indique un Nombre (minúsculas, dígitos y guiones, como máximo 64 caracteres) y el Nombre de host (dirección IP o nombre DNS; localhost y las direcciones de bucle local se rechazan).
3. Fije el Puerto SSH (22 por defecto), el Usuario (root por defecto) y la Autenticación: Clave SSH o Contraseña.
4. Guarde y use Probar conexión: sh0 comprueba la conexión SSH y Docker en el nodo.

Desde la CLI (nodes create admite --port para un puerto SSH no estándar y --password en lugar de --ssh-key):

sh0 nodes create --name worker-1 --host 203.0.113.20 --ssh-user root --ssh-key <ssh-key-id>
sh0 nodes list
sh0 nodes info <node-id>
sh0 nodes test <node-id>

Por la API:

curl -X POST https://panel.example.com/api/v1/nodes \
  -H "Authorization: Bearer $SH0_TOKEN" -H "Content-Type: application/json" \
  -d '{"name":"worker-1","hostname":"203.0.113.20","port":22,"username":"root","auth_method":"ssh_key","ssh_key_id":"<ssh-key-id>"}'

• port, username y auth_method son opcionales (22, root, ssh_key). Con "auth_method":"password", envíe password en lugar de ssh_key_id; se guarda cifrada.
• Desde 1.10.3: sh0 intenta conectarse en cuanto se crea el nodo: el estado pasa a online si lo logra, a error con el mensaje si falla. El intento está limitado a 15 segundos: con una dirección que no responde, el nodo se registra en error y la CLI termina con código 1, indicando nodes test para reintentar y nodes delete para eliminarlo.
• La clave de host SSH del nodo se registra en la primera conexión y se comprueba después. Si el servidor se reinstala, su clave cambia y la conexión se rechaza: restablezca la huella (POST /api/v1/nodes/<id>/reset-fingerprint) para que la siguiente conexión registre la nueva clave.

Desplegar en un nodo

Al crear una aplicación desde un repositorio Git, un Dockerfile, una imagen Docker, un framework o un archivo comprimido, el campo Nodo destino elige el servidor; por la API, envíe node_id (el ID o el nombre del nodo). Un valor vacío designa el servidor principal; un valor que no corresponde a ningún nodo se rechaza en lugar de desplegarse en silencio en el principal.

Trasladar una aplicación

Una aplicación se traslada cambiando su node_id con PATCH /api/v1/apps/<id>. La aplicación debe estar detenida antes; si no, el cambio se rechaza, porque su contenedor quedaría en marcha en el servidor anterior. Una cadena vacía devuelve la aplicación al servidor principal.

curl -X PATCH https://panel.example.com/api/v1/apps/<app-id> \
  -H "Authorization: Bearer $SH0_TOKEN" -H "Content-Type: application/json" \
  -d '{"node_id":"worker-1"}'

Después vuelva a desplegar la aplicación: la imagen se compila en el principal y se transfiere al nuevo nodo. El contenedor del nodo anterior no se migra y los datos de los volúmenes no lo siguen: cópielos usted mismo.

Estado de los nodos

Nodos lista cada servidor con su estado (En línea, Pendiente, Error, Desconectado), su versión de Docker, CPU y memoria, y el último contacto. Un monitor vuelve a comprobar los nodos cada 30 segundos y reabre los relés de las aplicaciones en marcha tras una reconexión.

Quitar un nodo

Un nodo solo se puede quitar cuando ya no tiene ninguna aplicación asignada: «Cannot delete node: N app(s) still assigned. Migrate them first.» Traslade o elimine antes esas aplicaciones y luego elimine el nodo desde Nodos, con sh0 nodes delete <id-del-nodo> o DELETE /api/v1/nodes/<id>.

Limitaciones

• El principal es un punto único de fallo. Si se detiene, el panel, las compilaciones y el enrutamiento hacia todos los nodos se detienen con él.
• Todo el tráfico pasa por el principal. Las solicitudes llegan a un nodo por el relé SSH; dimensione el ancho de banda del principal en consecuencia.
• Sin ubicación automática. sh0 no elige un nodo por usted ni reparte réplicas entre nodos: cada aplicación se ejecuta en un solo servidor.
• Sin vaciado ni migración automática. Vaciar un nodo supone detener, trasladar y volver a desplegar sus aplicaciones una por una.
• Sin red entre servidores. Vea los nombres internos más arriba.
• Use el ID del nodo en la CLI. sh0 nodes test, info y delete anuncian «Node ID or name», pero en v1.10.2 solo se encuentra el ID.