Compose: O esquema de nomenclatura padrão para contêineres criados pelo Compose

Infelizmente não, desculpe.

Mesma coisa aqui. Este recurso de slug deve ser opcional. É difícil passar um sinalizador no comando up ou build para desligá-lo?

Eu concordo - isso deve ser opcional. Vários programas que usam o Docker Compose agora só são executados se você fizer o downgrade para 1.22.

Eu concordo, isso deve ser opcional. Não precisamos desse recurso slug de forma alguma e muitos scripts bash estão usando o formato de nomenclatura antigo.

O mesmo para nós, devemos permanecer no 1.22, pois usamos o recurso "volumes de" e contamos com o antigo esquema de nomenclatura. Por favor, torne-o recurso opcional em 1.24.

Esse recurso torna difícil referir-se aos contêineres depois que eles foram aumentados.

Eu não entendo o objetivo dessa mudança. Atualmente, nem docker nem compose oferecem qualquer descoberta de serviço. Portanto, se eu quiser obter um nome de host de dentro do contêiner, o que devo fazer? Rolar minha própria descoberta de serviço?

BTW, quais são os benefícios desta mudança? Vale realmente a pena quebrar a compatibilidade com versões anteriores?

A alteração do nome _slug padrão é a abordagem correta, mas não ter uma maneira de desativá-la por meio de uma variável de ambiente ou opção de linha de comando quebra muitos fluxos de trabalho existentes. Considere esta uma solicitação de recurso para adicionar um sinalizador de algum tipo para trazer de volta o comportamento de nomenclatura docker-compose <= 1.22.0.

Desculpe, mas "external_links" estão inutilizáveis ​​agora. Tenho que saber o nome de um container para vinculá-lo.
+1 por torná-lo opcional

@ shin- este novo comportamento estraga muito. Antes daquele slug aleatório, era possível endereçar um contêiner lançado de um arquivo docker-compose dentro de outro arquivo como

services:
  app:
    image: app
    external_links:
      - "other-project_other-app_1:other-app"
networks:
  default:
    external:
      name: other-project_default

E é isso. Agora, isso não vai funcionar de jeito nenhum.

Como isso não é opcional, pelo menos?

Outro passo para a morte do docker, creio eu.

Portanto, há uma solução alternativa. container_name parâmetro slug não é usado nele. Pelo menos, isso ajuda.

@ shin- por favor, não considere este um relatório de bug sobre slug não está sendo usado com container_name . Deixe como está. Estou literalmente ensacando aqui.

Oh garoto! https://github.com/ansible/ansible/issues/47978

Embora eu entenda o incentivo por trás da mudança, é altamente perturbador, especialmente porque não há período de carência para, pelo menos, dar aos desenvolvedores tempo para ajustar seu script. Muitos scripts foram escritos com essa convenção de nomenclatura em mente, que existiu literalmente para sempre. Basicamente, essa mudança torna docker-compose 1.23 não compatível com versões anteriores com qualquer outro docker-compose.

@ shin- Você pessoalmente e toda a equipe docker-compose e docker já devem aprender o que é mudança incompatível com versões anteriores e como trazê-la para um projeto amplamente adotado em que toda a indústria depende.

Em primeiro lugar, mudança incompatível com versões anteriores não significa quebrar o que garantiu anteriormente. Ninguém se importa se essa coisa não for usada por ninguém.

Mudança incompatível com versões anteriores é quando você quebra algo em que sua base de usuários realmente depende. E não importa quais são as garantias, porque afinal é o Apache 2.0 e todo o projeto provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND . Seus usuários decidem em que confiar. E você (toda a equipe) deve começar a aprender a saber quem usa seu projeto, por que e como.

Em segundo lugar, você deve aprender como introduzir essa mudança em sua base de usuários. Essa "coisa de sufixo aleatório" definitivamente quebra a maneira como seus usuários usam external_links e volumes_from . Portanto, o aviso de depreciação no caso de não haver um conjunto container_name explícito ou quando parece que seria muito apreciado. Por favor, considere estes documentos para estar familiarizado com "o que os outros fazem":

• https://www.python.org/dev/peps/pep-0004/
• http://api.mongodb.com/python/current/compatibility-policy.html
• https://docs.openstack.org/python-novaclient/pike/reference/deprecation-policy.html
• https://docs.djangoproject.com/en/dev/internals/release-process/#deprecation -policy

Terceiro, @ shin-, você pessoalmente deve aprender a falar com pessoas que não contribuem diretamente com seu projeto e que são apenas seus usuários, mas ao mesmo tempo são pessoas muito ocupadas que são leais ao seu projeto o suficiente para investir seus preciosos tempo preenchendo solicitações e participando de discussões aqui com a única esperança de trazer algum sentido para o desenvolvimento futuro do projeto e tentar evitar o investimento de mais recursos na migração para outra solução.

Quarto, a equipe do Docker está tentando ganhar dinheiro com o Docker, mas não se trata do Docker em si. A única maneira pela qual o Docker pode ser uma boa coisa para pagar é se toda a infraestrutura do Docker provar que vale a pena pagar. Não vejo como é um produto orientado para o sucesso do usuário se a equipe de desenvolvimento dá as costas para a comunidade na maioria das vezes.

Quinto, mais uma vez, todos nós aqui somos seus colégios e amigos, e não inimigos, e estamos realmente tentando ajudá-los com tudo isso. E porque somos seus amigos, o êxodo da pilha do docker será doloroso, mas, por falar nisso, agora vai, aquela despedida não parece nada irreal.

Esta é uma implementação terrível de uma grande mudança de quebra de versão, que quebra completamente a capacidade de implantar nosso framework e eu não posso nem imaginar quantos outros terão o mesmo problema exato, com absolutamente nenhum aviso prévio; a menos que alguém procure manualmente os últimos changelogs para docker, eles não têm ideia sobre isso, e imagino que a maioria das pessoas não fará isso

@ shin- Esta alteração é altamente prejudicial aos fluxos de trabalho existentes e deve haver um sinalizador fornecido para não gerar slugs. Milhares de horas de desenvolvimento foram gastas para escrever scripts e automatizar serviços que dependem da previsibilidade do docker-compose. Sem a descoberta de serviço adequada, qual é o plano da equipe para permitir o direcionamento automatizado de contêineres individuais?

Tentei usar a diretiva docker-compose container_name mas ela não entrou em vigor no GitLab.
Mas parece que na minha última versão de docker-compose no Mac Os Mojave está funcionando. Não tenho certeza do que está acontecendo :)

Meu arquivo .gitlabci.yml está baixando a última imagem de tmaier (deve ser 1.23.1).

Olá a todos, alguns comentários gerais que espero abordar algumas das preocupações expressas aqui:

• Eu definitivamente entendo que isso quebra alguns scripts. Nossas notas de lançamento desde 1.23.0-rc1 dizem isso no topo. Isso é muito mais um tipo de situação de "arrancar o curativo", em que a dor momentânea nos ajuda a seguir em frente com uma base mais saudável.
• Os benefícios da solução atual são numerosos e expressos em parte neste problema de longa data: # 1516 - e o problema com docker-compose run especialmente foi relatado várias vezes aqui: # 4688 # 4549 # 5240
• A descoberta de serviço não deve ser um problema, pois deve ser tratada usando nomes de serviço (em vez de nomes de contêiner) e aliases de rede, que são estáticos em sua rede associada. Você pode ler os documentos de rede para obter mais detalhes sobre isso especificamente
• Acho que isso torna volumes_from e external_links todos os projetos do Compose mais difíceis de usar. Por favor, considere que mesmo antes dessa mudança, não havia garantia de que o Compose respeitaria o formato "esperado" para um determinado nome de contêiner (veja por exemplo # 6155 ou o prefixo que é mencionado em # 3415), tornando-o uma solução falha e propensa a ser executada em questões obscuras no longo prazo.
  
  
  
  • A maneira recomendada de permitir que contêineres de diferentes projetos se comuniquem é compartilhar uma rede external e usar o (s) apelido (s) de outro (s) serviço (s). Da mesma forma, volumes_from em projetos devem, em vez disso, alavancar external volumes nomeados.
  
  
• Estou interessado em sugestões de como essa mudança poderia ter sido melhor comunicada. Para referência, a mudança foi mencionada em nossas notas de versão e está disponível para teste desde 1.23.0-rc1, que foi lançado em 26 de setembro. 1.23.0 GA foi lançado mais de um mês depois, e saber que a mudança seria controverso, colocamos isso como um grande aviso no topo do changelog. Se houver algo mais que eu pudesse ter feito para tornar essa mudança visível, fico feliz em ouvir e fazer essas coisas na próxima vez que considerarmos uma mudança arriscada como esta.
  
  
  
  • Por outro lado, se a conclusão geral aqui é "não faça nenhuma alteração significativa nunca ou deixe-me cancelar todas elas indefinidamente", tenho certeza de que a maioria de vocês perceberá que não é uma maneira saudável e razoável de seguir sobre a manutenção de um projeto de software do tamanho do Compose, que já supera muitos obstáculos para manter a compatibilidade com uma ampla gama de versões do Docker Engine, formatos de arquivo do Compose e idiomas obsoletos.
  
  

Avise-me se houver algo que não seja abordado aqui. Eu entendo que este é um grande obstáculo para muitos de vocês e os ânimos podem aumentar quando estamos lidando com circunstâncias imprevistas. Leve o tempo necessário para fazer a atualização e fixar sua versão do Compose por enquanto. Fico feliz em ajudar com perguntas como "Como faço XYZ sem nomes previsíveis?" até então, neste tópico ou no Slack. E, por favor, tenha consideração na maneira como você interage com outras pessoas nesses fóruns, verifique novamente se as informações que você está compartilhando estão corretas (eu já vi alguns tópicos sendo mencionados ou redirecionados que não tiveram nada a ver com essa mudança , o que cria uma sensação desnecessária de alarme e não ajuda as pessoas com o problema que estão sendo mal direcionadas aqui) e não atrapalha a conversa. Obrigado pelo seu tempo e paciência.

Na parte das comunicações, eu esperaria que uma mudança como essa fosse comunicada e explicada por meio de algum canal de comunicação com antecedência, basicamente da maneira que você acabou de fazer aqui neste tópico, explicando por que e o que fazer agora, mas fazendo antes todas as consequências.

@ shin- Você não leu meu último comentário e links que eu forneci, leu?

O último de você parece gentil, mas parece o mesmo.

Estou interessado em sugestões de como essa mudança poderia ter sido melhor comunicada.

TL; DR

• Apresente o novo version de docker-compose.yml
• Adicione DeprecationWarning para external_links com um link para um documento que descreve a atualização e fornece um exemplo de solução para aqueles que desejam migrar.
• Suporta o comportamento antigo para todas as versões de formato de arquivo de composição anteriores ao novo.

Para referência, a mudança foi mencionada em nossas notas de lançamento

O changelog é uma coisa para contribuidores. Os usuários não leem. Um usuário instala docker-compose e reza para que ainda funcione depois de ontem.

Por outro lado, se a conclusão geral aqui é "não faça nenhuma alteração significativa nunca ou deixe-me cancelar todas elas indefinidamente", tenho certeza de que a maioria de vocês perceberá que não é uma maneira saudável e razoável de seguir sobre a manutenção de um projeto de software do tamanho do Compose, que já supera muitos obstáculos para manter a compatibilidade com uma ampla gama de versões do Docker Engine, formatos de arquivo do Compose e idiomas obsoletos.

Eu tenho uma boa notícia para você. Você já garantiu "não faça nenhuma alteração importante, ou deixe-me cancelar todas elas indefinidamente". E mais, você tem um recurso para isso. É o version no arquivo docker-compose.yml . Portanto, considere reverter essa alteração o mais rápido possível e introduzi-la no próximo version número.

Fico feliz em ajudar com perguntas como "Como faço XYZ sem nomes previsíveis?" até então, neste tópico ou no Slack.

Por favor, forneça a solução para external_links e volumes externos sem container_name definido (como vemos que nem sempre funciona) em outro docker-compose.yml neste tópico.

Esta é uma maneira popular de seus usuários usarem seu projeto. A maioria dos usuários usa docker-compose para o desenvolvimento local. Freqüentemente, um tem vários projetos interligados em desenvolvimento. Nesse caso, é uma prática comum direcionar vários arquivos docker-compose para a mesma rede e definir external_links para que serviços de projetos diferentes possam se comunicar na máquina do desenvolvedor.

não atrapalhe a conversa

@ shin- Todas as conversas que li até agora envolvendo você descarrilaram porque você não fez nada para resolver os problemas que as pessoas têm.

Sério, com tal atitude negando constantemente as solicitações dos usuários e forçando a luta da sua comunidade quando você pode evitar que é melhor você passar este projeto para outra pessoa.

PS: Desculpe por outro comentário "offtopic". Sinta-se à vontade para bloquear este problema à medida que você também for usado.

Por favor, forneça a solução para external_links e volumes externos sem container_name definido (como vemos que nem sempre funciona) em outro docker-compose.yml neste tópico.

Já fiz, por favor, consulte meu comentário anterior:

A maneira recomendada de permitir que contêineres de projetos diferentes se comuniquem é compartilhar uma rede external e usar o (s) apelido (s) de outro (s) serviço (s). Da mesma forma, volumes_from em projetos devem, em vez disso, aproveitar external volumes nomeados.

O resto de sua postagem é desnecessariamente contraditório e não vou responder a isso. Estou aqui e estou disposto a ter uma discussão, mas não preciso aceitar sua intimidação.

Honestamente, @ shin-

Estou interessado em sugestões sobre como essa mudança poderia ter sido comunicada melhor

Não vejo que você esteja “interessado”. Fechar o tíquete sobre puxar a imagem antes de criar o arquivo de composição e marcá-lo como „spam” (risos) me diga que você definitivamente não está interessado no que a comunidade sugere. Realmente não sei o que você deseja alcançar, mas sinto que manter um relacionamento com a comunidade deve ser feito por outra pessoa.

Estou aqui e desejando ter uma discussão

Mesmo se fornecermos argumentos meritórios puros, você simplesmente os ignora. Então, por que se preocupar?

PS. Marque como offtopic, vá em frente, mostre-nos como você respeita nossa opinião. Ver tantos votos positivos em opiniões diferentes dói?

Já fiz, por favor, consulte meu comentário anterior:

Não vejo uma solução de amostra de trabalho lá, desculpe.

O resto de sua postagem é desnecessariamente contraditório e não vou responder a isso. Estou aqui e estou disposto a ter uma discussão, mas não preciso aceitar sua intimidação.

Desculpe, se você se sente assim. Por favor, considere suportar o comportamento antigo para as versões atuais do arquivo docker compose e apresentar a nova versão do formato que se comportará da nova maneira. Esta é a única opção que você tem para fornecer uma boa solução para sua base de usuários.

Por favor. considere ler estes dois meus comentários novamente com a ideia de que estou disposto a ajudar o projeto em sua mente:

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

Sobre as comunicações: obtivemos a atualização por meio do Docker para Mac e não parecia mostrar nenhum tipo de changelog apontando essa mudança, então demorou um pouco para descobrir por que nossas variáveis ​​de ambiente haviam mudado.

Uma vez que fiquei sabendo disso, porém, aproveitei isso como uma oportunidade para atualizar nossa configuração de v1 para v3 e vincular usando nomes de serviço em vez de variáveis ​​de ambiente, e isso na verdade tornou as coisas muito mais limpas 👍

FWIW, um hack compatível com versões anteriores para exec em um contêiner criado por compose:

docker container exec -it $(docker container ls -f name=expected -q) cmd

Uma vez que eu estava ciente disso, porém, aproveitei a oportunidade para atualizar nossa configuração de v1 para v3 e vincular usando nomes de serviço em vez de variáveis ​​de ambiente, e isso na verdade tornou as coisas muito mais claras

Você poderia fornecer um pequeno exemplo aqui para o nome do serviço vinculando em diferentes abordagens de arquivos docker-compose?

docker container exec -it $(docker container ls -f name=expected -q) cmd

Isso não tem nada a ver com docker-compose.

@lig Isso contorna a mudança no nome expected criado por docker-compose. Esta solução alternativa não existiria se não fosse pela mudança no esquema de nomenclatura.

@joebowbeer, o principal problema após essa mudança é a vinculação de arquivos docker-compose. Eu vejo, há uma maneira de encontrar um contêiner iniciado por docker-compose via docker cmd. Mas isso ajuda um pouco no assunto :(

@ shin- Acho que todos ainda estamos esperando a explicação de por que precisamos do docker composer para gerar nomes de contêineres de linha de enxame.

Para mim, está bastante claro que ninguém em seu estado são precisaria usar o compositor para fins de produção. Compose é um poderoso projeto de ramp up a ser testado localmente. Não vejo o apelo de obter um privilégio / funcionalidade docker swarm para uma ferramenta amplamente usada para testes apenas locais. Se precisássemos de um nome semelhante a enxame para contêineres, usaríamos enxame. Direito?

A segunda grande questão aqui é: por que isso não foi incluído como um recurso opcional por meio de um argumento? Não vejo em meus fóruns e comunidades pessoas apelando para que esse comportamento seja o padrão. Portanto, provavelmente devemos introduzi-lo como um novo argumento: docker-compose up --slug . Simples, elegante e não quebraria os scripts de ninguém.

  * On the flipside, if the general takeaway here is "don't make any breaking change ever, or let me opt out of all of them indefinitely", I'm sure most of you realize that it's not a healthy, reasonable way to go about maintaining a software project the size of Compose, which already jumps through a lot of hoops to maintain backward-compatibility with a wide array of Docker Engine versions, Compose file formats, and deprecated idioms.

Trabalhando em empresas, no passado, tendíamos a ter uma regra de "duas versões principais" para interromper as alterações - descontinuar em uma e remover na seguinte. Não tenho certeza de como isso poderia ter sido feito como opt-in, mas um opt-out _temporary_ teria sido muito apreciado.

Docker-compose não parece ter um conceito de versões principais, mas não vejo como uma opção temporária "desabilitar isso" (seja na linha de comando ou no arquivo de composição) limitada a uma ou duas versões (1.23 e possivelmente 1,24) constituiria "indefinidamente".

Dado que isso parece estar ligado às atualizações automáticas para os usuários não Linux, muitas pessoas foram pegas de surpresa, e em vez de ter o restante do trimestre para "executar com este sinalizador de linha de comando enquanto atualizamos nosso script" temos um monte de desenvolvedores que precisam fazer o downgrade manualmente e / ou descartar o que estão fazendo para atualizar os scripts.

Essa mudança significativa é um desastre. Quebrou muita implantação automática de repente. Por favor, não faça isso de novo.

* Introduce the new `version` of the `docker-compose.yml` 
* Add `DeprecationWarning` for `external_links` with a link to a document which describes the update and provides a sample solution for those willing to migrate.
* Support the old behavior for all compose file format versions prior the new one.

Faz muito sentido ... não faço ideia por que não é feito dessa forma.

Estou aqui e estou disposto a ter uma discussão, mas não preciso aceitar sua intimidação.

@ shin- é bastante óbvio que não há discussão aqui, pois você não está considerando as sugestões racionais apresentadas. Além disso, se alguém está intimidando - você está - com essa mudança significativa, você está efetivamente intimidando vários desenvolvedores em todo o mundo.

Muitas pessoas (eu e alguma outra pessoa provavelmente) não usam a composição no modo enxame. Eu especifico uma versão inferior para meus arquivos de composição por causa de problemas que tive no passado em que a suposição é que um arquivo de composição é usado para definir serviços para enxames. Eu percebi que a versão que eu especificou estava ligada aos resultados produzidos no meu docker node e ao bloquear a versão para algo baixo, eu seria capaz de obter resultados consistentes e ainda fazer atualizações para compor para ficar compatível com a versão do docker Estou correndo. Aparentemente, não posso esperar um versionamento adequado aqui.

Podemos encaixar o docker-compose para garantir que eles não quebrem nossas coisas de repente?

Acho que a melhor solução seria introduzir uma nova opção de configuração no arquivo docker-compose.yml em que a adição da parte do slug aos nomes dos contêineres pudesse ser desabilitada.

s / desativado / ativado /. Pelo menos nas versões existentes do arquivo de composição.

Esse comportamento precisa estar vinculado ao número da versão do arquivo de composição. Independentemente de esse comportamento ter sido "especificado", ele é amplamente usado e, portanto, é uma alteração incompatível com versões anteriores. Por que criar uma versão da especificação nesse ponto, se o que um arquivo de composição faz não é garantido que funcione da mesma maneira quando eu atualizar meu binário? Descontinuando uma especificação de arquivo de composição (com muitos avisos quando docker-compose é executado, é claro) e, em seguida, removendo-a, seria definitivamente minha culpa todas as minhas coisas não estão mais funcionando, mas espero que eu leia seu lançamento notas para um programa que tem o privilégio de imprimir mensagens de aviso na minha cara?

Fazer alterações como essa parece uma boa motivação para controlar a versão do comportamento da especificação, além de seu formato: você pode descontinuar as suposições de código dos outros com aviso. Eu acho que a quantidade de questões externas mencionando essa questão mostra como isso foi surpreendente para muitas pessoas. É muito bom ver o comportamento legado sendo destruído para que o código não se complique, mas mudanças como essa não podem ser aplicadas todas de uma vez. Posso esperar que outras suposições sobre a composição de nomes de contêiner sejam quebradas? O nome do serviço sempre estará no nome do contêiner ou pode ser removido como os nomes previsíveis?

Isso realmente me lembra de quando a Nomenclatura de dispositivo de rede consistente foi amplamente adotada no Linux (mas isso é o oposto da nomenclatura ... idk). Muito código foi codificado para a ethN (e ainda está em alguns lugares surpreendentes) e isso não mudou realmente. No entanto, existe uma maneira de recuperar o comportamento antigo em sistemas systemd (e em outros sistemas, mas pode variar) adicionando net.ifnames=0 aos argumentos do kernel.

(Desculpe pelo discurso retórico, mas não acho que o primeiro foi muito construtivo.)

Parece que essa mudança torna a opção --scale inútil. porque o postfix aleatório deve ser conhecido para alcançar instâncias em escala de um serviço.

Por exemplo, várias instâncias de serviço como servidores upstream para Nginx.

Editar: veja # 6365 para mais informações

Uau, que mudança horrível. 👎

Como devemos obter a string gerada aleatoriamente para uso em scripts?

Também me deparei com esse problema e gostaria de expressar minha recomendação para futuras alterações incompatíveis com versões anteriores. Nós também temos scripts que dependem do formato project_service_index, com muitas pessoas usando esses scripts no Mac. Em um mundo ideal, seríamos capazes de controlar a versão do Docker para Mac que as pessoas usam, mas por enquanto as pessoas atualizam quando a caixa de diálogo de atualização automática aparece.

Meus problemas e recomendações são:

1) A caixa de diálogo de atualização não tinha nenhuma indicação dessa mudança significativa, portanto, não tínhamos avisos óbvios sobre essa mudança. Em um mundo ideal, verificaríamos todas as notas de lançamento de cada atualização, mas não o fazemos no momento. Portanto, seria muito grato se algo significativo como isso fosse chamado explicitamente na caixa de diálogo de atualização.

2) Devido a 1), não houve nenhum aviso óbvio. Seria ótimo se uma mudança como essa fosse mencionada na atualização anterior. Por exemplo, a atualização antes da última diria algo como “o esquema de nomenclatura do contêiner está mudando na próxima versão, atualize seus scripts”

3) Eu entendo que, depois de ler este tópico, o esquema de nomenclatura que estamos usando não é garantido e percebo que existem maneiras melhores de nos referirmos a contêineres. No entanto, todos nós temos uma vida profissional ocupada e precisamos planejar nossas tarefas, então, como mantenedor de nossos scripts, não sou capaz de converter nosso uso de nomes de contêiner em algo melhor imediatamente. Tenho o prazer de usar a prática recomendada, mas preciso de tempo para migrar nosso código. Portanto, seria ótimo ter uma estratégia de suspensão de uso para uma mudança como essa.

A principal conclusão aqui é que a maior parte do mundo assume um esquema de nomenclatura de contêiner que é fundamental para o uso do docker compose, e alterar o comportamento padrão sem uma estratégia de reprovação óbvia pode ser prejudicial para esses fluxos de trabalho.

As pessoas nem sempre usam o software exatamente da maneira que foi planejado, e cabe a essas pessoas consertar as coisas quando suas suposições falham. No entanto, algumas comunicações simples podem nos ajudar a nos preparar para mudanças futuras e ajudar a nos motivar a seguir as práticas recomendadas mais recentes.

Se você dependia anteriormente de docker container exec -it project_php_1 bash , não pode mais usar isso.

Você deve usar docker ps para encontrar o ID do serviço.

No entanto, você não pode usar docker ps -q --filter=name=project_php porque isso corresponderá aos serviços chamados project_php e project_php_xdebug ou qualquer outra coisa que corresponda à esquerda de project_php .

O docker container exec -it project_php_1 bash legível anteriormente agora deve se tornar este:

docker container exec -it \
    $(docker ps -q \
        --filter label=com.docker.compose.project=project \
        --filter label=com.docker.compose.service=php) \
    bash

Esta foi uma mudança mal pensada.

@jtreminio FWIW, do projeto você ainda pode fazer docker-compose exec php

Obrigado a todos que reservaram um tempo para compartilhar suas ideias sobre a mudança. Concordamos que isso foi mal tratado e com um pouco de zelo excessivo de nossa parte, e foi parcialmente revertido no Compose 1.23.2 (estamos mantendo sufixos aleatórios para contêineres criados por docker-compose run , o que nos permite lidar com eles de maneira mais elegante : # 4688 # 4549 # 5240, como foi inicialmente planejado).

Informe se houver algum problema pendente que precisa ser resolvido.

Existe algum plano para adicionar uma opção de linha de comando para desligar isso --no-slug ou mais preferencialmente --slug para que o padrão seja funcionar como antes.

1.23.2 voltar a ser como era antes.

Só foi revertido para docker-compose up mas não para docker-compose run

Obrigado pela resolução rápida disso !!

Em 28 de novembro de 2018, às 20h09, Joffrey F [email protected] escreveu:

Obrigado a todos que reservaram um tempo para compartilhar suas ideias sobre a mudança. Concordamos que isso foi mal tratado e com um pouco de excesso de zelo de nossa parte, e foi parcialmente revertido no Compose 1.23.2 (estamos mantendo sufixos aleatórios para contêineres criados pela execução docker-compose, o que nos permite lidar com eles com mais elegância: # 4688 # 4549 # 5240, conforme pretendido inicialmente).

Informe se houver algum problema pendente que precisa ser resolvido.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub ou ignore a conversa.

@ shin- Presumo que isso será retornado em algum ponto - possivelmente em 1.24 (uma vez que é uma alteração significativa?). Em caso afirmativo, você poderia trabalhar com a comunidade para entender e recomendar mecanismos leves alternativos para pessoas que os usavam sem lesmas? Não tenho certeza sobre o melhor lugar para ter essa conversa.

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

mudou de <project>_<service>_<index> para <project>_<service>_<index>_<slug>

Este é um bug, não um recurso.
Obrigado!
Pense nos manuais ansible que estão sendo executados com ansible_connection=docker ... 😔 !!
devemos dar container_name explícito? ou devemos manter atualizando nosso inventário com <slug> aleatórios !!.
Realmente muito ruim!