@jmmills Você não pode iniciar seus contêineres como: "docker-compose scale worker = 5" e esse serviço começaria com 5?

@aanm Sim, mas acho que a funcionalidade deve ser espelhada como padrão na definição do serviço. Talvez eu tenha um conjunto mínimo de workers que devem estar sempre em execução e quero que isso seja declarado claramente como padrão.

@ @aanm Você espera que docker-compose up leve em consideração o parâmetro scale ? O único problema que vejo com isso é que estamos introduzindo parâmetros na configuração declarativa que NÃO são compatíveis com os conceitos subjacentes da API Docker / Docker, mas muito específicos para o Docker Compose.

Se fôssemos fazer isso daqui para frente; Eu sugiro algo como:

#!yaml worker: build: rqworker $scale: 5 links: - redis command: rqworker -u tcp://redis

Onde $<parameter> denota uma coisa específica do Docker Compose.

Nós discutimos se scale pertence ao YAML; houve um PR para adicioná-lo antes (# 630). Ainda sou da opinião de que a maioria das pessoas não deveria colocar números de escala em sua configuração, porque isso a torna menos portátil, mas eu entendo os casos de uso para fazer isso.

Agora que temos uma maneira rudimentar de aumentar os arquivos Compose com extends (e esperançosamente melhores em breve - # 1380, # 758), as preocupações que levantei em https://github.com/docker/compose / pull / 630 # issuecomment -69210279 são talvez menos problemáticos.

Eu gostaria de definir scale=0 no meu yml para serviços relacionados a testes que normalmente não desejo iniciar. Só quero criar esses serviços explicitamente com docker-compose run ou scale explícito.

@jamshid Eu sempre quis isso, uma definição que configura um ambiente, mas não funciona por padrão. Fui relegado a criar uma imagem de base (com a qual uma escala zero / sem operação também ajudaria) na qual executo meus testes de unidade (via docker run ) e, em seguida, minha composição de contêiner consome o imagem de base.

Algo assim parece muito útil para configurações de desenvolvimento

myproject:
    build: .
    command: nosetests
    scale: 0
    links:
       - redis
redis:
    image: redis
apiserver:
    image: myproject
    command: plackup
    links:
       - redis
workerserver:
    image: myproject
    command: rqworker
    links:
        - redis

@jamshid @jmmills E quanto a enabled parâmetro / chave no arquivo YAML por serviço? Para que você possa desabilitar / habilitar um serviço?

@prologic Por que fazer isso quando o parâmetro a "escala" resolveria ambas as necessidades?
Se você quiser imaginar um processo / contêiner em execução como uma instância de uma classe, pode-se até chamá-lo de instances

@jmmills , estou apenas tentando encontrar uma _solução_ para o seu caso de uso que não envolva quebrar o docker-compose atual como tal. Tenho a tendência de pensar que scale=0 não parece muito adequado e estou em dúvida se scale=X deve ser parte do próprio Compose.

Na minha opinião a escala (ou número de cópias) faz parte da composição de um serviço, portanto deve ser incluída na composição.

Bem, acho que temos uma chave scale=0 ou disabled .

: +1: por ter a capacidade de definir um tamanho padrão de scale para uma instância. E eu concordo, uma vez que a escala está inserida, não há necessidade de uma tecla disabled , já que você simplesmente definiria a escala para 0.

+1

Além disso, outro caso de uso: e se eu quiser dimensionar o número de contêineres, mas não quiser colocar em segundo plano todos os serviços ou precisar pular para outro terminal (ou processo) e definir meus números de escala ...
por exemplo:

$ docker-compose up && docker scale thing=4

Não funciona porque para cima não sai.
Mas se meu arquivo de composição definir a escala de meus contêineres ...

$ docker-compose up

Torna-se DWIM.

Não tenho certeza se gosto disso; de repente up assume duas funções:

• Traga quaisquer contêineres que não tenham o parâmetro scale .
• Traga todos os recipientes que contenham scale=0 .

Agora estamos realmente abusando do comando "up". "Escala" também adquire um novo significado, pois agora faz duas coisas:

• escalar recipientes para cima / para baixo
• Desative os contêineres / serviços por meio de ` scale=0

Por que criaria contêineres com um scale=0 ?
O Build construiria imagens com scale=0 , facilitando assim a necessidade de uma imagem de base.

Eu _poderia estar errado_ mas lendo seu último comentário meio que sugeriu que :)

Deixe-me explicar:

base_thing:
    build: .
    scale: 0

thing:
    image: base_thing
    # scale: 1 implied by default

workers_for_thing:
    image: some_other_image
    scale: 4
    links:
      - thing

test_harness:
    image: base_thing
    command: nosetests --where=my_test_code_dir --all-modules
    scale: 0

Agora, comportamento esperado: docker-compose build constrói qualquer contêiner com "construir" (compor puxa imagens externas na construção? Não se lembra), docker-compose up executaria qualquer coisa com uma escala positiva (o padrão é 1), docker-compose run test_harness construiria "base_thing" se necessário e executaria meu único comando. Savvy? :)

Editar: docker-compose up executaria 1 "thing" e 4 "workers_for_thing"

Ok :) Obrigado; seu exemplo faz muito mais sentido e um pouco mais claro quanto à intenção de scale=0

Acho que docker-compose "puxa" imagens em up / run .

Preciso criar receita indicar número de de intâncias (escala), para teste, produção, qa, etc.

+1 para scale=X . Isso seria muito útil.
E +1 para @jmmills comentário com descrição da configuração e resultados esperados.

Yay! por scale=x . Inicializar um conjunto de contêineres definitivamente ajudaria a identificar condições de corrida em potencial ao definir as configurações de cluster.

+1 para scale=x (incluindo scale=0 para desativar os serviços para docker-compose up )

+1 para scale=x .

x é NaN, eu proporia -1 lugar.

+1 para escala = x.

+1

+1

Que tal pararmos com os + 1s, por favor?

Marcar com +1 é útil para ver o nível de interesse de um recurso.

@shofetim Eu conheço uma maneira melhor de fazer exatamente isso: implementar o recurso em questão e enviar uma solicitação de pull ...

O +1 também é uma boa maneira de ver as pessoas concordarem sobre uma solução proposta. É um comportamento bastante comum no github. Clicar no botão cancelar inscrição nas notificações irá desativá-las, se isso for um problema.

Bem, parece que pessoas assim. Há um item semelhante na lista de pendências de composição (que sobrou da Fig), tenho certeza de que fiz um comentário sobre ele em algum momento. Vou tentar fazer o acompanhamento mais tarde esta noite.
Estou na PuppetCon a maior parte desta semana, então espero que isso me dê algum tempo para hackear - vou ver se consigo escrever isso.

Aqui está uma solução alternativa para o caso de uso "escala = 0":

app:
  build: .
  environment:
    - DATABASE_URL=postgres://user:password<strong i="6">@host</strong>:5432/dbname
  command: sleep 999999999999

app_web:
  extends:
    service: app
  ports:
    - "3000:3000"
  command:
    # intentionally blank to use Dockerfile's default RUN command

app_worker:
  extends:
    service: app
  command:
    rake jobs:work

@wkonkel sim, já fiz coisas semelhantes no passado.

No momento, estou trabalhando para me familiarizar com a base de código de composição, uma vez que sei onde estão todas as coisas para composição, vou hackear um PR para um parâmetro de configuração de escala.
Não parece que vai ser muito difícil, há um método scale para um projeto que é o backend para a interface cli, então tudo que eu realmente deveria ter que fazer é adicionar "escala" ao esquema de campo, certifique-se de que se estiver presente para chamá-lo após a criação do contêiner ... então certifique-se de que ele não execute um contêiner se estiver definido como zero.

Na verdade, há um PR muito antigo aberto para isso: # 630.

O problema é que a escala é uma preocupação operacional, não faz parte da definição do aplicativo, então não se encaixa realmente no arquivo de composição.

Seria bom oferecer suporte a uma configuração para um nível de escala padrão, mas não acho que o arquivo de composição seja o lugar certo para isso.

O caso de scale: 0 já deve ser resolvido por # 1754. Um contêiner "no-op" pode ter apenas um comando que sai imediatamente (echo, true, etc). Os casos para querer scale: 0 são geralmente um de dois: contêineres de volume de dados ou "tarefas adhoc / admin".

Em breve, não precisaremos mais de contêineres de volume de dados, porque os volumes estão obtendo novos endpoints de API e poderemos definir volumes sem a necessidade de um contêiner.

As tarefas administrativas são gerenciadas melhor com # 2051. Você pode definir admin.yml que estende o núcleo docker-compose.yml e permite vincular suas tarefas administrativas à "composição do núcleo" sem confundir a definição de cada uma.

Ambas as mudanças estão em master agora e estarão disponíveis na versão 1.5.0 (que está chegando).

Assim, resta apenas o caso de querer dimensionar um serviço para> 1 por padrão. Já é muito fácil fazer um script assim, mas poder colocá-lo em um arquivo de configuração ainda seria bom. Acho que vamos explorar a ideia de uma configuração separada no # 745. É minha opinião que esta nova configuração seria um bom lugar para coisas que não fazem parte da definição do aplicativo (nome do projeto, nome da rede padrão, escala padrão, etc).

Respeitosamente, discordo que a escala seja apenas uma preocupação operacional. Os aplicativos podem se preocupar com a contagem mínima de serviços em execução.
No que diz respeito ao contêiner autônomo, parece kludgey executar realmente um contêiner quando o propósito desse contêiner é acionar uma imagem de base a ser construída na qual outros contêineres usam para seu campo image .

Os aplicativos podem se preocupar com a contagem mínima de serviços em execução.

Você poderia dar um exemplo desse caso?

No que diz respeito ao contêiner no-op, parece kludgey executar um contêiner quando o propósito desse contêiner é acionar uma imagem de base a ser construída na qual outros contêineres usam para seu campo de imagem

Existe um motivo pelo qual a imagem de base precisa fazer parte da mesma construção? Como eu chamo em # 1455, compose não é principalmente uma ferramenta de "docker build". Seu objetivo é fornecer uma composição de contêineres em tempo de execução. Tentar oferecer suporte a todos os cenários de construção possíveis aumenta muito o escopo da composição e tira o foco da composição do contêiner. Seria difícil até mesmo para uma ferramenta projetada em torno da construção de imagens para dar suporte a cada uma dessas solicitações. Acho que a melhor direção é manter o máximo da complexidade de compilação fora da composição e permitir que os usuários troquem a ferramenta de compilação apropriada no lugar de docker-compose build .

O caso de uso que me interessa é escala = 0 (talvez abstract = true seja um descritor melhor). Quero compartilhar imagens e variáveis ​​de ambiente entre diferentes comandos. Especificamente, quero um servidor da web em execução e um servidor de trabalhos em segundo plano em execução, ambos com o mesmo código e as mesmas variáveis ​​de ambiente.

@wkonkel usando seu exemplo, acho que isso também funcionaria?

app_web:
  build: .
  ports:
    - "3000:3000"
  environment:
    - DATABASE_URL=postgres://user:password<strong i="7">@host</strong>:5432/dbname

app_worker:
  extends:
    service: app_web
  command: rake jobs:work
  ports: []

Você troca ter um serviço abstrato com uma substituição não operacional command por nenhum resumo com uma substituição não operacional em ports . Isso soa certo?

1988 está relacionado a serviços abstratos.

@dnephin Sim, funciona no meu caso.

Na verdade, retiro o que disse ... Eu apenas tentei com docker-compose-1.4.2 e parece que "portas: []" não substitui o pai, então o app_worker falha ao iniciar com "porta já alocada "

@dnephin O tópico talvez tenha uma explicação melhor, mas tentarei articulá-lo aqui.

O primeiro que vem à mente são os sistemas de trabalho em que contêineres separados executando o mesmo código podem ser modelados como um tipo de serviço pai-> fork () -> pool filho no qual a configuração do aplicativo padrão deseja um número mínimo de trabalhadores para simultaneidade.

Minha inspiração para isso veio de um aplicativo que usa trabalhadores RQ anexados a diferentes filas que compartilhavam uma imagem de base que continha meus pacotes Python (código de trabalho), mas tinha várias instâncias em execução para cada fila. A disponibilidade mínima de simultaneidade era um requisito do aplicativo devido aos trabalhos de longa execução.

Só acho que ter um comando no-op parece um desperdício de recursos apenas para obter uma imagem de base compartilhada construída da mesma forma que o resto da pilha de aplicativos. Você acaba com um loop while / sleep apenas para uma imagem de base, o que é uma solução legal, mas não parece uma maneira intuitiva de fazer isso. Sem mencionar que deixa um item em nossa árvore de processos sem função de tempo de execução.

Se docker-compose realmente não passar para o domínio de codificação de relações de construção de imagem, talvez a opção de construção deva ser removida e alguns outros sistemas de definição de construção devam ser criados para que eu possa definir um alvo de construção para construir uma imagem base e, em seguida, outras imagens que consomem essa base com alguns dos artefatos / configuração modificados e na ordem correta?

Ou talvez, eu esteja apenas sendo muito opinativo e deveria envolver meus comandos docker compose em scripts de shell para iniciar meus serviços com escala e definir todos os meus builds de imagens como destinos de make com dependências.

Só acho que ter um comando no-op parece um desperdício de recursos apenas para obter uma imagem de base compartilhada construída da mesma forma que o resto da pilha de aplicativos.

Com o # 1754 (na próxima versão) isso não é mais necessário. Um serviço pode ser encerrado e não interromperá os demais serviços. Então você pode ter a base apenas sair e não se preocupar com isso.

@dnephin Legal, então você forneceria um link para esse contêiner básico / intermediário para garantir que ele seja construído primeiro?

@dnephin : Eu tenho um corredor de CI que faz o equivalente a docker compose up . Quero que meu ambiente de teste seja executado com várias versões de um serviço (ou seja, escala). Eu poderia copiar todo o bloco de configuração, mas isso envolveria me repetir. Nesse caso, não é "apenas uma preocupação operacional", é algo que preciso em meu ambiente de desenvolvimento enquanto desenvolvo um aplicativo em cluster, que atualmente é totalmente descrito como um arquivo de composição. No momento, eu teria que ter alguma configuração de escala fora da banda e, de alguma forma, invocar docker-compose scale , suponho, mas isso não parece ideal e apresenta mais oportunidades de falha e corrida.

Em casos de produção, você pode querer começar seus serviços com uma escala mínima. Digamos, por exemplo, que você esteja migrando de um cluster para outro, e vamos manter algumas partes difíceis da migração como dados de cópia para a simplicidade do exemplo; e você realmente precisa começar a lidar com algum tráfego desde o início, então você precisa implantar com docker-compose até pelo menos (n) instâncias de algum serviço, digamos web.

Ter escala sob o serviço no arquivo de configuração realmente cuidará disso. É também um caso de uso de usabilidade, pois se o caso de uso de fato expõe o requisito de ter pelo menos (n) instâncias de algum runnign de serviço e não apenas um no ponto inicial.

Do meu ponto de vista, a escala é de fato um parâmetro definidor de uma topologia e composição.

@dnephin

Você poderia dar um exemplo desse caso?

Consul, MariaDB Master-Master ou qualquer outro aplicativo distribuído no Swarm realmente precisa ter pelo menos 3 nós no cluster para ser confiável. Definitivamente, há casos de uso para vários serviços disponíveis no arquivo de configuração, não entendo por que você é tão contra isso. Grande: +1: de mim aqui.

Não sou contra uma forma de configurar a escala, só não acho que ela pertença ao arquivo de composição porque é um estado que muda independentemente do arquivo de composição.

Veja este exemplo, que assume que adicionamos alguma configuração de escala ao arquivo de composição:

1. Eu defino uma escala inicial de 3 para um serviço
2. Eu corro docker-compose up -d , meu serviço escala para 3
3. Eu corro docker-compose scale service=4
4. Eu faço algumas mudanças e reimplanta com docker-compose up -d .. O que acontece? Diminui a escala para 3 novamente? Ele ignora a escala inteiramente agora?

Nenhum desses cenários parece bom ou apropriado, e este é apenas um exemplo trivial que ignora as falhas de instância (o que o torna ainda mais complicado).

Se fosse para ser adicionado ao arquivo de composição, acho que desejaríamos remover o comando scale , para que eles não entrem em conflito.

O exemplo que você dá é um exemplo de requisito operacional. Você não precisa de vários mestres para executar o aplicativo, você precisa deles para confiabilidade (operação) do serviço. E você ainda pode fazer isso com scale db=x .

Usando o exemplo fornecido acima por @dnephin :

Em primeiro lugar, acho que o comando de escala também é ingênuo, já que você não pode dizer se vai aumentar ou diminuir um serviço, tendo dois comandos diff para explicar a intenção de aumentar ou diminuir apenas dizendo quantos serviços fazem que você deseja criar ou remover, respectivamente, será muito melhor.

A resposta à pergunta levantada por @dnephin é que espero ter tantos serviços / contêineres em execução quanto antes da modificação.

Compose é uma ferramenta sem estado que não conhece ou monitora os serviços / contêineres que usa a API docker para ajudar o Ops a orquestrar e é onde eu acho que está o problema, o compose foi projetado para ser uma ferramenta de ajuda, não um serviço de orquestração completo, e agora precisamos daquele, temos um motor que funciona perfeitamente, temos uma máquina para provisionar e temos um enxame para juntar todos eles em um cluster, mas vazamos um serviço / ferramenta de orquestração real que nos deu a flexibilidade para configurar e para gerenciar os serviços / contêineres implantados de forma semelhante ao que o k8s faz. No momento, compor é algo que é muito parecido com isso, mas se não for no futuro deste projeto evoluir para algo maior, melhor pensar será dos desenvolvedores e mantenedores oficiais para contar sobre isso para que possamos descobrir outro ferramenta que pode fazer isso.

Pessoalmente acho que será melhor evoluir o compor já que é uma ótima ferramenta e bem conhecida por todos nós.

Ficarei feliz em ver isto: docker-compose > docker compose .
Não tenho certeza sobre o resto das ferramentas, mas para isso seria muito bom ter uma integração com estado com o motor. Desculpe por um comentário fora do tópico.

Criei o nº 2496 para minha proposta de remover o comando de escala e substituí-lo pela opção de escala (da postagem acima). O feedback sobre esta proposta seria ótimo.

@dnephin com o # 2496 compose perderemos a capacidade de aumentar ou diminuir facilmente, precisaremos reconfigurar o arquivo de composição e executar o compose novamente apenas quando o que precisamos é dimensionar uma instância para baixo ou para cima, acho que isso é bonito complicado.

Mais uma vez estamos perdendo o ponto de que todos esses cenários partem do ponto que o compõe é uma ferramenta stateless e daí não se pode controlar o estado dos serviços e quantos deles estão em algum ponto.

O cenário que você menciona na nova proposta será facilmente resolvido por uma nova composição de serviço / ferramenta state-full.

+1

+1

+1

@dnephin O comportamento não seria o mesmo se você fizesse:

$ docker-compose up -d && docker-compose scale node=4 && docker-compose up -d

Isso não é mais um problema em como a composição persiste escala internamente.

É isso, "Componha o aplicativo" não tem estado. O único estado é 1) o arquivo de composição e 2) os rótulos do contêiner do docker gerenciados pelo mecanismo.

O arquivo de composição é editado apenas por uma pessoa, não pelo Compose. Seria uma bagunça tentar escrever yaml com os mesmos comentários, ordem e estrutura. Não é compatível com pyyaml ​​e não é algo que realmente queremos fazer de qualquer maneira.

O mecanismo docker não está ciente da escala, portanto, não pode armazenar esse estado. É possível com mudanças arquitetônicas muito maiores, mas isso está um tanto fora do escopo deste problema.

Por enquanto, nossas opções são basicamente manter a escala como uma opção de linha de comando ou movê-la para o arquivo de composição, mas como descrevo em # 2496, acho que ter as duas coisas é confuso e leva a um comportamento incorreto.

up && scale && up realmente faz a coisa certa agora. up recriará todos os contêineres e, como não há valor de escala na configuração, não há confusão sobre qual deve ser a escala desejada. Já foi definido pelo comando de escala e rastreado por rótulos de contêiner.

@dnephin Acho que concordo com o que você está dizendo, [posso estar errado nessa suposição] que o que você está realmente questionando é _se_ o número de instâncias de um componente é na verdade a preocupação com a composição de um serviço (um agrupamento de contêineres executando diferentes contêineres de componentes). Eu diria que atualmente está abordando essa preocupação, apenas com a ressalva de falta de paridade entre o cli e a definição de composição (yaml).

Se o escopo da responsabilidade for determinado que a escala não é a preocupação da composição, então a escala deve ser removida como uma opção CLI (provavelmente irritando muitos usuários), ou se for determinado que a escala é a preocupação da composição de um serviço que deve haver paridade entre o cli e yaml com o suporte adicional de um mínimo de instâncias para contabilizar instâncias em cluster que requerem N + 1.

Concordo com @jmmills Especialmente ao executar clusters de contêineres de dados, quando disponibilidade e replicação andam de mãos dadas, um mínimo de scale faz parte do aplicativo: sem a escala adequada, pode nem funcionar

+1

+1

+1

Atualmente, preciso declarar coisas assim:

selenium-chrome1:
...
selênio-cromo2:
...

Seria bom:
selênio-cromo:
escala: 2

+1

exatamente o que @caioquirino disse. +1

docker-compose up deve criar um ambiente de trabalho sem exigir outro trabalho. A única maneira de ativar serviços que requerem vários nós é usar o padrão que

A escala no arquivo yml corrige isso.

Grande +1, também gostaria de usar isso para definir serviços que têm escala definida como 0 inicialmente.

Ao longo das linhas de ...

consul_bootstrap:
  build: ./consul
consul_master:
  build: ./consul_master
  scale: 0

A ideia é que você possa usar o mesmo docker-compose.yml e fazer a transição perfeita de um ambiente de desenvolvimento para a produção. As instâncias de consul_master se juntariam automaticamente à jangada e estabeleceriam um quorum fazendo docker-compose scale consul_master=3 . Isso seria muito legal.

Para responder a @dnephin ...

Veja este exemplo, que assume que adicionamos alguma configuração de escala ao arquivo de composição:

1. Eu defino uma escala inicial de 3 para um serviço
2. Eu executo docker-compose up -d, meu serviço aumenta para 3
3. Eu executo o serviço docker-compose scale = 4
4. Eu faço algumas alterações e reimplanta com docker-compose up -d .. O que acontece? Diminui a escala para 3 novamente? Ele ignora a escala inteiramente agora?
5. Adoro
6. Tudo bem
7. Eu ainda estou com você
8. Acho que deve haver alguma diferenciação entre uma implantação existente e uma nova implantação para que a continuidade da escala possa ser mantida para implantações existentes que estão recebendo atualizações contínuas. Uma implantação individual incluiria o env DOCKER_HOST etc, junto com a escala de cada componente, IDs de imagem e um histórico de reimplementações. Esse poderia ser um bom lugar para se conectar a mecanismos de upstack, como implantação contínua ou implantações azul-esverdeadas? Estou imaginando um fluxo de trabalho um pouco mais pronto para a produção, então você pode simplesmente se conectar a um DOCKER_HOST diferente e fazer um docker-compose up -d e, em seguida, fornecer ganchos para que as ferramentas de upstack possam gerenciar coisas como CI e implementações azul / verde. Talvez adicione algo como DOCKER_COMPOSE_ENV = {"teste" || "produção" || "dev"}?

IMHO, tendo "codificado" scale , digamos 3, deve começar com 3 contêineres

Acho que grande parte da confusão sobre um parâmetro "escala" versus o comando "escala" seria aliviada ao nomear o parâmetro YAML "escala_inicial" ou "escala_padrão". Isso deixa bem claro que é apenas um valor que será usado se não houver algum tipo de substituição. Também (IMHO pelo menos) parece razoável que este parâmetro "initial_scale" só seja referenciado quando docker-compose ativa o serviço pela primeira vez, e não quando o docker-compose é executado novamente com algumas instâncias do serviço já em execução.

+1 para "initial_scale", também irá descrever explicitamente este parâmetro como específico de composição, porque o docker em si não tem tal parâmetro.

Há uma coisa interessante que acontece, na postagem do blog https://blog.docker.com/2016/02/video-containers-as-a-service-caas/ at video "48.56 mostra que no novo docker datacenter lançado você pode, no ponto de criação da pilha, realmente configurar quantas instâncias de um contêiner você deseja executar. Portanto, essa ideia não é nova para a equipe do docker, espero que seja incluída nas próximas versões compostas

+1

+1

Milhões de questões e solicitações escalam / initial_count e assim por diante .. e ainda não planejados.

É triste ver projetos bons de outra forma, mas as pessoas apenas encontrando desculpas e criando questões novas e duplicadas, fechando questões e "fazendo" o trabalho.

+1

+1

+1

+1

POR FAVOR PARE!
NÃO ADICIONE +1!
APENAS ASSINAR O NÚMERO!

+1 ( @pierrre desculpe)

+1 é muito importante ( @pierrre , desculpe)

Eu concordo, mas não quero receber 100.000 notificações para o seu "+1"!

/ me bifurca o docker compose e começa a aprender a base de código.

Muitos pontos válidos acima, parece que ter um parâmetro default/inital scale no arquivo de configuração + um comando scale cli abordará ambos. Para adicionar casos de uso em suporte a uma opção de escala inicial, considere os serviços em cluster onde um quorum consiste em um número X de nós e que não deveriam estar operacionais de outra forma (por exemplo, não menos que 3). O objetivo de docker-compose é ter um descritor totalmente contido de tal sistema.

Meu caso de uso é:

Eu estendi um serviço com algumas configurações comuns para permitir menos duplicação. O serviço de base, entretanto, é criado (ao ser executado sem especificar explicitamente os nomes do serviço) e, em seguida, eu o encerro manualmente. Gostaria que o serviço de base tivesse uma escala inicial de 0.

Estou de acordo geral. Embora, em minha opinião, esse problema e os problemas vinculados / relacionados se resumam a um problema ligeiramente diferente: up e scale última análise, desejam ser o mesmo comando.

Às vezes, eles já são:

• docker-compose up service
• docker-compose scale service=1 .

E, se scale expôs todas as opções cli (por exemplo, --force-recreate ) que up faz, ou se up sabia sobre contagem, então elas basicamente estariam.

Se, como este problema propõe, uma diretiva de "escala inicial" for adicionada a docker-compose.yml , então up terá que aprender a contar. Nesse ponto, up não deveria apenas suportar a sintaxe de contagem docker-compose up service=10 (que poderia sobrescrever qualquer escala definida no yaml)?

Há uma distinção sendo feita entre "escala inicial" e "escala", que pode ser o domínio de comandos diferentes. Mas porque up é idempotente e projetado para ser executado repetidamente sem necessariamente alterar o estado, não acho que essa distinção seja estrita. Acho que, em vez disso, devemos considerar up cannibalize scale imediatamente.

@mattgiles: Eu concordo, é para onde eu queria chegar com # 2496, porém não havia considerado que service=count pudesse ser adicionado a up . Acho que isso pode resolver a situação. O único problema que vejo é que atualmente up web significa apenas ativar o serviço da web e suas dependências. Tentar fazer up web=3 teria que continuar significando a mesma coisa. O que significa que não há como up tudo e substituir a contagem da escala de uma vez, mas provavelmente está tudo bem.

Vou atualizar a proposta em # 2496

@dnephin Eu perdi a proposta mais recente. Incrível!

fwiw, acho que é totalmente intuitivo para docker-compose up web=3 trazer três contêineres para o serviço "web", bem como quaisquer dependências ... nas proporções definidas no yaml (por algo como scale diretiva

As invocações subsequentes de up poderiam continuar, como fazem agora, para deixar os contêineres existentes intactos. Somente se a escala atual for menor do que a definida no yaml, ela mudará as contagens para ficar de acordo com a escala prescrita. Nenhuma escala definida continuaria a implicar uma escala de 1.

Coisas como --force-recreate também devem provavelmente deixar as contagens em paz se forem mais altas do que o definido no yaml, mas ainda assim recriar todos os contêineres para estarem em linha com outros atributos.

Também faria sentido para mim ser capaz de matar contêineres, como alguém faz atualmente com scale , chamando algo como docker-compose up web=2 etc etc.

+1

+1 (apenas para irritar @pierrre ;))

+1

+1 para escala = x.

Relacionado a isso, eu adoraria uma maneira de descrever Singletons. scale=1

Qualquer sucesso aqui com a opção de escala

+1

Eu não vi nada de novo sobre isso do upstream, pessoalmente não tive a chance de ver se consigo hackear um patch para isso.

Obrigado,
Jason Mills

• Enviado de celular.

Em 8 de agosto de 2016, às 17:19, lavvy [email protected] escreveu:

Qualquer sucesso aqui com a opção de escala

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

+1

+1

+1

+1

+1 (para irritar @pierrre novamente)

+1

Eu gostaria de reiterar o caso

escala = 0
Útil para teste, depuração. serviços de teste etc. que você normalmente não deseja exibir, mas deseja definir - porque eles geralmente são usados ​​no contexto de outros serviços no arquivo.

escala = 1
Porque eu quero um e apenas um destes - _ever_. Em um cluster MariaDB, há casos em que posso querer apenas um único nó configurado com um mecanismo de armazenamento específico (por exemplo, Spider, ColumnStore etc.).

escala = n
Porque há momentos em que sei que preciso de 'n' serviços rodando, por exemplo, um cluster MariaDB onde sempre terei um Primário (com sua configuração) e dois Secundários (com suas configurações diferentes, da Primária).

Faz todo o sentido para mim, @alvinr. O padrão deve ser 1.

DISCLAMER: Eu não sou um representante da Maratona ou da Mesosfera

Este é mais um exemplo de solicitação de recurso bastante simples que foi abandonada / adiada pela equipe de suporte do docker por mais de um ano. https://github.com/docker/docker/pull/12749 é outro exemplo. O Kubernetes e o Marathon já têm essas opções há algum tempo ("instâncias": 3 no arquivo marathon.json) e até implementam o escalonamento automático. É a falta de vontade do grupo de suporte do docker que me afastou do data center & swarm do docker há algum tempo.

Kontena também tem isso como instances: 3 (https://www.kontena.io/docs/references/kontena-yml)

Outra maneira de fazer isso é adicionar uma seção scale na versão 2 do arquivo de composição.

Não se misturaria com as opções apenas do docker usadas nos serviços.

Um exemplo seria:

version: "2"

services:
  worker:
    image: something
    command: work

scale:
  worker: 2    

Com a capacidade de especificar scale: 0 potencialmente mataria dois coelhos com uma cajadada só, sendo a outra https://github.com/docker/compose/issues/1896

Isso parece um acéfalo.

Quero implantar nginx + nodejs + mongodb com 3 ou 4 instâncias de nodejs. Toda vez que eu inicio o aplicativo.

Se você tiver uma opção de linha de comando para fazer isso, por que não no arquivo yml?

docker-compose up scale nodejs = 4

Faria.

É simples. Eles querem seguir o caminho de "outra pessoa construir e nós
tentará suportá-lo ". Além do docker base, eles não criaram
nada. Compose era um produto diferente que eles consumiam e agora eles têm
não tenho ideia de como apoiá-lo / estendê-lo, e é por isso que produtos como maratona e
os kubernetes são mais populares do que o enxame.

Em 16 de outubro de 2016, 21:36, "Michael Schwartz" [email protected]
escreveu:

Isso parece um acéfalo.

Quero implantar nginx + nodejs + mongodb com 3 ou 4 instâncias de nodejs. Cada
vez que eu inicio o aplicativo.

Se você tiver uma opção de linha de comando para fazer isso, por que não no arquivo yml?

docker-compose up scale nodejs = 4

Faria.

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/docker/compose/issues/1661#issuecomment -254093296,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AES98nZt1uIejnIU9iajVt54QbzdlVK1ks5q0tETgaJpZM4FS8ZQ
.

Sinceramente, estou um pouco surpreso que haja _qualquer_ resistência nisso, pois parece tão óbvio ter ...

@westlakem Vamos torcer para que o Docker para MacOS não sofra o mesmo destino, espero que os caras do Unikernel continuem.

Seria bom criar uma pilha completa em seu tamanho funcional de uma só vez. Em nosso caso de uso atual, a pilha de serviço precisa ter "workers = 16" para funcionar corretamente.

Isso é horrível:

docker-compose up -d
docker-compose scale workers=16
docker-compose down
docker-compose up --abort-on-container-exit

que claramente pode ser substituído por algo como:

docker-compose up --abort-on-container-exit --scale workers=16

Editar: vejo que "Rancher" tem uma sintaxe docker-compose e suporta um parâmetro de escala inicial: https://paypertrail.com/blog/tech/docker-rancher-and-laravel-easy-and-safe-scalability

Uma solução alternativa é usar os recursos de âncora e mesclagem YAML e duplicar o serviço dentro do arquivo docker-compose.

services:
  toscale: &my_service
     ... # all paramteres
  # second instance
  toscale2: 
     << : *my_service
     ports:
       - 81:80 # override port if needed

etc ...

Isso seria muito útil!

Isso é super estranho isso não existe ...

Posso acabar tendo que criar serviços duplicados porque sou muito preguiçoso.

Isso já está em andamento no arquivo composer v3 https://github.com/aanand/compose-file/blob/master/schema/data/config_schema_v3.0.json que será e já é suportado no docker-compose v1. 10.0-rc1

Suas ofertas de "Serviços" têm o parâmetro embutido. É muito triste que, como um
assinante desta edição, ninguém da equipe de desenvolvimento nos informou que
estava chegando no produto de Serviços, e alguém teve que ler as notas RC
para 1,10 para qualquer insight. Onde estão os representantes do docker?

Na sexta-feira, 6 de janeiro de 2017 às 6h30, Yasmany Cubela Medina <
notificaçõ[email protected]> escreveu:

Isso já está em andamento no arquivo composer v3 https://github.com/aanand/
arquivo de composição / blob / master / schema / data / config_schema_v3.0.json que será
e já é compatível com docker-compose v1.10.0-rc1

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

+1

+1

Olá, tenho uma pergunta relacionada.
Sempre me perguntei se docker-compose up pode se lembrar da escala que eu já defini.

Por exemplo, eu corro docker-compose scale nodejs_web=4 depois docker-compose down ,
então eu começo de novo docker-compose up , ele vai começar 4 nodejs_web.

Eu quero saber onde o comando scale salva o número 4?

O docker-compose.yml pode ser:

version: '2'
services:
  nodejs_web:
    image: node
    command: node

Apoio a proposta @dnephin em # 2496
Forneça-nos este recurso básico.

Os serviços na nova versão do Docker oferecem um recurso de 'réplicas'.

Na segunda-feira, 20 de março de 2017 às 15:28, alwaysastudent [email protected]
escreveu:

Apoio a proposta @dnephin https://github.com/dnephin em # 2496
https://github.com/docker/compose/issues/2496
Forneça-nos este recurso básico.

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

@westlakem - esse recurso é para enxame. Não é para o escalonamento de serviço regular.

Muitos prós, poucos contras. Qual é o problema com este problema?

Há uma proposta mais recente sobre a remoção completa do comando de escala em https://github.com/docker/compose/issues/2496

Eu realmente não entendo por que ou por que não há initial_scale: 3 opção no arquivo de composição (eu entendo por que não pode ser apenas scale: 3 )

Implementado em 1.13.0. Obrigado a todos por seus comentários e paciência.

@ shin- Por que isso é considerado fechado? No gerenciamento de aplicativos de grande escala onde TUDO é automatizado e no controle de versão, agora devo modificar meu Ansible que executa o Docker para definir quantas instâncias de um serviço estarão em execução.

O Ansible deve configurar tudo para que o Docker possa ser executado. O Docker deve definir quantas instâncias de um serviço o aplicativo precisa. Agora é responsabilidade do Docker saber o inventário de serviços, mas é responsabilidade do Ansible ligar para o Docker para saber quantos contêineres girar?

@greenscar Desculpe, não tenho certeza de qual é o problema - você está insatisfeito com a maneira como o recurso foi implementado? Em caso afirmativo, de que forma podemos torná-lo melhor?

Por que isso não está presente na versão 3? Extremamente confuso, já que "deploy.replicas" e "up" não são equivalentes, você poderia dizer que esse recurso está faltando na v3.

@cgarciae deploy.replicas serve ao mesmo propósito que scale . Por que eles não são equivalentes em sua opinião?

@ shin- Se eu não quiser criar um swarm e usar apenas docker-compose up -d , o docker compose me diz que irá ignorar as configurações de "implantação".

@cgarciae Por que você está usando um arquivo v3 se não deseja criar um Swarm?

Acho que todo mundo que usa o docker espera que o parâmetro de escala funcione para os arquivos do docker 2 ou 3. Não há razão para não fazer isso e pode até definir o valor padrão para deploy.replicas também. Se deploy.replicas for definido, ele substitui a escala no swarm. O que há de errado com essa imagem além de ser o que todos esperam que aconteça (e, claro, se você não gostar, não precisa usá-la em docker-compose.yml)?

O parâmetro de escala ausente fez um serviço falhar, já que esqueci de aumentá-lo como estava antes, desde o último redeloy -.- por que isso não é algo que salvaria o serviço e talvez até mesmo vidas dependendo do que está sendo executado

Basta abordar esse problema também. Parece que não há como especificar quantos de um serviço devem ser iniciados a partir da configuração do docker compose? É ainda mais confuso que a documentação do docker compose tenha muita documentação para coisas que não funcionam com o docker-compose ...

Oh, espere, então se eu mudar minha configuração de composição do docker para version: "2.2" então posso usar scale: 2 mas se alguém quiser ir para uma versão posterior, não há mais uma opção para fazer isso?

Ok, vejo que este problema de "versão" não significa realmente versões já foi levantado, https://github.com/docker/compose/issues/4693

Eu uso a v3.6 porque preciso de algumas configurações que não existem no 2.2. Para o desenvolvimento local, não uso enxame, mas quero definir scale = 0 para alguns contêineres em meu docker-compose.overrides.yml. Porque alguns deles são apenas para processos de construção, como o contêiner de frontendbuild. Este contêiner compartilha alguns volumes com outros contêineres em execução, mas não deve ser iniciado junto com esses outros contêineres no docker-compose up. Portanto, o buildcontainer apenas executa com o comando run. Sim, posso definir o parâmetro --scale ao chamar docker-compose, mas acho melhor gravá-lo diretamente na configuração. :)

Obrigado pelo parâmetro de escala. Consegui usá-lo em uma não produção docker-compose.yml para que qualquer pessoa pudesse usar uma configuração HA de Consul e Vault. O parâmetro de escala facilitou o provisionamento de uma configuração local de HA. https://github.com/samrocketman/docker-compose-ha-consul-vault-ui

Neste caso, destina-se apenas a alguém experimentar o Consul e o Vault em uma configuração HA e usar o Consul DNS.

Em qual versão do docker compose você está executando? Desde a v3, esse recurso foi descartado (por gota, quero dizer, nunca implementado), por isso é ignorado. Veja https://docs.docker.com/compose/reference/scale/

Eu nunca uso o formato v3 devido à falta de recursos. Costumo usar o formato 2.1 ou 2.2 mais baixo, dependendo dos recursos que estou usando.

Edit: para não dizer que evito o formato v3. Só que, quando vou escrever um arquivo de composição, geralmente falta o que desejo usar.

Ok, suponho que você fale sobre docker compose com swarm stack, é por isso. Nunca tentei, mas é estranho falar de HA com docker compose sem orquestrador e nó mutli. É para "poc" ou para fins de teste? Enfim, nunca tentei neste contexto

Nesse caso, o HA simplesmente se refere a um cluster cônsul e a um cluster de cofre. Pretende servir como uma prova de conceito disponível para experimentação e facilidade de bootstrap. O HA não se refere ao HA docker ou mesmo HA multi-máquina. É apenas HA em que a pessoa que faz a experiência pode matar um dos contêineres do cluster e ver se o cônsul e / ou serviço de cofre não é afetado.