Compose en equipo: override

Trabajar en equipo con Docker Compose puede generar fricciones cuando cada desarrollador necesita personalizar su entorno sin alterar el archivo compartido en el repositorio. La solución está en una herramienta que permite hacer cambios locales sin afectar a los demás: Docker Compose Override. Además, escalar servicios horizontalmente con un solo comando abre posibilidades para probar concurrencia y carga de forma sencilla.

¿Qué es Docker Compose Override y por qué resuelve conflictos en equipo?

El archivo docker-compose.yml suele estar versionado en Git, lo que significa que cualquier cambio personal al entorno de desarrollo genera modificaciones que no queremos commitear. Tener un archivo trackeado que cambiamos constantemente pero que no debemos subir resulta incómodo y propenso a conflictos [01:00].

Compose Override es simplemente otro Compose File con un nombre especial: docker-compose.override.yml. Este archivo permite personalizar o sobreescribir definiciones del archivo base sin tocarlo. Se crea con un simple comando [02:22]:

bash touch docker-compose.override.yml

Si el archivo se llama exactamente así, Docker Compose lo detecta automáticamente. Si tiene otro nombre, hay que indicárselo con una opción adicional.

¿Cómo funciona la herencia entre el archivo base y el override?

El mecanismo funciona de forma similar a una herencia de clases [04:30]. El override puede redefinir propiedades específicas de un servicio sin necesidad de repetir todo lo demás. Por ejemplo, si el archivo base define un servicio app con una imagen, el override puede indicar que se haga un build en su lugar:

yaml version: "3.8" services: app: build: .

Cuando se combinan image y build en un mismo servicio, Docker Compose construye la imagen y le asigna el nombre indicado en image, en lugar del nombre por defecto [05:02].

¿Qué propiedades se combinan y cuáles generan conflicto?

Para las variables de entorno, Docker Compose hace un merge inteligente. Si el archivo base define MONGO_URL y el override agrega una variable distinta, ambas estarán disponibles en el contenedor [05:40]. Esto se puede verificar entrando al contenedor:

bash docker compose exec app bash env

Si el override define la misma variable que el base, el override tiene precedencia y la sobreescribe.

Sin embargo, los puertos no se combinan bien entre ambos archivos [06:30]. Es recomendable definir ports en un solo lugar, ya que procesarlos en etapas distintas puede generar errores irreconciliables.

Un dato curioso mencionado durante la práctica: las versiones iniciales de Docker Compose nacieron como un proyecto open source llamado Fig, que Docker adquirió y renombró [03:05]. Muchos desarrolladores aún usan fig como alias por comodidad.

¿Cómo escalar servicios horizontalmente con Docker Compose?

Docker Compose permite levantar múltiples instancias de un servicio con la opción --scale [08:20]:

bash docker compose up -d --scale app=2

Este comando intenta crear dos contenedores del servicio app. El problema surge cuando hay un port binding fijo: no es posible tener dos contenedores escuchando en el mismo puerto del host.

La solución es definir un rango de puertos en el archivo Compose [09:10]:

yaml ports:

• "3000-3001:3000"

Con esta configuración, Docker asigna el puerto 3000 del host al primer contenedor y el 3001 al segundo. Ambos apuntan al puerto 3000 dentro de sus respectivos contenedores. Se puede ampliar el rango a 3000-3010 si se necesitan más instancias.

Esta capacidad es muy práctica para probar programación concurrente o verificar que no existan problemas de escala, enviando peticiones a distintas instancias de un mismo servicio [10:25]. Si se necesita un único punto de entrada, habría que agregar un balanceador de carga, pero eso ya es otra configuración.

¿Cómo mantener limpio el repositorio con override?

Al hacer git status, el archivo docker-compose.override.yml aparece como no trackeado, mientras que el docker-compose.yml permanece sin modificar [07:50]. Esto significa que cada desarrollador puede tener su propio override sin riesgo de generar conflictos.

• Agregar docker-compose.override.yml al .gitignore evita commits accidentales.
• Cada persona personaliza su entorno sin "pisarse los talones".
• El archivo base se mantiene estable y compartido.

Para limpiar todo al terminar, basta con ejecutar:

bash docker compose down

Esto elimina todos los contenedores creados, incluyendo múltiples instancias escaladas y bases de datos, sin necesidad de comandos adicionales [11:00].

Estas herramientas —override, escalamiento horizontal y gestión colaborativa— son las que se usan en el día a día profesional con Docker. La esencia no cambia con aplicaciones más complejas; lo que varía es la cantidad de servicios y configuraciones. Si estás comenzando a trabajar con Docker Compose en equipo, te invitamos a probar el override en tu próximo proyecto y compartir tu experiencia.