Despliegue de Aplicaciones con Docker Compose: Frontend y Backend
Contenido del curso
Cristian Pisco Intriago
José Pablo Jiménez Cucanán
Iván Andrés Pineda Salazar
Abraham Siso
Daniela Quintana
Amin Espinoza
Profesor
Gabriel Enrique Ortega Colmenares
Alba Nubia Giraldo Molina
Amin Espinoza
Profesor
Guillermo Jimenez
Iván Andrés Pineda Salazar
Amin Espinoza
Profesor
José Fabián Beltrán Meza
Airy Nieves
Daniel Eduardo Rojas Pulido
IVAN CARAPIA BARAJAS
José Pablo Jiménez Cucanán
Amin Espinoza
Profesor
Johan Puentes
Amin Espinoza
Profesor
Jose Emmanuel Chavez Narvaez
Ivan David Martinez Baron
Amin Espinoza
Profesor
Gustavo Pú
Daniela Quintana
Jair Israel Avilés Eusebio
Mario Alexander Vargas Celis
Luis Uriel Lugo Ramírez
Stephanie Martha Peñaloza Cortés
Amin Espinoza
Profesor
Cristian Mora Jimenez
Jose Elier Fajardo
Ruben Galindo
ROMMEL DUAREZ SAENZ
Martín Correa
Mauro Benito Montoya Arenas
El ejemplo de esta clase funciona muy bien como ambiente de desarrollo. Sin embargo, la práctica más común que se hace cuando se lo quiere llevar a un ambiente de desarrollo y producción es crear un REVERSE PROXY, este proxy puede ser un nuevo servicio en el docker-compose o agregarlo en el Dockerfile del servicio frontend.
En mi caso lo agregué en el servicio frontend. el Dockerfile del frontend quedaría así:
FROM nginx:latest
COPY /website /usr/share/nginx/html COPY nginx.default.conf /etc/nginx/conf.d/default.conf
Dentro de la carpeta frontend crear el archivo nginx.default.conf que contiene lo siguiente:
server { listen 80; server_name localhost; index index.html; root /usr/share/nginx/html; location / { try_files $uri $uri/ =404; add_header Cache-Control "no-cache"; } location /api { proxy_pass <URL>; } }
El cambio que hice en el backend fue cambiar el endpoint
@app.route('/getMyInfo') → @app.route('/api/getMyInfo')
Agregué la librería flask-cors en el archivo requirements.txt
Flask==3.0.0 waitress==2.0.0 flask-cors==3.0.10 # app.py import json from flask import Flask from flask_cors import CORS
app = Flask(__name__) CORS(app)
@app.route('/api/getMyInfo') def getMyInfo(): value = { "name": "Amin", "lastname": "Espinoza", "socialMedia": [ {"facebookUser": "aminespinoza10"}, {"instagramUser": "aminespinoza10"}, {"xUser": "aminespinoza"}, {"linkedin": "amin-espinoza"}, {"githubUser": "aminespinoza10"} ], "blog": "", "author": "Miranda Espinoza" } return json.dumps(value)
reverse proxy es muy útil. A mi me ha servido para acceder a múltiples servicios en contenedores desde un único diminio
Gracias Cristian, buen aporte.
En 2025 no es necesario incluir la version en el docker-compose.yml
Si tienes mac y tienen error con el puerto 5000, sólo desactiva el AirPlay y listo :)
Oh!!! Muy buen tip!! Gracias por eso Daniela!!
genia !
Amin, falta cargar los recursos 😉
Muchas gracias Alba, ya lo notificaré
Siguen sin estar los recursos
Si mencionas recursos, se espera que estén disponibles, pero en varios vídeos ha habido el mismo problema. Platzi hay que prestar atención a esos detalles.$$$$
Gracias por hacerlo notar, ya veré que podemos hacer.
Los cargaron en el video anterior
La clase se centra en el despliegue de aplicaciones con Docker Compose, que permite orquestar contenedores de frontend y backend. Aquí tienes un resumen de los comandos clave:
docker compose build: Compila las imágenes definidas en el archivo docker-compose.yaml.docker compose up: Inicia los contenedores y establece la red entre ellos.docker compose down: Detiene y elimina los contenedores y redes creados.Estos comandos son esenciales para gestionar la creación y ejecución de contenedores, facilitando la comunicación entre el frontend y el backend de la aplicación sin conflictos.
Muy completa la info, gracias
Se puede ejecutar docker-compose up en segundo plano usando el flag -d (diminutivo de Detached)
¡Es correcto! ¡Gracias por el aporte!
algo a considerar es que no podemos usar cualquier puerto, la razón principal de usar puertos superiores al 3000 o muy superiores a los primeros puertos, es por el hecho de que algunos puertos están reservados para operaciones del sistema operativo y programas de uso cotidiano, puedes usar el que quieras pero ten en cuenta esto cuando hagas deploy o desarrolles un proyecto.
Eso es cierto, sin embargo creo que al mencionar "cualquier puerto" es que ya estamos dando por hecho que hay algunos "sagrados" como el 80, 8080 o 443.
Es una buena practica poner los puertos entre comillas para evitar que YAML los interprete erroneamente como numeros en base 60
ports: - "8080:80"
Lo que no me queda claro es porque ambas imagenes se cargan en un mismo contenedor. No se supone que cada imagen va en un contenedor?
De hecho se cargan en una "lista de contenedores", lo que Compose hace es solo unificarlos como una especie de orquestador, si expandes este contenedor podrás ver ahí todos los demás!
1. Crear un archivo docker-compose.yml
Este archivo YAML define todas las configuraciones necesarias para desplegar los contenedores, incluyendo las imágenes a utilizar, los puertos a exponer, las dependencias entre servicios, volúmenes para persistencia de datos, y más.
Ejemplo de un docker-compose.yml para una aplicación web y su base de datos:
version: '3'
services:
web:
image: my-web-app:latest
ports:
- "5000:5000"
depends_on:
- db
networks:
- mynetwork
db:
image: postgres:latest
environment:
POSTGRES_PASSWORD: mysecretpassword
networks:
- mynetwork
networks:
mynetwork:
En este ejemplo:
my-web-app:latest, mapeando el puerto 5000 del host al puerto 5000 del contenedor y dependiendo del servicio de base de datos.postgres:latest con una variable de entorno para la contraseña.2. Iniciar los servicios con Docker Compose
Una vez que tienes tu archivo docker-compose.yml configurado, puedes usar Docker Compose para desplegar tus servicios.
Este comando busca el archivo docker-compose.yml en el directorio actual, construye las imágenes si es necesario (si has especificado un contexto de construcción en lugar de una imagen preconstruida), crea los contenedores y los inicia.
Este comando detiene y elimina los contenedores, redes, y otros recursos creados al iniciar los servicios.
3. Escalar servicios
Docker Compose también permite escalar servicios fácilmente, aumentando o disminuyendo el número de réplicas de contenedores que se están ejecutando.
Este comando aumentaría el número de contenedores del servicio web a tres.
Conclusión
Desplegar un conjunto de imágenes con Docker y Docker Compose te permite gestionar aplicaciones compuestas por múltiples servicios de una manera mucho más sencilla y reproducible, tanto en desarrollo como en producción.
Aún no están los recursos para descargar -.-
Esta en la clase anterior
Devuélvete al anterior video.
La capacidad de Docker de usar DNS interno se conoce como "service discovery" o "descubrimiento de servicios". Esto permite que los contenedores se comuniquen entre sí utilizando nombres de host en lugar de direcciones IP. Cuando se crea una red en Docker, se asigna un nombre a cada contenedor, y estos pueden resolverse mediante el DNS interno de Docker, facilitando la comunicación entre servicios sin necesidad de configurar direcciones IP manualmente. Esto es clave al trabajar con Docker Compose, donde los contenedores se agrupan en una red específica.
No encuentro los recursos :(
Gracias por decirlo! Veremos que pasa.
Están en la clase 17
Para los que estan buscando los recursos de la clase, los encontre en un repo de Platzi. Aca se los dejo:
¿Cuándo debo usar la instrucción depends_on?
Imagina que tu aplicación es un restaurante. El frontend son los meseros y el backend es la cocina. Si los meseros empiezan a tomar órdenes antes de que la cocina esté abierta, habrá un caos. La instrucción depends_on en tu archivo docker-compose.yml garantiza exactamente este orden lógico de encendido.
Debes usarla siempre que un servicio necesite que otro esté funcionando previamente para no colapsar. En arquitecturas modernas, es común que una interfaz web intente consumir datos de una API apenas arranca. Si el backend tarda unos segundos más en levantar, el frontend arrojará errores de conexión. Al declarar depends_on: - backend, le dices a Docker Compose que ponga en pausa el despliegue del frontend hasta que el contenedor del backend esté completamente creado y listo para recibir peticiones. Es una regla de oro para evitar errores de sincronización en tus despliegues.
en clase no dejo claro como debía ser el docker-compose.yml para que el contenedor backend solo pudiese ser accedido desde dentro de la red de docker compose?
Hola ROMMEL. Para que el contenedor del backend solo sea accesible internamente y no desde fuera (tu máquina local), simplemente debes eliminar la sección ports de su configuración en el archivo docker-compose.yml.
Al quitar los puertos, Docker no mapeará el servicio a tu máquina, pero el backend seguirá siendo accesible para el frontend a través de la red interna de Docker, usando el nombre del servicio (ej. backend) como host.
Tu configuración quedaría así:
services: backend: build: ./backend # Sin la sección 'ports', no se expone al exterior frontend: build: ./frontend ports: - "8080:80" depends_on: - backend
De esta forma, el frontend se comunica con el backend mediante el nombre http://backend:5000, manteniendo el backend aislado de conexiones externas.
Te recomiendo revisar Redes en Docker: Configuración y Gestión Eficiente de Contenedores para profundizar en cómo funcionan estas comunicaciones internas.
Es verdad que el puerto es una elección personal, pero hay que tener en cuanta que hay convenciones en la industria y varios puertos ya estan reservados para otras cosas
Ahora en docker-compose.yaml no se necesita colocar la version.