logongas

Herramientas de usuario

Herramientas del sitio

Ocultar Menú
Traza: • 4.b Despliegue avanzado en Servidor: Docker Compose • 1. Repaso de sistemas
clase:daw:daw:1eval:tema04.b

Diferencias

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

Enlace a la vista de comparación

Ambos lados, revisión anteriorRevisión previa
Próxima revisión		Revisión previa
clase:daw:daw:1eval:tema04.b [2026/10/16 18:41] – Código viejo: tampoco lo arregla docker compose build ni up --build claudeclase:daw:daw:1eval:tema04.b [2026/10/19 00:27] (actual) – Lorenzo
Línea 1: Línea 1:
-===== 4.b Despliegue avanzado en Servidor: Docker Compose =====+====== 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. 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 ====+===== 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: Un archivo ''docker-compose.yml'' define la configuración de una aplicación multi-contenedor. Aquí se presentan las secciones principales:
Línea 27: Línea 27:
  
  
-==== Comandos Básicos de Docker Compose ====+===== Comandos Básicos de Docker Compose =====
  
   - Iniciar la aplicación basada en la configuración de ''docker-compose.yml''.   - Iniciar la aplicación basada en la configuración de ''docker-compose.yml''.
Línea 87: Línea 87:
 <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> <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>
  
-==== Construir las imágenes con Compose ====+===== Construir las imágenes con Compose =====
 Hemos visto que con ''docker compose up'' es como hacer un ''docker container run''. Pues resulta que también puede crear las imágenes con su ''Dockerfile'' antes de levantar los contenedores. Para ello, en el servicio se pone ''build:'' con el ''Dockerfile'' a usar y la carpeta de donde copia los ficheros: Hemos visto que con ''docker compose up'' es como hacer un ''docker container run''. Pues resulta que también puede crear las imágenes con su ''Dockerfile'' antes de levantar los contenedores. Para ello, en el servicio se pone ''build:'' con el ''Dockerfile'' a usar y la carpeta de donde copia los ficheros:
  
Línea 106: Línea 106:
 ''docker compose up'' construye la imagen la primera vez. Para reconstruirla cuando cambia el código, [[#reconstruir_las_imagenes|Reconstruir las imágenes]]. ''docker compose up'' construye la imagen la primera vez. Para reconstruirla cuando cambia el código, [[#reconstruir_las_imagenes|Reconstruir las imágenes]].
  
-==== Reconstruir las imágenes ====+===== 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: 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.   * **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 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 ''%%docker compose build --no-cache%%'': esa opción hace que no se reutilice la caché, no que no se guarde. 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 aunque se reconstruya con ''docker compose build'' o ''%%docker compose up --build%%'', o se borre la imagen antes del ''up'', 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''.   * **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 aunque se reconstruya con ''docker compose build'' o ''%%docker compose up --build%%'', o se borre la imagen antes del ''up'', 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''.
  
Línea 126: Línea 126:
  
 <note> <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.+''docker buildx prune -f'' vacía la caché de build de toda la máquina, no solo la de tu proyecto. En un servidor con varios ''compose.yaml'', los de los demás proyectos pueden tardar más en crear sus imágenes la próxima vez, porque ya no tienen la caché. No se rompe nada.
 </note> </note>
  
  
clase/daw/daw/1eval/tema04.b.1792168881.txt.gz · Última modificación: por claude