Compose: Depends_on na versão 3

depends_on ainda existe na v3, mas as dependências da verificação de integridade (e, como resultado, a sintaxe estendida) não serão transferidas.

HTH

Mas eu escrevi um docker-compose v3 e tento implantar no swarm, mas depends_on não está funcionando porque o contêiner não está iniciando da maneira em que deve ser iniciado.

Você está usando docker-compose ou docker stack deploy ?

Estou usando docker stack deploy
e tento implantá-lo em um enxame de 7 máquinas

Qual seria o equivalente no docker-compose v3 para obter algo como dependências de verificação de integridade? Se você vai descartar essa funcionalidade na v3, basicamente nunca deve usá-la, ou pelo menos deve haver um caminho de migração para isso.

Quais são as intenções de apresentá-lo em um novo docker-compose v2.1 e, em seguida, descartá-lo para a v3? No momento, estou configurando diferentes arquivos de composição para nossos aplicativos, mas não quero usar recursos que serão descartados na próxima versão e, portanto, evito que o uso seja atualizado para uma versão mais recente do arquivo docker-compose.

No momento, você deve presumir que a nova sintaxe depends_on não será transferida para a v3, pois não temos planos para fazer isso.

Sei que essa não é a resposta que muitas pessoas desejam, mas espero que ajude a dar alguma clareza, pelo menos.

Posso perguntar por que não está nos planos? Suponho que seria muito útil fazer isso.

Ele dá clareza, mas não explica. Você pode explicar o porquê? E sobre as alternativas (se existirem)?
O Depends_on nos dá uma maneira realmente fácil de depender de um serviço, ao invés de manipulá-lo dentro do contêiner (o que pode significar envolver uma imagem de terceiros com algum script de espera e ter que mantê-lo).

@ shin- então por que você o implementou no 2.1? Se as pessoas o usarem e passarem a depender dele, nunca poderão fazer upgrade. Com todo o respeito, isso parece um planejamento muito ruim da parte de vocês.

Então, qual é a sintaxe Depende_on com suporte para v3? https://docs.docker.com/compose/compose-file/#version -3 não menciona depends_on, e quando eu uso docker-compose v1.10 para implantar um aplicativo, nem os sabores Depends_on v2 ou v2.1 funcionam para eu em um arquivo de composição v3 ...

@mustafaakin

Posso perguntar por que não está nos planos? Suponho que seria muito útil fazer isso.

@hsmade

Você pode explicar o porquê? E sobre as alternativas (se existirem)?

De https://github.com/docker/docker/issues/30404#issuecomment -274825244

depends_on é autônomo quando usado com docker stack deploy . Os serviços do modo Swarm são reiniciados quando falham, então não há razão para atrasar sua inicialização. Mesmo se falharem algumas vezes, eles eventualmente se recuperarão.

@brettmc

Então, qual é a sintaxe Depende_on com suporte para v3?

Ao usar docker-compose , a sintaxe com suporte para v3 é a sintaxe de lista (semelhante à usada para 2.0). Se você estiver usando docker stack deploy , as dependências não serão respeitadas (veja a justificativa acima)

O formato da versão 3 é o primeiro passo na mudança da ferramenta docker-compose externa em direção à solução docker stack integrada. A implementação atual tem suas peculiaridades que estão sendo trabalhadas. O suporte para o formato da versão 3 em docker-compose tem como objetivo ajudar nessa transição. Muitas coisas mudaram e melhoraram no Docker desde que fig / Compose foi introduzido pela primeira vez, e isso significa que muitas das coisas que faziam sentido agora se tornaram obsoletas. docker stack é um novo começo usando novos conceitos e descarta algumas das sintaxes e conceitos mais pesados, de volumes_from a depends_on .
Se você tiver preocupações específicas sobre algumas dessas alterações, relate-as no repositório docker / docker onde está sendo iterado ativamente.
Se você ainda não está pronto para fazer a transição para os serviços Docker e docker stack , fique à vontade para continuar usando o formato v2. Embora seja razoável supor que o projeto será encerrado em algum momento no futuro, será anunciado com bastante antecedência. E depois disso, o código permanecerá disponível e de código aberto.

Obrigado. Agora faz sentido.

Os serviços do modo Swarm são reiniciados quando falham, então não há razão para atrasar sua inicialização. Mesmo se falharem algumas vezes, eles eventualmente se recuperarão.

IMHO esta não é uma boa abordagem. Nem todos os serviços podem detectar corretamente se os outros serviços dos quais eles dependem não estão prontos, eles tentam muitas vezes e falham, então o contêiner pode morrer mais tarde. Ainda precisamos introduzir scripts de wrapper de ponto de entrada, o que não é muito bom. A dependência de verificação de integridade era muito boa, mas simplesmente não suporta o modo enxame.

Os serviços do modo Swarm são reiniciados quando falham, então não há razão para atrasar sua inicialização. Mesmo se falharem algumas vezes, eles eventualmente se recuperarão.

Ei pessoal!
Isso significa que se, por exemplo, eu tiver um serviço que executa e termina seu trabalho muito rapidamente (e deve ser executado apenas uma vez por design), ele será iniciado novamente e novamente ... repetidamente?

@ Marvel77 Por padrão, sim, mas você pode substituir esse comportamento usando a seção deploy.restart_policy : https://docs.docker.com/compose/compose-file/#restartpolicy

@ shin- Muito obrigado!

@mustafaakin Na verdade, a prática recomendada é (IMHO) ter uma conexão tolerante a falhas com os serviços dos quais você depende. Por exemplo, se você usa um banco de dados, pode atrasar a inicialização até que ele responda. Mas como você lida com uma reinicialização do banco de dados? Seu aplicativo deve ser capaz de se recuperar disso, e você não precisa depender de 'depend_on' também.
Em certo sentido, a depreciação é uma coisa boa. Essas conveniências nos tornam preguiçosos.

@hsmade Mas quase todo init (upstart, systemd) depende do relacionamento. Portanto, não é ser preguiçoso, é o que faz sentido. O daemon SSHD não inicia até que seu dispositivo de rede esteja pronto. Não tenho controle sobre todos os sistemas que tenho, sim, posso fazer com que meus sistemas sejam tolerantes a falhas. Mas suponha que A dependa de B. A demora um pouco para inicializar, não é muito determinístico. Então, como você pode escrever uma política de reinicialização em B? reiniciar para sempre? E se você não quiser isso?

Este é um problema maior do que o Compose, o Compose apenas os inicia. O Swarm é o que os faz correr, então acho que o Swarm deve lidar com essa dependência do relacionamento com a saúde.

@mustafaakin Não acho que você possa comparar a execução de micro serviços em um ambiente em contêiner com os sistemas init clássicos. Isso realmente não faz sentido. Acho que a ideia dos microsserviços é que eles são entidades mínimas independentes. Eles têm uma definição muito clara de sua API, etc. Eles não devem assumir nenhum status de seu mundo externo. Sim, seria necessário um banco de dados, mas não, você não pode presumir que esteja lá. Como tentei dizer, saber que sua dependência existe na inicialização é o menor dos seus problemas, lidar bem com ela quando ela vai embora é mais importante, e deve resolver também a primeira.

Mas, novamente, esses são meus pensamentos sobre o assunto, e posso estar errado;)

Sim, não faz sentido para microsserviços, mas nem tudo é um microsserviço, eu executo o Hadoop em um contêiner. O Docker não é apenas para microsserviços. Como eu disse, é ótimo para os ambientes que eu tenho controle, mas nas coisas que eu não tenho controle, é necessário encapsular o ponto de entrada dos serviços. Foi apenas resolvido com depends_on com healtcheck, eu só acho que seria ótimo tê-lo no Swarm também. Reiniciar contionously é apenas a escolha de um homem preguiçoso.

Rapazes,

Eu acho que há uma espécie de concepção errônea de "tolerante a falhas" e uma espécie de "inicialização pela primeira vez".
Concorde que a abordagem parece boa o suficiente para o primeiro, mas o último é uma verdadeira dor.
Eu imagino que não só eu, mas geralmente alguém precisaria iniciar os serviços em uma ordem particular, pois eles dependem um do outro mais ou menos.

Ter reinicializações contínuas na fase de inicialização e esperar que os serviços em algum ponto iniciem na ordem adequada por si só é como um pesadelo - não se pode planejar qualquer "tempo de inatividade" para o processo de inicialização se o pior acontecer. Não só o pior, mas às vezes há, digamos, um tempo de "manutenção" em que algo precisa mudar e ninguém seria capaz de prever quanto tempo levaria para o sistema realmente iniciar, porque diferentes serviços são reiniciados por enxame repetidamente novamente aguardando o pedido adequado.
Eu tentei e esperei para ver como ficaria com 7 contêineres e por 20 minutos _swarm_ ainda não descobri e todo o serviço ainda estava fora do ar.
Portanto, não se pode nem mesmo afirmar quanto tempo levaria para trazer de volta e restaurar toda a infraestrutura, pois realmente não se sabe quanto tempo levaria a _inicialização inicial_.
Parece absurdo para mim.

Não acho que posso entrar em "produção" sem essa previsibilidade, embora isso aconteça raramente (totalmente para baixo) - melhor nunca acontecer.
Mas, exatamente se isso ainda acontecer, eu estaria no local e serei desafiado a restaurar o mais rápido possível e naquele momento e pressão, eu não teria absolutamente nenhuma ideia de quanto tempo meus contêineres iriam iniciar, só porque eles continuam a reiniciar durante a _inicialização._

@ozlatkov Isso realmente deve ser postado no rastreador de problemas do docker / docker, não aqui.

@ shin- Obrigado! Mudei para docker / docker tracker:

https://github.com/docker/docker/issues/31333

Acho muito ruim que a equipe do Docker presuma que o Docker Swarm seja usado. O Compose é uma ferramenta autônoma totalmente funcional.

No entanto, usamos muito o Docker Compose em nossos pipelines de teste e uma REMOÇÃO tão fundamental de recursos (sem fornecer uma alternativa viável) está realmente tendo efeitos negativos dramáticos em seus usuários.

No momento, estou revisando um PR muito feio dos membros da minha equipe, onde eles estão tentando encontrar todos os tipos de soluções alternativas para isso (já que dependemos muito dessa funcionalidade), incluindo permanecer no Compose 2.X por toda a eternidade.

O Docker deve nos ajudar a atingir nossos objetivos, e não dificultar as coisas removendo recursos críticos dos quais muitas equipes já dependem.

Reconsidere a portabilidade de tudo isso para o Docker Compose 3.

Muito apreciado.

Pela centésima vez: não há razão para usar o formato v3 se você não pretende usar os serviços de enxame.

Isso significa que a equipe está se comprometendo a oferecer suporte aos formatos 2.X para aqueles que estão usando o compose como uma ferramenta de desenvolvimento independente?

Exatamente minha pergunta: a equipe do Compose está comprometida em oferecer suporte ao formato v2 para sempre?

Não podemos padronizar no Docker Compose se o formato v2 estiver programado para desaprovação a qualquer momento.

Sinto que isso força todos os contêineres em um padrão init container , remove a política de reinicialização do docker e cria uma abordagem hacky para a ordem de inicialização. Deve-se presumir que> = v3 do compose se moverá nessa direção para focar em pilhas e criar pacotes de aplicativos? E se estiver certo, você poderia me indicar como manter a ordem de inicialização em uma pilha do docker? wait-for-it.sh ou dockerize a abordagem lá?

Qual é o equivalente declarativo de docker-compose.yml para uma pilha?

Oi pessoal, qual é a prática recomendada se eu pretendo usar docker stack e me livrar do docker-compose?

Esta parece ser a solução, mas ter scripts do tipo hacky para containers init não parece uma boa prática. É mesmo?

Obrigado.

@mustafaakin Obrigado pelo seu

@VinceOPS Não tenho certeza sobre as "melhores práticas", mas tenho usado verificações de saúde e restart: always então ele apenas executa um ciclo até funcionar ¯ \ _ (ツ) _ / ¯

@hutchic Mas, como mencionado na conversa acima, não poderia ter uma data de término, algum tipo de reinicialização circular em caso de falha.

Por que a equipe do docker remove esse recurso na versão 3 e rejeita adicioná-lo?

@ tianhao-au veja a discussão em https://github.com/moby/moby/issues/31333 (e https://github.com/moby/moby/issues/31333#issuecomment-409143581)

Para escrever, também deixei uma sugestão em https://github.com/moby/moby/issues/31333#issuecomment -333265696 (tenha um x-depends_on )

Essa mudança de recurso é literalmente porque eu não uso mais docker-compose. Se estou usando docker na produção e docker-compose localmente para ambientes de desenvolvimento, agora preciso fazer com que meus containers docker se comportem de maneira radicalmente diferente em desenvolvimento e em produção. Na produção, conto com um sistema de orquestração para garantir a integridade e a ordem de minhas implantações. Na terra do desenvolvimento, essa orquestração era feita por docker-compose. Agora estou escrevendo um monte de scripts mutilados para verificar a integridade das coisas para orquestrar meu sistema. Se vou fazer isso, por que não escrever um golang para gerenciar minhas docas e acabar logo com isso? Um pouco chateado foi derrubado. Só meu 2p

Tentando usar a versão docker-compose mais recente para tornar as coisas mais preparadas para o futuro, esbarrei nesse problema. Isso é triste.