Levantar el compose equivocado sobre producción
Un archivo de composición pensado para desarrollo, ejecutado en el servidor de producción, publica puertos, monta volúmenes distintos y puede recrear servicios con configuración de prueba. Cómo se hace imposible en vez de recordarlo.
El archivo de composición de desarrollo existe para trabajar cómodo: publica puertos para entrar desde la máquina propia, monta el código como volumen, usa credenciales de prueba y a veces levanta servicios auxiliares que en producción no van.
Ejecutado por error en el servidor de producción, cada una de esas comodidades es un problema distinto, y varias no dan ningún error.
Qué pasa exactamente
| Diferencia del archivo de desarrollo | Consecuencia en producción |
|---|---|
| Publica puertos | Servicios internos quedan accesibles desde internet, saltándose el firewall |
| Monta el código local | El contenedor sirve archivos que no existen o son de otra versión |
| Credenciales o variables de prueba | La aplicación arranca apuntando a otra base, o sin la configuración real |
| Nombres de volumen distintos | Los datos aparecen vacíos: están en el volumen anterior, intactos, pero el servicio ya no los ve |
Esa última merece una aclaración, porque es el momento de pánico: si el volumen cambió de nombre, los datos siguen ahí. Antes de intentar restaurar nada, conviene listar los volúmenes existentes.
Por qué pasa
Las cuatro formas de equivocarse
- El nombre del archivo por defecto. La herramienta toma uno automáticamente; si el de desarrollo tiene ese nombre, se usa sin que nadie lo elija.
- Un archivo de sobrescritura que se aplica solo. Hay convenciones donde un segundo archivo se suma automáticamente al principal, y eso sorprende.
- Estar en el directorio equivocado, con dos aplicaciones que tienen archivos parecidos.
- Copiar un comando de la documentación de desarrollo y pegarlo en la sesión del servidor.
Cómo se vuelve difícil de hacer mal
Lo que funciona no es el cuidado sino la asimetría: que el camino cómodo sea el correcto y el peligroso requiera esfuerzo.
Cinco medidas concretas
- Un archivo por entorno, con nombres explícitos, y ninguno con el nombre por defecto. Levantar algo exige nombrar cuál.
- Un script de despliegue que sea la única forma de desplegar, con el archivo correcto adentro. Nadie escribe comandos a mano.
- Nombre de proyecto fijo y explícito, para que los volúmenes y las redes no dependan de en qué carpeta estás parado.
- El archivo de desarrollo, fuera del servidor. Si no está, no se puede ejecutar por accidente.
- Variables por entorno con nombres distintos, para que arrancar con las de prueba falle en vez de funcionar a medias.
Antes de seguir, predecí
Qué hacer si ya pasó
El orden que evita empeorarlo
- Bajar lo que se levantó mal, para que deje de servir con configuración de prueba.
- Inventariar: qué contenedores hay, qué volúmenes existen, qué puertos quedaron publicados.
- Restaurar la definición correcta y levantar con ella, verificando que use los volúmenes originales.
- Revisar la exposición, porque unos minutos de puertos abiertos alcanzan para que alguien entre si había un servicio sin contraseña.
- Recién ahí, respaldos, si efectivamente falta algo.
Más a fondo · nivel seniorLa definición de producción como código, no como archivo suelto
La causa de fondo es que la configuración de producción vive en archivos que alguien edita en el servidor. Tenerla versionada en el repositorio, desplegada por un script y con el archivo de desarrollo fuera del servidor cambia el problema: el error deja de ser posible por accidente y pasa a requerir una decisión deliberada. Es la misma idea que hace que un despliegue sea reproducible.
Qué quedó pasando, diferencia por diferencia
Se corrió el archivo de desarrollo en producción. Las cinco diferencias entre un archivo y el otro.
Cómo se vuelve imposible
Cierre
Autoevaluación
¿Lo entendiste?
Práctica