Compose: docker-compose up no muestra la última imagen si la imagen existe localmente

¿Hay alguna razón por la que docker-compose pull && docker-compose up sea ​​práctico?

Creo que la mayoría de los puntos a favor / en contra son los mismos que los discutidos en el tema por agregar --pull a docker run . Van desde ux y consistencia, hasta facilidad de scripting / flujo de trabajo, para integración de swarm (por curiosidad, ¿qué hace docker-compose pull con swarm?).
No creo que sea un tema importante, pero sí algo a considerar. El mismo tipo de usuarios que deseaban la función en otro lugar probablemente también la disfrutarían aquí.

Estoy tratando de ejecutar "docker-compose build", pero no actualiza la imagen a la que se hace referencia en el Dockerfile, excepto cuando usa _-- pull_.

También puede construir contenedores durante el inicio con _up --build_. Pero no se extraerán las imágenes más recientes. ¿Podemos esperar algo como "docker-compose up --build --pull" (o similar)? Tal vez tenga sentido colocarlo en el YML ya que no todas las compilaciones deben actualizarse (cfr. Imágenes locales).

En lugar de (o además de) agregar --pull al cli, ¿qué hay de agregar algo en la definición del servicio en el archivo docker-compose?

version: '2'

services:

  postgres:
    image: postgres
    container_name: postgres
    pull: true
    ports:
     - '5432:5432'

De esta manera, si hay un servicio que no me importa que sea el más reciente y uno que sí lo hago, docker-compose no perderá tiempo descargando imágenes que no me interesan.

Vine aquí buscando esta función porque la usamos en nuestro clúster de producción de Kubernetes. Allí, la etiqueta es "imagePullPolicy" y se puede configurar como "IfNotPresent", "Siempre" o "Nunca". Algo similar para un entorno de redacción sería bueno.

En nuestro caso, necesitamos reconstruir la imagen base todos los días para asegurarnos de que las últimas dependencias estén actualizadas para las aplicaciones. Docker componer para extraer la última imagen con la misma etiqueta es una buena característica. Por qué no !

¿Alguna noticia sobre esto?

Hola,

¿Alguna noticia sobre este tema?

+1

+1

Como mencioné anteriormente, docker-compose pull && docker-compose up es funcionalmente idéntico. No hay una buena razón para agregar otra bandera.

Imagina que git no tiene pull porque git fetch && git merge origin/master es funcionalmente idéntico.

Agregar una etiqueta pull: true podría ser útil, por ejemplo, si algunas de las imágenes que usa en su archivo de redacción están en su caché. docker-compose pull extrae _todas_ las imágenes en su archivo de redacción, y esa extracción fallará si estas imágenes están en su caché pero no en el repositorio.

+1

Un escenario en el que docker-compose pull && docker-compose up vuelve impráctico es cuando está utilizando varios archivos de composición de docker. Puede terminar fácilmente con un comando como docker-compose -f docker-compose.test.yml pull && docker-compose -f docker-compose.test.yml up .

Tenemos un escenario en el que nos desarrollamos localmente y solo querríamos sacar algunas de las imágenes de forma remota. El (o más) desarrollado localmente debe permanecer intacto. En ese caso, estamos obligados a crear / extraer imágenes manualmente antes de ejecutar docker-compose up.
Un pull: true sería beneficioso.

@ shin- ¿qué tal si reconsideras tu decisión sobre esto? Creo que los comentarios y reacciones a ellos parecen lo suficientemente autodescriptivos.

No, soy bueno. Este es un proyecto de código abierto, si no está de acuerdo con el enfoque conservador que tomamos al agregar funciones, puede bifurcarlo.

Acepte agregar una bandera al comando docker-compose up o un parámetro a la configuración. Usamos una imagen base con una configuración adicional que tiende a cambiar con frecuencia durante el proceso de desarrollo. Queremos crear un entorno infalible, donde un desarrollador puede simplemente ejecutar docker-compose sin depurar lo que no necesita depurar.

De hecho, llegué a este hilo después de que mi colega revisara mi solicitud de extracción y dijera que rompió la compilación. Y la razón es que a la imagen base simplemente le faltaban un par de paquetes, pero se ejecutó en el Dockerfile final. Sería una buena característica, pero aparentemente no es algo que usaste, @ shin-.

Estaremos encantados de que presente esta función en la nueva versión.

@ shin- Creo que @blockloop mostró con el ejemplo git lo conveniente / útil que es la opción de extracción. Sinceramente espero que para tales cosas no sea necesario bifurcar ningún proyecto.

Entiendo totalmente el enfoque conservador, pero parece que ya ni siquiera se considera una opción. ¿Quizás pueda ser parte de una próxima versión?

Un pull: IfNotPresent estaría bien. Por lo que podría ser posible utilizar alternativas como
1) usa una imagen local
2) tire si no es local
3) construir si no puede tirar

@ shin- sigues preguntando por una razón por la que el método && no lo corta, y mi razón es esta. Lo uso para una imagen de "aplicación" para probar (Puppet PDK / Onceover). El archivo de redacción es parte del repositorio de la plantilla, por lo que cuando un desarrollador de marionetas (en realidad, gente de operaciones) necesita crear un nuevo módulo, bifurca ese repositorio. Jenkins ejecuta la imagen para la validación de fusión en ese repositorio de módulo (internamente tenemos un complemento de jenkins que maneja la actualización de los trabajos). Ahora, las personas que usan esto no serán expertos en Docker, y tener que decirles que hagan el && es un extra paso que pueden (y probablemente lo harán) arruinar. No veo por qué sería difícil o qué desventaja crearía, pero este razonamiento parece una razón valiosa para agregarlo. Nos ayuda a los desarrolladores a enviar cosas que requieren menos instrucciones y pasos.

el corto es .... para protegerse contra la pereza

Aquí hay una mejor razón: && es sincrónico. Pero docker-compose ha incorporado un gran soporte para el ejecutor paralelo que optimiza estas cosas. docker-compose up --pull --build podría comenzar a construir la imagen y ejecutarla tan pronto como se extraiga, en lugar de esperar a que se extraigan todas las imágenes y solo entonces comenzar a compilar

@shin está asumiendo que uno lo está usando para nosotros de manera muy rara con Dockerfiles de actualización poco común.
Pero si actualiza una imagen de Docker todos los días que los desarrolladores usarán, rápidamente se producirán problemas de desarrollo si solo un desarrollador se olvida de extraer la imagen que tiene que hacer todos los días (especialmente aquellos que no están realmente familiarizados con Docker, y eso es en realidad no es de su incumbencia saberlo y recordarlo). Desastre programado.
¿Es un gran problema simplemente agregar esta opción al docker-compose.yml?
Quiero decir, no cambiará otras cosas, solo agrega funcionalidad. ..

es la razón principal por la que no puedo usar docker-compose y necesito escribir scripts de envoltura con comandos heredados de ejecución de docker, pero eso es feo.

Tratando de averiguar las circunstancias bajo las cuales se cerró este boleto, ¿alguien podría dar más detalles? Si es de alguna ayuda, soy profesional agregando una bandera --pull a docker-compose up .

Creo que aquí se están debatiendo dos propuestas:

1 - ¿Debería agregarse como una opción de línea de comandos? En realidad, el problema publicado.
2 - ¿Debería agregarse esta opción al archivo YML?

Definitivamente estoy de acuerdo con este último, aunque @shin en realidad no comentó sobre eso. Descartarlo con el mismo argumento, que es funcionalmente idéntico, sería incoherente. Todo en el archivo YML es funcionalmente idéntico a la línea de comandos.

Puedo ver su punto con respecto al primero, pero creo que la razón es demasiado amplia. Puedo hacer casi cualquier cosa en la línea de comandos encadenando una serie de declaraciones con && . Seamos claros, esos son dos comandos, no uno. El criterio debería ser: ¿Hay suficiente demanda para que sea posible hacerlo en un paso en lugar de dos? Porque si se usa con suficiente frecuencia, el número de comandos encadenados sigue creciendo. El punto es que, cuando escribe un guión, quiere que sea lo más conciso posible.

@orodbhen no hay necesidad de discutir. No hay nadie escuchándonos aquí.

Para agregar al razonamiento para agregar una bandera ... en el transcurso del último año más o menos, me encontré buscando esto mismo y terminé aquí solo para descubrir que ya había aprobado varios comentarios a favor de un --pull bandera. Me imagino que también me encontraré aquí la próxima vez.

@ shin-, vuelva a abrir o bloquee este problema. Ha estado abierto durante casi dos años, recibiendo comentarios constantes (inteligentes y entretenidos), decenas de participantes y cientos de votos.
Sin embargo, parece claro que el equipo de redacción no está interesado en seguir esta característica. Así que no perdamos el tiempo a nadie ni dejemos lugar a falsas esperanzas de que el problema revivirá si ese no es el caso.

Abstente de usar blasfemias.

Aunque yo creo que hay utilidad en la solicitud original, mucha gente en este tema parecen olvidar el espíritu de código abierto: si es tan importante para usted, usted es libre de tenedor y modificar el contenido de su corazón. Entiendo que es posible que no desee mantener una bifurcación, pero quejarse de que los mantenedores no implementarán una característica es contraproducente: no es así como se implementan las características y hará que los mantenedores quieran ayudarlo menos .

Realmente no importa que haya demanda de una función, especialmente si nadie paga por usar el producto. Hay más que considerar que solo incluir todas las funciones que todos desean en el producto principal. Debemos respetar la respuesta de @ shin-'sobre esto, y creemos que hay buenas razones para no implementarlo.

@lig No busca discutir. Simplemente haciendo el caso.

Dependiendo de su necesidad, la bifurcación puede ser excesiva. En mi caso particular, he descubierto que Compose no se presta muy bien a la creación de scripts, a menos que sea un script muy básico. Usar la API de Docker Python y mi propio archivo YAML para conservar la configuración es más versátil y, a menudo, más simple.

@ bdharrington7 - pero debe mantener su horquilla y mantenerla instalada en todas las máquinas que usa (lo que rara vez es posible). La advertencia es que Docker Compose es popular, otros dirían: "¿a quién le importa?"

La realidad es que el comentario "es de código abierto, crea tu propia bifurcación", simplemente no es realista. La sobrecarga de mantener su propia bifurcación y mantenerla actualizada con los últimos cambios del repositorio principal hace que rara vez valga la pena la inversión. Un enfoque mucho mejor es presentar una petición a los mantenedores y proporcionar las razones adecuadas de por qué la función es importante.

Lamentablemente, eso siempre resultará en problemas como este con cierta insatisfacción. Creo que el problema principal aquí es que no parece haberse presentado un caso adecuado de por qué esto es una mala idea. El argumento

"Debemos respetar la respuesta de @ shin-'sobre esto, y creemos que hay buenas razones para no implementarlo".

simplemente no va a satisfacer a la gente. La comunidad necesita ver las "buenas razones".

El punto es que golpear tus puños y mendigar rara vez resultará
en conseguir lo que quieres, mucho de lo que estaba sucediendo en este hilo.
También se han mencionado muchos buenos casos de uso en el hilo,
pero a menos que esté pagando por el software, no hay ninguna obligación
de los mantenedores para hacer algo al respecto, ni dar ninguna razón. soy
Solo le doy a @ shin- y compañía el beneficio de la duda aquí.
El sábado, 24 de marzo de 2018 a las 5:39 a.m., Greg Pakes [email protected] escribió:

La realidad es que el comentario "es de código abierto, crea tu propia bifurcación",
simplemente no es realista. La sobrecarga de mantener su propia bifurcación y
mantenerlo actualizado con los últimos cambios del repositorio principal
hace que rara vez valga la pena la inversión. Un enfoque mucho mejor es solicitar
mantenedores y proporcionar las razones adecuadas de por qué la función es
importante.

Lamentablemente, eso siempre resultará en problemas como este con algunos
insatisfacción. Creo que el problema principal aquí es que no parece haber
Se ha presentado un caso adecuado de por qué esto es una mala idea. los
argumento "Debemos respetar la respuesta de @ shin- http: /// shin- sobre esto,
y cree que hay buenas razones para no implementarlo. "simplemente no
va a satisfacer a la gente. La comunidad necesita ver las "buenas razones".

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/compose/issues/3574#issuecomment-375805478 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AEV8Q9RseMxYS8KGyD9E2BK0pZv7OJpuks5thWt7gaJpZM4IyPQh
.

El punto sigue siendo que golpear los puños y suplicar rara vez dará como resultado la obtención de lo que desea.

Esto simplemente no es cierto. Si bien no lo apruebo como una estrategia para pedir que se haga trabajo gratis, en realidad es bastante efectivo. Es exactamente como funcionan las peticiones y cuantas más personas "golpeen sus puños", más probabilidades hay de que las personas importantes se den cuenta. De nuevo, no digo que lo apruebe

También se han mencionado muchos buenos casos de uso en el hilo.

Puedo ver un caso, que esencialmente se reduce a "puedes hacer estos dos comandos en su lugar". Pero claramente la gente no lo quiere. Así que involúcralos y enséñales por qué es un buen trabajo.

no hay obligación por parte de los mantenedores de hacer nada al respecto, ni dar ninguna razón por la cual

Estoy de acuerdo. Pero tienes que esperar que la gente se sienta frustrada con eso. Es una actitud despectiva. Al final del día, todos aquí están en el mismo equipo. Las personas que mantienen el proyecto y los usuarios del proyecto solo quieren que el proyecto tenga éxito.

¿Qué producto es gratis exactamente aquí? Si uso docker-compose.exe y ejecuto docker EE, ¿no significa realmente que de hecho estoy pagando por el producto?

En mi humilde opinión --build debería tirar; sin necesidad de ninguna otra bandera o configuración. si no desea que se extraiga, especifique la versión de la imagen.

@ ET-CS: las versiones de imagen son solo etiquetas y aún pueden cambiar a un hash diferente

buen punto @lifeofguenter gracias. ¿Puede componer verificar si la imagen cambió a un hash diferente y tirar en ese caso también?

En tal escenario, creo que me gustaría que todos los entornos (dev, prod) tuvieran la misma imagen posible ahora que los desarrolladores están usando el nuevo hash mientras que la producción usa el anterior.

Esperaría que --build traiga todo a la última versión.

Entonces, aquí hay un buen caso de uso:

Implementé un CI para mi proyecto de microservicios, que extrae nuevas imágenes a un registro cuando desarrollamos nuevas funciones en el servicio de backend. El equipo de frontend (que sabe poco sobre Docker) necesita tener una forma de mostrar toda la pila de backend en sus máquinas locales, y confían en las imágenes más actualizadas. Si algo se rompe, solo entonces recordarán sacar las imágenes.

Ahora bien, esto es lo que sucedió: todo un sprint de desarrollo falló porque alguien olvidó actualizar las imágenes del backend y desarrolló una función completa basada en una versión anterior. La culpa es del equipo de frontend, pero esto podría evitarse con esta funcionalidad (lo que haré usando scripts de envoltura).

@agnjunio Eso suena realmente desafortunado, lo siento. Sin embargo, si la persona olvidó ejecutar docker-compose pull , no estoy seguro de cómo es menos probable que se olvide de usar una bandera hipotética --pull .

@ shin- Lo siento, olvidé mencionar algo importante: la solución en mi caso es tener la etiqueta pull: always dentro del yaml, tal vez dentro de las opciones image:

@ ET-CS de https://github.com/docker/compose/issues/3574#issuecomment -382451356:

Espero que --build lleve todo a la última versión.

En mi humilde opinión --build debería tirar; sin necesidad de ninguna otra bandera o configuración. si no desea que se extraiga, especifique la versión de la imagen.

AFAIK eso bloquearía el caso de uso con una compilación usando un FROM que es el resultado de una compilación depends_on .

version: "3.4"
services:
  some-base-image:
    image: our/base-image
    build:
      context: ./base
  # This Dockerfile has FROM our/base-image
  coolthing:
    depends_on:
    - some-base-image
    build:
      context: ./coolthing

Estoy a favor de una bandera como se sugiere en https://github.com/docker/compose/issues/3574#issuecomment -252861859 y https://github.com/docker/compose/issues/3574#issuecomment -279460839

@solsson
No estoy seguro de ver por qué o qué está bloqueando en este caso de uso.
por favor comparta más información sobre eso si puede.

@ shin- La diferencia aquí sería que si ejecuto docker-compose up --help recibiría una forma descriptiva de cómo usar: la imagen más reciente, en cambio hoy en día tengo que buscar en el documento o en el google que me lleva a este hilo y necesito leer todos los comentarios para entender que docker-compose up no hace lo que necesito / quiero, así que ahora necesito ejecutar dos comandos.

@agnjunio Eso suena realmente desafortunado, lo siento. Sin embargo, si la persona olvidó ejecutar docker-compose pull, no estoy seguro de cómo es menos probable que se olvide de usar un indicador hipotético --pull.

Cordialmente

Una de las principales razones por las que usamos docker-compose es la capacidad de colocar un archivo docker-compose.yaml en un repositorio y tener una salida reproducible cuando un desarrollador extrae el repositorio y ejecuta docker-compose up [service] .

Utilizamos varios servicios dentro de nuestros archivos docker-compose que realizan tareas como ejecutar codegen y ejecutar una herramienta para eliminar la referencia de un esquema JSON en un solo archivo.
Asegurarse de que estas herramientas estén actualizadas es fundamental, especialmente si actualizamos nuestra imagen de codegen para solucionar algún problema crítico común que se observa en todos los proyectos.

Tener la capacidad de colocar:

services:
  codegen:
    image: myimage:latest
    pull: Always

retendría nuestra capacidad de tener un desarrollador que ejecute de manera confiable docker-compose up y obtenga los resultados esperados, en lugar de tener que complementar cada repositorio con documentación para recordar a los desarrolladores que ejecuten una cadena de comandos o scripts para extraer las últimas imágenes disponibles antes de iniciar las aplicaciones .

No se trata de "la funcionalidad ya existe para hacer esto ejecutando estos comandos", es una mejor experiencia de usuario.

Imagínese cuando alguien sugirió agregar --stop a docker-compose rm la respuesta fue "¿qué pasa con docker-compose stop myapp && docker-compose rm myapp , o si alguien hubiera solicitado la implementación de docker-compose down simplemente preguntó por qué docker-compose stop myapp && docker-compose rm -v myapp && docker-compose images -q myapp | xargs docker rmi ... práctico?

Este hilo se ha planteado hace 2 años y todavía pensaba que agregar una bandera en el docker-compose.yml es la mejor manera. En mi caso, tenemos como 37 servicios en un enjambre, y actualizar 4-5 imágenes de ese total no es fácil. Acabo de crear un shell por ahora que puede monitorear el cambio desde el repositorio y hacer la extracción de la imagen específica antes de recrear el servicio si se ha actualizado.

Otro punto aquí es que docker-compose up tiene una opción --quiet-pull . Cuando intenté averiguar por primera vez si up incluía un tirón, asumí que lo hacía en función de su presencia. Es lógico que no usar --quiet-pull resulte en una extracción detallada.

Dos años de gente tratando de convencer a los encargados de mantenimiento de Docker Compose de que tener una opción --pull sería una mejor experiencia sin tener que ejecutar un comando por separado. Si los mantenedores de docker-compose simplemente implementaran la función, para empezar, la vida de todos sería mejor. Parece estar claro que los mantenedores actuales no quieren agregar esta característica para el mejoramiento de la comunidad.

Tal vez deberíamos simplemente bifurcar el docker-compose y actualizarlo nosotros mismos.

Si alguien presentara un PR, ¿tendría alguna posibilidad de ser aceptado?
Esto es de código abierto. Estuve cerca de considerar implementarlo algunos
veces yo mismo. Supongo que podría ser aceptado, de lo contrario este rol se cerrará,
¿Derecha?

Me encontré con el mismo problema y mierda, un montón de llorones aquí. Este es un software de código abierto GRATUITO. Dale un descanso a los mantenedores. Estoy seguro de que tienen cosas mucho más importantes en las que trabajar que esto. Si alguien necesita esto con tanta urgencia, ¿por qué no abre un PR? Si el código está limpio con un riesgo mínimo, no veo por qué no lo aceptarían.

Este problema debe reabrirse ya que la discusión carece de una buena razón para no implementar esta solicitud. Es más probable que las personas empiecen a trabajar en temas _ abiertos_ que en temas cerrados.

El hecho de que este tema "cerrado" se haya mantenido tan activo sugiere que no se ha manejado bien.

Desafortunadamente, descubrí que las respuestas a publicaciones problemáticas en algunos repositorios de GitHub no son muy útiles. El tono suele ser conciso y sugiere que la retroalimentación es menos que bienvenida.

Algunos han señalado aquí que este es un proyecto de código abierto y (al menos la mayoría de nosotros) no somos clientes de pago. Sin embargo, también vale la pena señalar que enviar informes de problemas constituye una importante inversión de tiempo, más aún si participa en la resolución del problema.

Un usuario o desarrollador, que haya dedicado tiempo a solucionar un problema y haya encontrado una solución alternativa, decidirá si desea dedicar más tiempo a informarlo. Una respuesta poco receptiva de los mantenedores probablemente hará que opten por no molestarse la próxima vez.

El software no es realmente "GRATIS", en el sentido de "cerveza gratis". ya que todos estamos tratando de participar para mejorarlo. Tener personas dispuestas a probar su software y proporcionar comentarios es un recurso valioso. Aquellos con las habilidades de programación requeridas incluso están dispuestos a contribuir con código, pero quieren algún tipo de indicación de que sus contribuciones son bienvenidas antes de dedicar tiempo a ello.

Obviamente, los comentarios que simplemente se quejan de un problema y exigen que se solucione no son útiles, pero la mayoría no lo hace, y los comentarios como "es de código abierto, simplemente bifurque" son igualmente inútiles.

@ shin- ¿Por qué se implementó "--build"? ¿Es diferente a docker-compose build && docker-compose up? Solo trato de entender la diferencia filosófica entre --build (que se agregó) y --pull (que se ha considerado redundante). Entender el proceso de pensamiento podría ayudarme a recordar cómo funcionan las cosas. Y si se abre el problema, me complace enviar un PR. @everybodyelse ... ¿es realmente el "espíritu de código abierto" que si no te gusta algo te bifurcas? Pensé que el espíritu del código abierto era "si no te gusta algo, a) ayudas a contribuir a los requisitos si ahí es donde estás, b) ayudas a contribuir al código si puedes" y que solo bifurcabas si tus requisitos eran muy claramente algo de lo que solo usted se beneficiaría. es decir, pensé que nos beneficiamos más cuando compartimos, pero estoy feliz de ser educado aquí.

Después de dos años de insistir, dar buenas razones que se ignoran y un enorme apoyo de la comunidad para que esto realmente se implemente, yo diría que esta característica no funcionará solo porque @ shin- no quiere. No hay razón para seguir insistiendo.

Hay una razón: la ventana acoplable no actualizará las imágenes si falla una extracción y no hay una buena razón para no hacerlo.

Estoy buscando la política de extracción de imágenes de Kubernetes en docker compose, sería genial si se pudiera usar "pull".

@ shin- Deja de ser infantil. Se han mencionado muchas buenas razones para implementar esta función. Al menos esté abierto a los RP ...

Puede no estar de acuerdo conmigo, pero me decepciona que recurriera a ad hominems, @Wenzil. Nuestra comunidad generalmente se mantiene a un nivel más alto.

@ shin- Nuestra comunidad piensa lo mismo en su mayoría y no lo dice debido a la razón que mencionaste. @Wenzil es lo suficientemente honesto como para decirlo en voz alta.
Mucha gente que conozco prefiere no molestarse y renunció a tratar de convencer a docker-compose de que se mueva hacia sus usuarios.

Mucha gente no está de acuerdo @ shin- por razones muy válidas descritas. Como mínimo, debería ser una declaración de servicio. Encadenar los comandos de bash no es una solución particularmente buena para las implementaciones programáticas.

Mucha gente que conozco prefiere no molestarse y renunció a tratar de convencer a docker-compose de que se mueva hacia sus usuarios.

Esta. Y no se trata solo de docker-compose. Docker-stack, docker-machine y docker-cli son todos similares.

https://github.com/docker/compose/issues/6316#issuecomment -438564025

Bloqueo ya que esto sigue descarrilando. Reevaluaremos dependiendo del destino de https://github.com/docker/cli/pull/1498

Como actualización, hemos decidido internamente considerar la posibilidad de agregar un parámetro pull_policy a las definiciones de servicio. Todavía tenemos que averiguar cuáles serán las opciones y la sintaxis exacta, pero esperamos que satisfaga las necesidades expresadas en este hilo.