Diferencias

Muestra las diferencias entre dos versiones de la página.

--- clase:daw:daw:1eval:tema04.b [2026/10/16 18:30] – Reconstruir las imágenes: los tres problemas (imágenes, caché, código viejo) y la solución con down --rmi local + buildx prune + up claude
+++ clase:daw:daw:1eval:tema04.b [2026/10/28 09:26] (actual) – Movido a clase:daw:daw:1eval:tema05 claude
@@ Línea 1: / Línea 1: @@
-===== 4.b Despliegue avanzado en Servidor: Docker Compose =====
-Docker Compose es una herramienta que permite definir y administrar aplicaciones Docker de múltiples contenedores. Utiliza un archivo [[https://es.wikipedia.org/wiki/YAML|YAML]] para configurar los servicios, las redes y los volúmenes, facilitando la definición y el despliegue de aplicaciones complejas.
-==== Estructura Básica de un archivo docker-compose.yml ====
-Un archivo ''docker-compose.yml'' define la configuración de una aplicación multi-contenedor. Aquí se presentan las secciones principales:
-<sxh>
-services:
-  nombre_contenedor_1:
-    image: imagen_servicio1
-    restart: opciones si se reinicia el servidor
-    hostname: nombre del host
-    volumes:
-      - /ruta/host:/ruta/contenedor
-    ports:
-      - "puerto_host:puerto_contenedor"
-    environment:
-      - VARIABLE=valor
-    tty: true
-    stdin_open: true
-    pull_policy: never
-  nombre_contenedor_2:
-    # Configuración del segundo servicio
-</sxh>
-==== Comandos Básicos de Docker Compose ====
-  - Iniciar la aplicación basada en la configuración de ''docker-compose.yml''.
-<sxh bash>
-docker compose up -d
-</sxh>
-  - Detener y eliminar los contenedores definidos en el archivo ''docker-compose.yml''.
-<sxh bash>
-docker compose down
-</sxh>
-- Muestra el estado de los contenedores definidos en el archivo ''docker-compose.yml''.
-<sxh bash>
-docker compose ps
-</sxh>
-==== Ejemplo de Uso ====
-Supongamos un archivo ''docker-compose.yml'' para una aplicación web con un servicio de frontend y otro de base de datos:
-<sxh yaml>
-services:
-  peliculas_java:
-    image: temurin_peliculas
-    restart: always
-    hostname: peliculas_java
-    volumes:
-      - /opt/peliculas/target:/opt/app
-    ports:
-      - "80:8080"
-  peliculas_mysql:
-    image: mysql:8.3.0
-    restart: always
-    hostname: peliculas_java
-    environment:
-      - MYSQL_ROOT_PASSWORD=peliculas
-      - MYSQL_DATABASE=peliculas
-      - MYSQL_USER=peliculas
-      - MYSQL_PASSWORD=peliculas
-</sxh>
-Para iniciar esta aplicación, ejecutamos:
-<sxh>
-docker compose up -d
-</sxh>
-Esto levantará los contenedores de frontend y base de datos con la configuración especificada.
-Docker Compose simplifica la gestión de aplicaciones Docker complejas, permitiendo definir y coordinar múltiples servicios con facilidad.
-<note tip>Para pasar un script de docker al formato de docker compose se puede usar la herramienta: [[https://it-tools.tech/docker-run-to-docker-compose-converter]]</note>
-==== Compose build ====
-Hemos visto que con ''docker compose up'' es como hacer un ''docker container run''. Pues resulta que también podemos compilar las imágenes antes de levantar los contenedores con:
-<sxh bash>
-docker compose build --no-cache
-</sxh>
-Pero para ello hay que modificar el ''docker-compose.yml'' añadiendo el fichero ''Dockerfile'' a usar y la carpeta de donde podría copiar los ficheros.
-<sxh yaml>
-services:
-  peliculas_java:
-    build:
-      context: .
-      dockerfile: Dockerfile.tienda-back
-    restart: always
-    hostname: peliculas_java
-    volumes:
-      - /opt/peliculas/target:/opt/app
-    ports:
-      - "80:8080"
-</sxh>
-==== Reconstruir las imágenes ====
-Cada vez que cambia el código hay que volver a crear las imágenes, y hacerlo sin más tiene tres problemas:
-  * **Las imágenes viejas llenan el disco**: al reconstruir una imagen con un nombre que ya existe, el nombre pasa a la nueva y la vieja se queda sin nombre, como ''<none>:<none>'' (es una imagen //dangling//). Queda una por cada despliegue.
-  * **La caché de build llena el disco**: Docker guarda en una caché el resultado de cada orden del ''Dockerfile'' para no repetirla en el siguiente build. Guarda una copia en cada build, también con ''%%--no-cache%%'', que solo hace que no se reutilice. Y no la recorta hasta que queda menos del 20% del disco libre. Cuánto ocupa se ve con ''docker buildx du''.
-  * **La imagen no tiene el código nuevo**: ''docker compose up'' solo construye la imagen si no existe; si existe, la usa tal cual. Y al construirla, Docker reutiliza de la caché el resultado de un ''RUN'' si el texto de la orden no ha cambiado, sin ejecutarlo. ''RUN git clone ...'' es el mismo texto aunque haya commits nuevos en GitHub, así que la imagen se queda con el código del primer ''git clone''. Por eso borrar la imagen no basta: se vuelve a construir sacándola de la caché.
-Los tres se resuelven bajando todo, borrando las imágenes y la caché y volviendo a levantar:
-<sxh bash>
-docker compose down --rmi local
-docker buildx prune -f
-docker compose up -d
-</sxh>
-  * ''docker compose down --rmi local'': para y borra los contenedores y borra las imágenes que ha construido Compose, las de los servicios con ''build:''. Las que se descargan de DockerHub, como la de MySQL, se quedan. No lleva ''-v'', así que la base de datos se conserva.
-  * ''docker buildx prune -f'': vacía la caché de build.
-  * ''docker compose up -d'': como no encuentra las imágenes, las construye desde cero con el código actual y levanta los contenedores. No queda ninguna imagen sin nombre.
-<note>
-''docker buildx prune -f'' vacía la caché de build de toda la máquina, no solo la de tu proyecto. En el servidor del instituto los builds de los compañeros tardarán más la próxima vez, pero no se rompe nada.
-</note>