Ejecute Docker en un VPS con un plan operativo de producción
Docker facilita el empaquetado de una aplicación, pero que un contenedor sea accesible es solo el principio de su operación. Un VPS sigue necesitando un presupuesto de recursos, una exposición de red deliberada, datos recuperables y un proceso de publicación que alguien pueda mantener.
La conclusión práctica
Trate el proyecto Compose como una definición de aplicación reproducible, mantenga los datos persistentes de forma explícita, publique solo los puntos de entrada previstos y pruebe una ruta de recuperación antes de confiar en el despliegue.
Describa la aplicación y el límite de un solo host
Empiece con un diagrama que incluya el proxy inverso público, la aplicación, la base de datos, los workers y los archivos persistentes. Anote qué componentes deben comunicarse entre sí y cuáles necesitan acceso desde Internet. Un despliegue Compose pequeño puede ser un modelo operativo práctico para un VPS. No se convierte en un clúster de alta disponibilidad solo porque haya varios contenedores en ejecución.
Identifique las responsabilidades a nivel de host: actualizaciones del sistema operativo, mantenimiento de Docker, acceso administrativo, política de firewall y programación de copias de seguridad. El comportamiento de reinicio de los contenedores puede ayudar a recuperar un proceso detenido, pero no puede reparar datos perdidos, almacenamiento no disponible ni un host fallido. Decida qué hace el proyecto cuando todo el VPS no está disponible y cómo se recrearía la aplicación en otro lugar.
Compruebe el sistema operativo seleccionado y la arquitectura de la imagen de la aplicación con la documentación del software. Mantenga las comodidades de desarrollo separadas de las decisiones de producción. Un montaje bind del código fuente, el modo de depuración o una credencial solo local que resultaba útil en un portátil no deberían formar parte del despliegue público solo porque aparezcan en el mismo archivo Compose.
Presupueste juntos la memoria, la CPU y el disco temporal
| Componente | Asignación de memoria de ejemplo | Qué medir |
|---|---|---|
| Host y agentes de soporte | 1 GB | Sistema operativo y sobrecarga operativa habitual |
| Base de datos | 2 GB | Búferes, conexiones simultáneas y carga real de consultas |
| Procesos de la aplicación | 2 GB | Carga normal y picos de solicitudes realistas |
| Procesos en segundo plano | 1 GB | Importaciones, procesamiento de imágenes y tareas programadas |
| Margen sin asignar | 2 GB | Solapamiento de versiones y actividad operativa inusual |
Este presupuesto ilustrativo de 8 GB es un ejercicio de planificación, no un requisito medido ni una promesa de rendimiento del alojamiento. Confirme el uso real con la aplicación prevista y configure los controles de recursos adecuados para su configuración de Docker. Una base de datos y un proceso en segundo plano pueden alcanzar su pico a la vez aunque cada uno pareciera holgado en pruebas separadas. Un recuento de contenedores no sustituye de forma útil a una medición de la carga de trabajo.
La planificación del disco requiere más que el tamaño actual de la base de datos. Incluya imágenes, volúmenes persistentes, cargas de la aplicación, registros y espacio temporal durante las importaciones o los despliegues de la aplicación. Mantenga una reserva que permita tareas de investigación y recuperación. Si un despliegue necesita descargar una nueva imagen mientras conserva la anterior, un disco que ya está casi lleno puede convertir una actualización ordinaria en una interrupción del servicio.
Defina los datos persistentes y demuestre su recuperación
Utilice volúmenes con nombre explícitos o montajes bind cuidadosamente documentados para los datos que deben sobrevivir al reemplazo de un contenedor. Indique el propietario y la finalidad de cada montaje. Mantenga distinguibles en las notas operativas los archivos de base de datos, las cargas y las cachés desechables. La capa de escritura dentro de un contenedor individual no debe ser el único lugar donde exista un documento de cliente.
Un volumen de Docker persiste independientemente de un contenedor, pero la persistencia no es una copia de seguridad independiente. Elija un método de copia de seguridad consistente compatible con la base de datos, capture los archivos de aplicación relacionados y pruebe la restauración en un despliegue aislado. No asuma que copiar un volumen de base de datos en uso produce un punto de recuperación utilizable. Registre cómo se corresponden el volumen, la versión de la aplicación y el estado de la base de datos durante la recuperación.
Antes de adjuntar un montaje, confirme tanto su origen como su destino. Montar un volumen sobre un directorio puede ocultar archivos ya presentes en esa ruta del contenedor. Cuando una aplicación parece vacía inesperadamente tras un despliegue, compruebe el montaje real y el volumen seleccionado antes de realizar una limpieza destructiva. Es posible que los datos estén en otro volumen en lugar de ausentes.
Publique los puntos de entrada de forma deliberada y pruébelos desde el exterior
Normalmente el punto de entrada público es el proxy inverso, mientras que la base de datos de la aplicación solo es accesible a través de la ruta interna prevista. Distinga un puerto usado entre contenedores de un puerto publicado en el host. Evite exponer interfaces de base de datos, administración y métricas solo para facilitar una prueba de conexión. Proteja el acceso de gestión por separado del sitio web público.
Docker crea reglas de red y cortafuegos en Linux. El tráfico de sus puertos publicados puede eludir la ruta del cortafuegos del host que un operador espera al usar ufw. Siga la documentación de Docker para el backend de red y cortafuegos instalado y, a continuación, verifique el resultado desde fuera del VPS. Una lista tranquilizadora de reglas del host no demuestra que un puerto de contenedor publicado sea inaccesible.
Para la primera revisión de producción, enumere todos los puertos accesibles desde el exterior y asígneles una finalidad. Compruebe el nombre de host de la aplicación a través de HTTPS y confirme que las rutas administrativas no previstas no sean públicas. Mantenga la configuración privada fuera del código fuente de las imágenes y de los repositorios públicos. Revise los privilegios, montajes e interfaces del host concedidos a cada servicio en lugar de dar automáticamente acceso amplio a todos los contenedores.
Mantenga las versiones reproducibles y los registros acotados
Registre una versión o un digest explícito de la imagen para cada despliegue y conserve la configuración utilizada para desplegarla. Revise los ajustes de Compose específicos de producción, incluidos el comportamiento de reinicio, los puertos, el entorno y los montajes. Pruebe la aplicación de reemplazo antes de aceptarla. Revertir una imagen solo es seguro cuando los cambios de esquema de la base de datos siguen siendo compatibles o cuentan con su propio procedimiento de recuperación ensayado.
Establezca una política de registro deliberada. Los controladores de registro de Docker difieren, y la configuración predeterminada json-file puede crecer sin rotación. Elija una configuración acotada adecuada y confírmela en los contenedores que realmente se están ejecutando; cambiar un valor predeterminado del demonio no reconfigura automáticamente los contenedores existentes. Conserve eventos útiles de la aplicación sin registrar contraseñas, tokens ni cuerpos de solicitud sensibles completos.
- La imagen documentada y la configuración de Compose pueden recrear la aplicación.
- Los datos persistentes cuentan con un procedimiento de recuperación independiente y probado.
- Solo los puertos aprobados son accesibles desde fuera del VPS.
- Los registros tienen una política de tamaño y retención verificada.
- Un operador designado se encarga de las actualizaciones, la revisión de alertas y las comprobaciones tras cada despliegue.
Comience con un despliegue lo bastante pequeño como para comprenderlo. Añada complejidad de orquestación solo cuando un requisito medido lo justifique y el equipo pueda operar los componentes adicionales. Un plan de recuperación claro en un único host es más útil que una colección de contenedores cuyos datos y responsabilidades nadie puede rastrear.
