Conecta una aplicación a una base de datos privada

Este recorrido da a una aplicación acceso privado a una base de datos sin publicar el puerto de la base de datos y sin compartir la credencial de propietario de la base de datos. Opfield crea una vinculación duradera (la relación gestionada entre una carga de trabajo y una base de datos) y aprovisiona una identidad del motor dedicada para esa relación.

Si es tu primer flujo de trabajo con bases de datos, lee la visión general de bases de datos, prepara una base de datos gestionada y revisa cómo se comportan las vinculaciones de aplicaciones antes de crear datos de producción.

La carga de trabajo recibe solo los valores de conexión que necesita. Retirar el acceso de la aplicación y eliminar la base de datos son operaciones separadas.

Decide si una base de datos gestionada es adecuada

Usa una instancia PostgreSQL, clave-valor o ClickHouse gestionada por Opfield cuando quieras que Opfield sea responsable del aprovisionamiento, del ciclo de vida en ejecución, de los ajustes de capacidad, de las credenciales, de la monitorización y de las vinculaciones privadas con cargas de trabajo en un nodo Storage. Usa una conexión externa cuando otra plataforma ya ejecuta la base de datos y Opfield solo guarda la conexión y ejecuta contra ella comprobaciones de estado, Explorer, Console y copias de seguridad. Las vinculaciones, y por tanto este recorrido, solo se aplican a las bases de datos gestionadas; una aplicación que usa una base de datos externa recibe sus valores de conexión como secretos de la carga de trabajo. Compara ambos modelos en Bases de datos gestionadas y externas de un vistazo.

Antes de crear datos, aprueba:

• el motor de base de datos y la versión compatible;
• el nodo Storage y la ubicación del almacenamiento duradero;
• los límites de CPU, memoria, swap y almacenamiento;
• quién es responsable de la copia de seguridad, la retención, la restauración y la eliminación;
• si realmente se necesita la publicación TCP directa;
• qué recurso de aplicación recibirá la vinculación;
• los límites de conexiones esperados y el comportamiento de reintentos de la aplicación.

Eliminar una base de datos gestionada es destructivo y elimina su disco o imagen gestionados, o su montaje, junto con la instancia. Eliminar una conexión o una vinculación no es la misma acción. Deja clara esta distinción en los permisos de los operadores y en los runbooks.

1. Prepara el nodo Storage

Registra un nodo Storage dedicado y verifica su comprobación previa de almacenamiento. Los nodos Storage usan almacenamiento gestionado de tamaño fijo con aplicación del límite en el host. El instalador comprueba el Docker Engine local y el ciclo de vida de los dispositivos loop, montaje, escritura, crecimiento, redimensionamiento, desmontaje y liberación que usan las instancias gestionadas.

Una VM o un host físico normalmente exponen estas capacidades directamente. Un invitado LXC requiere permisos explícitos de dispositivos loop y de montaje por parte de su host externo; Opfield no recurre a un volumen sin límites cuando falta el límite necesario.

El nodo debe estar en línea, tener suficiente almacenamiento sin asignar para la base de datos solicitada y un destino de copias de seguridad documentado. No coloques contenedores de aplicaciones en un nodo Storage solo porque ambos usen Docker internamente.

2. Aprovisiona la base de datos de forma privada

Abre Databases, elige el motor y la versión compatibles, selecciona el nodo Storage y configura los límites de recursos y de almacenamiento. Mantén desactivado Publish TCP salvo que el acceso directo de clientes sea un requisito revisado. La publicación y su puerto del host se pueden cambiar más adelante en los ajustes de la base de datos; Opfield vuelve a crear entonces el contenedor de la base de datos y conserva sus datos, así que planifica una breve interrupción.

Espera a que el aprovisionamiento y las comprobaciones de estado lleguen a Ready. Confirma el motor, el nodo, la capacidad de almacenamiento, el estado de TLS y la monitorización que se muestran. No continúes desde un estado simplemente creado o en arranque.

Opfield mantiene interna la credencial de propietario del motor. Reveal credentials muestra un usuario de acceso directo aparte solo mientras la publicación TCP está activada; sirve para una administración externa controlada, no es la credencial que hay que copiar en cada aplicación.

3. Crea la vinculación de la aplicación

Abre el Container, el Deployment o el servicio de Compose de destino y crea un enlace a una base de datos gestionada. Selecciona la base de datos y las variables u opciones de conexión compatibles. Opfield crea un rol de PostgreSQL, un usuario ACL clave-valor o un usuario de ClickHouse distinto para esa vinculación.

Para un Container independiente, Opfield conecta la red privada de la vinculación y usa el flujo normal de recreación para aplicar el entorno de conexión. Para un Deployment, se actualiza la configuración deseada y se despliega un slot para que las futuras instancias blue y green reciban el mismo endpoint privado, servido por el conector de Secure Links compartido del nodo Docker de destino. Compose mantiene la vinculación asociada al servicio propietario y no al nombre de un contenedor hijo efímero. También se puede enlazar una carga de trabajo detenida, que falla o que todavía no se ha desplegado: la vinculación se guarda como pending y se aplica la próxima vez que la carga de trabajo arranque o termine su despliegue; consulta Cargas de trabajo que no están en ejecución.

Aplica o recrea la carga de trabajo solo cuando la interfaz indique que la configuración de ejecución modificada lo requiere. El estado deseado de la vinculación es duradero; una recreación normal de la carga de trabajo no debe crear un usuario del motor nuevo cada vez.

4. Verifica desde la aplicación

Usa la aplicación o un diagnóstico controlado dentro de la carga de trabajo para abrir una conexión y realizar una operación inofensiva específica del motor. Verifica que:

• el nombre de host, el puerto, el nombre de la base de datos y las credenciales proceden de la vinculación y no de credenciales de propietario copiadas; la vinculación se conecta por la red privada de la vinculación y no añade ajustes de TLS;
• la conexión funciona sin publicar el puerto del host de la base de datos;
• el motor ve el usuario específico de la vinculación;
• el comportamiento de las conexiones y las consultas coincide con los ajustes del pool de la aplicación, y los pools de todos los contenedores a los que sirve la base de datos se mantienen juntos por debajo del propio límite de conexiones de la base de datos, que comparten todos sus enlaces, igual que los dos slots de un Deployment durante un despliegue: max_connections de PostgreSQL (100 por defecto, entre 20 y 10000, que se fija en Database Settings → Maximum connections), maxclients del almacén clave-valor o 4096 para ClickHouse (Capacidad de los enlaces);
• la telemetría de ejecución de la vinculación pasa a estar en buen estado y muestra los flujos y el tráfico esperados;
• los logs de la carga de trabajo no imprimen los valores secretos.

Después recrea la carga de trabajo mediante su ciclo de vida normal de Opfield y repite la consulta. Reinicia el daemon de Docker o vuelve a conectar el nodo durante las pruebas de aceptación y confirma que la conciliación restablece el enlace y la vinculación sin generar un rol adicional. Un reinicio de Opfield no interrumpe el tráfico establecido de la vinculación; una actualización de Relay sí puede hacerlo.

Garantías y límites esperados

• La carga de trabajo no recibe la credencial de propietario de la base de datos.
• Cada vinculación recibe una identidad del motor distinta que se puede revocar de forma independiente.
• La recreación de la carga de trabajo conserva la propiedad deseada de la vinculación.
• La eliminación de la vinculación revoca su principal sin eliminar la base de datos.
• Las nuevas admisiones fallan de forma segura cuando no está disponible la base de datos, el daemon o el camino de Relay necesarios.
• La conciliación restablece el enlace de la vinculación y valida la identidad del motor existente en lugar de crear usuarios huérfanos ante fallos transitorios.

Una vinculación privada no es un sistema de copias de seguridad, de replicación ni de alta disponibilidad. La disponibilidad de la base de datos sigue dependiendo de la instancia gestionada, de su nodo, del almacenamiento y de tu diseño de recuperación. En Business y Enterprise, la propia base de datos puede ejecutarse en 2 a 5 nodos Storage, un primario y sus copias; las vinculaciones siempre llegan al primario (Bases de datos y almacenamiento en varios servidores). Las actualizaciones de Relay son mantenimiento explícito del plano de datos y pueden interrumpir las sesiones de los túneles; las actualizaciones de la aplicación o del plano de control y el mantenimiento de Relay son eventos distintos.

Fallos y recuperación segura

Si la vinculación está en mal estado, identifica primero qué capa no está disponible: la carga de trabajo de la aplicación, el nodo Docker, el conector de Secure Links del nodo, Relay, el nodo Storage, la instancia de base de datos, la identidad del motor o TLS. Inspecciona un historial de operaciones y unos logs acotados antes de cambiar el estado.

Prefiere la conciliación o un reintento concreto después de corregir la causa raíz. No elimines a mano las redes, los conectores ni los usuarios del motor propiedad de Opfield; eso puede convertir una caída de ejecución recuperable en una discrepancia de propiedad o en un problema de limpieza huérfana. No publiques el puerto de la base de datos solo para sortear un incidente del enlace privado.

Si hay que retirar el acceso de la aplicación, elimina la vinculación y verifica que se ha revocado su principal del motor. Si hay que eliminar la propia base de datos, confirma los requisitos de copia de seguridad y de retención y usa el flujo de eliminación de bases de datos gestionadas, sabiendo que se elimina su almacenamiento gestionado. Mantén separadas esas dos decisiones en la aprobación de cambios.

Mapa de diagnóstico

Síntoma	Comprueba primero	Guía detallada
La base de datos nunca llega a Ready	Nodo Storage, comprobación previa del almacenamiento, versión del motor, Task de aprovisionamiento	Bases de datos gestionadas
La vinculación está en mal estado	Base de datos, ambos nodos, Relay, enlace de la vinculación e identidad del motor	Vinculaciones de bases de datos para aplicaciones
Se deniega el acceso a la aplicación	Valores de conexión, modo TLS y principal específico de la vinculación	Operaciones con bases de datos
La vinculación falla tras reiniciar un nodo	Actualidad de los datos del nodo e historial de conciliación	Actualizaciones de nodos y comportamiento sin conexión
Se necesita acceso directo	Puerto TLS publicado y restricciones de red	Puertos y rutas de red