Cómo construir un servidor doméstico de desarrollo para Git, imágenes de Docker, bases de datos y aplicaciones de vista previa
Crea una plataforma de servicios estable, separa los datos persistentes de los artefactos que se pueden reconstruir y asegúrate de que todos los servicios de desarrollo puedan recuperarse sin tener que conservar el propio host.
Para uno o dos desarrolladores en casa, un único servidor Linux puede alojar Git, un registro de imágenes, bases de datos y aplicaciones de vista previa. El diseño sigue siendo manejable solo si se planifican la identidad, las funciones del almacenamiento, la exposición a la red, las copias de seguridad y la restauración antes de que los servicios empiecen a depender unos de otros.
Asigna funciones de servicio antes de elegir el hardware
Trata Git, el registro de contenedores, los motores de bases de datos y las aplicaciones de vista previa como funciones de servicio independientes, aunque compartan un mismo host. Git conserva el historial del código fuente; el registro almacena artefactos que se pueden reconstruir; las bases de datos contienen el estado mutable de las aplicaciones; las aplicaciones de vista previa son entornos de ejecución desechables.
Calcula la CPU y la memoria según las compilaciones simultáneas, los conjuntos de datos de las bases de datos y las vistas previas activas. Calcula el almacenamiento según los repositorios, la retención del registro, el crecimiento de las bases de datos, los registros y el espacio temporal para copias de seguridad. Así evitarás comprar un disco grande y que la memoria siga siendo el primer cuello de botella.
Al principio, usa un único nodo de computación si es aceptable que falle durante el desarrollo. Más adelante, separa los nodos de compilación si las compilaciones intensivas empiezan a saturar las bases de datos o las vistas previas interactivas.
Separa los datos persistentes, reconstruibles y de recuperación
| Función de los datos | Ejemplos | Protección |
|---|---|---|
| Estado persistente | Repositorios Git, volúmenes de bases de datos | Instantáneas más copia de seguridad independiente |
| Artefactos que se pueden reconstruir | Imágenes de contenedor, caché de compilación | Política de retención; copia de seguridad opcional |
| Secretos y configuración | Claves de despliegue, archivos de entorno | Exportación cifrada y copia de recuperación sin conexión |
| Medios de recuperación | Instalador del sistema operativo, notas de restauración | Almacenado fuera del servidor |
No hagas copias de seguridad de todos los bytes por igual. Por lo general, se puede reconstruir un registro a partir del código fuente y las instrucciones de compilación; una base de datos, no. Almacena los volcados de la base de datos o las instantáneas coherentes por separado del volumen activo de la base de datos.
Un plan práctico de copias de seguridad autohospedadas demuestra el valor de automatizar Git y las copias externas como tareas distintas, en lugar de asumir que el NAS en sí es la copia de seguridad.
Crea una vía de acceso privado
Asigna al servidor una dirección LAN estable y un nombre DNS local. Expón las rutas de Git, el registro, la base de datos y las vistas previas solo a las redes que las necesiten. El acceso remoto debe realizarse mediante una VPN privada o una ruta de proxy inverso autenticada, no mediante una serie de puertos de servicios redirigidos.
Usa cuentas de servicio y claves de despliegue independientes. Los desarrolladores no deberían compartir una contraseña de administrador, y las aplicaciones de vista previa no deberían heredar credenciales que permitan modificar los repositorios de Git o el registro.
Elige SMB o NFS solo para flujos de trabajo con archivos que realmente necesiten un montaje compartido. La guía para elegir entre clientes SMB y NFS ayuda a mantener separada la elección del protocolo del acceso a los servicios de aplicaciones.
Haz que el orden de despliegue coincida con el grafo de dependencias
Inicia los montajes de almacenamiento, la identidad, las bases de datos, el registro, Git y, por último, las aplicaciones de vista previa. Las comprobaciones de estado deben probar dependencias reales, sin reiniciar una base de datos lenta solo porque una aplicación siga iniciándose.
Mantén las definiciones de despliegue, las migraciones del esquema y las rutas del proxy inverso bajo control de versiones. Mantén los secretos fuera del repositorio e indica claramente dónde restaurarlos. Un host de reemplazo debería poder recrear los servicios a partir de las definiciones y del estado protegido.
Valida la configuración volviendo a crear una aplicación de vista previa a partir de una copia limpia del repositorio, descargando su imagen, aplicando una restauración de prueba de la base de datos y accediendo a ella desde la ruta de cliente prevista.
Haz copias de seguridad para restaurar, no para acumular
Haz copias de seguridad de los repositorios, los volcados nativos de la base de datos, la configuración de los servicios y los secretos cifrados en un destino que no esté montado con permisos de escritura para todos los servicios. Conserva al menos una copia fuera del ámbito de alimentación eléctrica y administración del servidor.
Cada trimestre, restaura en un espacio de nombres aislado. Confirma los usuarios, las extensiones, las tareas programadas, los permisos de los repositorios, la autenticación del registro y las rutas DNS; no te limites a comprobar que los archivos estén presentes.
Amplía la configuración cuando las colas de compilación retrasen el trabajo interactivo, aumente la latencia de la base de datos durante la carga de imágenes o las ventanas de copia de seguridad coincidan con la jornada laboral. Deja de añadir roles al mismo host cuando un servicio experimental pueda agotar los recursos o las credenciales que necesita el plano de servicios estables.
Regla final de configuración
La configuración está lista cuando cada servicio tiene un rol asignado, un estado protegido, una ruta de acceso controlada, una restauración probada y un criterio medible para dividir o ampliar la topología.
Productos recomendados
Configuración de NAS y servidores
Más para leer
¿Puede un servidor en una residencia estudiantil funcionar lo bastante silenciosamente como para dormir, estudiar y hacer videollamadas?
Sí, un servidor para una residencia universitaria puede pasar desapercibido si el hardware consume poca energía, se controlan las vibraciones del almacenamiento, se programan...
Un laboratorio doméstico estudiantil que puede pasar de la habitación de la residencia universitaria al primer apartamento
Mantén portátil el laboratorio doméstico de un estudiante separando los servicios de la red específica de cada habitación, minimizando el hardware, haciendo copias de...
Cómo compartir un servidor doméstico con tus compañeros de piso sin compartir cuentas ni archivos privados
Asigna a cada compañero de piso una identidad con nombre, almacenamiento privado y solo los roles compartidos que necesite; mantén la administración, las copias...
