Compose: docker-compose up não puxa para baixo a imagem mais recente se a imagem existir localmente

Existe uma razão pela qual docker-compose pull && docker-compose up não é prático?

Acho que a maioria dos pontos a favor / contra são os mesmos discutidos na edição para adicionar --pull a docker run . Eles variam de ux e consistência a facilidade de script / fluxo de trabalho e integração de enxame (por curiosidade, o que docker-compose pull faz com enxame?).
Não acho que seja um grande problema, mas algo a considerar. O mesmo tipo de usuário que desejou o recurso em outro lugar provavelmente também o apreciaria aqui.

Estou tentando executar "docker-compose build", mas não atualiza a imagem referenciada no Dockerfile, exceto quando você usa _-- pull_.

Você também pode construir contêineres durante o início com _up --build_. Mas as imagens mais recentes não serão puxadas. Podemos esperar um sthg como "docker-compose up --build --pull" (ou similar)? Talvez faça sentido colocá-lo no YML, já que nem todos os builds devem ser atualizados (cfr. Imagens locais).

Em vez de (ou além de) adicionar --pull ao cli, que tal adicionar algo na definição de serviço no arquivo docker-compose?

version: '2'

services:

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

Assim, se houver um serviço que não me interessa ser o mais recente e outro que faço, o docker-compose não perderá tempo baixando imagens nas quais não estou interessado

Vim aqui em busca desse recurso porque o usamos em nosso cluster de produção do Kubernetes. Lá, a tag é "imagePullPolicy" e pode ser definida como "IfNotPresent", "Always" ou "Never". Algo semelhante para um ambiente composto seria bom.

Em nosso caso, precisamos reconstruir a imagem base todos os dias para garantir que as dependências mais recentes sejam atualizadas para os aplicativos. O Docker compor para puxar a imagem mais recente com a mesma tag é um bom recurso. Por que não !

Alguma notícia sobre isso?

Oi,

Alguma notícia sobre esse assunto?

+1

+1

Como mencionei anteriormente, docker-compose pull && docker-compose up é funcionalmente idêntico. Não há um bom motivo para adicionar outro sinalizador para ele.

Imagine que o git não tivesse pull porque git fetch && git merge origin/master é funcionalmente idêntico.

Adicionar uma tag pull: true pode ser útil, por exemplo, se algumas das imagens que você usa em seu arquivo de composição estiverem em seu cache. docker-compose pull pull _todas_ as imagens em seu arquivo de composição, e esse pull falhará se essas imagens estiverem em seu cache, mas não no repositório.

+1

Um cenário em que docker-compose pull && docker-compose up se torna impraticável é quando você está usando vários arquivos docker-compose. Você pode facilmente terminar com um comando como docker-compose -f docker-compose.test.yml pull && docker-compose -f docker-compose.test.yml up .

Temos um cenário em que desenvolvemos localmente e gostaríamos apenas de extrair algumas das imagens remotamente. Aquele (ou mais) desenvolvido localmente deve permanecer intocado. Nesse caso, somos obrigados a criar / extrair imagens manualmente antes de executar docker-compose up.
A pull: true seria benéfico.

@ shin- que tal repensar sua decisão sobre isso? Acredito que comentários e reações a eles parecem suficientemente autodescritivos.

Não, eu estou bem. Este é um projeto de código aberto, se você discordar da abordagem conservadora que adotamos ao adicionar recursos, fique à vontade para fazer um fork dele.

Concorde em adicionar um sinalizador ao comando docker-compose up ou um parâmetro à configuração. Usamos uma imagem de base com configuração adicional que tende a mudar frequentemente durante o processo de desenvolvimento. Queremos criar um ambiente à prova de falhas, onde um desenvolvedor pode simplesmente executar docker-compose sem depurar o que não precisa depurar.

Na verdade, cheguei a este tópico depois que meu colega estava verificando minha solicitação de pull e disse que quebrou a compilação. E o motivo é que a imagem base simplesmente não tinha alguns pacotes - mas foi executada no Dockerfile final. Seria um bom recurso, mas aparentemente não é algo que você usou, @ shin-.

Ficaríamos felizes se você introduzisse esse recurso na nova versão.

@ shin- Acho que git como a opção pull é conveniente / útil. Sinceramente espero que para tais coisas não seja necessário bifurcar nenhum projeto.

Eu entendo totalmente a abordagem conservadora, mas parece que nem é mais considerada uma opção. Talvez possa fazer parte de uma próxima versão?

A pull: IfNotPresent seria bom. Portanto, pode ser possível usar substitutos como
1) usar imagem local
2) puxe se não for local
3) construir se não for capaz de puxar

@ shin- você fica perguntando por que o método && não vai funcionar, e minha razão é esta. Eu o uso para uma imagem de "aplicativo" para teste (Puppet PDK / Onceover). O arquivo de composição é parte do repositório de modelo, portanto, quando um puppet dev (realmente ops, pessoal) precisa fazer um novo módulo, ele bifurca esse repositório. Jenkins executa a imagem para validação de mesclagem nesse repositório de módulo (internamente temos um plugin jenkins que lida com a atualização para os trabalhos). Agora, as pessoas que usam isso não serão especialistas em docker e ter que dizer a eles para fazer o && é um extra passo que eles podem (e provavelmente irão) estragar. Não vejo por que seria difícil ou que desvantagem criaria, mas esse raciocínio parece um motivo válido para adicioná-lo. Isso nos ajuda, desenvolvedores, a enviar coisas que exigem menos instruções e etapas.

o resumo é .... para se proteger contra a preguiça

Aqui está um motivo melhor: && é síncrono. Mas docker-compose tem um ótimo suporte embutido para o executor paralelo, o que otimiza essas coisas. docker-compose up --pull --build pode começar a construir a imagem e executá-la assim que for extraída, em vez de esperar que todas as imagens sejam extraídas e só então começar a construir

@shin está assumindo que alguém está usando para nós mesmos em uma base muito rara, com raras atualizações de Dockerfiles.
Mas se você atualizar uma imagem Docker todos os dias que os desenvolvedores usarão, isso levará rapidamente a problemas de desenvolvimento se apenas um desenvolvedor se esquecer de puxar a imagem que ele tem que fazer todos os dias (especialmente aqueles que não estão realmente familiarizados com o docker, e isso na verdade, não é da sua conta saber e lembrar disso). Desastre programado.
É um grande problema apenas adicionar essa opção ao docker-compose.yml?
Quer dizer, não mudará outras coisas, apenas adiciona funcionalidade. ..

é o motivo do matador pelo qual não posso usar docker-compose e preciso escrever scripts de wrapper com comandos docker run legados, mas isso é feio.

Tentando descobrir as circunstâncias em que este tíquete foi fechado - alguém poderia explicar? Se ajudar, estou adicionando uma bandeira --pull a docker-compose up .

Acho que há duas propostas sendo discutidas aqui:

1 - Isso deve ser adicionado como uma opção de linha de comando? Na verdade, o problema postado.
2 - Deve esta opção ser adicionada ao arquivo YML.

Eu definitivamente concordo com o último, embora @shin não tenha realmente comentado sobre isso. Descartá-lo com o mesmo argumento, que é funcionalmente idêntico, seria incoerente. Tudo no arquivo YML é funcionalmente idêntico à linha de comando.

Eu posso ver seu ponto em relação ao primeiro, mas acho que o raciocínio é um pouco amplo. Posso fazer quase tudo na linha de comando encadeando uma série de instruções com && . Vamos ser claros, esses são dois comandos, não um. Os critérios devem ser: Há demanda suficiente para que seja possível fazê-lo em uma etapa em vez de duas? Porque se for usado com freqüência suficiente, o número de comandos encadeados continua crescendo. A questão é que, ao escrever um script, você deseja que seja o mais sucinto possível.

@orodbhen não precisa discutir. Não há ninguém nos ouvindo aqui.

Para aumentar o raciocínio para adicionar uma bandeira ... ao longo do último ano ou assim, me peguei procurando por isso e acabei aqui apenas para descobrir que já havia manuseado vários comentários a favor de um Bandeira --pull . Imagino que também vou me encontrar aqui da próxima vez.

@ shin-, reabra ou bloqueie este problema. Está aberto há quase dois anos, recebendo comentários constantes (inteligentes e divertidos), dezenas de participantes e centenas de votos.
No entanto, parece claro que a equipe de composição não está interessada em prosseguir com esse recurso. Portanto, não vamos desperdiçar o tempo de ninguém nem dar margem a falsas esperanças de que a questão seja reavivada se esse não for o caso.

Evite usar palavrões.

Embora eu ache que a solicitação original é útil, muitas pessoas neste tópico parecem esquecer o espírito do código aberto: se for tão importante para você, você está livre para bifurcar e modificar o que quiser. Eu entendo que você pode não querer manter um fork, mas reclamar que os mantenedores não implementam um recurso é contraproducente: não é assim que os recursos são implementados e fará com que os mantenedores queiram menos ajudá-lo.

Realmente não importa que haja demanda por um recurso, especialmente se ninguém estiver pagando para usar o produto. Há mais a se considerar do que apenas incluir todos os recursos que todos desejam no produto principal. Devemos respeitar a resposta de @shin-sobre isso e acreditar que há boas razões para não implementá-la.

@lig Não

Dependendo da sua necessidade, a bifurcação pode ser um exagero. No meu caso específico, descobri que o Compose não se adapta muito bem a scripts, a menos que seja um script muito básico. Usar a API Docker Python e meu próprio arquivo YAML para preservar as configurações é mais versátil e geralmente mais simples.

@ bdharrington7 - mas você tem que manter seu fork e mantê-lo instalado em todas as máquinas que você usa (o que raramente é possível). Advertência é o Docker Compose é popular, outros diriam: „quem se importa?”

A realidade é que o comentário "é código aberto, crie seu próprio fork", simplesmente não é realista. A sobrecarga de manter seu próprio fork e mantê-lo atualizado com as mudanças mais recentes do repositório principal raramente vale o investimento. Uma abordagem muito melhor é fazer uma petição aos mantenedores e fornecer as razões adequadas de porque o recurso é importante.

Infelizmente, isso sempre resultará em problemas como este com alguma insatisfação. Acho que o principal problema aqui é que não parece ter havido um caso adequado apresentado para explicar por que isso é uma má ideia. O argumento

"Devemos respeitar a resposta de @shin-sobre isso e acreditar que há boas razões para não implementá-la."

simplesmente não vai satisfazer as pessoas. A comunidade precisa ver as "boas razões".

A questão é que bater os punhos e implorar raramente resultará
em conseguir o que você quer, muito do que estava acontecendo neste tópico.
Também surgiram muitos casos de uso bons no thread,
mas, a menos que você esteja realmente pagando pelo software, não há obrigação
dos mantenedores para fazer algo sobre isso, nem dar qualquer motivo. Eu estou
apenas dando a @ shin- e empresa o benefício da dúvida aqui.
No sábado, 24 de março de 2018 às 5h39, Greg Pakes [email protected] escreveu:

A realidade é que o comentário "é código aberto, crie seu próprio fork",
simplesmente não é realista. A sobrecarga de manter seu próprio garfo e
mantê-lo atualizado com as últimas mudanças do repositório principal
faz com que raramente valha o investimento. Uma abordagem muito melhor é fazer uma petição
os mantenedores e fornecer razões adequadas para o motivo do recurso ser
importante.

Infelizmente, isso sempre resultará em problemas como este com alguns
insatisfação. Acho que o principal problema aqui é que não parece
tem sido um caso adequado apresentado para explicar por que isso é uma má ideia. o
argumento "Devemos respeitar a resposta de @ shin- http: /// shin- sobre isso,
e acredito que há boas razões para não implementá-lo. "simplesmente não é
vai satisfazer as pessoas. A comunidade precisa ver as "boas razões".

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/docker/compose/issues/3574#issuecomment-375805478 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AEV8Q9RseMxYS8KGyD9E2BK0pZv7OJpuks5thWt7gaJpZM4IyPQh
.

A questão é que bater os punhos e implorar raramente resultará em obter o que deseja

Isto simplesmente não é verdade. Embora eu não concorde com isso como uma estratégia para pedir trabalho gratuito, na verdade é bastante eficaz. É exatamente assim que as petições funcionam e quanto mais pessoas "batem os punhos", maior a probabilidade de pessoas que importam notarem. Novamente, não estou dizendo que aprovo isso

Também houve muitos casos de uso bons no thread

Eu posso ver um caso, que essencialmente se resume a "você pode fazer esses dois comandos em vez disso". Mas claramente as pessoas não querem isso. Portanto, envolva-os e eduque-os sobre por que essa é uma boa solução alternativa.

não há obrigação dos mantenedores de fazer nada a respeito, nem dar razões do porquê

Eu concordo. Mas você tem que esperar que as pessoas fiquem frustradas com isso. É uma atitude de desprezo. No final das contas, todos aqui estão no mesmo time. As pessoas que mantêm o projeto e os usuários do projeto desejam apenas que o projeto seja bem-sucedido.

Qual produto é gratuito exatamente aqui? Se eu usar docker-compose.exe e executar o docker EE, isso realmente não significa que estou pagando pelo produto?

IMHO --build deve puxar; não há necessidade de qualquer outro sinalizador ou configuração. se você não quiser que ele seja puxado, especifique a versão da imagem.

@ ET-CS: versões de imagens são apenas tags e ainda podem mudar para um hash diferente

bom ponto @lifeofguenter obrigado. pode escrever verificar se a imagem mudou para um hash diferente e puxar nesse caso também?

Em tal cenário, acho que gostaria que todos os ambientes (dev, prod) tivessem a mesma imagem possível agora que os desenvolvedores estão usando o novo hash enquanto a produção usa o antigo.

Eu esperaria que --build trouxesse tudo da última vez.

Portanto, aqui está um bom caso de uso:

Implementei um CI para meu projeto de microsserviços, que puxa novas imagens para um registro quando desenvolvemos novos recursos no serviço de back-end. A equipe de front-end (que sabe pouco sobre docker) precisa ter uma maneira de trazer toda a pilha de back-end em suas máquinas locais e contam com as imagens mais atualizadas. Se algo quebrar, só então eles vão se lembrar de puxar as imagens.

Agora é o que aconteceu: todo um sprint de desenvolvimento falhou porque alguém se esqueceu de atualizar as imagens de back-end e desenvolveu um recurso inteiro baseado em uma versão antiga. A culpa é da equipe de front-end, mas isso poderia ser evitado com essa funcionalidade (que farei usando scripts de wrapper).

@agnjunio Isso parece realmente lamentável, desculpe. No entanto, se a pessoa se esqueceu de executar docker-compose pull , não tenho certeza de como é menos provável que ela se esqueça de usar uma sinalização --pull hipotética.

@ shin- Desculpe, esqueci de mencionar uma coisa importante: a solução no meu caso é ter a tag pull: always dentro do yaml, talvez dentro de image: options

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

Eu esperaria --build para trazer tudo para o mais recente.

IMHO --build deve puxar; não há necessidade de qualquer outro sinalizador ou configuração. se você não quiser que ele seja puxado, especifique a versão da imagem.

AFAIK que bloquearia o caso de uso com uma construção usando um FROM que é o resultado de uma construção 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

Sou a favor de uma bandeira, conforme sugerido em https://github.com/docker/compose/issues/3574#issuecomment -252861859 e https://github.com/docker/compose/issues/3574#issuecomment -279460839

@solsson
Não tenho certeza se vejo por que ou o que está bloqueando neste caso de uso.
por favor, compartilhe mais informações sobre isso, se puder.

@ shin- A diferença aqui seria que se eu executar docker-compose up --help receberia uma forma descritiva de como usar a imagem: latest, em vez disso, hoje em dia tenho que pesquisar no doc ou no google que me leva a este tópico e eu precisamos ler todos os comentários para entender que docker-compose up não faz o que eu preciso / quero, então agora eu preciso executar dois comandos.

@agnjunio Isso parece realmente lamentável, desculpe. No entanto, se a pessoa se esqueceu de executar docker-compose pull, não tenho certeza de como é menos provável que ela se esqueça de usar um sinalizador --pull hipotético.

Cordialmente

Um dos principais motivos pelos quais usamos docker-compose é a capacidade de colocar um arquivo docker-compose.yaml em um repositório e ter uma saída reproduzível quando um desenvolvedor puxa o repositório e executa docker-compose up [service] .

Usamos vários serviços em nossos arquivos docker-compose que realizam tarefas como executar codegen e executar uma ferramenta para cancelar a referência de um esquema JSON em um único arquivo.
Garantir que essas ferramentas estejam atualizadas é fundamental, especialmente se atualizarmos nossa imagem codegen para corrigir alguns problemas críticos comuns vistos em todos os projetos.

Ter a capacidade de colocar:

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

manteria nossa capacidade de ter um desenvolvedor executando docker-compose de forma confiável e obter os resultados esperados, em vez de ter que complementar cada repositório com documentação para lembrar os desenvolvedores de executar uma cadeia de comandos ou scripts para obter as imagens mais recentes disponíveis antes de iniciar os aplicativos .

Não se trata de "a funcionalidade já existe para fazer isso executando esses comandos", é uma melhor experiência do usuário.

Imagine quando alguém sugerisse adicionar --stop a docker-compose rm que a resposta fosse "o que há de errado com docker-compose stop myapp && docker-compose rm myapp , ou se alguém tivesse solicitado a implementação de docker-compose down eles estavam apenas perguntado por que docker-compose stop myapp && docker-compose rm -v myapp && docker-compose images -q myapp | xargs docker rmi ... não é prático?

Esta discussão foi levantada 2 anos atrás e eu ainda acho que adicionar um sinalizador no docker-compose.yml é a melhor maneira. No meu caso, temos cerca de 37 serviços em um enxame e atualizar 4-5 imagens desse total não é fácil. Acabei de criar um shell por enquanto que pode monitorar a mudança do repositório e fazer o pull para a imagem específica antes de recriar o serviço, caso tenha sido atualizado.

Outro ponto aqui é que docker-compose up tem uma opção --quiet-pull . Quando eu estava tentando descobrir se up incluía um pull, presumi que sim com base em sua presença. É lógico que não usar --quiet-pull resulta em uma puxada detalhada.

Dois anos de pessoas tentando convencer os mantenedores do Docker Compose que ter a opção --pull seria uma experiência melhor sem ter que executar um comando separado. Se os mantenedores do docker-compose apenas implementassem o recurso, para começar, a vida de todos seria melhor. Parece estar claro que os mantenedores atuais não querem adicionar esse recurso para o aprimoramento da comunidade.

Talvez devêssemos apenas forker-compose e atualizá-lo nós mesmos.

Se alguém enviasse um PR, ele teria chance de ser aceito?
Este é um código aberto. Estive perto de implementar alguns
vezes eu mesmo. Suponho que poderia ser aceito, caso contrário, essa função seria encerrada,
direito?

Corri para este mesmo problema e puta merda, um bando de chorões aqui. Este é um software de código aberto GRATUITO. Dê um tempo aos mantenedores. Tenho certeza de que eles têm coisas muito mais importantes para trabalhar do que isso. Se alguém precisa tanto disso, por que você não abre um PR? Se o código estiver limpo com risco mínimo, não vejo por que eles não o aceitariam.

Este problema deve ser reaberto, pois a discussão carece de um bom motivo para não implementar esta solicitação. É mais provável que as pessoas comecem a trabalhar nos problemas _abertos_ do que nos encerrados.

O fato de esse problema "encerrado" ter permanecido tão ativo sugere que não foi bem tratado.

Infelizmente, descobri que as respostas às postagens de problemas em alguns repositórios do GitHub não são muito úteis. O tom costuma ser conciso e sugere que o feedback não é bem-vindo.

Alguns apontaram aqui que este é um projeto de código aberto e (pelo menos a maioria de nós) não está pagando clientes. No entanto, também é importante notar que o envio de relatórios de problemas constitui um investimento de tempo significativo, ainda mais se você participar da resolução do problema.

Um usuário ou desenvolvedor, depois de passar algum tempo solucionando um problema e encontrar uma solução alternativa, decidirá se deseja gastar mais tempo para relatá-lo. Uma resposta não receptiva dos mantenedores provavelmente fará com que eles optem por não se incomodar da próxima vez.

O software não é realmente "GRATUITO", no sentido de "cerveja grátis". pois todos estamos tentando participar para torná-lo melhor. Ter pessoas dispostas a testar seu software e fornecer feedback é um recurso valioso. Aqueles com as habilidades de programação necessárias estão até dispostos a contribuir com código, mas desejam algum tipo de indicação de que suas contribuições são bem-vindas antes de gastar tempo com isso.

Obviamente, comentários que simplesmente reclamam sobre um problema e exigem que ele seja corrigido não são úteis, mas a maioria não está fazendo isso, e comentários como "é código aberto, apenas garfo" são igualmente inúteis.

@ shin- Por que "--build" foi implementado? É diferente de docker-compose build && docker-compose up? Apenas tentando entender a diferença filosófica entre --build (que foi adicionado) e --pull (que foi considerado redundante). Compreender o processo de pensamento pode me ajudar a lembrar como as coisas funcionam. E se o problema for aberto, terei o prazer de enviar um PR. @everybodyelse ... é realmente o "espírito de código aberto" que se você não gosta de algo que você bifurca? Achei que o espírito do código aberto era "se você não gosta de algo, a) ajude a contribuir com os requisitos se for onde você está, b) ajude a contribuir com o código se puder" e que você só bifurcou se seus requisitos fossem muito claramente algo de que só você se beneficiaria. ou seja, pensei que nos beneficiamos mais quando compartilhamos - mas estou feliz por ser educado aqui.

Depois de dois anos insistindo, dando boas razões que são ignoradas e um enorme apoio da comunidade para que isso fosse realmente implementado, eu diria que esse recurso não vai funcionar só porque @ shin- não quer. Não há razão para continuar insistindo.

Há um motivo: o docker não atualizará as imagens se um pull falhar e não há um bom motivo para não fazê-lo.

Estou procurando a política de pull de imagens do kubernetes no docker compose, seria ótimo se o "pull" pudesse ser usado.

@ shin- Pare de ser infantil. Muitos bons motivos para implementar esse recurso foram mencionados. Pelo menos esteja aberto a PRs ...

Você pode discordar de mim, mas estou desapontado por você ter recorrido ao ad hominems, @Wenzil. Nossa comunidade geralmente se mantém em um padrão mais elevado.

@ shin- Nossa comunidade geralmente pensa o mesmo mantendo isso não dito devido ao motivo que você mencionou. @Wenzil está sendo honesto o suficiente para dizer isso em voz alta.
Muitas pessoas que conheço preferem não se incomodar e desistiram de tentar convencer docker-compose a se mover em direção a seus usuários.

Muitas pessoas discordam do @ shin- por razões muito válidas descritas. No mínimo, deve ser uma declaração de serviço. Encadear comandos bash juntos não é uma solução particularmente boa para implantações programáticas.

Muitas pessoas que conheço preferem não se incomodar e desistiram de tentar convencer docker-compose a se mover em direção a seus usuários.

Esse. E não é apenas docker-compose. Docker-stack, docker-machine e docker-cli são todos semelhantes.

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

Bloqueio, pois isso continua sendo descarrilado. Vamos reavaliar dependendo do destino de https://github.com/docker/cli/pull/1498

Como uma atualização, decidimos internamente adicionar um parâmetro pull_policy às definições de serviço. Ainda temos que descobrir quais serão as opções e a sintaxe exata, mas esperamos que satisfaça as necessidades expressas neste tópico.