library - cómo obtener la función docker-compose para usar la última imagen del repositorio
dockers images (7)
No sé qué estoy haciendo mal, pero simplemente no puedo docker-compose up para usar la última imagen de nuestro registro sin primero eliminar por completo los contenedores viejos del sistema. Parece que componer está utilizando la imagen iniciada anteriormente, a pesar de que la función de composición de la ventana acoplable ha obtenido una imagen más nueva.
Miré ¿Cómo obtener una composición acoplable para volver a crear siempre contenedores a partir de imágenes nuevas? que parecía ser similar a mi problema, pero ninguna de las soluciones provistas allí funcionan para mí, ya que estoy buscando una solución que pueda usar en el servidor de producción y no quiero eliminar todos los contenedores antes de iniciarlos de nuevo (¿posible pérdida de datos?). Me gustaría componer solo para detectar la nueva versión de las imágenes modificadas, extraerlas y luego reiniciar los servicios con esas nuevas imágenes.
Creé un proyecto de prueba simple para esto en el que el único objetivo es obtener una versión nr para aumentar en cada nueva compilación. La versión nr se muestra si navego al servidor nginx que se crea (esto funciona como se espera a nivel local).
versión de docker: 1.11.2 versión de docker-compose: 1.7.1 OS: probado tanto en CentOS 7 como en OS X 10.10 usando el docker-toolbox
Mi docker-compose.yml:
version: ''2''
services:
application:
image: ourprivate.docker.reg:5000/ourcompany/buildchaintest:0.1.8-dev
volumes:
- /var/www/html
tty: true
nginx:
build: nginx
ports:
- "80:80"
volumes_from:
- application
volumes:
- ./logs/nginx/:/var/log/nginx
php:
container_name: buildchaintest_php_1
build: php-fpm
expose:
- "9000"
volumes_from:
- application
volumes:
- ./logs/php-fpm/:/var/www/logs
en nuestro servidor jenkins ejecuto lo siguiente para construir y etiquetar la imagen
cd $WORKSPACE && PROJECT_VERSION=$(cat VERSION)-dev
/usr/local/bin/docker-compose rm -f
/usr/local/bin/docker-compose build
docker tag ourprivate.docker.reg:5000/ourcompany/buildchaintest ourprivate.docker.reg:5000/ourcompany/buildchaintest:$PROJECT_VERSION
docker push ourprivate.docker.reg:5000/ourcompany/buildchaintest
Esto parece estar haciendo lo que se supone que debe hacer ya que recibo una nueva etiqueta de versión en nuestro repositorio cada vez que se completa la compilación y se ha superado la versión nº.
Si ahora corro
docker-compose pull && docker-compose -f docker-compose.yml up -d
en una carpeta de mi computadora, donde el contenido es solo el docker-compose.yml y los Dockerfiles necesarios para compilar los servicios nginx y php, el resultado que obtengo no es el número de versión más reciente como se ha etiquetado en el registro o se muestra en el docker-compose.yml (0.1.8), pero la versión anterior a eso, que es 0.1.7. Sin embargo, la salida del comando de extracción sugeriría que se recuperó una nueva versión de la imagen:
Pulling application (ourprivate.docker.reg:5000/ourcompany/buildchaintest:latest)...
latest: Pulling from ourcompany/buildchaintest
Digest: sha256:8f7a06203005ff932799fe89e7756cd21719cccb9099b7898af2399414bfe62a
Status: Downloaded newer image for docker.locotech.fi:5000/locotech/buildchaintest:0.1.8-dev
Solo si corro
docker-compose stop && docker-compose rm -f
y luego ejecute el comando docker-compose up ¿Obtengo la nueva versión para que aparezca en la pantalla como se esperaba?
¿Es este comportamiento intencionado de docker-compose? es decir, ¿debería hacer siempre un docker-compose rm -f antes up volver up ejecutarlo, incluso en servidores de producción? ¿O estoy haciendo algo contra el grano aquí, por eso no está funcionando?
El objetivo es hacer que nuestro proceso de compilación se construya y crear versiones etiquetadas de las imágenes necesarias en un docker-compose.yml, enviarlas a nuestro registro privado y luego a la "versión para producción" para simplemente copiar el componente de docker-compose. yml para el servidor de producción y ejecute un docker-compose pull && docker-compose -f docker-compose.yml up -d para que la nueva imagen comience en producción. Si alguien tiene sugerencias sobre esto o puede apuntar a un tutorial de mejores prácticas para este tipo de configuración, también sería muy apreciado.
He extendido un poco más el guión de Abhi como se muestra abajo.
export composeFile="docker-compose.test.yml"
docker-compose -f $composeFile down
docker-compose -f $composeFile pull
docker-compose -f $composeFile up -d
He visto que esto ocurre en nuestro sistema de producción de ventanas acopladas 7-8. Otra solución que me funcionó en producción fue ejecutar.
docker-compose down
docker-compose up -d
Esto quita los contenedores y parece que crea ''nuevos'' a partir de la última imagen.
Esto aún no resuelve mi sueño de abajo + arriba por CADA contenedor cambiado (en serie, menos tiempo de inactividad), pero funciona para forzar ''arriba'' para actualizar los contenedores.
La documentación de la ventana acoplable para el comando ''up'' indica claramente que actualiza el contenedor en caso de que la imagen se modifique desde la última ''arriba'':
Si existen contenedores para un servicio y la configuración o la imagen del servicio se modificaron después de la creación del contenedor, la función docker-compose recoge los cambios deteniendo y volviendo a crear los contenedores (conservando los volúmenes montados).
Por lo tanto, al usar ''detener'' seguido de ''tirar'' y luego ''subir'', esto debería evitar los problemas de volúmenes perdidos para los contenedores en ejecución, excepto, por supuesto, para los contenedores cuyas imágenes se hayan actualizado.
Actualmente estoy experimentando con este proceso e incluiré mis resultados en este comentario en breve.
Opción down resolver este problema
Ejecuto mi archivo de redacción:
docker-compose -f docker/docker-compose.yml up -d
Luego borro todo con down --rmi all
docker-compose -f docker/docker-compose.yml down --rmi all
Stops containers and removes containers, networks, volumes, and images
created by `up`.
By default, the only things removed are:
- Containers for services defined in the Compose file
- Networks defined in the `networks` section of the Compose file
- The default network, if one is used
Networks and volumes defined as `external` are never removed.
Usage: down [options]
Options:
--rmi type Remove images. Type must be one of:
''all'': Remove all images used by any service.
''local'': Remove only images that don''t have a custom tag
set by the `image` field.
-v, --volumes Remove named volumes declared in the `volumes` section
of the Compose file and anonymous volumes
attached to containers.
--remove-orphans Remove containers for services not defined in the
Compose file
Para cerrar esta pregunta, lo que parecía haber funcionado es en efecto correr.
docker-compose stop
docker-compose rm -f
docker-compose -f docker-compose.yml up -d
Es decir, retire los contenedores antes de correr up nuevo.
Lo que hay que tener en cuenta al hacerlo de esta manera es que los contenedores de volumen de datos también se eliminan si solo ejecuta rm -f . Para evitar que especifique explícitamente cada contenedor a eliminar:
docker-compose rm -f application nginx php
Como dije en mi pregunta, no sé si este es el proceso correcto. Pero esto parece funcionar para nuestro caso de uso, por lo tanto, hasta que encontremos una solución mejor, continuaremos con esta.
Para obtener las imágenes más recientes, utilice la compilación docker-compose --pull
Yo uso el siguiente comando que es realmente 3 en 1
"docker-compose down && docker-compose build --pull && docker-compose up -d"
Este comando detendrá los servicios, extraerá la última imagen y luego iniciará los servicios.
para asegurarse de que está utilizando la versión más reciente para su :latest etiqueta de su registro (por ejemplo, el concentrador de la ventana acoplable) también necesita volver a extraer la última etiqueta. en caso de que cambie, el diff se descargará y se iniciará cuando vuelva docker-compose up .
Así que este sería el camino a seguir:
docker-compose stop
docker-compose rm -f
docker-compose pull
docker-compose up -d
pegué esto en una imagen que ejecuto para iniciar docker-compose y asegurarme de que las imágenes estén actualizadas: https://hub.docker.com/r/stephanlindauer/docker-compose-updater/