Crear un balanceador de carga con NGINX en Docker es más sencillo de lo que parece. Aquí verás cómo preparar tres sitios estáticos en contenedores, conectarlos a una misma red de Docker y poner al frente un reverse proxy que actúe como endpoint para distribuir el tráfico entre ellos. La experiencia es visual y práctica: al refrescar, verás rotar “primera versión”, “segunda versión” y “tercera versión”.
¿Cómo construir el escenario de balanceo con NGINX y Docker?
La idea central es armar tres sitios casi idénticos con NGINX y un cuarto contenedor que funcione como proxy reverso. Todo se conecta por una red personalizada para que los contenedores se resuelvan por nombre.
- Estructura clara de carpetas y archivos.
- Imágenes propias para cada sitio con un Dockerfile mínimo.
- Un proxy NGINX que escuche en el puerto 80 y reparta solicitudes.
- Un contenedor expuesto en el host, por ejemplo con 8080:80.
¿Qué estructura de carpetas y archivos se crea?
- Carpeta principal: carga.
- Subcarpetas: sitio uno, sitio dos, sitio tres.
- En cada sitio: Dockerfile que usa la imagen base de NGINX y una página HTML simple con el texto “Mi página de inicio personalizada” variando en “primera/segunda/tercera versión”.
- Carpeta proxy: con un Dockerfile para NGINX y el archivo nginx.conf.
Ejemplo conceptual del Dockerfile del proxy:
# Dockerfile (proxy)
FROM nginx
# Copiar nginx.conf a la carpeta de configuración de NGINX.
¿Cómo se configura el reverse proxy con nginx.conf?
- Se define NGINX como reverse proxy en el puerto 80.
- Se enruta el tráfico a servidores llamados: backend uno, backend dos, backend tres.
- Es crucial que los contenedores de los sitios usen esos nombres para que el proxy los encuentre.
Fragmento conceptual de nginx.conf:
upstream backend {
server backend uno;
server backend dos;
server backend tres;
}
server {
listen 80;
location / {
proxy_pass http://backend;
}
}
¿Cómo se crean imágenes y contenedores en la red?
- Crear la red de trabajo para comunicación interna.
- Construir imágenes de los tres sitios.
- Ejecutar contenedores con nombres que coincidan con nginx.conf.
- Construir y levantar el contenedor del proxy exponiendo el puerto al host.
Comandos ilustrativos:
# Red para el balanceo.
docker network create red_balance
# Construcción de imágenes de los sitios.
docker build -t server uno ./sitio uno
docker build -t server dos ./sitio dos
docker build -t server tres ./sitio tres
# Contenedores backend en la red.
docker run -d --name Backend uno --network red_balance server uno
docker run -d --name Backend dos --network red_balance server dos
docker run -d --name Backend tres --network red_balance server tres
# Imagen y contenedor del proxy.
docker build -t proxy ./proxy
docker run -d --name Load Balancer -p 8080:80 --network red_balance proxy
Verificación útil:
Habilidades y conceptos en práctica:
- Dockerfile: definición mínima de una imagen basada en NGINX.
- Imagen y contenedor: construir con docker build y ejecutar con docker run.
- --name y --network: nombrar contenedores y conectarlos a una red común.
- Puertos: mapear 8080:80 para acceder desde el navegador.
- Docker Desktop y terminal: confirmación visual y por comandos.
- Endpoint: única puerta de entrada que distribuye tráfico internamente.
¿Qué comandos de Docker necesitas para red y contenedores?
Los comandos clave construyen el flujo completo desde cero hasta la verificación final. Usa banderas con precisión para que los nombres coincidan con tu configuración de NGINX.
- docker network create: crea la red red_balance.
- docker build -t: genera imágenes para server uno/dos/tres y para proxy.
- docker run -d: levanta contenedores en segundo plano.
- --name: asigna nombres como Backend uno/dos/tres y Load Balancer.
- --network: conecta todos los contenedores a red_balance.
- -p 8080:80: expone el servicio del proxy al host.
- docker ps y docker images: verifican contenedores e imágenes vigentes.
Buenas prácticas del flujo:
- Nombrar de forma consistente para que el reverse proxy resuelva por nombre.
- Construir primero las imágenes y luego ejecutar los contenedores.
- Limpiar la terminal y validar con docker ps antes de seguir.
¿Qué se logra con el endpoint y cuándo considerar un orquestador?
El contenedor del proxy reverso actúa como endpoint. Al entrar por 8080, reparte solicitudes entre los tres backends y muestra “primera/segunda/tercera versión” al refrescar, evidenciando el balanceo de carga. Este patrón permite usar un contenedor como “embudo” que redirige el tráfico a múltiples servicios internos con nombres predecibles.
En entornos reales, un orquestador de contenedores puede encargarse de gestionar este reparto sin intervención manual. Aun así, este ejercicio didáctico es ideal para comprender redes de Docker, nombres de servicio y la integración de NGINX como reverse proxy.
¿Te gustaría comentar cómo extenderías este setup, por ejemplo agregando más sitios o variando los nombres de backend para probar distintos escenarios?
