Requisitos y planificación

Dale a Opfield su propio host y mantén las aplicaciones y las bases de datos en nodos gestionados. Opfield guarda los usuarios y los permisos, la configuración de los recursos, los certificados, las operaciones y el historial de auditoría, y vigila el estado de cada nodo. Los propios hosts siguen siendo responsabilidad tuya: su dimensionamiento, sus discos, las actualizaciones del sistema operativo y el bastionado.

Decide la forma del despliegue

Una evaluación pequeña puede colocar la aplicación Opfield y sus servicios internos en un único host Linux. Los entornos de producción deben tratar igualmente ese host como una dependencia del plano de control, con una propiedad explícita, almacenamiento duradero, un procedimiento de recuperación y capacidad supervisada. Los roles de cargas de trabajo gestionadas se pueden registrar más adelante y pueden estar en hosts físicos, máquinas virtuales o contenedores de sistema debidamente aislados por separado.

Antes de la instalación, registra:

la URL HTTPS canónica en la que confiarán los usuarios y los nodos gestionados;
quién es responsable del DNS, los certificados, la autenticación, las copias de seguridad y las actualizaciones;
qué redes pueden llegar a la aplicación web y a Relay;
qué roles de nodo se necesitan de inmediato y cuáles se pueden añadir después;
el plan de producto y los derechos de funciones necesarios;
el objetivo de recuperación de los datos y del material de cifrado de Opfield.

Evita diseñar en torno a direcciones IP temporales o a un nombre de host que se vaya a renombrar después de la puesta en marcha. La URL canónica interviene en la seguridad del navegador, las redirecciones, los comandos generados y las integraciones.

Decisión sobre el host y la capacidad

Proporciona un host Linux compatible con acceso root o un sudo que funcione. Docker no es un requisito previo para el instalador público: cuando faltan Docker Engine o el plugin Compose v2, el instalador los instala y configura desde los repositorios de paquetes oficiales de Docker. La instalación automática de Docker admite las familias Debian, Ubuntu, Fedora, CentOS y RHEL. Si Docker ya está presente, el instalador valida que se pueda llegar al motor y que Compose v2 esté disponible.

Usa estos perfiles de dimensionamiento base para el plano de control:

Perfil	CPU	Memoria	Capacidad SSD libre
Mínimo	2 vCPU	4 GB de RAM	32 GB
Recomendado	4 vCPU	8 GB de RAM	64 GB

Las cifras de disco son la capacidad libre después de instalar el sistema operativo. El logging local de ClickHouse gestionado por Opfield necesita 32 GB adicionales como mínimo o 128 GB recomendados; el uso real depende del volumen de ingesta y de la retención. Un ClickHouse externo no añade almacenamiento de logging local al host de Opfield.

Reserva almacenamiento persistente para los datos de PostgreSQL de Opfield, la persistencia de Redis cuando esté configurada, los artefactos subidos, los certificados, la configuración, el registro interno y los logs estructurados opcionales. Los builds desde código Git necesitan capacidad adicional en el registro, porque se conservan los artefactos correctos, activos, de reversión, en curso y fijados manualmente. Los contenedores propios de Opfield (la aplicación, Relay, el registro, PostgreSQL y Redis) conservan como máximo tres archivos de log de 50 MB cada uno; una actualización añade este límite a las instalaciones existentes salvo que un servicio ya tenga su propia configuración de logging.

Como mínimo, asegúrate de que el host también tiene:

margen suficiente para la aplicación, PostgreSQL, Redis y Relay sin presión sostenida de swap;
almacenamiento duradero con supervisión del espacio libre y un destino de copias de seguridad probado;
la hora del sistema correcta y una resolución DNS fiable;
un proceso de actualización del sistema operativo que no sustituya silenciosamente los volúmenes persistentes;
acceso a la versión firmada actual de Opfield y al servicio de licencias.

No guardes en el host de Opfield la única copia de la copia de seguridad o de la clave de cifrado. Una copia de seguridad de la base de datos sin el material de cifrado de secretos correspondiente no es un conjunto de recuperación completo.

Detalle para operadores: acceso de red

La instalación pública normalmente necesita HTTP/HTTPS entrante para la interfaz de usuario y la API. Los nodos gestionados se conectan a través de Relay, que requiere 9443/tcp accesible cuando los nodos están fuera de la red local. Restringe el acceso administrativo en el perímetro de la red cuando sea posible, pero no pongas un proxy o un cortafuegos en el camino de Relay salvo que admita las conexiones de larga duración necesarias.

El acceso saliente depende de las funciones activadas. Los destinos habituales incluyen proveedores de identidad, proveedores de ACME y DNS, sistemas de control de código fuente, registros de contenedores, servicios de versiones y de licencias, endpoints de correo y webhooks, receptores SIEM y los proveedores de IA configurados. Los Build Workers pueden necesitar una política de salida distinta y más restrictiva que el plano de control.

Algunos roles de nodo necesitan más:

Nodos Storage: descargan el runner de copias de seguridad desde GitHub Container Registry, así que necesitan HTTPS saliente hacia ghcr.io. Los motores gestionados (SeaweedFS, PostgreSQL, Valkey, ClickHouse) y el sidecar de Compose de los nodos Docker se descargan por digest primero desde el mirror de Opfield en ghcr.io, con Docker Hub como alternativa.
Workload Availability en modo lease: cada nodo Docker de una política y cada nodo Ingress de sus Routes deben llegar a todos los Relays del pool en su puerto anunciado; consulta Conmutación por error del plano de datos.

Revisa Puertos y red antes de cambiar los cortafuegos. Valida los caminos desde el host y el espacio de nombres de red reales que iniciarán la conexión; una petición correcta desde el portátil de un administrador no demuestra que Opfield o un nodo puedan llegar al mismo endpoint.

Roles de los nodos y límites de confianza

Elige solo los roles que necesites:

nodo nginx: tráfico entrante, materialización de TLS, Pages, logs de acceso y de errores y métricas de tráfico;
nodo Docker: Containers, Deployments, Compose Projects, archivos, logs y estado de ejecución;
nodo Storage: instancias gestionadas de PostgreSQL, clave-valor o ClickHouse, almacenamiento de objetos gestionado, su almacenamiento duradero y los trabajos de copia de seguridad de bases de datos;
Build Worker: ejecución aislada con BuildKit/containerd sin exponer un socket de Docker Engine;
nodo de monitorización: recopilación específica de monitorización para los destinos compatibles;
miembro del Relay Pool: transporta los Secure Links y los enlaces de bases de datos y almacenamiento. Producción y cualquier configuración de Availability necesitan al menos dos en hosts distintos del host de Opfield, en dominios de fallo diferentes (host, alimentación, ruta de red); consulta Cuántos Relays.

Requisitos previos de los nodos Storage y Docker

Un nodo Storage ejecuta el daemon de Docker como root y guarda cada base de datos gestionada, cada clúster de almacenamiento de objetos y cada espacio de trabajo de copias de seguridad en una imagen ext4 de tamaño fijo sobre un dispositivo loop, de modo que su uso de disco está acotado. El instalador lo comprueba antes del registro: formatea, monta, amplía y libera una imagen de prueba y se detiene si el host no puede hacerlo. Cada base de datos gestionada, cada miembro de almacenamiento de objetos y cada copia de seguridad en ejecución ocupan un dispositivo loop mientras existen. Las máquinas virtuales y los hosts físicos crean dispositivos loop según los necesitan. Un invitado LXC solo funciona cuando su host le pasa /dev/loop-control y un pool de dispositivos loop y permite los dispositivos de bloque loop y los montajes; dimensiona ese pool para cada instancia gestionada y cada copia de seguridad simultánea que vaya a tener el nodo. Cuando se agota el pool, crear una instancia falla con node has no free loop device; el daemon libera por sí solo los dispositivos de las instancias eliminadas.

En un nodo Docker, un volumen de imagen de disco gestionado también ocupa un dispositivo loop. Para la conmutación por error del plano de datos, cada nodo Docker que puede tener un lease de Availability ejecuta el lease watchdog como servicio root con systemd u OpenRC; lo instala el instalador de nodos Docker.

Un nodo Docker también necesita que Docker dé a sus contenedores los controladores de cgroup memory, pids y cpu; en caso contrario, el instalador se niega a registrar el nodo. Un invitado LXC de Alpine con OpenRC suele necesitar antes una configuración de cgroups; consulta Invitados Alpine, OpenRC y LXC. Un Build Worker necesita systemd. Los daemons de monitorización, Docker, nginx y Relay pueden ejecutarse sin root; consulta Ejecuta un daemon sin root.

La separación de roles es una decisión operativa y de seguridad. Un nodo Storage debe tener políticas de almacenamiento y de copias de seguridad adecuadas para servicios con estado. Un Build Worker procesa entradas de build controladas por el repositorio y no debe compartir host con cargas de trabajo no relacionadas ni con credenciales de infraestructura reutilizables. Trata la VM externa del worker o su contenedor de sistema sin privilegios como el límite de seguridad; el sandbox interno del build es defensa en profundidad, no el único límite.

Un nodo Docker normalmente necesita el control del Docker Engine local. Quien controla ese camino del daemon puede crear contenedores privilegiados, montar rutas del host y afectar a otras cargas de trabajo del mismo motor. Trata un nodo Docker como equivalente a root dentro del límite de confianza de Docker de ese host; usa un host dedicado o un límite de cargas de trabajo aceptado deliberadamente en lugar de suponer que los ámbitos de recursos aíslan a un administrador del host comprometido.

DNS y certificados

Decide si Opfield gestionará el DNS a través de Cloudflare o si los registros seguirán gestionándose externamente. La emisión de certificados con HTTP-01 requiere el puerto 80 público en el nodo de ingress asignado. DNS-01 requiere una integración con un proveedor configurada con los permisos mínimos necesarios para crear los registros de desafío. Los certificados subidos necesitan un responsable de la renovación y de la supervisión de la caducidad.

Usa para la URL inicial de Opfield un nombre de host que ya esté cubierto por un certificado de confianza. Las advertencias del navegador durante el arranque fomentan soluciones poco seguras y pueden ocultar problemas reales de proxy o de nombre de host.

Lista de comprobación de preparación

Antes de ejecutar el instalador, confirma todo lo siguiente:

El nombre de host canónico se resuelve al endpoint previsto.
La terminación TLS y quién es responsable de las cabeceras reenviadas están documentados.
Existen almacenamiento persistente y un destino de copias de seguridad fuera del host.
Las reglas del cortafuegos cubren la aplicación web, Relay y los servicios salientes necesarios.
Se ha identificado al primer administrador y a un segundo responsable de la recuperación.
Los roles de los nodos y el aislamiento de los hosts son intencionados.
Las expectativas de retención, auditoría, notificaciones y SIEM están documentadas.
Los derechos del plan necesarios están disponibles.

Si alguna de estas decisiones es desconocida, detente antes de poner en marcha cargas de trabajo de producción. Es mucho más seguro cambiar la topología, el DNS o la autenticación antes de que los nodos y las integraciones dependan de ellos.

Consulta Puertos y red antes de cambiar los cortafuegos.