Añade tu primer nodo
Un nodo es un host Linux registrado en Opfield para un rol operativo concreto. El host ejecuta un daemon gestionado por Opfield que informa de su identidad y sus capacidades y recibe solo los comandos permitidos para ese rol. Añadir un nodo no mueve automáticamente ninguna carga de trabajo existente; crea capacidad de confianza que puedes seleccionar más adelante.
Elige cómo conectar
Sección titulada «Elige cómo conectar»Puedes añadir un nodo de cualquiera de estas formas:
- En tu propio servidor o VM: ejecuta el comando de instalación generado por Opfield siguiendo las instrucciones de abajo.
- Crea una VM a través de Opfield: si quieres contratar una VM directamente desde la interfaz, conecta un proveedor de hosting y elige Hosted VM en Add Node. Opfield crea la VM e instala el daemon. Espera a que el nodo esté listo, no solo a que el proveedor la encienda.
Un registro correcto significa que el nodo está Online con el rol y las capacidades previstos.
Elige el rol antes del registro
Sección titulada «Elige el rol antes del registro»| Rol | Úsalo para | Decisión principal de propiedad |
|---|---|---|
| Ingress | Routes, materialización de TLS, Pages, logs de nginx y métricas de tráfico | Qué direcciones y puertos públicos son responsabilidad de este host |
| Docker | Containers, Deployments, Compose Projects, imágenes, volúmenes, redes y operaciones de ejecución | Qué cargas de trabajo pueden compartir este host Docker |
| Storage | PostgreSQL, almacenes clave-valor y ClickHouse gestionados por Opfield, almacenamiento de objetos gestionado y trabajos de copia de seguridad de bases de datos | Aislamiento del almacenamiento, de las copias de seguridad y de las cargas de trabajo con estado |
| Build Worker | Builds aislados desde código Git con BuildKit/containerd | Salida de red de los builds y separación de las credenciales reutilizables |
| Monitoring | Recopilación de monitorización compatible | Qué sistemas puede observar el nodo |
| Relay | Capacidad y resiliencia del plano de datos de los Secure Links | Dirección anunciada accesible y dominio de fallo físico |
No elijas un rol solo porque su instalador funcione en el host. Un rol de producción debe corresponderse con el límite de confianza, la ubicación en la red, el almacenamiento y el responsable de la recuperación previstos para el host. En particular, los Build Workers y los nodos Storage deberían estar normalmente dedicados a su función.


Antes de crear el nodo
Sección titulada «Antes de crear el nodo»Confirma que el destino es un host Linux compatible con acceso root o un sudo que funcione, la hora del sistema correcta, un DNS fiable y accesibilidad saliente hacia el destino gRPC público de Opfield en 9443/tcp. Ese destino es el endpoint de control respaldado por Relay que usan los daemons gestionados; puede ser un host o una IP directos aunque la interfaz web de Opfield esté detrás de un proxy.
Confirma también la propiedad específica de cada rol:
- Los nodos Ingress necesitan los listeners públicos previstos y un modelo operativo claro de DNS/TLS.
- Los nodos Docker necesitan un Docker Engine local compatible y capacidad suficiente para sus cargas de trabajo; el instalador del nodo puede preparar los componentes de ejecución compatibles en un host nuevo compatible.
- Los nodos Storage necesitan un almacenamiento duradero adecuado, las capacidades de loop y de montaje necesarias y HTTPS saliente hacia
ghcr.io. No des por hecho que un invitado LXC restringido normal basta: necesita un pool de dispositivos loop dimensionado para cada instancia gestionada y para las copias de seguridad simultáneas; consulta Requisitos previos de los nodos Storage y Docker. - Los Build Workers necesitan un host dedicado o un contenedor externo sin privilegios y un perfil de salida de red aprobado.
- Los nodos Relay necesitan una dirección y un puerto accesibles desde los hosts de Opfield, Docker, Ingress y Storage participantes. Opfield no abre el cortafuegos ni atraviesa NAT por ti.
Registra el nodo en tu propio host
Sección titulada «Registra el nodo en tu propio host»- Abre Nodes, selecciona Add Node y elige External VM.
- Elige el rol previsto. Para Relay, introduce la dirección que usarán los demás participantes para llegar al worker de Relay.
- Da al nodo pendiente un nombre reconocible que describa su función estable, no un ticket temporal ni el nombre de una persona.
- Crea el nodo y copia el comando de instalación generado. Contiene un token de registro de un solo uso y la huella esperada del certificado de Opfield.
- Ejecuta el comando en el host de destino con los privilegios necesarios. No elimines la huella ni sustituyas la dirección de Opfield generada salvo que el destino público o local configurado sea incorrecto.
- Conserva la salida de la instalación hasta que el daemon se haya registrado y la interfaz de Opfield muestre el nodo como Online.
- Abre los detalles del nodo y compara el nombre de host, el rol, el sistema operativo, la versión, las direcciones y las capacidades informados con el diseño previsto.
El daemon verifica el certificado fijado de Opfield antes de enviar el token de un solo uso. Tras un registro correcto, la autenticación a largo plazo usa TLS mutuo: tanto Opfield como el nodo presentan certificados. La relación reutilizable es la identidad registrada, no el token de arranque.
Criterios de éxito
Sección titulada «Criterios de éxito»Considera el registro completado solo cuando:
- el nodo está Online, no solo creado o pendiente;
- su tipo y su nombre de host son correctos;
- la versión informada es compatible con la versión de Opfield;
- están presentes las capacidades esperadas y no se muestra ninguna advertencia de versión incompatible;
- el estado específico del rol es correcto;
- el nodo se vuelve a conectar tras reiniciar el servicio de su daemon;
- una comprobación de actualizaciones integrada puede llegar al canal de versiones configurado;
- el operador asignado tiene los ámbitos necesarios para verlo y operarlo sin un acceso amplio de administrador del sistema.
Para Relay, un registro correcto hace que el host físico pueda formar parte del Relay Pool. Añadir un Relay en buen estado no mueve automáticamente los endpoints existentes; verifica la accesibilidad y usa la operación explícita de reequilibrio cuando quieras cambiar la ubicación.
Comprobaciones del operador por rol
Sección titulada «Comprobaciones del operador por rol»- Ingress: valida la configuración de nginx, inspecciona la dirección de servicio, confirma los puertos 80/443 cuando sea necesario y abre unos logs de nginx acotados.
- Docker: confirma la sincronización del inventario, el estado de ejecución, el acceso al sistema de archivos y cualquier capacidad de GPU o de Secure Runtime esperada.
- Storage: confirma la raíz de almacenamiento seleccionada, la aplicación de la capacidad y que se completa la comprobación previa antes de crear una base de datos o un almacenamiento gestionados.
- Build Worker: confirma el estado de BuildKit/containerd, el perfil de recursos aplicado, la disponibilidad del escáner y la política de salida de red seleccionada.
- Relay: confirma el estado del supervisor y del worker, el endpoint anunciado, el número de túneles activos y la ubicación en el dominio de fallo.
Fallos y recuperación segura
Sección titulada «Fallos y recuperación segura»Si el registro no se completa, conserva el nodo pendiente mientras diagnosticas. Comprueba el comando generado exacto, la hora del sistema, el DNS, la accesibilidad saliente de 9443/tcp, la huella del certificado, el log del instalador y el log del servicio del daemon. Un nombre de host web con proxy de Cloudflare no es automáticamente un destino gRPC válido.
No elimines la fijación del certificado para que la conexión funcione. Eso convierte un problema de configuración en un riesgo de identidad. Corrige Settings > General y genera un comando nuevo si el destino gRPC público o local es incorrecto.
Un nodo pendiente se puede eliminar y volver a crear cuando quieras deliberadamente una identidad de registro nueva. No reutilices nunca un token de un solo uso antiguo. Tras el registro, la eliminación tiene consecuencias específicas de cada rol: un Relay con asignaciones activas debe vaciarse, y un nodo que tiene cargas de trabajo o datos debe retirarse siguiendo el runbook de cargas de trabajo o de bases de datos correspondiente, en lugar de eliminarlo sin más del inventario.
Siguiente paso
Sección titulada «Siguiente paso»Con un nodo Ingress o Docker en línea, continúa con Publica tu primera Route. Para las comprobaciones de producción específicas de cada rol, usa Roles de los nodos e instalación y Actualizaciones de nodos y comportamiento sin conexión.