Muy a menudo, docker-compose up no reconstruye la imagen especificada como "build:" en el docker-compose.yml aunque el respectivo Dockerfile ha cambiado. En su lugar, necesito ejecutar docker build -t servicename_foldername. manualmente para el servicio afectado que realmente actualizará la imagen en consecuencia.
¿Es esto intencionado? Debido a que es bastante molesto, nunca puedo estar seguro de que la imagen esté realmente actualizada y necesito ejecutar docker build manualmente antes de usar docker-compose up.
Es cierto que docker-compose up
nunca reconstruye una imagen. Esto es "intencionado", pero es algo que creo que deberíamos cambiar: # 693
Puede ejecutar docker-compose build
para construir las imágenes.
Duplicado de # 614
Hola @dnephin , ¡qué mundo tan pequeño!
Me encuentro con un problema en el que docker-compose build
no está reconstruyendo correctamente los contenedores. Está causando problemas para evitar que un contenedor de barniz se inicie debido a archivos de bloqueo obsoletos.
Según lo que he leído en otra parte (por ejemplo, # 1195), parece que docker-compose build
es la forma recomendada de reconstruir contenedores y debería evitar problemas como estos.
╭─wting<strong i="11">@nuc</strong> ~/code/reddit-mobile ‹python-2.7.12› ‹wting_chan-159_add_varnish_to_2X×ad20b6d›
╰─➤ docker ps 2016.09.15 12:20:46 PDT
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
╭─wting<strong i="12">@nuc</strong> ~/code/reddit-mobile ‹python-2.7.12› ‹wting_chan-159_add_varnish_to_2X×ad20b6d›
╰─➤ docker-compose --version 2016.09.15 12:20:48 PDT
docker-compose version 1.8.0, build f3628c7
╭─wting<strong i="13">@nuc</strong> ~/code/reddit-mobile ‹python-2.7.12› ‹wting_chan-159_add_varnish_to_2X×ad20b6d›
╰─➤ docker --version 2016.09.15 12:20:51 PDT
Docker version 1.12.1, build 23cf638
╭─wting<strong i="14">@nuc</strong> ~/code/reddit-mobile ‹python-2.7.12› ‹wting_chan-159_add_varnish_to_2X×ad20b6d›
╰─➤ docker-compose build && docker-compose up 2 ↵ 2016.09.15 12:23:35 PDT
Building web
Step 1 : FROM reddit/reddit-nodejs:latest
---> ee57c186eb35
Step 2 : VOLUME /src
---> Using cache
---> 3720601d98c8
Step 3 : WORKDIR /src
---> Using cache
---> d4b9b360ef4e
Step 4 : EXPOSE 4444
---> Using cache
---> 5e232be73781
Step 5 : ENTRYPOINT npm start
---> Using cache
---> 1094fc9857bb
Successfully built 1094fc9857bb
Building varnish
Step 1 : FROM quay.io/reddit/varnish-fastly
# Executing 1 build trigger...
Step 1 : COPY default.vcl /etc/varnish/default.vcl
---> Using cache
---> ac9dadb35674
Step 2 : ENV VARNISH_PORTS 8080
---> Using cache
---> 3c43e0226f5f
Step 3 : EXPOSE 8080
---> Using cache
---> c88093c2ff32
Successfully built c88093c2ff32
Starting redditmobile_web_1
Starting redditmobile_varnish_1
Attaching to redditmobile_web_1, redditmobile_varnish_1
varnish_1 | storage_malloc: max size 100 MB.
varnish_1 | SHMFILE owned by running varnishd master (pid=1) # STALE LOCK FILE
varnish_1 | (Use unique -n arguments if you want multiple instances.)
web_1 |
web_1 | > [email protected] start /src
web_1 | > NODE_ENV=production npm run server
web_1 |
redditmobile_varnish_1 exited with code 2
web_1 |
web_1 | > [email protected] server /src
web_1 | > NODE_ENV=production node ./bin/ProductionServer.js
web_1 |
web_1 | Started cluster with 4 processes.
web_1 | Started server at PID 31
web_1 | Started server at PID 46
[..]
hey @wting
Creo que lo que podría estar sucediendo es que el archivo de bloqueo está en un volumen (https://docs.docker.com/compose/overview/#/preserve-volume-data-when-containers-are-created).
Puede probar docker-compose down
para eliminar los contenedores antiguos, lo que eliminará la referencia de volumen. El próximo up
debería comenzar con volúmenes nuevos.
Si no está en un volumen, supongo que podría ser que nunca se quitó el candado. Compose intentará iniciar un contenedor si existe y la configuración no ha cambiado, por lo que ejecutar down
debería solucionarlo.
¡Gracias! docker-compose down
funcionó, así como docker-compose up --force-recreate
(pero no docker-compose --build
). Supongo que no es intuitivo porque hay un volumen montado para el contenedor web pero no para el contenedor Varnish; sin embargo, las limas de barniz se quedan. Aquí está el archivo docker-compose.yml
:
version: '2'
services:
web:
build:
context: .
dockerfile: Dockerfile.dev
ports:
- "4444:4444"
volumes:
- .:/src
varnish:
build:
context: .
dockerfile: Dockerfile.varnish
ports:
- "4301:80"
depends_on:
- web
Para el contexto:
Dockerfile.dev
( VOLUME
presente)Dockerfile.varnish
(no VOLUME
)reddit/varnish-fastly/Dockerfile
(no VOLUME
)Gracias wting, y todos los que escribieron sobre este tema, me "salvó" su comentario => "docker-compose up --force-recreate (pero no docker-compose --build)".
docker-compose up --build
Es cierto que
docker-compose up
nunca reconstruye una imagen. Esto es "intencionado", pero es algo que creo que deberíamos cambiar: # 693Puede ejecutar
docker-compose build
para construir las imágenes.Duplicado de # 614
Gracias que realmente me ayudaron a asignar un nuevo Dockerfile y reconstruir el contenedor con los últimos cambios.
Para su información, tuvo el mismo problema y la misma solución que se discutió. Las interwebs me llevaron aquí. ¡Gracias por las buenas discusiones!
docker-compose up --build -V
Para aclarar qué es el parámetro -V
:
-V, --renew-anon-volumes Recreate anonymous volumes instead of retrieving data from the previous containers.
Para reconstruir una sola imagen dentro de docker-compose
:
docker-compose up -d --force-recreate --no-deps --build $service
p.ej:
docker-compose up -d --force-recreate --no-deps --build varnish
Comentario más útil
Es cierto que
docker-compose up
nunca reconstruye una imagen. Esto es "intencionado", pero es algo que creo que deberíamos cambiar: # 693Puede ejecutar
docker-compose build
para construir las imágenes.Duplicado de # 614