O nome do projeto não é importante. Gosto da ideia de um nome de projeto aleatório. Melhor ainda - podemos gerar um hash do caminho para fig.yml e usá-lo?

Na verdade, acho que o nome do projeto é muito importante. Se você quiser fazer qualquer coisa com as imagens em um pipeline de CI, precisará saber o nome do projeto para poder retagá-las como outra coisa.

Ser capaz de substituir o nome do projeto a partir de variáveis ​​de ambiente torna mais fácil mantê-las exclusivas e previsíveis. Acho que não importa o que aconteça, precisamos oferecer suporte à substituição das variáveis ​​de ambiente.

Gosto da ideia de tornar o nome do projeto configurável a partir de um arquivo. Acho que uma discussão semelhante aconteceu em (# 45). Ter o nome do projeto em .fig/project-name parece que levará a muitos arquivos realmente pequenos. Acho que seria mais fácil simplesmente colocá-lo no próprio fig.yml (como sugerido no # 45 e em uma das propostas de composição do docker).

Quais são as vantagens de colocá-lo em um diretório e arquivo separados?

O motivo para colocá-lo em um arquivo separado tem vários motivos, tentarei explicar meu pensamento por trás disso;

• Para preservar o nome que foi usado para _iniciar_ o projeto (ou seja, --project-name=foobar ), que pode ser diferente do nome do projeto automático.
• Ter várias instâncias ou _versões_ de um projeto em execução no mesmo servidor, sem conflito entre si
• Ou, em resumo, .fig/project-name contém o nome dessa instância_do projeto.

Talvez o arquivo deva se chamar instance-name ou similar.

Eu gosto da ideia de tornar o nome do projeto configurável a partir de um arquivo

Embora _possível_ fazer isso com esta proposta (criando manualmente o arquivo project-name ), meu caso de uso principal era fazer com que _fig_ criasse o arquivo para salvar o nome que foi usado.

levará a muitos arquivos realmente pequenos.

Verdade, a alternativa é pular o diretório .fig , entretanto, se coisas adicionais forem necessárias no futuro, arquivos extras podem ser adicionados sem bagunçar a raiz do seu projeto. Git faz isso de forma semelhante e acho que é uma abordagem limpa.

Eu acho que seria mais fácil apenas colocá-lo no fig.yml

Acho que as duas opções podem ser complementares; use o nome de fig.yml como o padrão se o nome não for substituído por um sinalizador ou variável env. Coloque o nome que realmente é usado para _iniciar_ o projeto dentro do .fig/project-name

Ser capaz de substituir o nome do projeto a partir de variáveis ​​de ambiente torna mais fácil mantê-las exclusivas e previsíveis. Acho que não importa o que aconteça, precisamos oferecer suporte à substituição das variáveis ​​de ambiente.

Curioso; como você lida com o gerenciamento de vários projetos? Ou seja, cd project-a && fig ps depois cd project-b fig <something> ?

Obrigado pelo seu feedback!

Curioso; como você lida com o gerenciamento de vários projetos?

Normalmente executo fig de python-tox , o que me permite definir o ambiente, portanto, nunca o estou definindo no meu shell. Eu também costumo usar o tmux, então tenho shells diferentes para cada projeto.

Acho que ambas as opções podem ser complementares

Legal, eu concordo.

Não sei se estou convencido de que .fig/instance-name vs digamos .fig-instance.yml que podem conter quaisquer substituições específicas de instância, mas acho que este é mais um ponto secundário.

Pensando no nome do projeto; Se eu entendi sua situação corretamente, é importante ter controle sobre as _imagens_ sendo produzidas, por exemplo, myapp:build12345 , ou também os nomes dos _contêineres_? Apenas para "sentir" a sua situação.

Meu pensamento por trás de nomes de projeto "aleatórios" era que, desde que Fig seja capaz de localizar os contêineres de um projeto, nomes bonitos não são importantes. Se eu, como usuário, posso acessar um container de serviços através de seu nome de serviço (por exemplo, fig stop web ), o nome do container real não importa.

Até pensei que o fig poderia rastrear contêineres por ID em um armazenamento local dentro do diretório .fig (o que poderia ser um ganho de desempenho em máquinas com muitos contêineres em execução). Mas isso é realmente algo para um problema separado.

Alguma ideia sobre como criar "implicitamente" o arquivo 'nome do projeto' ou "explicitamente" via fig init ? Talvez se eu tiver algum tempo durante as próximas férias eu possa experimentar um pouco (nunca codifiquei nada em Python, então será _realmente_ experimental :))

é importante poder ter controle sobre as imagens que estão sendo produzidas, por exemplo, myapp: build12345 , ou também os nomes dos contêineres?

Acho que a imagem é realmente importante, mas ser capaz de garantir que os nomes dos contêineres não entrem em conflito também é muito importante em hosts compartilhados. Vejo que esta proposta também visa lidar com essa questão.

Mas acho que nomes previsíveis para contêineres ainda são importantes. Posso pensar em algumas tarefas em que é importante para os sistemas externos (não apenas a fig) conseguir identificar um contêiner pelo nome:

• scripts de limpeza para remover containers antigos, podendo identificar qual projeto criou um container
• depuração / inspeção de contêineres

Ambos são muito fáceis agora porque eu já sei qual será o nome do contêiner. Se eu tiver que procurar um nome, é um pouco mais complicado.

Até pensei que fig poderia rastrear contêineres por ID em um armazenamento local dentro do diretório .fig

É verdade que isso pode ser um ganho de desempenho, mas temo que seja a abordagem errada. Adicionar qualquer estado persistente ao fig introduz a possibilidade de muitos bugs (que vêm junto com o estado). Eu preferiria ver isso sendo tratado por um sistema de etiquetagem no dockerd. Se a fig puder apenas rotular os recipientes e, em seguida, consultar todos os recipientes com aquele rótulo, ele mantém todo o estado em um único lugar (dockerd). Sei que se falou nisso em algum momento, não tenho certeza se está no roteiro.

Alguma ideia sobre a criação "implícita" do arquivo 'nome do projeto' ou "explicitamente" via fig init?

Acho que implicitamente seria mais compatível com versões anteriores. Eu gostaria de evitar fig init menos que seja absolutamente necessário. Em vez de usar o basedir, eu poderia vê-lo criando implicitamente um nome de projeto de <basename>-<4 digit random id>

Só posso dizer que se o fig começar a gerar nomes aleatórios agora, irei sair dele porque corro mais de 1000 contêineres em um único host e quando não consigo mais identificá-los pelo nome, não é nada para mim.

@frank-dspeed obrigado por adicionar seu caso de uso. Se bem entendi, você _inicia_ seus contêineres com fig, mas _ "gerencia" _ diretamente via Docker depois disso, usando a convenção de nomenclatura que Fig usa?

Talvez isso também seja do seu interesse: https://github.com/docker/docker/pull/9882 - ter metadados ofereceria mais maneiras de identificar contêineres, não apenas seu nome.

ah sim, eu fiz muitas propostas desse tipo, por exemplo, simplesmente adicionando novos campos e isso, mas eu terminei nesse caso simplesmente adicionando um ENV e então eu tenho isso como costume, posso analisá-lo: dardo:

Acho que gerenciar a clareza do nome do projeto não deve ser responsabilidade da fig.

quando entendi sua proposta corretamente, a geração de um nome aleatório tornaria a FIG_PROJECT_VARIABLE e a --project-name -opção inúteis. o que é útil para serviços de 'modelagem'.

Acho que gerenciar a clareza do nome do projeto não deve ser responsabilidade da fig.

Eu não tenho tanta certeza; Fig sobrescrever "silenciosamente" os containers de outros projetos, porque se acontecer de estar em um diretório com o mesmo nome às vezes é desagradável.

quando entendi sua proposta corretamente, a geração de um nome aleatório tornaria FIG_PROJECT_VARIABLE e a opção --project-name-option inúteis. o que é útil para serviços de 'modelagem'.

Seguindo a discussão acima, acho que algo assim funcionaria

• Se --project-name for fornecido, use-o (e escreva / atualize .project-name ? Não tenho certeza)
• Nenhum --project-name é fornecido, mas FIG_PROJECT_NAME is, use FIG_PROJECT_NAME (e escreva / atualize .project-name ?)
• Nenhuma das opções acima, mas .project-name está definido, use .project-name
• Nenhuma das acima; crie um nome _random_ e escreva-o em .project-name

da perspectiva de alguém que usa fig em scripts que cuidam de um nome e o passam para fig, armazenar um nome no local do projeto (que no meu caso é um modelo) não faz sentido.

e ainda assim, percebi que é muito intuitivo que o nome do diretório seja usado no nome dos contêineres resultantes quando acabei de executar fig up .
e digamos que você olhe para docker ps -a , que não será muito útil se estiver preenchido com nomes aleatórios.

uma opção --random-name ajudaria em sua situação?
além disso, acho que a capacidade de acrescentar [a-zA-Z0-9_].* para refletir algum namespacing seria útil para implantações mais amplas.

Que tal usar o fig.yml para armazenar essas informações?

schema-version: 1.1
project_name: foo
containers:
  web:
    build: .
   command: python app.py
    links:
     - db
    ports:
     - "8000:8000"
  db:
    image: postgres

E para manter o BC, em compose / project.py :: from_config

<strong i="9">@classmethod</strong>
    def from_config(cls, name, config, client):
        if 'schema-version' not in config:
            config = {
                'schema-version': '1.0',
                'containers': config
            }
        dicts = []
        for service_name, service in list(config.containers.items()):
            if not isinstance(service, dict):
                raise ConfigurationError('Service "%s" doesn\'t have any configuration options. All top level keys in your docker-compose.yml must map to a dictionary of configuration options.' % service_name)
            service['name'] = service_name
            dicts.append(service)
        return cls.from_dicts(name, dicts, client)

@jderusse Sou muito a favor de algo como você sugeriu. Talvez você queira adicionar sua proposta ao nº 45, pois este é provavelmente o melhor lugar para discuti-la?

afinal para chegar a uma resolução sobre este tíquete? Parece que o # 1233 proposto oferece o melhor dos dois mundos, permitindo que o usuário decida a ação pretendida, sem quebrar nenhuma compatibilidade com versões anteriores.

Originalmente eu queria o nome em docker-compose.yml , mas depois de pensar mais sobre isso, eu realmente gosto da ideia de um arquivo separado.

Um arquivo separado oferece a opção de mantê-lo fora do controle de versão, se desejar (para os casos em que você deseja que cada usuário possa ter um nome de projeto diferente).

Com o novo suporte de rede, há uma solicitação de recurso para poder configurar o nome da rede também (o padrão é o nome do projeto). Portanto, com um arquivo de configuração separado, poderíamos incluir coisas como nome de rede padrão, escala padrão, etc. Todas as metaconfigurações que não fazem parte da definição do aplicativo, mas ainda são relevantes para a execução da composição.

Eu concordo com o que dnephin disse. Que tal um arquivo .docker-compose ? Poderíamos listar opções padrão para todos os argumentos de linha de comando lá.

@dnephin sgtm

@mikehaertl Eu usei uma pasta .docker-compose no meu exemplo, mas um arquivo pode funcionar também, dependendo de quanta informação queremos armazenar

@thaJeztah Oh, certo, desculpe. Eu senti falta disso.

@mikehaertl acabou de renomeá-los de .fig para .docker-compose ;-)

Direito :)

Na verdade, prefiro um arquivo simples. Que tal o estilo ini? Opções globais na parte superior, opções específicas de comando em uma seção:

project-name = blabla

[build]
no-cache

Algumas ideias para informações semirrelacionadas que podemos desejar armazenar no mesmo arquivo ou no mesmo diretório:

• nome da rede (os usuários podem querer um nome de rede diferente do nome do projeto. Já recebemos uma solicitação para isso).
• versão da API do cliente
• anfitrião docker
• valor de escala padrão

Agora que oferecemos suporte a vários arquivos de composição, também pode ser interessante incluir os caminhos para os arquivos de composição a serem usados ​​como configuração.

versão da API do cliente

possivelmente docker_host ?

Isso também parece bom (adicionado)

Acabei de encontrar esse problema.

Estou em um ponto em que a estrutura básica da configuração do docker foi resolvida e agora estou replicando para outros serviços. Como todos os projetos têm a mesma estrutura, todos usam o mesmo subdiretório (e, portanto, o nome do projeto padrão). O que significa que não consigo fazer spool com segurança de 2 serviços no mesmo host.

Posso ter que mudar a estrutura para que o nome do diretório do projeto acabe sendo o padrão, mas não tenho 100% de certeza sobre o que isso significa para copiar arquivos no momento da criação da imagem.

Mesmo aqui, resolvi um problema semelhante com os destinos Makefile . Mesmo assim, quando você deseja executar comandos docker-compose , você precisa usar -p customname .

No momento, estou tentando descobrir como evitar que configurações docker-compose em /home/alice/myproject e /home/bob/myproject pisem nos contêineres uns dos outros. Existe uma maneira de derivar os nomes dos contêineres do caminho completo do arquivo em vez de apenas o último nome do diretório?

@ chris-martin Esta é apenas uma solução alternativa ...

alias docker-compose="docker-compose -p ${PWD}"

docker-compose retira / dos nomes dos projetos?

Está documentado quais caracteres são permitidos em nomes de projetos?

Acabei mudando minha estrutura de diretório e colocando docker-compose.yml na raiz do projeto, o que é uma solução bastante decente

Ele concede alguma proteção, se você tende a colocar todos os seus repositórios git no mesmo diretório (por exemplo, $ HOME ou $ HOME / projects), mas será problemático se você usar outra estrutura (digamos, um diretório por organização, como eu costumam fazer), ou se sua máquina usa boot2docker, que tende a vazar informações entre os usuários na mesma caixa, a menos que você tenha o cuidado de garantir que a máquina docker forneça VMs distintas.

Eu acho que # 2294 ou apenas ser mais higiênico com a docker-machine também resolveria meus problemas.

Também recomendo colocá-lo na raiz do projeto e ter um nome de pasta diferente.

No meu caso, gostaria de definir o nome do projeto inicial porque tenho uma máquina compartilhada no AWS e, embora tenha o docker-compose.yml na raiz, um usuário pode clonar o repositório em um diretório com um nome diferente. Se isso acontecer atualmente, eles terão problemas ao iniciar / interromper contêineres.

Com a nova sintaxe v2 isso pode ser implementado conforme mencionado em https://github.com/docker/compose/issues/745#issuecomment -74028861

Na verdade, é apenas um container_name_prefix , não é?

@ schmunk42

Na verdade, é apenas um container_name_prefix, não é?

Também é usado como volume_name_prefix , image_name_prefix e network_name_prefix , então acho que project_name é um termo mais genérico.

.docker-compose soa familiar para docker-compose.override.yml várias maneiras. Além disso, por que introduzir outro formato de configuração (por exemplo, ini) quando já temos YAML?
Portanto, sou a favor da sugestão de # 745 (comentário) para adicionar uma chave project_name a docker-compose.yml , para habilitar o caso de uso de @JosephEarl.

A personalização específica do usuário já pode ser implementada usando docker-compose.override.yml e excluindo-a por meio de .gitignore .
Se um terceiro arquivo de substituição explicitamente específico do usuário for desejado, sugiro .docker-compose.local-override.yml .

Em relação à estrutura do YAML, sugiro criar uma nova chave de nível superior chamada project , que contém project_name e pode conter outras variáveis ​​no futuro. Isso evita poluir o namespace de nível superior. Ilustrar:

project:
  project_name: "your-project"
  network_prefix: "abc"

Observe que, em vez de usar network_prefix , pode ser mais compreensível personalizar diretamente os nomes das próprias redes. Pelo que entendi, existem dois casos:

• O primeiro caso é "apenas dê às redes um nome exclusivo, mas não me importa qual exatamente". Para este caso, project_name é o suficiente.
• O outro caso são redes que são referenciadas por sistemas externos. Nesse caso, especificar explicitamente os próprios nomes de rede provavelmente é melhor.

A proposta sugerida acima parece boa para mim, concordo que não queremos introduzir nenhum arquivo de configuração extra

1 sobre o conceito deste problema
Mas também +1 sobre o uso de uma chave em docker-compose.yml vez de adicionar outro arquivo aos nossos repositórios.

Para resumir os comentários anteriores: Uma proposta para a sequência de pesquisa do nome do projeto seria a seguinte; os itens anteriores têm precedência sobre os posteriores:

1. Use --project-name se especificado
2. Use COMPOSE_PROJECT_NAME se especificado.
3. Use a chave project_name de docker-compose.yml (ou onde quer que essa configuração esteja armazenada).
4. Use o basename do diretório do projeto

Não tenho certeza da prioridade de 2 vs. 3:

• Para consistência com --project-name , COMPOSE_PROJECT_NAME deve definitivamente substituir project_name: .
• Mas: Fazer COMPOSE_PROJECT_NAME ter precedência sobre project_name: torna possível usar acidentalmente o nome de projeto errado devido à variável de ambiente que está sendo definida; isso pode ser difícil de depurar. Talvez uma mensagem de aviso possa ser um problema neste caso?

que tal introduzir uma nova propriedade container_name_pattern com o valor padrão %(project_name)s_%(service_name)s_%(instance_number)s para manter BC
este parâmetro nos permite alterá-lo para hardcodedproject_%(service_name)s_%(instance_number)s e corrigir definitivamente o problema

Acabei de resolver esse problema depois de procurar essa funcionalidade por 10 minutos.

A primeira coisa que fiz foi procurar a chave certa no documento Compose File Reference, então +1 para project_name key in docker-compose.yml

: +1: para estratégia @ cr7pt0gr4ph7

+1 para estratégia @ cr7pt0gr4ph7

O Compose possui sintaxe para substituição de ambiente. Em vez de usar uma variável de ambiente para o nome do projeto, talvez deixe as pessoas fazerem isso sozinhas, se quiserem.

Por outro lado, a máquina docker usa a extremidade para decidir em qual máquina uma compilação será construída, então talvez o nome do projeto e o destino devam funcionar da mesma forma. Hmm, esta é difícil.

https://github.com/docker/compose/issues/745#issuecomment -182296139 parece certo. A variável de ambiente teria precedência sobre o valor no arquivo de composição, que atua como padrão (assumindo que o nome do projeto pertence ao arquivo de composição).

Algo a se considerar, o que acontece quando você usa vários arquivos de composição em que cada um define um nome de projeto?

Não acho que deveria ser um erro, que forçaria os arquivos a serem "primários" ou "extras", o que não é o caso agora. Qualquer arquivo pode ser usado isoladamente ou em combinação com outros.

Talvez um aviso seja razoável ou talvez nós apenas o ignoremos completamente (já que o valor pode ser ignorado definindo uma opção ou variável de ambiente também).

Algo a se considerar, o que acontece quando você usa vários arquivos de composição em que cada um define um nome de projeto?

Se você fizer algo como docker-compose -f compose1.yml -f compose2.yml up e ambos os arquivos definirem o nome do projeto, o nome usado deve ser compose2.yml .

Acho que todos estão em uma solução de que já gosto: -) Ou seja, project_name em docker-compose.yaml. Só quero mencionar outro caso de uso para ter o nome do projeto no arquivo docker-compose.yaml:

Nas páginas HTTP 500 Internal Server Error em meu projeto, eu digo ao desenvolvedor como corrigir ou solucionar o problema, por exemplo, eu digo a ele / ela que ele pode zcat database-dump.tgz | docker exec -i projectname_db_1 psql se o servidor perceber que não há banco de dados PostgreSQL e usuário foi criado - e então eu quero escolher projectname eu mesmo, caso contrário, as mensagens de ajuda não podem ser copiadas e coladas no console.

Concorde que deve haver um aviso quando COMPOSE_PROJECT_NAME substituir o nome do projeto no compose.yml - esse comportamento faz sentido com base nos comandos Docker existentes, mas não é particularmente lógico ou óbvio para um novato.

+1 para estratégia @ cr7pt0gr4ph7

Tentei pesquisar algo antes de abrir um problema porque não consegui encontrar nada.
+1 para project_name no arquivo docker.compose.yml. Com a v2, acho que isso faz cada vez mais sentido.

Concorde que deve haver um aviso quando COMPOSE_PROJECT_NAME substituir o nome do projeto no compose.yml - esse comportamento faz sentido com base nos comandos Docker existentes, mas não é particularmente lógico ou óbvio para um novato.

É um comportamento muito normal para variáveis ​​de ambiente substituir as configurações de configuração e para argumentos de linha de comando substituir as configurações de configuração e variáveis ​​de ambiente.
Temos realmente um aviso para isso? Não é como se alguém pudesse criar acidentalmente uma variável de ambiente chamada COMPOSE_PROJECT_NAME .

Seria correto criar um PR que usasse apenas project_name de docker-compose.yml para fazer isso? Ou queremos coisas extras, como usar o project_name do último yml arquivo referenciado imediatamente?

Que tal agora?

version: "2"
project:
    default_name: "app"

Vou mudar minha implementação (https://github.com/docker/compose/pull/3118) para este formato. Mas não tenho certeza se há alguma necessidade da seção project ....

1 esteja interessado em ver este recurso

@timgriffiths , parece que isso é possível no RC mais recente adicionando um arquivo de ambiente ao seu projeto:

• https://docs.docker.com/compose/env-file/
• https://github.com/docker/compose/releases/tag/1.7.0-rc1

@deizel Então olhei para o arquivo de ambiente, mas ainda acho que há um bom caso de uso para ser capaz de definir o nome do projeto dentro do arquivo de composição.

Em nossa situação, temos arquivos Prod, Staging, UAT, Dev compor apenas para que possamos iniciar versões diferentes de nossa pilha de aplicativos e, às vezes, queremos criar um ambiente Staging e UAT no mesmo enxame, para que eu possa usar o ambiente variáveis ​​ou o que não, mas isso depende do usuário lembrar de definir isso, onde, como se estivesse no arquivo de composição, tudo seria verificado no repositório e poderíamos manter tudo embutido e simples de explicar para todos os usuários.

+1 Temos uma situação em que nosso arquivo de composição contém referências a volumes remotos pré-configurados. O Compose adiciona automaticamente o nome do projeto aos nomes dos volumes que falham na montagem devido a nomes incompatíveis. Ser capaz de definir explicitamente o nome do projeto no arquivo yml de composição tornaria a convenção de nomenclatura muito mais óbvia para os outros envolvidos no projeto, em vez de ocultar variáveis ​​de ambiente em arquivos externos obscuros que podem variar entre os ambientes.

@edevenport, no seu caso, você pode usar a opção externa de volumes nomeados:

# docker-compose.prod.yml
volumes
  dbdata:
    external:
      name: my-project-db-data

Obrigado @fesor - eu deveria ter entrado em mais detalhes. Na verdade, estou montando volumes glusterfs usando uma configuração semelhante a esta:

    ...
    volumes:
      - media:/data/media:ro

volumes:
  media:
    driver: glusterfs

Neste caso, media torna-se projectname_media no host e falha na montagem, a menos que o volume glusterfs seja criado antes do tempo com o nome do projeto. Eu tinha pensado em montar os volumes glusterfs no host manualmente e usar external no arquivo docker-compose, mas prefiro não ter que fazer isso manualmente em todos os nós antes do tempo.

@edevenport eu entendo isso. Mas você pode simplesmente adicionar este volume manualmente com docker volume create e usá-lo:

    volumes:
      - media:/data/media:ro

volumes:
  media:
    external:
      name: my-glusterfs-media

Portanto, não há necessidade de alterar o projeto e se livrar de quaisquer prefixos.

O caso de @timgriffiths é algo mais complexo e não tem nenhuma solução alternativa. Eu uso um invólucro simples em torno de docker-compose apenas para não lembrar os nomes dos projetos.

@fesor, portanto, contornamos o problema apenas colocando os arquivos de composição em nomes de pasta descritivos, isso contorna essa limitação. Mas seria muito bom vê-lo adicionado em versões posteriores

@timgriffiths Fiz um PR (https://github.com/docker/compose/pull/3118) - talvez isso ajude. Mas não resolve o seu caso se você tiver vários arquivos de composição.

@fesor que PR seria perfeito, é uma possibilidade de

Agora, o Compose fornece o arquivo de ambiente , para que o nome do projeto possa ser persistido nele.

@mkuzmin é triste que haja COMPOSE_FILE mas não haja COMPOSE_OVERRIDE_FILE .

@fesor AFAIK você pode especificar vários arquivos

@ schmunk42 Eu também poderia especificar o nome do projeto. Mas isso não resolve o problema. Eu quero ter no script de implantação algo assim:

docker-compose up -d

ao invés de

docker-compose -f $COMPOSE_FILE -f $COMPOSE_OVERRIDE_FILE \
            up -d

COMPOSE_PROJECT_NAME no exemplo acima é especificado por CI. E recursos como .env file são legais, mas ... inúteis no caso de persistência do nome do projeto.

Eu uso .env para variáveis ​​env DRY (e para docker-compose <1.7 eu tenho um wrapper simples), mas isso não resolve nenhum outro problema. @timgriffiths já apontado no caso com implantação no cluster swarm.

COMPOSE_FILE=one.yml:two.yml é como definir vários arquivos. Portanto, apenas inclua o arquivo de substituição em $COMPOSE_FILE

@dnephin perdeu esse recurso, legal.

Bem ... sobre a implantação do swarm, já estou lidando com isso por meio de COMPOSE_PROJECT_NAME nas variáveis ​​ENV do meu trabalho de Jenkin, portanto, problemas apenas com a implantação manual. E minha implementação não permite que o nome do projeto padrão seja substituído, então ...

Este problema tem quase 2 anos e ainda não foi resolvido. Eu me pergunto o que exatamente está impedindo a equipe do docker de finalmente adicionar uma correção adequada. É realmente tão difícil adicionar uma nova diretiva de configuração simples para docker-compose.yml arquivos?

Embora a solução alternativa com .env seja boa, ela nem sempre pode ser usada (o arquivo .env já pode ser usado por seu aplicativo). E também ainda é uma solução alternativa.

E eu até vi outros novos problemas que podem estar relacionados ao nome do projeto se arrastando para as versões mais recentes (# 3966).

Então, qual é o problema realmente?

É realmente tão difícil adicionar uma nova diretiva de configuração simples para docker-compose.yml arquivos?

Não! O problema nunca foi a dificuldade de implementação.

Embora a solução alternativa com .env seja boa, ela nem sempre pode ser usada (o arquivo .env já pode ser usado por seu aplicativo). E também ainda é uma solução alternativa.

Não é uma solução alternativa, é uma solução! O arquivo .env contém variáveis ​​de ambiente que devem ser lidas pelo Compose. Se você tiver variáveis ​​de ambiente que devem ser lidas pelo seu aplicativo, coloque-as em um arquivo diferente (digamos app.env ) e faça referência a ele usando a opção env_file .

Então, qual é o problema realmente?

Adicionar o nome do projeto a um arquivo docker-compose.yml o torna menos portátil, o que não é algo que queremos encorajar. Agora que há uma maneira (com .env ) de especificar persistentemente o nome do projeto sem sacrificar a portabilidade de docker-compose.yml , o caso de adicioná-lo como uma opção de configuração é mais fraco. Esse é o principal motivo pelo qual esse problema não mudou.

Adicionar o nome do projeto a um arquivo docker-compose.yml torna-o menos portátil,

Isso não poderia ser opcional? Pessoalmente, nunca verifico meu docker-compose.yml mas apenas forneço um docker-compose-example.yml em meu repo, que ajusto localmente. Por exemplo, durante o desenvolvimento, posso adicionar algumas variáveis ​​env extras ou mapear volumes adicionais em meu contêiner. Por que não nos dar a opção de especificar o nome do projeto?

Seguindo sua argumentação, você também deve mover todas as network opções para .env já que elas geralmente não são portáveis ​​e dependem da configuração de rede de sua máquina host.

Dito de outra forma: o que torna o nome do projeto tão especial? Já existem muitas outras opções no docker-compose.yml que não são realmente portáteis. Por que não dar ao desenvolvedor a opção de escolher o que for melhor para seu caso de uso?

Eu também acho que a opção deveria ser disponibilizada. À medida que o uso do Docker se torna mais difundido, os projetos com apenas um desenvolvedor usando containerização em seu fluxo de trabalho se tornarão cada vez mais comuns. Nesses casos de uso, o nome do projeto sendo constante está bom. Um bom exemplo de outro projeto que permite flexibilidade como este é vagrant com seus Vagrantfile . Eles percebem que certamente existem casos de uso para grandes equipes, mas também reconhecem os cenários de desenvolvedor de lobo solitário.

Acho que implementar uma opção de nome de projeto aqui é importante para adoção. Isso pode confundir desenvolvedores solo que não se importam com uma "estratégia de configuração de nomes de projeto escalável".

Adicionar o nome do projeto a um arquivo docker-compose.yml torna-o menos portátil, o que não é algo que queremos encorajar. Agora que existe uma maneira (com .env) de especificar persistentemente o nome do projeto sem sacrificar a portabilidade de docker-compose.yml, o caso de adicioná-lo como uma opção de configuração é mais fraco. Esse é o principal motivo pelo qual esse problema não mudou.

Como adicionar o nome do projeto a docker-compose.yml torna menos portátil?

IMHO é realmente o contrário, como mostrado por # 3966 criado por @mikehaertl. Este problema mostra claramente que não ter o nome do projeto armazenado em docker-compose.yml torna as coisas realmente menos portáveis ​​(como em: ter uma probabilidade maior de entrar em conflito com outros projetos de composição iniciados na mesma máquina), uma vez que o Compose se baseia em uma convenção sobre o nome da pasta do contêiner que muitas pessoas, pelo menos inicialmente, não saberão.

Adicionar a adição de um arquivo .env não apenas adiciona algo a ser aprendido para novas pessoas que desejam adotar o Compose, mas também tenho que adicioná-lo ao meu repo próximo a docker-compose.yml para evitar que colisões Não vejo como isso seria diferente em termos de portabilidade do que apenas definir o nome do projeto em docker-compose.yml .

Também devo adicionar o nome em docker-compose.yml. O arquivo .env é usado em outras estruturas que eu uso e é importante que permaneça fora do repo. No entanto, para manter contêineres localizados entre meus desenvolvedores, quanto menos eles souberem sobre o docker (no início), melhor. Eu quero um ponto de entrada simples que não colida com outros projetos. Não quero explicar por que as coisas são como são. Apenas um simples

clone repo
docker-compose up

Minha solução alternativa agora ainda é criar o arquivo proposto por @ schmunk42 .

O contêiner em si não deve se preocupar com o nome do projeto. Por que usar variáveis ​​de ambiente como um mecanismo destinado apenas ao host?

Adoraria ver suporte para isso no arquivo docker-compose.yml . Se for necessário configurá-lo por meio de uma variável de ambiente, ele pode ser definido no arquivo .env (se não for configurado diretamente no host) e usado por meio da substituição de variável no arquivo docker-compose.yml .

Se contêineres nomeados são permitidos, por que projetos nomeados não seriam permitidos?

O caso de uso em que uma definição de nome de projeto no arquivo .yml seria útil é o seguinte:
Temos o mesmo arquivo docker-compose para diferentes servidores da web (diferentes credenciais de banco de dados, diferentes volumes de dados, algumas pequenas diferenças como logotipo, etc). Existem 3 serviços por aplicativo em execução e eles são configurados em um arquivo de composição. Quando vários servidores são executados próximos um do outro, seria bom ver qual serviço pertence a qual projeto.

A substituição de variável no nome do contêiner é útil, com $ COMPOSE_PROJECT_NAME como prefixo. Bem, eu entendo a solução de arquivo .env, mas isso não a torna mais "amigável ao desenvolvedor" em um ambiente de implantação (CI).

Ter um docker-compose kill containers de um docker-compose totalmente diferente porque não havia nenhum -p ou conjunto de variáveis ​​de ambiente e você criou o docker-compose em uma subpasta "docker" é um bug crítico em minha opinião.

Simplesmente há muito espaço para erros em implantações sérias. Apenas esqueça de especificar o nome do projeto, seja em -p, .env ou em outro lugar: você fica offline por algum tempo até perceber o que aconteceu. Pior ainda: o serviço em conflito fica offline, não aquele em que você está trabalhando. Você terá um dia feliz :(

@dnephin O que exatamente está impedindo a equipe do docker para finalmente implementar isso? Quantos usuários mais reclamando são necessários? Esta é uma solução tão trivial que é difícil de acreditar, que ainda nada aconteceu.

Talvez eu seja o único aqui que tem alguma preocupação com isso, mas enfim.
Em nossa configuração, modificamos apenas .env e app.env arquivos para alternar entre ambientes, mas isso depende de ter vários arquivos e mesclar yml arquivos.

Se isso for implementado, pense no BC.

Por exemplo. se um nome de projeto for definido em docker-compose.yml e .env o último deve ter precedência. Caso contrário, as pessoas que dependem do gerenciamento disso por meio de .env , terão problemas semelhantes com pilhas sobrepostas, como no fluxo de trabalho atual e dependendo dos nomes das pastas.

@ schmunk42 Não estamos dizendo que o recurso .env deve ser removido. Se você preferir que o nome do seu projeto seja .env , simplesmente não o configure em docker-compose.yml .

Mas outros preferem tê-lo em seus docker-compose.yml como a discussão aqui mostra claramente. Eles devem ser capazes de fazer isso, se quiserem. É um recurso opcional. O que tem precedência se ambos estiverem configurados é uma questão de definir uma convenção simples.

Srsly, adicione projetos nomeados. Caso de uso:
Projeto um:
docker-compose up --build --remove-orphans

• nginx
• conteúdo estático
  Projeto dois:
  docker-compose up --build --remove-orphans
• nginx
• conteúdo estático

Quando o projeto dois começa, ele mata os containers do projeto com uma saída 137 (código 128 + nível 9).

Agora preciso executar docker system prune e reconstruir redes todos os dias para evitar dezenas de contêineres mortos.

export COMPOSE_PROJECT_NAME=somethingnew

Alguém da equipe principal pode finalmente explicar o que está impedindo esse recurso? É tão frustrante como coisas tão fáceis de consertar são bloqueadas sem um bom motivo.

O único argumento até agora era manter o docker-compose.yml portátil. Isso não faz sentido, porque

• nome do projeto no arquivo composer não o torna mais portátil automaticamente
• nem todo mundo tem esse requisito
  
  
  
  • já temos outras opções que podem limitar a portabilidade da mesma maneira: networks , port , ...
  
  

Tudo depende muito do caso de uso específico. Mas só porque alguns não querem essa opção não significa que todos tenham que seguir sua opinião!

@mikehaertl Você já tem nomes de projetos persistentes. Basta colocar .env file e definir a variável COMPOSE_PROJECT_NAME lá. Não vejo mais nenhum benefício no nome do projeto no arquivo de composição.

@fesor Eu geralmente não tenho .env arquivos sob controle de versão porque eles contêm configurações específicas da máquina / ambiente - é também por isso que eu gostaria de ver nomes de projetos sendo configruáveis ​​no arquivo docker-compose.yml .

@fesor : Acho que @thasmo está correto nisso. O nome do projeto deve ter a opção de ser especificado no arquivo compose.yml porque se for relevante para todos os desenvolvedores que usam o projeto, deve estar no controle de versão.

@fesor , sinto muito, mas não acho que a preferência pessoal seja um argumento real. A verdadeira questão não é, por que não queremos usar .env ou variável de ambiente. É o contrário: por que não foi colocado no arquivo de configuração ao qual pertence?

Quase todas as opções que você pode passar para docker na linha de comando podem ser especificadas nesse arquivo. Apenas o nome do projeto é excluído por alguns motivos misteriosos. É uma forma de apartheid entre discussões? : PI reivindica direitos iguais para todos eles! Deixe o desenvolvedor decidir e não coloque restrições artificiais neles.

E novamente: Ninguém está tirando a opção antiga de você - nós apenas queremos essa opção extra. Isso é justo.

@dnephin : Parece que você e todos os outros estão felizes com a solução indicada no refinamento de cr7pt0gr4ph7 para esse problema .

Você estaria disposto a aceitar um pull request que o implemente ou pretende que um dos mantenedores o escreva?

@ cr7pt0gr4ph7

@dnephin @fesor ter o nome do projeto no * compose.yml facilita um esquema de configuração unificado

Não está claro para mim por que o nome do projeto é importante. Nenhuma parte do arquivo de configuração deve contar com qualquer nome de projeto específico.

A única qualidade importante do nome do projeto é que ele não entra em conflito com o nome de nenhum outro projeto, o que na verdade é um argumento contra colocá-lo no arquivo docker-compose.yml . Um desenvolvedor em um projeto geralmente usa um nome de diretório diferente para cada projeto, portanto, o padrão é geralmente correto para a maioria dos casos de uso.

Quando o padrão não está correto, há uma maneira de o desenvolvedor substituí-lo ( -p ou COMPOSE_PROJECT_NAME ), que podem ser aliases ou colocados no arquivo .env .

Não sou contra um arquivo de projeto que definiria o nome do projeto, gostaria apenas de entender por que esse recurso é tão crítico para alguns. Se for porque o arquivo Compose requer um nome de projeto específico, vejo isso como um problema separado que deve ser tratado de forma diferente,

Eu queria ter 4 arquivos de composição em 1 diretório. O nome do diretório está errado por padrão aqui. A única opção que tenho é .env que só funciona para 1 arquivo de composição em 1 diretório.

_Por que excluo COMPOSE_PROJECT_NAME e -p: _
O COMPOSE_PROJECT_NAME e o -p, na minha opinião, não são salvos na produção, pois você deve se lembrar de defini-los. Ou crie um script de inicialização e lembre-se de não usar o docker compose diretamente. Quando a pessoa A depende desse mecanismo e a pessoa B não sabe disso, isso é uma certa falha.
(Já detalhei acima)

@dnephin Para mim e minha equipe, a lógica do aplicativo geralmente é armazenada em uma pasta htdocs em nossa pasta de projeto. Isso nos permite manter outros documentos / recursos relacionados juntos em um diretório. Como dev ops, trabalhando com desenvolvedores remotos. É fácil para mim fazer com que eles adotem o Docker se eu não tiver que assumir nada sobre sua estrutura de pastas. Eu disse isso no passado, .env não é uma opção para mim porque normalmente não faz parte do repo que todos nós compartilhamos.

Não está claro para mim por que o nome do projeto é importante. Nenhuma parte do arquivo de configuração deve contar com qualquer nome de projeto específico.

Aconteceu mais de uma vez comigo, que eu fiz uma 'composição docker para baixo' em um host - e tive um contêiner diferente do que o que eu queria cair Só porque não me lembrava, que também havia configuração em um arquivo .env .

A única qualidade importante do nome do projeto é que ele não entra em conflito com o nome de qualquer outro projeto, o que na verdade é um argumento contra colocá-lo no arquivo docker-compose.yml. Um desenvolvedor em um projeto geralmente usa um nome de diretório diferente para cada projeto, portanto, o padrão é geralmente correto para a maioria dos casos de uso.

Talvez isso seja verdade para você - não é para mim e para muitos outros. A estrutura do meu aplicativo é como myapp/app/docker-compose.yml . Portanto, todos os meus aplicativos compartilham o nome de diretório app . E eu tenho mais de 1 contêiner em um host.

Quando o padrão não está correto, há uma maneira do desenvolvedor substituí-lo (-p ou COMPOSE_PROJECT_NAME), que pode ser apelido ou colocado no arquivo .env.

Sério, começo a me sentir como se estivesse em um romance de Kafka aqui. Não é óbvio que você pode colocar basicamente todas as opções de linha de comando para docker em docker-compose.yml - exceto por esta grande exceção?

Em vez de nos perguntar repetidamente e ignorar nossas respostas, por que alguém não consegue finalmente justificar a resistência? E não: "... mas eu não preciso" não é um argumento válido!

@dnephin Eu tenho vários projetos em seus próprios docker (o contexto de construção se torna .. , tudo funciona perfeitamente).

Para executar vários projetos em um único servidor, atualmente tenho que criar docker/.env.dist em cada repo e cp docker/.env.dist docker/.env após git clone . Caso contrário, o nome do projeto é apenas docker , o que eu obviamente não quero. Em alguns casos, .env contém senhas etc., portanto, copiar .env.dist é necessário de qualquer maneira, mas na maioria dos casos .env existe simplesmente porque não há como definir COMPOSE_PROJECT_NAME em docker-compose.yml .

Eu entendo que pode haver falhas em como os contêineres são iniciados e parados se o mesmo COMPOSE_PROJECT_NAME for usado duas vezes dentro de docker-compose.yml , mas isso já está acontecendo se eu esquecer de copiar .env.dist ou quando eu acidentalmente atribuo o mesmo nome em dois .env arquivos diferentes no mesmo servidor. Para mim, seria ideal se eu pudesse definir default_compose_project_name corretamente em docker-compose.yml e, em seguida, substituir o valor em .env se, digamos, eu queira executar uma cópia de teste de algum projeto . Isso seria 100% AC, mas mais conveniente.

Eu disse isso no passado, .env não é uma opção para mim porque normalmente não faz parte do repo que todos nós compartilhamos.

Talvez essa seja a causa raiz de tudo. Eu disse antes que docker-compose "sequestrou" este arquivo e fomos forçados a renomear nossas coisas para app.env .

Talvez docker-compose.env fosse a escolha certa.

FWIW: Estamos apenas alterando .env arquivos em produção, os yml arquivos são mesclados com docker-compose.override.yml se necessário.

Uma solução alternativa também é definir seus arquivos yml de uma forma que eles não comecem sem um arquivo .env , por exemplo. usando uma variável image: $IMAGE .

Esta é uma solução alternativa para meus 4 arquivos docker-compose em 1 caso de diretório acima de @ schmunk42 ? Mesmo?

@RobIsHere Mas você precisa usar -f qualquer maneira, certo?

Em resposta a @dnephin neste comentário :

Não está claro para mim por que o nome do projeto é importante.

É importante porque afeta o nome dos contêineres do Docker que docker-compose gerencia. Se você esquecer de definir o nome do projeto, docker-compose ps não encontrará os contêineres que você criou antes com docker-compose --project-name <project_name> up -d <container_name> .

Além disso, ao executar o comando global docker ps , o nome do projeto será incluído na lista de contêineres em execução, para que você saiba de onde eles vieram. Por exemplo, se você estiver testando vários projetos de código ao mesmo tempo que usam MySQL e cada um deles tem um contêiner mysql , docker ps mostrará uma lista ambígua de contêineres. Portanto, o nome do projeto é importante no contexto de muitos projetos Docker em execução na mesma máquina.

Nenhuma parte do arquivo de configuração deve contar com qualquer nome de projeto específico.

Ter que definir o nome do projeto em um local diferente de _todas as outras variáveis ​​associadas ao projeto Docker Compose_ não faz sentido.

A única qualidade importante do nome do projeto é que ele não entra em conflito com o nome de qualquer outro projeto, o que na verdade é um argumento contra colocá-lo no arquivo docker-compose.yml.

Pelas razões declaradas no meu primeiro parágrafo, esta não é a _ "única qualidade importante do nome do projeto" _. É para facilidade de uso e compreensão.

Um desenvolvedor em um projeto geralmente usa um nome de diretório diferente para cada projeto, portanto, o padrão é geralmente correto para a maioria dos casos de uso.

No caso não padrão em que um desenvolvedor coloca _todos_ os arquivos Docker relacionados no diretório docker , que é uma maneira perfeitamente razoável de organizar um projeto Docker, a mágica que define o nome do projeto criará nomes de projeto conflitantes. Portanto, os mesmos conflitos que você mencionou ocorrem neste caso específico. Você não precisa proteger o desenvolvedor contra colisões de nomes de projetos quando eles estão definindo explicitamente o nome do projeto de qualquer maneira.

Quando o padrão não está correto, há uma maneira do desenvolvedor substituí-lo (-p ou COMPOSE_PROJECT_NAME), que pode ser apelido ou colocado no arquivo .env.

Definir variáveis ​​de ambiente é um nível extra de complexidade que não é necessário. Quando você está compartilhando um projeto entre desenvolvedores com controle de versão, faz sentido usar apenas arquivos. Ter que incluir parâmetros de linha de comando em cada chamada é entediante e sujeito a erros. E o arquivo .env não pode ser compartilhado no controle de versão porque ele deve conter variáveis ​​_específicas do usuário_, não _específicas do projeto_. Portanto, as formas atuais de definir um nome de projeto são insuficientes.

Não sou contra um arquivo de projeto que definiria o nome do projeto, gostaria apenas de entender por que esse recurso é tão crítico para alguns. Se for porque o arquivo Compose requer um nome de projeto específico, vejo isso como um problema separado que deve ser tratado de forma diferente,

Todas as variáveis ​​que afetam o funcionamento de docker-compose devem ir no mesmo lugar, o arquivo docker-compose.yml . As formas atuais de definir um nome de projeto introduzem uma complexidade desnecessária.

Quase todas as pessoas que subscreveram esta edição concordam com esses pontos.

Adicionar a capacidade de definir o nome do projeto em docker-config.yml não entrará em conflito com nenhuma funcionalidade atual. Não há razão para não implementá-lo.

@ schmunk42 Da última vez que verifiquei, o docker não nos permitiu escolher o nome do nosso arquivo .env. Perdi alguma coisa (é difícil acompanhar as mudanças). Alterá-lo para algo como docker-compse.env iria corrigi-lo para meu caso de uso. O problema que tenho é que estou usando duas tecnologias muito populares que exigem arquivo .env. O framework PHP Laravel não rastreia aquele arquivo no repositório e em ambientes de produção ele às vezes não existe.

Descobri que isso é um verdadeiro obstáculo quando adotei o Docker pela primeira vez, porque como @RobIsHere ilustra. Todos os meus diretórios de projeto estão no formato myapp/htdocs/docker-compose.yml . Nos primeiros dias de adoção do Docker, excluí acidentalmente outros contêineres que não pretendia. Seria melhor se docker nomeasse seu projeto aleatoriamente, em vez de usar o nome da pasta no meu caso.

Tenho vários outros desenvolvedores remotos que estão começando a adotar o Docker. Como equipe, é sempre mais fácil instruir esses desenvolvedores a sempre / apenas docker-compose up para colocar esses aplicativos em execução. Quanto menos esses primeiros usuários souberem sobre o Docker, melhor. Assim que virem o poder por trás disso, eles vão melhorar por conta própria.

Então, para resumir, os casos de uso parecem ser quando o padrão não é apropriado. Já existem maneiras de substituir o padrão, mas elas podem estar sujeitas a erros e não são óbvias para os primeiros usuários.

Casos em que o padrão não é apropriado:

• vários arquivos de composição no mesmo diretório (já requer que você especifique -f para executá-los)
• usando o mesmo nome de diretório para todos os projetos (acho que isso também requer que você especifique -f , uma possível solução alternativa é usar um nome de diretório exclusivo).

@dnephin, eu acrescentaria, menos um obstáculo possível para os primeiros usuários do Docker.

@dnephin Você também se comentário :

Originalmente, eu queria o nome no docker-compose.yml, mas depois de pensar mais sobre isso, eu realmente gosto da ideia de um arquivo separado. Um arquivo separado oferece a opção de mantê-lo fora do controle de versão, se desejar (para os casos em que você deseja que cada usuário possa ter um nome de projeto diferente).

Definir a ordem de precedência da resolução do nome do projeto como esta resolverá o problema (números maiores substituem os menores):

1. docker-compose.yml
2. A variável de ambiente COMPOSE_PROJECT_NAME
3. A opção de linha de comando --project-name

A última vez que verifiquei, o docker não nos permitiu escolher o nome do nosso arquivo .env.

@fiveanddone AFAIK, você não pode fazer isso, mas também

Em nosso caso com phd5 , movemos o ambiente (app) para src/ e .env é apenas o "arquivo de ambiente de controle", tentei explicar isso aqui .
Eu não gosto disso e não teria mudado sozinho. Eu sei que isso pode não ser possível para muitos projetos.
Mas ter um .env de seu aplicativo no mesmo nível que seu docker-compose.yml torna-se muito irritante, porque a) você obtém variáveis ​​em seu "ambiente de controle" que não pertencem a ele eb) você tem que encaminhar essas variáveis ​​para o seu contêiner, se precisar delas lá ec) você não pode mais sobrescrever / alterá-las em seu arquivo app.env .

@dnephin Que tal introduzir docker-compose.env como o arquivo env preferido e usar .env como reserva. Você fez o mesmo com fig.yml uma vez.

Não acho que isso resolva o problema para todos. A nomenclatura do arquivo .env parece um problema diferente para mim.

Acho que o cerne do problema é este:

O projeto original de docker-compose up era para ser um único comando (curto) que você poderia executar para fazer os serviços rodarem. Isso é o que os desenvolvedores esperam dele. No entanto, esse comportamento não pode ser alcançado para alguns usuários ( nesses casos ).

Existem muitas maneiras de contornar o problema, mas nenhuma que pareça funcionar para todos.

Acho que a ordem de precedência (do mais alto para o mais baixo) precisa ser algo assim:

1. --project-name (sempre substitui)
2. COMPOSE_PROJECT_NAME variável de ambiente
3. Um padrão definido pelo usuário, separado de qualquer arquivo com versão
4. Um padrão definido pelo projeto, que pode ser verificado
5. O nome do diretório (o padrão quando nada é especificado)

(3) poderia ser alcançado com um arquivo .docker/project-name (conforme proposto no OP)
(4) poderia ser alcançado com um campo no arquivo docker-compose.yml

É uma pena que haja tantas maneiras diferentes de definir o nome do projeto.

@dnephin em relação a 3, permitir que um usuário defina um padrão, é para isso que servem os env vars, sem necessidade de criar um arquivo

Hmm ... E se generalizarmos o problema um pouco e simplesmente introduzirmos a seção default_environment em docker-compose.yml ? Desta forma, seremos capazes de definir COMPOSE_PROJECT_NAME sem introduzir um campo especial no yaml, mas também seremos capazes de definir outras variáveis ​​padrão, que provavelmente estarão presentes em outras partes do arquivo. Isso reduzirá o número de casos em que .env.dist precisa ser copiado para .env e o custo de se esquecer de fazer isso será menor.

Exemplo de uso:

# ~/projects/sketches/sketch-42/docker/docker-compose.yml
version: "2"
default_environment:
  - SUBDOMAIN=sketch-42
  - ROOT_HOST=example.com
  - COMPOSE_PROJECT_NAME=sketch-42
services:
  web:
    build:
      context: ../
      dockerfile: docker/Dockerfile
    environment:
      - VIRTUAL_HOST=${SUBDOMAIN}.${ROOT_HOST},www.${SUBDOMAIN}.${ROOT_HOST}
      - VIRTUAL_PORT=80
      - VIRTUAL_NETWORK=proxy
      - LETSENCRYPT_HOST=${SUBDOMAIN}.${ROOT_HOST},www.${SUBDOMAIN}.${ROOT_HOST}
      - LETSENCRYPT_EMAIL=admin@${ROOT_HOST}
    restart: always
    networks:
      - proxy

networks:
  proxy:
    external:
      name: proxy

Este yaml é muito semelhante ao que eu uso com frequência - descreve um esboço de visão, que sempre tem um serviço chamado web , mas também pode ser feito por um mini servidor API e talvez um contêiner com um banco de dados. Presume-se que https://github.com/jwilder/nginx-proxy fica na frente de tudo e escuta as portas reais 80 e 443.

No momento, não importa se estou em uma máquina local ou em um servidor remoto, preciso me lembrar de manter .env e também ter certeza de que _todas_ as variáveis ​​de ambiente estão definidas lá. Se, digamos, eu esqueci SUBDOMAIN , o contêiner inicia, mas o servidor da web permanece quebrado.

Com a seção default_environment à minha disposição, eu poderia ter todas as minhas variáveis ​​de produção no lugar em um arquivo e não teria que copiar .env.dist quando no servidor. Na máquina local, no exemplo acima, eu apenas colocaria uma única variável em .env , que seria ROOT_HOST=example.com.dev (ou talvez eu pudesse até export ROOT_HOST=example.com.dev no perfil do bash? )

Para resumir, a seção default_environment em docker-compose.yml pode não apenas resolver o problema que estamos discutindo, mas também pode permitir alguns truques extras, sendo 100% BC e fácil de entender!

WDYT?

Isso parece bom, mas pode ser útil para mim em alguns cenários.

No entanto, esteja ciente de que, à luz da discussão acima (acalorada), seu
solução se traduz aproximadamente no seguinte: “Em vez de adicionar um novo arquivo ao
yml, que tal adicionarmos uma nova seção? ” :)

Em Ter, 28 de fevereiro de 2017, 00:02 Alexander Kachkaev [email protected]
escrevi:

Hmm ... E se generalizássemos o problema um pouco e simplesmente apresentássemos
seção default_env em docker-compose.yml. Assim definimos
COMPOSE_PROJECT_NAME sem introduzir um campo especial no yaml, mas
também será capaz de definir outras variáveis ​​padrão, que provavelmente serão
presente em outro lugar ao longo do arquivo. Isso reduzirá o número de casos
quando .env.dist precisa ser copiado para .env e o custo de se esquecer de
fazer isso será menos.

Exemplo de uso:

~ / projects / sketches / sketch-42 / docker / docker-compose.yml

versão 2"
default_env:
SUBDOMAIN = sketch-42
ROOT_HOST = example.com
COMPOSE_PROJECT_NAME = sketch-42
Serviços:
rede:
Construir:
contexto: ../
dockerfile: docker / Dockerfile
meio Ambiente:
- VIRTUAL_HOST = $ {SUBDOMAIN}. $ {ROOT_HOST}, www. $ {SUBDOMAIN}. $ {ROOT_HOST}
- VIRTUAL_PORT = 80
- VIRTUAL_NETWORK = proxy
- LETSENCRYPT_HOST = $ {SUBDOMAIN}. $ {ROOT_HOST}, www. $ {SUBDOMAIN}. $ {ROOT_HOST}
- LETSENCRYPT_EMAIL = admin @ $ {ROOT_HOST}
reiniciar: sempre
redes:
- proxy

redes:
proxy:
externo:
nome: proxy

Este yaml é muito semelhante ao que eu costumo fazer - descreve um vis
sketch, que sempre tem um serviço chamado web, mas também pode ser feito backup
por um mini servidor API e talvez um contêiner com um banco de dados. É assumido
que https://github.com/jwilder/nginx-proxy fica na frente e escuta
para as portas reais 80 e 443.

No momento, não importa se estou em uma máquina local ou em um servidor remoto,
Preciso me lembrar de manter o .env e também ter certeza de que todos
as variáveis ​​de ambiente são definidas lá. Se, digamos, eu esqueci
SUBDOMAIN, o contêiner é iniciado, mas o servidor da web permanece quebrado.

Com a seção default_env à minha disposição, eu poderia ter toda a minha produção
variáveis ​​no local e eu não teria que copiar .env.dist no servidor.
Na máquina local, eu apenas colocaria uma variável em .env, que seria
ROOT_HOST = example.com.dev (ou talvez eu pudesse até exportar
ROOT_HOST = example.com.dev no perfil bash?)

Para resumir, a seção default_env em docker-compose.yml não pode apenas
resolver o problema que discutimos agora, mas também pode permitir um uso mais agradável
cenários!

WDYT?

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/docker/compose/issues/745#issuecomment-282885661 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAQJJZumr10j3i17gPxrSyA-n8CwvsXTks5rg1X_gaJpZM4DLBNs
.

Ter o "project_name" dentro de docker-compose.yml resolveria um problema com nossa pilha.
Temos um repo monolith com uma árvore padronizada que lida com vários projetos, mais ou menos assim:

projectA/infrastructure/docker-compose.yml
projectB/infrastructure/docker-compose.yml
...

É obviamente mais complexo do que no mundo real, então não podemos simplesmente mover o arquivo docker-compose.yml para a pasta "projectA / projectB".

Temos uma CLI na raiz que pergunta quais projetos inicializar e, como o nome do projeto depende diretamente da pasta pai do docker_compose.yml, estamos enfrentando conflitos.

Como não escrevemos o comando docker-compose (envolto em nosso script CLI), não podemos simplesmente adicionar o argumento "-p" ao comando manualmente.
Uma solução para nós seria sempre gerar um project_name dentro do script CLI para que sempre tenhamos um "-p" ao chamar docker-compose, com base no absolute_path, mas parece estranho.

Alguém aqui disse "funciona na maioria das vezes porque na maioria dos projetos, o docker-compose.yml está localizado dentro da pasta raiz do projeto, e os projetos têm nomes diferentes, evitando conflitos", só não concordo esta. Nem sempre está dentro da pasta raiz.

Por que isso é possível definir o "container_name" em um arquivo docker-compose.yml (desativando o dimensionamento) para um serviço, mas não pode definir um "project_name" para o próprio arquivo docker-compose.yml, no mesmo nível que "versão" / "serviços" / "redes" / "volumes"?

Isso parece necessário com o uso de scale para que os nomes dos contêineres sejam óbvios. (por exemplo, <project_name>_<container_name>_1 ).

Isso ajudará ao usar o nome do contêiner para dns.

Vim aqui esperando que isso fosse feito. Saiu desapontado. 3 anos +

Sim, é um dos problemas de usabilidade mais estúpidos do Docker e não é corrigido.

Passamos muito tempo discutindo com os desenvolvedores sobre isso e, embora houvesse consenso, ninguém admitia que era um design ruim.

É frustrante porque há suporte de usuário óbvio para isso, mas uma vez que não se encaixa com os próprios casos de uso dos desenvolvedores - ficamos revisando este ano após ano.

Qual é o ponto de docker-compose se precisarmos adicionar opções usando cli?
Alguns contêineres foram sobrescritos graças ao esquema de nomenclatura.

Hoje eu estava configurando outro projeto docker-compose com mais um arquivo .env para dar ao projeto um nome persistente. Então, pensei em verificar esse problema, pois já se passaram alguns anos desde que verifiquei pela última vez. Mas nada de novo aqui, pelo que posso ver? Acho que terei que continuar usando a solução alternativa .env . Para mim, nomear um projeto no arquivo yaml parece a coisa mais básica que você pode fazer, mas acho que há algo sobre isso que simplesmente não entendo, pois ainda não foi resolvido.

Ter que especificar o nome do projeto externamente (por linha de comando ou variável), mas ser incapaz de defini-lo no arquivo docker-compose.yml - o arquivo que especifica absolutamente tudo o mais - é simplesmente estúpido. Existem muitos casos em que um processo pode precisar abordar uma pilha específica de serviços com base em um arquivo docker-compose.yml arbitrário, independentemente do nome do diretório pai, ambiente de shell ou presença de uma linha específica em um .env file. Não quero que meus trabalhos de CI tenham que "descobrir" continuamente qual deve ser o nome do projeto - ele deve estar claramente definido em docker-compose.yml para que meus trabalhos possam extraí-lo e usá-lo.

Isso parece acontecer uma e outra vez com este projeto. Docker é uma tecnologia maravilhosa, mas às vezes me pergunto se os desenvolvedores realmente têm alguma experiência no mundo real ou são todos hackers de 18 anos que pensam que sabem o que é melhor? As pessoas querem usar essas coisas para um trabalho real, e não gastar seu tempo constantemente procurando soluções alternativas.

Meu palpite é que a equipe está, entretanto, ignorando esse problema. Tentar convencer os desenvolvedores do docker pode ser uma verdadeira dor, para dizer o mínimo.

Argumentos claros são contestados com alguma lógica estranha que não faz muito sentido. A opinião dos usuários do mundo real de que todos vêm aqui pelo mesmo motivo é ignorada. É uma vergonha.

Não quero que meus trabalhos de CI tenham que "descobrir" continuamente qual deve ser o nome do projeto - ele deve ser declarado claramente no docker-compose.yml para que meus trabalhos possam extraí-lo e usá-lo.

Você tem o problema de que sua pilha seja nomeada como "build1234" e / ou como gostaria de usar o nome da pilha em outro lugar, como docker exec build1234_myservice script.sh ?

Pode não caber em nenhum caso de uso, mas por ter dito ...

Em nossas configurações, apenas alteramos arquivos .env ao configurar um projeto (clone). Se precisarmos de mudanças ou uma configuração dinâmica, reutilizamos as variáveis ​​de .env em docker-compose.yml . Uma vantagem é que docker-compose avisa (ou falha) se uma variável estiver faltando.

Não quero dizer que você precisa mudar seus fluxos de trabalho, porque também fiquei incomodado com esse problema.
É basicamente algo como, tratamos as alterações em docker-compose.yml mais como alterações no código-fonte, enquanto .env é apenas configuração. Mas também concordo que existem várias opções em docker-compose.yml , como network que são altamente dependentes do projeto. Voltando ao acima; Eu definiria uma variável .env para a rede. 🤐

Não quero dizer que você precisa mudar seus fluxos de trabalho, porque também fiquei incomodado com esse problema.

Pensei um pouco mais na minha situação. Na verdade, não tenho problemas em definir externamente o nome do projeto e, na verdade, faço isso com o sinalizador -p <project_name> , que torna possível isolar instâncias exclusivas da pilha em CI e executar várias pilhas simultaneamente se necessário. Apenas essa cadeia de CI precisa saber o nome do projeto para que possa ser gerado automaticamente ou aleatório (mas conhecido), sem problemas. Eu também não tenho problemas em usar uma variável de ambiente para substituir o nome padrão, no entanto, acho o truque .env não óbvio.

No entanto, existem outras situações em que é útil ter o _nome padrão_ do projeto explicitamente definido em algum lugar. Então, por que o nome do diretório pai é a origem desse nome? Esse, para mim, é o ponto fraco aqui. Pode ser obtido de qualquer lugar - a escolha de um diretório pai parece simplesmente arbitrária e sem muita razão (por exemplo, em quase todos os meus projetos, o arquivo docker-compose.yml fica em um subdiretório chamado docker ). Portanto, se for arbitrário, armazene-o em algum lugar que seja mais explícito, como o arquivo yml, em vez de criar efeitos colaterais externos influenciando os nomes do diretório pai que, em muitos casos, devem ser completamente independentes do conteúdo do diretório (com base em anos experiência de trabalho com recursos reutilizáveis).

Ele pode ser obtido de qualquer lugar - a escolha de um diretório pai parece arbitrária e sem muitos motivos (por exemplo, em quase todos os meus projetos, o arquivo docker-compose.yml fica em um subdiretório chamado docker).

Se você precisar de algo diferente de um ID aleatório, não vejo alternativa real para o diretório pai. Pelo menos você tem a chance de saber de onde sua pilha "veio".
Mas também concordo com você, já que em nossos projetos temos pilhas de teste em pastas tests que - sem um arquivo .env - também colidiriam gravemente umas com as outras. É por isso que propus preferir um arquivo chamado docker-compose.env que seria muito mais claro IMHO.

Vocês fechariam este bug admitindo que não se importam ou implementariam algo incrivelmente simples que a grande maioria de nós deseja? São 2,86 anos depois. Saia da panela. Assuma suas decisões ou corrija seus erros. Da maneira que você quiser ver. Faça mais do que nada.

@matsaman e todas as pessoas fazendo seu comentário com o polegar para cima:

Vocês fechariam este bug admitindo que não se importam ou implementariam algo incrivelmente simples que a grande maioria de nós deseja? São 2,86 anos depois. Saia da panela. Assuma suas decisões ou corrija seus erros. Da maneira que você quiser ver. Faça mais do que nada.

Quem são "vocês"? No código aberto, a comunidade é dona das decisões e corrige os erros dos outros. Docker é de código aberto. Considere enviar uma solicitação pull em vez de reclamar.

Eu também estou triste por isso ainda não ter sido implementado. Mas, no código aberto, ou contribuímos ou esperamos pacientemente.

CLI arg:

$ cd foo
$ docker-compose up
$ docker-compose -p bar up
... some time later wanting to take down bar forgetting '-p'
$ docker-compose down
Stopping foo_nginx_1 ... done
Stopping foo_mysql_1 ... done
Removing foo_nginx_1 ... done
Removing foo_mysql_1 ... done
$ FU@$_!@*#%$(!_*@
-bash: FU@!@*#%$: command not found

Falhou.

Arquivo Env:

$ cd foo
$ source foo.env
$ docker-compose up
$ source bar.env
$ docker-compose up
... some time later wanting to take down foo forgetting to `source .foo.env`
$ docker-compose down
Stopping bar_nginx_1 ... done
Stopping bar_mysql_1 ... done
Removing bar_nginx_1 ... done
Removing bar_mysql_1 ... done
$ FU@$_!@*#%$(!_*@
-bash: FU@!@*#%$: command not found

Falhou.

Soluções propostas com o nome do projeto no arquivo yml:

$ cd foo
$ docker-compose -f foo.yml up
$ docker-compose -f bar.yml up
... some time later
$ docker-compose down
ERROR:
        Can't find a suitable configuration file in this directory or any
        parent. Are you in the right directory?

        Supported filenames: docker-compose.yml, docker-compose.yaml

Yay!

$ COMPOSE_PROJECT_NAME=foo docker-compose up -d
$ COMPOSE_PROJECT_NAME=bar docker-compose up -d
... some time later
$ docker-compose down -v
Removing network project_default
WARNING: Network project_default not found.

o/

Quem são "vocês"?

@benjaminwood São os mantenedores deste projeto. Seu argumento faria sentido se estivéssemos falando sobre uma mudança complexa e ninguém encontrasse tempo para fazê-lo.

É bastante óbvio que não é o caso aqui: a implementação provavelmente seria muito fácil para aqueles familiarizados com a base de código e muito mais difícil para alguém de fora. Portanto, não é que ninguém tenha tempo para fazer isso, mas sim que os mantenedores não querem fazer isso. E isso é o que os torcedores aqui acham extremamente annyoing, dado o tempo que esta questão está aberta agora e a massa de: +1: aqui.

As soluções alternativas postadas várias vezes aqui são bem conhecidas, mas não se aplicam a todos. E ainda não consegui encontrar uma resposta por que, de todas as coisas, quase apenas o nome do projeto foi omitido nos recursos de docker-compose.yml . Se alguém pensa que não pertence a esse lugar , simplesmente não o use! Mas não obstrua sua opinião sobre os outros se a demanda por isso for tão óbvia.

Vamos ver isso de outro ponto.

Se eu estiver em uma pasta com um arquivo docker-compose.yml , como descubro qual nome de projeto minha pilha tem?
Essa é uma pergunta bastante básica, mas não há uma resposta fácil para ela.

Atualmente é (classificado por prioridade):

• o valor de -p
• o valor de COMPOSE_PROJECT_NAME do seu ambiente
• o valor de COMPOSE_PROJECT_NAME do seu arquivo .env
• o nome do diretório atual

Para ser o advogado do diabo, por que adicionar um 5º a este cenário já confuso?

Apesar da decisão disso, deve haver uma informação "dry-runnable" sobre o nome atual. Nem docker-compose config tem isso, nem docker-compose ps se a pilha não estiver funcionando.
Talvez docker-compose create seja a melhor opção disponível atualmente, mas está longe de ser perfeita.

Deve haver pelo menos algo como docker-compose config --project-name . Atualmente preciso saber os locais acima e verificá-los na ordem correta.

Se eu estiver em uma pasta com um arquivo docker-compose.yml, como descubro qual nome de projeto minha pilha tem?

Mais uma vez: se você não quiser usar, não use! Se você está satisfeito com sua solução - bom para você !! Nada mudará para você, então você não ficará confuso!

Mas você não pode aceitar que os outros tenham requisitos diferentes? Tudo o que queremos é que essa peça que faltava logicamente seja finalmente adicionada.

Para ser o advogado do diabo, por que adicionar um 5º a este cenário já confuso?

A única razão pela qual pode ser confuso é porque o nome do projeto foi omitido de docker-compose.yml em primeiro lugar. Do contrário, tudo estaria naquele arquivo agora. Podemos definir uma lista de precedência - não é um problema.

Atualmente preciso saber os locais acima e verificá-los na ordem correta.

Por que você não sabe o nome do docker do seu projeto e por que isso é relevante para você? E por que você não usa o mesmo mecanismo em todos os seus projetos se isso o confunde tanto?

Mais uma vez: se você não quiser usar, não use! Se você está satisfeito com sua solução - bom para você !! Nada mudará para você, então você não ficará confuso!

Minha dúvida não era sobre o uso de um novo recurso, mas a falta de um existente. O nome do projeto é a única informação relevante que docker-compose usa para iniciar e parar um determinado conjunto de contêineres.
As pessoas neste segmento reclamam de eliminar os contêineres errados, porque o nome do projeto não faz parte da pilha.

Mas você não pode aceitar que os outros tenham requisitos diferentes? Tudo o que queremos é que essa peça que faltava logicamente seja finalmente adicionada.

Se você adicionar essa pessoa vai reclamar de matar os containers errados, porque faz parte da pilha, já que estava usando o nome do diretório antes.

A única razão pela qual pode ser confuso é porque o nome do projeto foi deixado de fora de docker-compose.yml em primeiro lugar. Do contrário, tudo estaria naquele arquivo agora. Podemos definir uma lista de precedência - não é um problema.

Na verdade, você não pode adicionar isso de uma maneira BC, já que teria que ter uma precedência inferior ao nome do diretório, o que o tornaria inútil. É por isso que eu estava perguntando "como obter o nome do projeto".

Por que você não sabe o nome do docker do seu projeto e por que isso é relevante para você?

Porque eu geralmente uso o nome do diretório, mas às vezes um valor personalizado em .env - é relevante porque o nome do projeto define os contêineres nos quais as ações são executadas.

cd /some/path/test
docker-compose up -d
cd /a-completely-different-path
docker-compose -p test down -v --remove-orphans

Isso matará sua primeira pilha, seria o mesmo com o nome do projeto no arquivo yml .

E por que você não usa o mesmo mecanismo em todos os seus projetos se isso o confunde tanto?

Sim, estou apenas usando os recursos padrão de docker-compose ; na maioria das vezes o nome do diretório está bom, mas no caso de eu precisar renomeá-lo, mas quiser continuar trabalhando com o mesmo conjunto de containers, adiciono um arquivo .env .

Se você adicionar essa pessoa vai reclamar de matar os containers errados, porque faz parte da pilha, já que estava usando o nome do diretório antes.

Isso não faz sentido. Se alguém não adicionar o nome do projeto a docker-compose.yml nada mudará. E se eles o adicionam, é porque o querem lá! Ninguém irá adicioná-lo a menos que seja necessário.

E mesmo que o façam, está tudo bem. Eu não entendo qual problema você tenta construir aqui. Você está complicando as coisas.

Se você misturar todas as opções onde um nome de projeto pode ser configurado, então eu diria que este é o seu problema. Você não deveria fazer isso.

3 das 4 opções na árvore de prioridade são inúteis, uma vez que você tem vários arquivos de composição nomeados em um diretório. Não me diga para criar subdiretórios, porque ainda compartilho um arquivo .env entre eles.

Não me diga para criar subdiretórios, porque ainda compartilho um arquivo .env entre eles.

Você compartilha um arquivo .env específico do aplicativo usado em env_file ?
Ou aquele que docker-compose usa?
Ou você os mistura?

Isso não faz sentido. Se alguém não adicionar o nome do projeto a docker-compose.yml, nada mudará.

Esse não é o problema, mas quando seria adicionado, o comportamento muda drasticamente.

Quando copiamos uma pilha para um novo diretório para gerar uma instância temporária (ou seja, para testar uma atualização), não precisamos tocar em docker-compose.yml alguma. Mas se isso fizer parte da pilha, precisaremos decidir se substituímos .env ou se mudamos docker-compose.yml .

Sim, pode ser que não devesse ter sido adicionado em primeiro lugar, mas ter outra opção aqui também não torna as coisas mais fáceis e concisas.

Eu tenho um único arquivo .env comum que 4 arquivos nomeados de composição (no mesmo diretório) usam. Sem variáveis ​​de ambiente. Sem scripts de shell. Eu uso apenas compor.

Eu preferiria isso

docker-compose -f service1.yml up -d

Em vez disso, é mais assim

docker-compose -f service1.yml up -d
# F#&$, forgot the -p flag.   Curse the compose devs for 3 years of c#*$blocking
docker-compose -f service1.yml down
docker-compose -f service1.yml -p service1 up -d

@ schmunk42 você acredita seriamente que é uma solução digitar 'COMPOSE_PROJECT_NAME = ...' cada vez para cada comando docker-compose, possivelmente além do nome do arquivo de composição? Isso também requer que você saiba e lembre-se do nome do projeto. Ser capaz de especificar o nome do projeto em uma variável de ambiente tem seus usos com certeza, mas em alguns casos você só quer ter um diretório com alguns arquivos yml e ser capaz de gerenciar projetos facilmente de uma maneira infalível, sem ter que lembre-se dos nomes de projeto que você escolheu meses atrás e sem ter que se lembrar de exportar variáveis ​​de ambiente.

Você não pode usar uma pasta por serviço e ainda ter um arquivo .env na pasta superior?

docker-compose -f service1/docker-compose.yml up -d
docker-compose -f service2/docker-compose.yml up -d

Basta escrever o nome do projeto no arquivo (-path) 😉

Desisto. É óbvio que a base de clientes para isso mudou.

Deixe-me saber o que há de errado com a proposta que fiz a você.

Tive as mesmas preocupações no início, mas ajustamos nossos fluxos de trabalho aos recursos disponíveis.

Não me lembro de matar acidentalmente uma pilha nos últimos 2 anos, por ninguém de nossa equipe. Estamos executando mais de 200 pilhas com cerca de 1.000 contêineres e 1.000 de reimplantações automáticas ou manuais dessa maneira.

Eu realmente não quero me envolver aqui ... mas não consigo resistir.

Há uma diferença muito importante entre uma "solução", dada a forma como as coisas estão agora, e a solução "certa", dadas as possibilidades existentes. O que esta questão deve ser focado em é encontrar a solução "certa", que, tanto quanto eu estou preocupado é bastante óbvio, embora alguns possam ainda discordam.

@ schmunk42 e @mikehaertl

Não me lembro de matar acidentalmente uma pilha nos últimos 2 anos, por ninguém de nossa equipe .

Eu tenho que perguntar. Vejo que vocês dois fazem parte da codemix org . Vocês são colegas de trabalho? Começando a se perguntar se nos bastidores vocês dois são ruins.

Atualmente é (classificado por prioridade):

1. o valor de -p
2. o valor de COMPOSE_PROJECT_NAME de seu ambiente
3. o valor de COMPOSE_PROJECT_NAME do seu arquivo .env
4. o nome do diretório atual

Para ser o advogado do diabo, por que adicionar um 5º a este cenário já confuso?

O problema, a meu ver, é _cada valor único_ que está atualmente disponível para uso é _específico do ambiente_. Não há como fornecer uma opção específica do projeto.

1 + 2. Deve ser fornecido manualmente pelo usuário que está chamando o comando.

1. _Pode_ ser compartilhado, mas na prática .env deve ser ignorado e não compartilhado por um bom motivo. (Eu resolvo isso compartilhando .env.example , mas isso ainda requer uma etapa manual extra.)
2. É efetivamente aleatório e específico do usuário / ambiente. (Eu também vejo isso como um fallback, porque componha _needs_ um nome de projeto. Não é nem mesmo um fallback muito bom, porque pode haver projetos em diferentes diretórios com o mesmo nome que entrariam em conflito.)

Na minha opinião, e em muitos dos que estão neste tópico, deve haver uma opção entre 3 e 4, onde um nome de projeto padrão _pode_ ser fornecido em qualquer arquivo docker-compose que está sendo usado para este projeto e é usado como o primeiro cair pra trás. Esse valor seria então compartilhado por qualquer pessoa que esteja implantando este projeto. As opções 1-3 anulariam esse valor e a opção 4 só seria usada se não fosse fornecida.

@benjaminwood , posso garantir que ninguém está rindo desse assunto. Sim, já nos conhecemos há bastante tempo e não é a primeira vez que discordamos fundamentalmente. Posso parecer chato para vários usuários aqui, mas não é minha intenção. Na verdade, gostaria de compartilhar minhas experiências e propor soluções. Acredito ter uma vasta experiência neste assunto. Se o recurso fosse introduzido conforme proposto, ele introduziria uma grande fonte de possíveis erros em nossa configuração.

@joshuajabbour

1. Pode ser compartilhado, mas na prática .env deve ser ignorado e não compartilhado por um bom motivo.

Isso depende da sua configuração, isso é ignorado em todos os nossos repositórios de projeto.
Mas não o ignoramos em nossos repositórios somente de pilha de teste e produção. Se você gostaria de compartilhar o nome confirmado em docker-compose.yml você também pode enviar .env (este arquivo é apenas para o comando docker-compose - nada mais)

1. É efetivamente aleatório e específico do usuário / ambiente.

Não é mais nem menos aleatório do que um valor em docker-compose.yml , você precisa ver a configuração da pilha como uma pasta, não um único arquivo. Se você fizer isso, você pode ter o nome em .env ou um nome de subpasta.

Tenho uma última alternativa para todos vocês:

docker stack deploy -c docker-compose.yml the-project-name

(*) Disponível apenas no modo enxame

Não consigo ver como um nome de projeto poderia ser colocado no arquivo yml no futuro, isso contradizia totalmente a ideia de uma definição de pilha.

Obrigado @ schmunk42. Eu acredito em você e acho que você lidou com as coisas muito bem entre todas as opiniões fortes exibidas neste tópico.

isso introduziria uma grande fonte de possíveis erros em nossa configuração.

Eis o problema. Encerre o problema.

Isso depende da sua configuração, isso é ignorado em todos os nossos repositórios de projeto. Mas não o ignoramos em nossos repositórios somente de pilha de teste e produção.

Portanto, esse recurso que todo mundo deseja não deve ser introduzido porque quebraria sua arquitetura de repositório incomum?

Se você compartilhar o nome confirmado em docker-compose.yml você também pode enviar .env (este arquivo é apenas para o comando docker-compose - nada mais).

Bem, se a única coisa em meu arquivo .env fosse COMPOSE_PROJECT_NAME , então sim. Mas é preenchido com muitas outras variáveis ​​_secure_ que não quero que sejam confirmadas. E eu os importo para o docker-compose usando a propriedade environment . É para isso que geralmente servem os arquivos .env ...

Eu ainda não entendo como isso iria quebrar sua configuração, já que na minha proposta, ele apenas substitui o nome do projeto padrão obtido do diretório. E se você estiver dependendo disso (porque é um diretório confirmado _no_ seu repo em oposição ao diretório em que seu repo foi clonado), então como ele poderia ser substituído pela configuração docker-compose.yml (porque isso também é confirmado ao seu repo; você controla as duas coisas em seu cenário)?

@ schmunk42 O que você diz é "Não quero novos recursos, porque de outra forma não entendo mais a configuração do meu projeto".

A sério? Este é o seu argumento: por que você quer que todos os outros que precisam disso fiquem sem?

Só para constar: também estou aqui. Sinta-se à vontade para encerrar o problema. A discussão aqui se tornou inútil.

Portanto, esse recurso que todo mundo deseja não deve ser introduzido porque quebraria sua arquitetura de repositório incomum?

Estou expressando minha preocupação de que isso possa introduzir fontes adicionais de erros.

Bem, se a única coisa em meu arquivo .env fosse COMPOSE_PROJECT_NAME, então sim. Mas é preenchido com muitas outras variáveis ​​seguras que eu não quero confirmadas. E eu os importo para docker-compose usando a propriedade de ambiente.

Use um secrets.env para eles e importe-o via env_file .
Como isso afetaria seu fluxo de trabalho?

É para isso que os arquivos .env geralmente servem ...

Verdade ... mas ainda acho que o problema é que docker-compose sequestra o arquivo .env .

Como seria se você pudesse definir essas variáveis mais aquelas usadas nos níveis superiores de docker-compose.yml , como IMAGE_VERSION , em um arquivo chamado docker-compose.env ?

Nunca ousei propor COMPOSE_COMMAND_ENV_FILENAME=.env - até agora :)

Eu ainda não entendo como isso iria quebrar sua configuração, ...

É verdade que não quebra imediatamente, mas é apenas sobre o meu primeiro ponto - e apresentando ainda mais opções.

Pense em usar vários arquivos -f docker-compose.A.yml -f docker-compose.B.yml , digamos que A seja o seu projeto e dependa do nome do projeto por diretório (fazemos isso, já que o controlamos!), Enquanto B é um conjunto de serviços extras com project_name: extra , acidentalmente introduzido durante o teste em uma pasta que tinha um arquivo .env que sobrescreveu o nome do projeto com COMPOSE_PROJECT_NAME=testing .

Mas agora qualquer projeto iniciado sem um arquivo .env seria denominado extra . 💥

Estamos mesclando arquivos em vários níveis, incluindo vários *.env arquivos, é um caso de uso muito válido.

A sério? Este é o seu argumento: por que você quer que todos os outros que precisam disso fiquem sem?

Aviso: ligeiramente fora do tópico, mas ainda relacionado ao docker ...

• "Eu não acho que realmente precisamos disso"
• "tem mais camadas do que o necessário. mais complexidade"

@mikehaertl Eu realmente me pergunto que você vê dessa forma;)

Ei pessoal,

Pegamos na discussão apaixonada neste tópico (obrigado àqueles de vocês que o mantiveram civil e cordial!) E, embora ainda acreditemos fundamentalmente que o nome do projeto não pertence a um arquivo Compose, descobrimos o que acreditamos ser um meio-termo razoável com o seguinte PR: # 5378. Dito isso, gostaríamos de receber seus comentários sobre isso para garantir que ele atenda às suas necessidades.

Aqui está a essência:

• Você pode adicionar uma entrada x-project-name dentro do seu arquivo de composição. Esta chave é ignorada por padrão.
• Quando COMPOSE_X_PROJECT_NAME é definido em seu ambiente (ou .env file), Compose tentará recuperar o nome do projeto da entrada x-project-name dentro de seu arquivo Compose.
• Esta opção tem uma prioridade menor do que COMPOSE_PROJECT_NAME e --project-name

Fico feliz em responder a quaisquer perguntas ou dúvidas sobre isso.

@ shin- Então COMPOSE_X_PROJECT_NAME teria que ser definido como 1 para ativar o recurso?

Nesse caso, COMPOSE_ENABLE_X_PROJECT_NAME também pode ser um nome para se pensar, mas esses são apenas meus 2 centavos - não vou usá-los de qualquer maneira 😄

@ schmunk42 Qualquer valor " true -y" funcionará , mas sim, essa é a ideia.

@matsaman Legal, obrigado pelo feedback útil e prático.

Em vez de nos dizer que teremos que dizer aos usuários finais para definir uma variável ou chamar um parâmetro, você está nos dizendo que teremos que dizer aos usuários finais para definir uma variável ou chamar um parâmetro.

Honestamente, e realmente não é por nada, não consigo imaginar como você considerou isso uma solução de alguma forma.

@ shin- vou explicar como essa mudança não faz nenhuma diferença útil:

Ter que definir uma variável de ambiente para permitir a procura pelo nome do projeto no arquivo de composição é aproximadamente o equivalente {quantidade de trabalho, risco de esquecimento e conveniência}, como definir uma variável de ambiente para o próprio nome do projeto.

O objetivo principal de definir o nome do projeto no arquivo de composição é evitar o uso de variáveis ​​de ambiente. Você pode usar a precedência para a variável de ambiente do nome do projeto para dar aos usuários a opção de substituir o nome do projeto no arquivo de composição.

Eu acho que é uma solução muito boa, já que não vai quebrar o BC e evitar a introdução de erros durante a fusão, como descrevi acima.

Ter que definir uma variável de ambiente para permitir a procura pelo nome do projeto no arquivo de composição é aproximadamente o equivalente {quantidade de trabalho, risco de esquecimento e conveniência}, como definir uma variável de ambiente para o próprio nome do projeto.

Não é, você pode fazer essa configuração uma vez, globalmente em seu ambiente - você não precisa fazer isso em todos os projetos.

Não é, você pode fazer essa configuração uma vez, globalmente em seu ambiente - você não precisa fazer isso em todos os projetos.

Estou assumindo que você quer dizer globalmente em todos os seus shells que você gera no seu computador. Se você fizer isso, poderá obter um comportamento indesejado em projetos completamente não relacionados. Também causará confusão quando um desenvolvedor puxar um projeto do controle de versão e se esquecer de definir a variável de ambiente.

Um dos objetivos mais importantes de ter o nome do projeto no arquivo de composição é garantir que todas as variáveis ​​relacionadas ao projeto de composição sejam armazenadas no controle de versão.

@nhooey @matsaman
Destina-se especificamente a ajudar pessoas que têm vários arquivos de composição no mesmo diretório, para quem a solução de arquivo .env não é uma opção. Se isso precisa estar sempre ativado para seus projetos, é fácil configurá-lo em seu arquivo .env , em seu .profile ou em qualquer outro lugar que garanta que x-project-name sempre será levado em consideração.

Em vez de nos dizer que teremos que dizer aos usuários finais para definir uma variável ou chamar um parâmetro, você está nos dizendo que teremos que dizer aos usuários finais para definir uma variável ou chamar um parâmetro.

Nossa principal preocupação com isso sempre foi que o "usuário final" tenha projetos próprios e queira evitar conflitos de nomes a todo custo. Nesse sentido, eles devem estar no controle do nome do projeto, não do distribuidor. Se você estiver enviando projetos "chave na mão" para os clientes, é igualmente trivial definir COMPOSE_X_PROJECT_NAME no arquivo .env associado - então, estou confuso sobre qual parte disso é uma preocupação para ser honesto.

Se você fizer isso, poderá obter um comportamento indesejado em projetos completamente não relacionados.

Você poderia dar um exemplo? Não consigo pensar em nenhum comportamento indesejado apenas definindo COMPOSE_X_PROJECT_NAME em meu shell.

Um dos objetivos mais importantes de ter o nome do projeto no arquivo de composição é garantir que todas as variáveis ​​relacionadas ao projeto de composição sejam armazenadas no controle de versão.

Por que você não pode usar .env para isso? Ninguém proíbe o armazenamento de .env no controle de versão (sim, não é comum).

Tínhamos .env no início. Você claramente perdeu toda a conversa.

@matsaman Você precisa seriamente

Para esclarecer um pouco da confusão

Você já poderia fazer isso

Anteriormente, você podia definir um nome de projeto usando uma variável de ambiente. A nova variável de ambiente não é um nome, é uma alternância que habilitou um recurso que permite definir um nome de projeto no arquivo de composição.

Estou assumindo que você quer dizer globalmente em todos os seus shells que você gera no seu computador. Se você fizer isso, poderá obter um comportamento indesejado em projetos completamente não relacionados.

Se você quer dizer "outros projetos" como em "algo que não é composto pode ler isso e quebrar" Eu acho que não é realista. Existem muitas variáveis ​​de ambiente definidas em cada shell. A variável de ambiente tem um namespace apropriado como "COMPOSE_X_".

Se você quer dizer "outros projetos compostos", então acho que está realmente argumentando por que essa variável é necessária. Se o recurso fosse habilitado por padrão, qualquer pessoa que dependesse do comportamento padrão atual quebraria.

Se não for nenhum desses, por favor, esclareça.

Também causará confusão quando um desenvolvedor puxar um projeto do controle de versão e se esquecer de definir a variável de ambiente.

Se um projeto só funciona com um nome de projeto específico, então acho que há outros problemas. Nunca deve haver um caso em que um projeto funcione apenas com um único nome.

Eu vejo isso como outro argumento para não colocar o nome do projeto no arquivo Compose. Se o nome do projeto estiver no arquivo de composição, dois projetos quaisquer poderiam usar o mesmo nome, causando um conflito, o que interromperia os dois projetos. O nome realmente deve ser definido pelo desenvolvedor, que está ciente de quais outros nomes de projeto já estão em uso.

Infelizmente, isso também não vai me ajudar pelos motivos que já mencionei há mais de um ano.

Uma solução que envolva variáveis ​​ambientais exigiria que os usuários, em primeiro lugar, precisassem saber como fazê-las. Eu sei que pode parecer difícil de acreditar, mas nem todo mundo trabalha dentro do terminal. Novamente, colocar um .env no repositório não é uma opção para mim.

A beleza de docker-compose é up . Não instruções sobre como configurar essa chamada.

@fiveanddone

Novamente, colocar um .env no repositório não é uma opção para mim.

Você pode expandir isso? Eu ouvi totalmente você sobre usuários com menos conhecimento técnico, mas se eles não foram feitos para interagir com o código ou ambiente, por que é um problema incluir um arquivo .env com o projeto?

@ shin- Sim, sem problemas.

Em alguns casos, incluí esse arquivo no repositório, mas ele não funciona o tempo todo. Meus casos de uso envolvem principalmente desenvolvimento web, onde o conhecimento técnico do desenvolvedor pode variar muito.

Os parâmetros de .env houses que são usados ​​em outras estruturas. Algumas das variáveis ​​dentro de meu .env são credenciais para serviços externos como SMTP. A maioria dos desenvolvedores de minha equipe aponta esses serviços para seus próprios endpoints usando seu próprio arquivo .env . Se .env não estiver lá, eu tenho os padrões.

Para desenvolvedores menos técnicos que talvez queiram apenas alterar algum CSS, o aplicativo funciona bem sem o arquivo .env . Isso presumindo que eles não tenham o mesmo nome em todas as pastas do projeto. :)

Pode não parecer muito, mas quando você está trabalhando com vários desenvolvedores e designers que abrangem o país - quanto mais simples, melhor.

Docker tornou minha vida muito mais fácil e estou muito grato por este projeto, mas posso me relacionar com as frustrações em torno deste tópico.

@fiveanddone Obrigado pelo insight! Portanto, se o arquivo .env fosse chamado de docker-compose.env (ou semelhante), isso aliviaria suas preocupações?

@canela-

Sim, seria para meus casos de uso.

O arquivo env é carregado automaticamente pelo Docker Compose?

Se não, docker-compose.env poderia ser carregado automaticamente?

@nhooey O arquivo env é carregado automaticamente se for denominado .env . E você também pode especificar o arquivo env para cada serviço individualmente. Veja a documentação .

O arquivo env é carregado automaticamente se for nomeado .env. E você também pode especificar o arquivo env para cada serviço individualmente. Veja a documentação.

Não quero ser o detalhista aqui, mas isso não é realmente correto. E IMHO a maior fonte de mal-entendido de todo o tópico.

Nenhuma das variáveis ​​de .env é passada para um contêiner / serviço, se você não o encaminhar explicitamente , usando qualquer um

env_file: 
  - .env

ou

environment:
  - VAR_FROM_DOTENV
  - FOO=${ANOTHER_VAR_FROM_DOTENV}

O arquivo .env é carregado automaticamente, sim, mas sem configuração adicional, ele se aplica apenas a essas variáveis ​​de ambiente do Compose CLI .

Eu apoiaria fortemente renomear isso para docker-compose.env por padrão e ainda melhor - uma variável para isso , então isso poderia ser usado em um modo BC com apenas a configuração de um ENV-var.

(obrigado a vocês que o mantiveram civil e cordial!)

Eu ouço você e certamente sou culpado de nem sempre manter minha compostura. Desculpe por isso. Alguns comentários às vezes realmente me ajudam a começar ... funcionará nisso.

Se o nome do projeto estiver no arquivo de composição, dois projetos quaisquer poderiam usar o mesmo nome, causando um conflito, o que interromperia os dois projetos.

Nossa principal preocupação com isso sempre foi que o "usuário final" tenha projetos próprios e queira evitar conflitos de nomes a todo custo. Nesse sentido, eles devem estar no controle do nome do projeto, não do distribuidor.

@ shin- Isso soa como é comumente aceito, que docker-compose.yml sempre faz parte de um projeto e reside no repositório do projeto. Eu diria que isso não é necessariamente verdade. Alguns de nós não compartilham docker-compose.yml mas querem manter sua versão local com personalizações locais (por exemplo, configurações de desenvolvimento, testes, etc.).

E sobre "evitar conflitos de nome": Em vez de um conflito de nome com o nome do projeto, agora temos um conflito de nome (IMO) mais crítico no nível do sistema de arquivos: .env é um nome comum que os projetos usam para definir seus configurações específicas do aplicativo. Ele não deve ser poluído com as configurações do docker, a menos que um desenvolvedor realmente queira fazer isso. Mas essa decisão deve ser deixada para o desenvolvedor.

Aqui está uma sugestão: Que tal adicionar duas outras opções para o nome do projeto e descontinuar o uso de .env na V4 de docker-compose.yml ? Um é project_name em docker-compose.yml , outro é um arquivo .dockerproject que contém apenas o nome e nunca deve ser enviado a um repositório. Deve ser um arquivo local.

Aqui está minha sugestão de precedência (mais alta primeiro):

• -p argumento CLI
• .dockerproject arquivo
• project_name em docker-compose.yml (deve ser evitado, se docker-compose.yml for distribuído com o projeto)
• COMPOSE_PROJECT_NAME do meio ambiente
• COMPOSE_PROJECT_NAME de .env (obsoleto)
• nome do diretório

Dessa forma, os usuários finais ainda podem substituir o nome de um projeto em .dockerproject mesmo se alguém o codificou em um docker-compose.yml distribuído.

ATUALIZAÇÃO: Eu também poderia viver usando .dockerenv ou docker.env vez de .dockerproject . Mas deve ter precedência mais alta para resolver o problema, pois alguns aqui precisam substituir nomes de projetos codificados permanentemente em docker-compose.yml .

Olá a todos,

Em primeiro lugar, obrigado @dnephin e @ shin- por olhar este caso. A alteração enviada por @ shin- parece ser um grande passo para resolver esse problema.

Eu validei o PR 5378 no projeto de teste para o seguinte caso de uso: A default project name defined by the project, that can be checked in (https://github.com/docker/compose/issues/745#issuecomment-282858900). Para isso fiz um repo git ilustrando diferentes possibilidades: https://github.com/estarter/compose_745

Descobri que o PR # 5378 cobre parcialmente o caso de uso. O problema é que a solução requer a variável COMPOSE_X_PROJECT_NAME env. Soluções possíveis:

1. persista a variável env na pasta do projeto. Tentei .env file, mas não funciona quando docker-compose é chamado de outro local (veja o exemplo de comandos , arquivos de composição )
2. definir COMPOSE_X_PROJECT_NAME globalmente (.profile ou equivalente). Isso funcionaria, mas não pode ser especificado no projeto, ou seja, não é uma solução para nosso caso de uso defined by the project, that can be checked in
3. existe outra opção?

Espero ter conseguido ilustrar o caso de uso que é abordado aqui.

Caros mantenedores, por favor, considerem como o caso de uso é resolvido por PR # 5369 que introduz a propriedade project_name opcional no arquivo docker-compose. Esta propriedade tem baixa prioridade, mas não depende do ambiente ou diretório de trabalho.

1. existe outra opção?

Existe esta opção docker-compose --project-directory <PATH> (Especifique um diretório de trabalho alternativo). Também deve funcionar com um arquivo .env .

Para adicionar outro caso de uso diferenciado à mistura:
No meu caso de uso, tenho dois repositórios, um para o projeto principal (usado para construir / implantar) e um para devops (contendo o Dockerfile, docker-compose.yml, etc.)
Em nossa configuração atual, o repositório principal do projeto está na raiz ./ e o repo devops é verificado em um subdiretório ./devops/

Nesta configuração, usar um arquivo .env não funciona porque deve ser:

colocado na pasta onde o comando docker-compose é executado (diretório de trabalho atual).
(ref doc)

O que não funciona, pois é chamado como: docker-compose -f devops/docker-compose.yml
Claro, podemos adicionar o parâmetro -p aqui, que é o que estamos usando atualmente, mas está sujeito a erro humano, conforme mencionado acima.

Se o arquivo .env (ou docker-compose.env proposto) pudesse ser lido do mesmo diretório em que o docker-compose.yml reside, definir o nome do projeto funcionaria para mim.

Usar a diretiva env_file dentro do docker-compose.yml não funciona, porque esses env vars são aplicados apenas dentro do contêiner, não para a criação dos contêineres.

Em última análise, meu objetivo é manter meus arquivos relacionados ao devops autocontidos de uma forma que não polua minha base de código de projeto real, mas ainda possa ser acessado / executado em paralelo com esse repo.

Existe esta opção docker-compose --project-directory(Especifique um diretório de trabalho alternativo). Também deve funcionar com um arquivo .env.

@ schmunk42 pode ser um bom tiro, mas --project-directory não funciona para arquivos .env. Tentei o seguinte, o arquivo .env foi ignorado ( arquivos de projeto ):

docker-compose -f PR_5378/docker-compose.yml -f PR_5378/docker-compose2.yml --project-directory PR_5378 down

Daqui para frente, excluirei comentários que não contribuem para a conversa de forma construtiva. Não tenho interesse em interagir com crianças.

Sobre ter um nome .env definível
O problema de ter uma variável de ambiente designando qual arquivo .env usar é que é essencialmente uma dependência circular. Teríamos que introduzir uma exceção na maneira como as variáveis ​​de ambiente são interpretadas, o que, embora sensato, é inerentemente contra-intuitivo.

No próprio .env name
É óbvio agora que o nome .env é usado por uma infinidade de softwares e estruturas, e geralmente não deve ser comprometido no controle de versão. Somos muito sensíveis a fazer alterações significativas, mas podemos introduzir um nome alternativo (por exemplo, docker-compose.env ) com um substituto para o arquivo .env se o anterior não existir, com a intenção de que pode ser compartilhado com outros usuários.

Ao adicionar project_name ao arquivo de composição
Já reiteramos nossa posição sobre isso várias vezes - veja o último comentário de Daniel para algumas das razões pelas quais nos opomos a fazer essa mudança. Não é que seja difícil. Não é que não tenhamos pensado nisso. Passamos muito tempo avaliando-o e sentimos que a qualidade do projeto seria muito prejudicada como resultado para justificar sua adição (neste formulário). Falando realisticamente, # 5378 é provavelmente a melhor concessão que podemos fazer para que isso funcione de uma forma que seja opcional e compatível com versões anteriores (EDITAR: Claro, estou aberto a sugestões que melhorem essa proposta dentro desses parâmetros)

Em --project-directory
Um pouco tangente, mas estou ciente de que essa opção está um pouco quebrada agora. Em retrospecto, eu teria preferido nem mesmo adicioná-lo, porque cria mais problemas do que resolve. Vou tentar gastar algum tempo para ver se é consertável, mas tem muitos casos extremos estranhos que o tornam realmente não confiável.

Com tudo isso dito, há alguém para quem docker-compose.env + # 5378 não seria uma solução satisfatória? Eu entendo que pode não ser sua solução favorita, mas estou perguntando se ela está fazendo concessões razoáveis ​​com as quais você pode lidar.

Brincadeiras à parte ...

Ainda não entendo como o último comentário de Daniel se relaciona com a "qualidade do projeto". Além disso, é uma regra geral que adicionar uma chave a um dicionário nunca deve causar quebra de compatibilidade com versões anteriores. Sempre há casos em que os programadores implementaram coisas de uma maneira que não é o caso, mas estou divagando.

Acho que o campo que quer o campo project-name (ou qualquer outro) se justifica, pois o "nome" do projeto é fundamental para muitos aspectos do ferramental. As pessoas neste campo podem querer simplesmente escrever esse nome em algum lugar na pedra para evitar problemas com soluções mais temporárias, como variáveis ​​de ambiente ou comandos como sinalizadores.

Espero que tenha sido construtivo.

@estarter Eu consideraria isso um bug, talvez valha a pena abrir uma edição separada para ele

Na verdade, eu esperaria que isso funcionasse com o arquivo .env no diretório PR_5378 :

docker-compose --project-directory PR_5378 -f docker-compose.yml -f docker-compose2.yml down

Ao adicionar project_name ao arquivo Compose

@ shin- Parece que a decisão já foi tomada. Mas ainda tento entender o pano de fundo. Eu já perguntei isso antes e nunca obtive uma resposta (que é uma das razões pelas quais a discussão foi tão irritante para mim).

Você poderia me ajudar a entender por que temos container_name e até network em docker-compose.yml ? O primeiro pode ser fonte de conflitos potenciais também. E o último é altamente específico do host. Seguindo sua lógica, esses dois (e outros) também não deveriam estar presentes. Não consigo ver a diferença para project_name .

Por favor, não ignore esta pergunta novamente.

@ michael-k Você está dizendo que project_name é igual a container_name ? Se você está dizendo isso, gostaria de informar que um projeto pode consistir em vários containers. Ou eu não entendi você?

Enquanto para network , não é necessariamente específico do host. Existem muitos casos em que um projeto requer uma rede central isolada na qual um contêiner interage com outra rede. E suas configurações são armazenadas em docker-compose.yml .

@AyushyaChitransh Você entendeu mal. A questão é: Por que container_name , network e outros em docker-compose.yml enquanto project_name não deveriam estar lá? Todos eles compartilham o mesmo potencial de conflito ou configuração específica de host que não deve ser compartilhada.

@aanand eu conheço esta oportunidade. Além disso, o mesmo poderia ser dito sobre os nomes dos contêineres, mas temos a oportunidade de definir o nome do contêiner no arquivo de composição, certo?

Sim, mas não acho que adicionar isso foi uma boa ideia.

Da discussão relacionada Especifique o nome da rede no arquivo docker-compose .

@estarter Eu consideraria isso um bug, talvez valha a pena abrir uma edição separada para ele

@ schmunk42 vejo que os mantenedores estão cientes disso - veja On --project-directory no comentário de Joffrey mais # 4709, # 4933 e # 4841

Na verdade, eu esperava que isso funcionasse com o arquivo .env no diretório PR_5378:
docker-compose --project-directory PR_5378 -f docker-compose.yml -f docker-compose2.yml down

Você presumiu que --project-directory afeta o parâmetro -f .
Na verdade não é o caso, este comando dá IOError: [Errno 2] No such file or directory: u'./docker-compose.yml'

É muito bom que --project-directory não esteja afetando -f - caso contrário, imagine como seria um pesadelo usar --project-directory e vários arquivos docker-compose, todos em diretórios diferentes.

Estou muito surpreso ao ver tanta deliberação sobre algo que vejo como um problema resolvido.

Esta é a ordem de precedência que estou acostumada a ver:

1. codificado
2. opção cli
3. meio Ambiente
4. project.rc
5. padrão são

Para project_name , atualmente não temos a opção # 1 ou a opção # 4. Este é o problema fundamental que as pessoas enfrentam e parece fácil de resolver de uma forma compatível com as versões anteriores.

Parece que estamos tendo argumentos filosóficos sobre pureza que podem não ser úteis. Por outro lado, usar um esquema de configuração em cascata de OSS muito comum é muito útil.

Parece que estamos tendo argumentos filosóficos sobre pureza que podem não ser úteis.

Ter esse argumento realmente não é o objetivo. Desde o início , temos sido muito claros sobre nossa posição em relação à definição do nome do projeto no arquivo Compose.

Mas deixe-me ser transparente sobre isso. Isso nunca acontecerá em docker-compose . Se esse for o único caminho de resolução que você está disposto a aceitar para esse problema, terá que seguir o próprio processo de OSS de bifurcar o projeto e fazer você mesmo. O código está disponível e compartilhado com uma licença muito permissiva.

Você poderia me ajudar a entender porque temos container_name e até mesmo rede em docker-compose.yml? O primeiro pode ser fonte de conflitos potenciais também. E o último é altamente específico do host. Seguindo sua lógica, esses dois (e outros) também não deveriam estar presentes. Não consigo ver a diferença para project_name.

Para container_name , essa opção foi introduzida bem no início do ciclo de vida do projeto. Como @ schmunk42 apontou, se fôssemos fazer tudo de novo, isso definitivamente não estaria nas especificações. É constantemente mal utilizado e tem sido a fonte de inúmeros problemas para os usuários ao longo dos anos.
Quanto a network , não tenho certeza de como ele se compara em sua mente?

E a opção nº 4 que mencionei? Vi uma conversa sobre a introdução de .docker-compose para configurações específicas do diretório local. Isso seria muito preferível (imo) a introduzir os sinalizadores de ambiente _x_ (que ainda requerem gerenciamento de ambiente).

Seria assim:

# <my-project-dir>/.docker-compose
project_name: foobar

O acima é diferente da opção de variável de ambiente e inferior na lista de precedência.

Isso resolve meu caso de uso muito bem e marca outro caminho de configuração padrão da lista.

@thedeeno Em nossa mente, COMPOSE_PROJECT_NAME dentro do arquivo .env já faz isso (com a mesma ordem de prioridade que teria em seu esboço). No entanto, ouvimos que .env é uma escolha ruim de nome, e é por isso que consideramos docker-compose.env como alternativa. Isso funcionaria para você?

Em nossa mente, COMPOSE_PROJECT_NAME dentro do arquivo .env já faz isso

@ shin- é aqui que discordamos. Eu acho que não.

Pessoalmente, adoro o fato de termos obtido o arquivo .env . Este é um lugar muito convencional para colocar segredos locais e outras configurações específicas de hardware local.

Isso funciona muito bem para ajudar com number 3 acima, configuração baseada em ambiente.

Não nos dá uma saída de emergência ( number 4 ) para quando não queremos que o ambiente seja o proprietário do nome do projeto.

No meu caso, cada um de nossos desenvolvedores terá seu próprio arquivo .env (não VC). Ele contém segredos para injeção em docker-compose.yaml . Amo isso.

Não queremos que os desenvolvedores tenham controle sobre o nome do projeto, no entanto, já que ele está fortemente acoplado a algumas ferramentas. Como .env não está no controle de versão, temos que fazer com que nossos desenvolvedores definam manualmente COMPOSE_PROJECT_NAME com esta abordagem; e é a _uma coisa_ diferente das outras, porque não é segredo.

Então, infelizmente não, simplesmente alterar o caminho de origem padrão de .env não nos ajudaria aqui. Na verdade, adoramos que .env seja obtido automaticamente. Só não queremos especificar o nome do projeto dessa forma.

vou mostrar um caso de uso da minha prática:

estou usando o arquivo .env para especificar a versão da imagem e para evitar a análise estranha do sed / awk / perl / qualquer que seja, apenas sobrescrevo o valor em CI:

    echo APP_VERSION=$CI_COMMIT_REF_NAME > .env
    docker-compose pull
    docker-compose up -d

posteriormente em docker-compose.yml , a imagem é especificada como:

    image: my.registry.example.net/app:${APP_VERSION}

agora, se eu precisar de mais variáveis ​​desse tipo, preciso fazer uma análise, a menos que vários arquivos .env sejam suportados.

então, talvez também adicione suporte a "diretório", como: docker-compose.env.d/* ou .docker-compose.env.d/* ou docker-compose.d/* .

mas, como tal, o glob pode instantaneamente criar problemas de correspondência de backups do editor ( *~ , *.bak ), é melhor usar alguma extensão: docker-compose.env.d/*.sh

... mas então, talvez apenas torne-o configurável em docker-compose.yml quais arquivos de nível raiz .env são carregados ou isso introduziria o problema do ovo de galinha? não sei como funciona o analisador de configuração :)

um pouco offtopic, mas COMPOSE_PROJECT_NAME env não permite o controle total do prefixo, ele ainda seria reduzido para corresponder a A-Za-z0-9_ ... eu queria usar - no meu prefixo. (não consigo encontrar onde relatei isso agora, mas afaik não foi abordado)

seria lógico permitir os mesmos caracteres aos quais o docker se limita.

@glensc É muita infraestrutura para gerenciar o ambiente. Eu pessoalmente não acho que isso seja responsabilidade de docker-compose .

A única coisa que vi outros projetos fazerem foi a fonte .env automaticamente

@glensc @thedeeno Então, idealmente, teríamos dois arquivos *.env , um destinado a ser compartilhado com outros usuários e outro privado, com o último substituindo o anterior quando ambos definem a mesma var?

Abordei .env nomes configuráveis ​​em meu comentário da semana passada.

Ter um docker-compose.env (embora ainda seja uma fonte automática privada .env ) funcionaria muito bem para nós!

Nós o trataríamos como um arquivo rc e o submeteríamos ao controle de origem.

Acho que ter arquivos env públicos / privados provavelmente resolve a maioria dos casos de uso observados aqui. se - também fosse permitido no nome do projeto, seria ótimo.

@thedeeno @glensc Você poderia dar um caso de uso onde você precisa de um arquivo ENV privado substituindo os valores no público?

Os segredos não devem ser definidos em docker-compose.env , pois eles não serão encaminhados automaticamente para os contêineres. Você ainda pode usar um arquivo .env e fazer o que quiser com ele. Mas parece confuso para mim misturar configurações para docker-compose e contêineres na pilha.

@ schmunk42 Não tenho esse caso de uso, então não ajudarei muito. Eu só preciso comprometer project_name para o controle de versão. docker-compose.env resolve isso.

Não tenho certeza se estou seguindo seu segundo parágrafo. Usamos .env para segredos e os injetamos manualmente em docker-compose.yaml .

@ schmunk42 https://github.com/docker/compose/issues/745#issuecomment -346491062

é apenas porque SÓ o lugar para definir ${variables} para image valor parece ser .env arquivo.

@glensc Concordo!

Mas, em vez disso, eu proporia docker-compose.override.env para alinhá-lo com o recurso de substituição atual para yml arquivos.

docker-compose.env
docker-compose.override.env
docker-compose.override.yml
docker-compose.yml

Não tenho certeza se estou seguindo seu segundo parágrafo. Usamos .env para segredos e os injetamos manualmente em docker-compose.yaml.

@thedeeno Presumo que você esteja fazendo isso:

environment:
  - ${SECRET_VAR_FROM_DOTENV}

o que também deve ser possível com docker-compose.override.env . Ou você pode fazer:

env_file:
  - .env

Você está sugerindo descartar .env em favor de um docker-compose específico
caminho?

Se pularmos a fonte automática de .env, isso terá um impacto negativo sobre o meu
fluxo de trabalho da equipe. Contamos com este arquivo para outras ferramentas. Nós acabaríamos
dividir nossos segredos em dois (.env e este outro arquivo que você está sugerindo)
lugares se docker-compose parar de olhar para .env.

Na quinta-feira, 23 de novembro de 2017 às 01h15 Tobias Munk [email protected]
escrevi:

@glensc https://github.com/glensc Aceito !

Mas, em vez disso, eu proporia docker-compose.override.env para alinhá-lo com
o recurso de substituição atual para arquivos yml.

docker-compose.env
docker-compose.override.env
docker-compose.override.yml
docker-compose.yml

Não tenho certeza se estou seguindo seu segundo parágrafo. Usamos .env para segredos e
injete-os manualmente em docker-compose.yaml.

@thedeeno https://github.com/thedeeno Presumo que você esteja fazendo isso:

meio Ambiente:

• $ {SECRET_VAR_FROM_DOTENV}

que também deve ser possível com docker-compose.override.env. Ou você
poderia fazer:

env_file:

• .env

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/docker/compose/issues/745#issuecomment-346538315 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAFIdxtbI7y3wW2TFa401Go6Msj0gC74ks5s5Q1vgaJpZM4DLBNs
.

Você está sugerindo descartar .env em favor de um docker-compose específico
caminho?

Não necessariamente, para BC docker-compose ainda poderia olhar para .env se os outros não forem encontrados, o mesmo que com fig.yml uma vez. Embora possa ser complicado decidir os seguintes casos:

.env
docker-compose.env

.env
docker-compose.override.env

.env
docker-compose.env
docker-compose.override.env

.env não seria usado no último caso, mas estou indeciso sobre como lidar com os dois primeiros, já que alguns usuários usariam .env como uma substituição, outros como um substituto.

Para mim, .env deve ser usado em todos os casos. É um arquivo com significado especial
no ecossistema mais amplo.

Em seus terceiros casos, é apenas o arquivo com a precedência mais baixa.

Tudo que eu preciso é uma maneira de comprometer o nome do meu projeto para o controle de origem. Eu não
se preocupam particularmente com um ambiente em cascata mais sofisticado
gestão. Na verdade, eu preferia que essa estratégia de nome de projeto não tivesse nada a
fazer com as variáveis ​​de ambiente.

Se um arquivo de configuração está fora da mesa e há uma maneira de comprometer meu
project_name com essa cascata de env que você está tomando, vou usá-la com prazer
Apesar!

Na quinta-feira, 23 de novembro de 2017 às 01h31 Tobias Munk [email protected]
escrevi:

Você está sugerindo descartar .env em favor de um docker-compose específico
caminho?

Não necessariamente, para BC docker-compose ainda poderia olhar para .env se o
outros não são encontrados, o mesmo que com fig.yml uma vez. Embora possa ser
complicado decidir os seguintes casos:

.env
docker-compose.env

.env
docker-compose.override.env

.env
docker-compose.env
docker-compose.override.env

.env não seria usado no último caso, mas estou indeciso sobre como lidar
aos dois primeiros, já que alguns usuários usariam .env como uma substituição, outros como um
cair pra trás.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/docker/compose/issues/745#issuecomment-346539891 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAFId95kZQIsiWp488JyPQOtGJju0OPbks5s5RFbgaJpZM4DLBNs
.

Quanto à rede, não tenho certeza de como ela se compara em sua mente.

@canela-

services:
    web:
        build: ./
        networks:
            - my_project_network_on_my_localhost
networks:
    my_project_network_on_my_localhost:
        external: true

Acho que estou fazendo errado, porque nunca comprometo meu docker-compose.yml no meu repo. Ele sempre contém configurações altamente específicas do host. Ele pode ter conteúdos bastante diferentes no desenvolvimento e na produção.

Eu sou um fã de "4 project.rc", embora provavelmente usaria algo como docker-project.yaml vez de um formato diferente. Isso é exatamente o que o problema original descreve. No que me diz respeito, qualquer discussão sobre colocar o nome do projeto no arquivo de composição deve estar em uma edição separada.

Tudo que eu preciso é uma maneira de comprometer o nome do meu projeto para o controle de origem.

Este ainda é um ponto que não entendo. Não deve haver razão para exigir um único nome de projeto codificado permanentemente. Se houver ferramentas externas que esperam um nome consistente, por que essas ferramentas não definem um nome de projeto antes de chamar docker-compose ?

my_project_network_on_my_localhost parece errado para mim. Por que você precisa do nome do projeto em uma rede externa? Não é necessário corresponder ao nome do projeto de composição.

my_project_network_on_my_localhost parece errado para mim.

Este foi apenas um exemplo. Tenho uma configuração de rede diferente em minha máquina de desenvolvimento local e em um servidor de produção. Muitas outras configurações em meu docker-compose.yml também diferem regularmente da produção, por exemplo, tenho contêineres de utilitários definidos lá para construir coisas específicas do projeto ou manter banco de dados ou o que for.

Pelo que entendi, inicialmente a ideia principal por trás de docker-compose (ou melhor, fig ) era organizar bem todas aquelas longas docker opções de linha de comando para uma configuração de contêiner complexa em um arquivo yaml simples. É por isso que parece tão estranho, que há uma única opção deixada de fora. Mas parece que de alguma forma não percebi que essa não é mais a ideia principal por trás disso.

Muitas outras configurações em meu docker-compose.yml também diferem regularmente da produção, por exemplo, eu tenho contêineres de utilitários definidos lá para construir coisas específicas do projeto ou manter banco de dados ou qualquer outra coisa.

Temos o mesmo fluxo de trabalho aqui. Em nosso caso, a definição docker-compose "comum" se resume a quase nada , mas essas são as únicas coisas que são realmente compartilhadas entre desenvolvimento, teste, teste e produção.
As partes principais das configurações de desenvolvimento são definidas em um arquivo separado, a fusão automática é feita por meio de um arquivo .env . É o mesmo para a configuração de teste .

Por estar em uma pasta em nosso caso, podemos fazer algo como

(cd tests && docker-compose up -d)
(cd tests && docker-compose ps)
(cd tests && docker-compose run php codecept run)

para testar ... ou isso

(cd production && docker-compose logs -f --tail 100)

para produção (Bônus: você poderia definir DOCKER_HOST na produção para apontar para outra máquina, mas apenas com docker-compose ).

Mas sim, é uma pasta, não um arquivo - e requer cp .env-dist .env em dois lugares para funcionar, caso contrário, ele falha com um arquivo de composição inválido. Na verdade, eu só queria compartilhar esse fluxo de trabalho bacana da IMHO.

Este ainda é um ponto que não entendo. Não deve haver razão para exigir um único nome de projeto codificado permanentemente. Se houver ferramentas externas que esperam um nome consistente, por que essas ferramentas não definem um nome de projeto antes de chamar docker-compose?

@dnephin Existem razões.

Sim, existem soluções alternativas. O pedido é torná-lo mais conveniente e previsível.

Aqui está um exemplo em que um nome de projeto embutido em código ajuda: os padrões de configuração do docker de traefik para a criação de regras de host para contêineres no seguinte formato: <service>.<project>.<domain> . Essa formatação não é fácil de mudar. É muito benéfico para nossos desenvolvedores usar os mesmos fqdns para nossos serviços docker-compose. Seria ótimo se pudéssemos usar a configuração de configuração zero, já que a única maneira de garantir a consistência é: a) forçá-los a usar um nome de diretório específico para seu clone b) especificar manualmente as regras para traefik. Ambos são péssimos.

Aqui está outra: fazer referência a imagens criadas com docker-compose. Se não podemos garantir o nome do projeto, não podemos garantir esses nomes de imagem e não podemos referenciá-los com confiança. Claro, podemos codificar o image_name para cada definição, mas francamente parece redundante porque _queremos usar a convenção_, mas estamos apenas preocupados que os desenvolvedores que escolherem usar nomes de arquivo diferentes tenham falhas muito surpreendentes em nossas ferramentas.

Pessoal, tantas discussões ... qual é o status disso, posso definir o nome do projeto padrão no meu arquivo .docker-compose ?
Ou ainda precisa de mais discussões neste tópico?

Armazenar o nome do projeto no arquivo docker-compose.yml faz muito sentido quando usado com outras ferramentas, por exemplo, PyCharm.

Seria ótimo armazená-lo no mesmo arquivo YAML, mas possivelmente substituí-lo, se necessário.

Acho que o cerne desse problema vem do fato de que o nome do projeto padrão é simplesmente (devo dizer _naively_?) Tomado como o nome base do diretório atual. Isso está compactando efetivamente o espaço de nomes do sistema de arquivos (hierárquico) em um plano, o que é problemático devido aos conflitos de nomes. Por exemplo, isso causa problemas para pessoas que executam serviços em ~/fooproject/master e ~/barproject/master .

Eu realmente acho que os nomes dos projetos não são importantes. Portanto, talvez uma maneira de tornar docker-compose robusto seja gerar nomes de projetos com base no caminho completo (ou seja, home_flaviovs_fooproject_master )?

Gosto da ideia persistente, no entanto. Ser capaz de comprometer o nome do projeto no Git é um caso de uso comum. Talvez ler um arquivo .env.default antes de .env seja uma solução simples para isso (que BTW cuidaria do antigo # 210 também)?

Resolvi isso envolvendo o binário docker-compose com minha própria função para poder chamar a função de qualquer lugar. Isso carrega o arquivo .env e usa o arquivo docker-compose certo em qualquer lugar.

Obviamente, você pode estender isso para ter uma função por projeto ou algo assim. Acho que pode haver desvantagens, mas não as descobri.

DEFAULT_DOCKER_COMPOSE=~/my-project

function dcompose() {
    pushd $DEFAULT_DOCKER_COMPOSE &> /dev/null;
    /usr/local/bin/docker-compose $@;
    popd &> /dev/null;
}
## maintain auto complete
function _dc {
    pushd $DEFAULT_DOCKER_COMPOSE &> /dev/null;
    _docker_compose;
    popd &> /dev/null;
}

complete -F _dc dcompose

Eu tenho um problema com a colisão de imagens, e parece muito estranho que eu não possa definir project_name no docker-compose.yml, pois parece uma solução muito lógica e direta. Na verdade, tirar o nome da pasta do projeto em primeiro lugar foi uma má ideia. Em muitos casos, as pastas de projetos podem ser como / home / project1 / repository, / home / project2 / repository e assim por diante; neste caso, docker gerou os mesmos nomes de imagens como repository_app.

@vedmant Você pode definir o nome da imagem em docker-compose.yml , basta usar image e build .

Então ... Que tal separar por projetos na pasta com o mesmo nome agora?

docker-compose -f /foo/bar up -d
docker-compose -f /foo/foo/foo/bar down

Talvez isso já tenha sido proposto. mas por que não fazer uma alteração significativa em version: 4 e adicionar alguma nova palavra-chave para permitir a definição do nome do projeto de docker-compose.yml ?

meu .docker-compose / project-name não funcionou ...
--project-name funcionou

Eu gostaria de definir o nome do projeto no docker-compose.yml também.

Meu caso de uso é, eu tenho um arquivo docker-compose.yml que tem um aplicativo da web e um serviço de banco de dados postgress.
Também quero arquivos docker-compose.yml separados para tarefas ad hoc - basicamente descrevendo tarefas ad hoc que gostaria de orquestrar com docker-compose. Essas tarefas ad hoc precisam aproveitar os mesmos serviços / redes / volumes usados ​​no projeto principal.

Um exemplo de tarefa adhoc que eu gostaria de orquestrar com docker-compose pode ser. migrando dados para o banco de dados postgress . É útil orquestrar isso com docker-compose porque a tarefa pode envolver a rotação de serviços e volumes adicionais, redes, etc., junto com os atuais, a fim de cumprir essa tarefa.

Portanto, para conseguir isso, posso criar um arquivo docker-compose.adhoctask.yml separado para representar a tarefa, para que eu possa executar essa tarefa sob demanda somente quando necessário. Por estar no mesmo diretório que o arquivo docker-compose original, ele obtém o mesmo nome de projeto por padrão e, portanto, tem acesso às mesmas redes, volumes, etc.? e outras coisas funcionam.

No entanto, o problema surge quando não quero que esse arquivo yml de tarefa ad hoc fique no mesmo diretório de nível superior (ou mesmo no mesmo repo) que o docker-compose.yml . Por exemplo, talvez eu queira colocar a tarefa ad hoc docker-compose.adhoc.yml em uma subpasta, com DOCKERFILE e ativos de que a tarefa precisa ser bem isolada / agrupada como seu próprio interesse. Assim que o movo para uma subpasta, o nome do projeto não corresponde mais. Isso significa que ele não tem mais acesso aos mesmos volumes / redes etc. definidos no projeto principal.

Se eu pudesse especificar projectname em docker-compose.yml e docker-compose.adhoc.yml - então eu poderia estruturá-los como eu quiser (até mesmo colocá-los em repositórios separados) e ainda executá-los sem ter que especificar constantemente argumentos de linha de comando adicionais ou alternar as variáveis ​​de ambiente.

Este é um problema real para mim, porque causa conflitos de nomenclatura

Tenho vários projetos na estrutura

/company
    /ab   # project prefix
        /backend   # actual project
        /webapp
    /cd
        /backend
        /webapp

agora, quando eu inicio um docker-compose em um projeto, ele cria a rede backend_default e os contêineres que não são explicitamente nomeados com backend_ .. agora Se eu quiser iniciar o outro projeto, para voltar à pasta certa e primeiro executar docker-compose down para evitar conflitos - caso contrário, ele iniciaria novos contêineres na mesma rede e, ao desligá-los, reclamaria sobre orhans, quando não houver nenhum.

Também é um problema para mim. Tenho vários projetos e uso docker-compose para suportes de demonstração dinâmicos em uma única máquina, um suporte por filial.

/project-1
    /dev # docker-compose.yml inside
    /master # docker-compose.yml inside
    /feature
        /new-feature # docker-compose.yml inside
/project-2
    /dev # docker-compose.yml inside
    /master # docker-compose.yml inside

Portanto, "masters" e "devs" são conflitantes entre os projetos. Um arquivo .docker-compose poderia resolver isso.

@simplesmiler Correndo o risco de me repetir, um .env já resolve isso.

@ shin- .env é freqüentemente usado para segredos que não estão no controle de versão.

O que @simplesmiler deseja é uma maneira de comprometer o nome do projeto para o controle de versão _ enquanto mantém .env fora do controle de versão_.

Pelo que eu posso dizer, ainda não há maneira de fazer isso facilmente.

@thedeeno não é o que seu post diz. Vocês estão trabalhando juntos? Do contrário, não devemos presumir que o caso de uso de outra pessoa está além do que está explicitamente escrito.

Não estamos trabalhando juntos. Essa é a minha interpretação do problema deles. Ponto totalmente justo, posso estar errado e posso estar presumindo.

Gostaria que NÓS trabalhássemos juntos para podermos tomar um café. Espero que você não pense que estou sendo um idiota aqui.

Talvez eu esteja apenas me lembrando deste tópico incorretamente: Existe uma maneira de enviar o nome do projeto para o controle de versão enquanto mantém .env ignorado?

Existe uma maneira de confirmar o nome do projeto para controle de versão, mantendo .env ignorado? Ou ainda é uma capacidade ausente?

Atualmente não. Como mencionei há alguns meses ^ 1, o plano é ter docker-compose.env como um arquivo env secundário que pode ser incluído no controle de versão. Ele caiu um pouco na lista de prioridades, mas espero chegar a isso em breve.

1 / https://github.com/docker/compose/issues/745#issuecomment -345054893

Essas são ótimas notícias! Aceitando RP?

Já perdi a esperança há muito tempo, mas vamos tentar de novo:

Acho que muitos aqui ainda não entendem por que somos forçados a manter um segundo arquivo para essa configuração.

Pelo que entendi, para alguns aqui, isso quebra a configuração do projeto. Mas para a maioria neste tópico, isso não seria um problema. Então, como pode ser que esses poucos imponham essa restrição a todos os outros que não têm esse recurso? Por que não podemos ter várias opções para configurar o nome e deixar a decisão para nós?

Nem faz sentido lógico: a falta dessa configuração em docker-compose.yml é tão óbvia que nem pude acreditar que essa opção estava faltando quando a procurei no manual. Quase todos os outros aspectos de sua configuração podem ser configurados lá. Para mim, isso é uma quebra clara na lógica de configuração.

Acho que se poderia dizer, (quase) todas as configurações em docker-compose.yml são "delimitadas" pelo nome do

Como sugerido em # 4841, uma opção para especificar qual arquivo .env usar (ou seja, --env-file ) deve ser muito útil.

@roipoussiere veja https://github.com/docker/compose/issues/4841#issuecomment -414543951

Obrigado @ schmunk42.
Mas isso significa que devo criar uma hierarquia como:

.
├── project_a
│   ├── .env
├── project_b
│   ├── .env

em vez de algo mais fácil como:

.
├── a.env
├── b.env

Sim, consulte também https://github.com/docker/compose/issues/745#issuecomment -345054893 - talvez seja necessário abri-lo em uma nova janela, pois às vezes está oculto aqui : nerd_face:

Eu apoio a proposta --env-file . Fiz um ingresso só para isso. Vá e curta se quiser esta opção.

Então eu li apenas alguns comentários sobre esse bug / recurso, e o fato de que a discussão continua e que ele está aberto me leva à conclusão de que já se passaram 4 anos desde que ele foi originalmente aberto e ainda não há solução? Podemos tomar uma decisão parcial e depois seguir em frente?

Devo admitir que não li toda esta edição e todas as edições relacionadas, mas existem problemas interessantes em torno deste tópico que tornam isso mais complicado do que parece à primeira vista. Por exemplo, como todos sabemos, .env é comumente usado para valores secretos, então você normalmente ignora isso no controle de versão.

Mas digamos que você esteja trabalhando com Stripe, que permite que você tenha chaves de teste e chaves ativas, também conhecido como. 2 conjuntos de chaves para trabalhar. No desenvolvimento, seria muito comum usar as chaves de teste e, na produção, acabaria usando as chaves ativas.

Isso significa automaticamente que você não pode usar .env sozinho para lidar com valores secretos porque você terá chaves diferentes em cada ambiente e não deseja ter que alternar os valores em seu arquivo entre a execução de seu app em dev ou prod (isso seria louco e muito sujeito a erros).

O que você provavelmente acabará fazendo é criar um arquivo .env e .env.prod e ignorar ambos do controle de versão. Desta forma, você pode ter suas chaves de teste / dev em desenvolvimento e referenciá-las com env_file em seu arquivo de composição de desenvolvimento.

Mas então, na produção, você faz referência a .env e .env.prod em seu arquivo de composição de produção.

Mas você vê onde isso vai dar? No momento, o Docker Compose não permite que você tenha arquivos env_file opcionais. Se o arquivo não existir, o Docker Compose irá explodir assim que você tentar executar o Docker Compose.

Portanto, você precisa automaticamente de um arquivo .env para existir no final se você planeja usá-lo com env_file e isso também não se limita ao Stripe. Muitos frameworks web têm certas configurações que são específicas do ambiente, mas mudariam tanto no desenvolvimento quanto na produção (ou seja, SERVER_NAME com o Flask).

Então isso significa que estamos limitados a ter algo como um arquivo .env_example que você envia para o controle de versão e é esperado que o usuário final renomeie esse arquivo para .env , e dentro deste arquivo conteria nosso velho amigo COMPOSE_PROJECT_NAME .

O que agora levanta a questão. Precisamos realmente de uma maneira alternativa de definir o nome do projeto? Não estou convencido de que sim, mas estou convencido de que definir um nome de projeto personalizado é uma boa ideia em qualquer projeto, ou pelo menos algo diferente do nome da pasta, já que você pode facilmente entrar em conflito de nomes.

Este problema está em algum roteiro, por favor?

O caso de uso para isso seria modificar o COMPOSE_PROJECT_NAME no caso em que seu projeto tem vários arquivos docker-compose (por exemplo, um para dev, test, talvez uma base, talvez um local de teste, etc.). Você pode precisar girar até 2 ambientes muito diferentes que são separados um do outro.

Em nosso caso, podemos contornar essa limitação do docker-compose criando COMPOSE_PROJECT_NAME em nosso makefile.

Eu gostaria de ver isso configurável de dentro do próprio yaml de composição.

Ainda está aberto? Oh meu Deus...

Subscrito. Também quero ser capaz de definir o nome do projeto no arquivo yaml de composição.

Isso está demorando muito 🤦‍♂

seria muito útil ter este recurso

esse recurso seria muito bem-vindo no projeto em que estou trabalhando

Ok, então, a partir deste longo thread, podemos concluir que o nome do projeto não estará no arquivo docker-compose.yml, porque os principais desenvolvedores são contra isso e não irão mesclar nenhuma solicitação pull.

Então, podemos, por favor, voltar à proposta original e no início desta questão: tornar o nome do projeto persistente. Usar um arquivo .docker-compose ou um diretório .docker-compose parece bom para mim. Mas seria bom se finalmente conseguíssemos algum progresso na implementação disso.

Eu adicionaria uma variável ENV a essa lista de alternativas.

Uma raiz substancial de toda a discordância é este tópico / problema é que para muitas pessoas não funciona se estiver em uma variável ENV. Eles querem ser capazes de submetê-lo a um repo (opcional, claro, a recomendação padrão pode ser não confirmá-lo).

Ter o ENV ao invés do conteúdo do yaml contradiz a filosofia de compartilhamento de arquivos yaml entre diferentes projetos. Na verdade, está oficialmente documentado: https://docs.docker.com/compose/extends/ (Veja "Exemplos de casos de uso", por exemplo). Se você usar o arquivo yaml de base única e, em seguida, substituir os arquivos para dev, test e prod, e Deus sabe o que mais, não faz sentido executá-lo com o mesmo nome de projeto ou definir o nome do projeto por ENV / cli. Ele apenas criará combinações N * N enquanto em N forem válidas.

Passei por várias dessas discussões e vi uma tonelada de comentários de pessoas querendo que o nome do projeto seja configurável no arquivo YML. Mas nem um único comentário explicando por que isso não deve ser feito. Essas discussões datam de muito tempo.

Como alguém que procura uma solução fácil de usar e descobre que não existe uma maneira fácil de definir o nome do projeto que não exija atenção cuidadosa do usuário na linha de comando executada (que compete com a ideia central de uma ferramenta para a qual você passe up e magicamente inicie um cluster completo de servidores) - Estou chocado que esta seja uma questão em aberto. Se houvesse alguma explicação clara de por que é problemático ou preocupante para implementar, eu estaria interessado.

uma solução elegante poderia ser usar o marcador na propriedade container_name (e outra nomenclatura dinâmica como volume, rede, ...)

services:
  my_service:
    container_name: {project_name}_{service_name}_{instance_number} # default value

com tal configuração, pode-se usar

services:
  my_service:
    container_name: fixedprojectname_{service_name}_{instance_number}

editar: esta não é uma solução perfeita, pois entrará em conflito para pessoas que usam 2 projetos distintos dentro do mesmo nome de pasta

@jderusse

uma solução elegante poderia ser usar o marcador na propriedade container_name (e outra nomenclatura dinâmica como volume, rede, ...)

services:
  my_service:
    container_name: {project_name}_{service_name}_{instance_number} # default value

com tal configuração, pode-se usar

services:
  my_service:
    container_name: fixedprojectname_{service_name}_{instance_number}

editar: esta não é uma solução perfeita, pois entrará em conflito para pessoas que usam 2 projetos distintos dentro do mesmo nome de pasta

Também estou fazendo isso e pensei que isso resolveria o problema de conflito, embora ainda precisemos definir a variável COMPOSE_PROJECT_NAME para algum valor exclusivo no arquivo .env .

Neste ponto, eu realmente só quero entender a razão pela qual os mantenedores estão rejeitando soluções. Já existe uma solicitação pull para uma solução.

Depois de sabermos o que está errado, podemos trabalhar para consertá-lo. Neste ponto, não vejo nenhum feedback além de "rejeitado".

Temos estes 2 comentários:

https://github.com/docker/compose/issues/745#issuecomment -345054893
https://github.com/docker/compose/issues/745#issuecomment -346487757

Mas devo admitir que mesmo lendo esses comentários, não entendo totalmente por que não apenas adicionar o project_name ao arquivo yaml. Para aqueles que pensam que isso torna seus arquivos docker-compose.yaml menos gerais, eles não devem simplesmente colocar o nome no arquivo yaml, mas por favor, deixe o resto de nós ter a opção de fazer isso.

OK, estou fazendo o meu melhor para ler as referências a outros comentários; realmente apreciaria pelo menos uma breve sinopse que referencie o conteúdo da referência, além da referência para ajudar a ter certeza de que estou lendo a coisa certa e obtendo o conteúdo certo.

Deixe-me tentar resumir o que vejo serem as preocupações. Qualquer ajuda para esclarecer isso seria apreciada.

(1) Adicionar o nome do projeto ao arquivo YML pode tornar o projeto menos reutilizável, pois evitaria, ou pelo menos complicaria, a execução de um arquivo YML com mais de um nome de projeto.
(2) "a qualidade do projeto sofreria muito como resultado para justificar sua adição (neste formulário)"
(3) "Se o nome do projeto estiver no arquivo de composição, dois projetos quaisquer poderiam usar o mesmo nome, causando um conflito, o que quebraria os dois projetos."

Tenho ideias sobre isso, mas vou adiar os comentários até que possamos chegar a um acordo sobre as questões que precisam ser abordadas. Isso é razoável?

(4) Implementação de forma compatível com versões anteriores (precedência / ordem dos valores)

(1) Adicionar o nome do projeto ao arquivo YML pode tornar o projeto menos reutilizável, pois evitaria, ou pelo menos complicaria, a execução de um arquivo YML com mais de um nome de projeto.

Mais uma vez, existe uma maneira oficial de dividir a configuração em base e arquivo e herdada - https://docs.docker.com/compose/extends/. Não foi possível definir o nome do projeto na configuração de base.

Para mim, o principal caso de uso que procuro é a capacidade de executar várias instâncias do projeto localmente (dev, ambientes de teste etc.).

Talvez a solução seja permitir que você defina o nome do projeto explicitamente ou uma passagem de caminho.

Se eu definir o nome do projeto no arquivo yaml explicitamente como my-project então posso simplificar as coisas para uma única instância de um projeto ou onde faço algo como adicionar todos os meus arquivos docker em uma pasta docker em vários projetos.

.
├── project_a
│   ├── docker
│   │   ├── docker-compose.yml (project_name: my-project)
├── project_b
│   ├── docker
│   │   ├── docker-compose.yml (project_name: some-other-project)

Mas isso não ajuda com várias instâncias do mesmo projeto, então que tal fazer algo com a travessia de caminho

project_name: ../(*) então com o mesmo exemplo

.
├── project_a
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_a)
├── project_b
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_b)
├── project_b_copy
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_b_copy)

similarmente project_name: ../(../*)

.
├── dev
│   ├── project_a
│   │   ├── docker
│   │   │   ├── docker-compose.yml (project_name=dev_project_a)
├── test
│   ├── project_a
│   │   ├── docker
│   │   │   ├── docker-compose.yml (project_name=test_project_a)

como especificar o percurso provavelmente deve ser pensado um pouco mais profundamente do que meu polegar, mas pelo menos fazendo isso, acho que temos flexibilidade para cobrir todos os casos de uso.

Só de brincadeira: isso significa que para configurar um nome fixo em meu docker-compose.yml, eu criaria um arquivo com o nome que desejo e, em seguida, definiria project_name: name-of-the-file-named-like-the-name-i-want ?

Atualmente, carrego docker-compose arquivos no mesmo diretório. Como dc-work.yml , dc-server.yml , etc., todos carregam serviços diferentes e não relacionados.

Quando eu executo docker-compose up dc-A.yml e, em seguida, executo docker-compose up dc-B.yml , o Docker me reclama que há serviços órfãos em execução (claro que não, é por causa do maldito nome do projeto).

Não há realmente nenhuma maneira de resolver isso? Mover cada dc-A|B|C|etc.yml arquivo para seu próprio diretório e, em seguida, passar por cada um para carregar todos os meus serviços parece uma verdadeira perda de tempo ou estou perdendo alguma coisa?

Por que esse problema não foi resolvido? A solução clara e direta foi apresentada por @ cr7pt0gr4ph7 aqui: https://github.com/docker/compose/issues/745#issuecomment -182296139. Recebeu muitos votos positivos. Cada preocupação foi abordada na discussão. E, o mais importante, ele resolve muitos problemas para muitas pessoas. O que da?

Também enfrentamos esse problema porque estamos usando uma estrutura de diretório de projeto fixa com uma pasta .docker que contém todas as coisas relacionadas ao docker, então estou terminando com muitos nomes de projeto .docker - estou trabalhando em uma arquitetura de microsserviços então é normal ter vários up ... mas essa coisinha continua atrapalhando -> também, PHPStorm etc não tem a opção de passar o argumento -p / - project-dir e eu não posso realmente use um .env para isso porque, acredite, definir o valor correto será esquecido ...

Desenvolvedores, por favor, deixe-nos saber como você deseja que seja resolvido.

Talvez adicionar uma propriedade ao arquivo docker-compose para definir o nome do projeto?

@AyushyaChitransh

Desenvolvedores, por favor, deixe-nos saber como você deseja que seja resolvido.

Este é o melhor resumo:
https://github.com/docker/compose/issues/745#issuecomment -182296139

Tem havido muita discussão. Não há necessidade de mais discussão. Os mantenedores do projeto precisam apenas ler os tópicos (plural) e fazer o necessário.

Para mim ainda é isso: https://github.com/docker/compose/issues/745#issuecomment -248644429

Para mim ainda é o seguinte: # 745 (comentário)

Sim, existe uma solução existente, mas pobre. Esses comentários foram rejeitados e os problemas foram claramente declarados por muitos. Os comentários vinculados simplesmente não abordam a maioria das preocupações legítimas levantadas nesses tópicos.

Tbh, é meio que um ponto discutível. Muitos de nós mudamos para o Kubernetes para obter a funcionalidade do tipo docker-compose . É um pouco prolixo. Mas está funcionando e é bem suportado pelos fornecedores de nuvem.

@AyushyaChitransh
Queremos usar o mecanismo para definir o nome do projeto conforme descrito aqui: https://github.com/docker/compose/issues/745#issuecomment -182296139

1. Argumento da linha de comando.
2. Variável de ambiente (arquivo .env)
3. No arquivo Compose diretamente
4. Caminho da pasta

Não pense que há qualquer objeção a isso.

Há, trata-se de portabilidade, como mencionado acima, de alguma forma semelhante ao usar container_name , que também não deve fazer parte do docker-compose.yml . Você não pode reutilizar a mesma configuração com as configurações existentes.

Se seu fluxo de trabalho depender do caminho da pasta e de alguma forma project-name for injetado em sua configuração, por exemplo. através da fusão, vários arquivos de composição, modelos, ... - você acabará com o mesmo problema - sobrescrever pilhas existentes.

Desculpe dizer isso, mas deve ser fechado como wontfix .. (editar) ou lançar uma nova versão MAJOR (!)

@ schmunk42

Se o seu fluxo de trabalho depender do caminho da pasta e de alguma forma o nome do projeto for injetado em sua configuração, por exemplo. através da fusão, vários arquivos de composição, modelos, ... - você acabará com o mesmo problema - sobrescrever pilhas existentes.

Em primeiro lugar, o nome do projeto só seria definido nos arquivos de composição por aqueles que precisassem disso e é precisamente porque eles desejam que os arquivos de composição funcionem com as pilhas existentes. Você pode adicionar seu aviso aos documentos sobre esta configuração.
Em segundo lugar, para aqueles que dependem de um nome de projeto específico, considere o seguinte:

1. E se o arquivo de composição for baixado de um repo git e, no próximo commit, o proprietário do repo o mover para uma subpasta diferente? Ou renomeou a pasta em que está? O impacto no fluxo de trabalho já está presente, pois os arquivos podem ser movidos e isso afeta o nome do projeto.
2. Se você depende de um nome de projeto específico, propomos o mecanismo para garanti-lo, usando a variável de ambiente (arquivo .env) ou o arg da linha de comando ao executar a composição do Docker - ambos substituíam qualquer valor que estivesse em o arquivo de composição (se algum foi adicionado por algum motivo).

Fechar isso como wontfix não é muito útil sem explicar por que o acima não é bom o suficiente .. ou oferecer um caminho para uma solução.

Não quero que meu fluxo de trabalho (ou melhor, o fluxo de trabalho de toda a minha equipe) dependa do nome da pasta para a qual fazem check-out do código.

Meu principal problema com a solução do arquivo .env é que esse arquivo deve estar no diretório de trabalho da execução do comando - enquanto o docker-compose resolve o arquivo de composição para um diretório pai. Portanto, torna-se essencial que todos os desenvolvedores (A) façam check-out do código na pasta com o mesmo nome (assumindo um arquivo docker-compose.yml na raiz de um repositório de código) ou (B) apenas executem comandos docker-compose em a pasta raiz do repo, caso contrário, cria pilhas conflitantes ou (C) eles têm nomes de pilha diferentes e toda a documentação e scripts precisam ser replace stack name here .

Se (C) for o que o docker sugere como a solução 'portátil' recomendada, a CLI do docker-compose precisa ser completa com os comandos da CLI do docker e, mesmo assim, ainda vejo um caso de uso para esse recurso.

Se o seu fluxo de trabalho depender do caminho da pasta e de alguma forma o nome do projeto for injetado em sua configuração, por exemplo. através da fusão, vários arquivos de composição, modelos, ... - você acabará com o mesmo problema - sobrescrever pilhas existentes.

Se um nome de projeto for adicionado ao arquivo docker-compose, certamente estará lá por uma razão (como todas as outras linhas em um arquivo docker-compose). Infelizmente, agora mesmo apenas renomeando minha pasta de check-out (sem fazer nenhuma alteração controlada no git), eu também recebo um sistema quebrado.

Não acredito que estamos em 2020 e ainda não corrigimos esse enorme caso de uso. Esta não é uma alteração importante, é um recurso totalmente opcional e faz todo o sentido. Dado que o Kubernetes é agora a ferramenta de implantação de fato para docker, imagino que docker-compose seja usado principalmente em implantações de desenvolvimento / locais e ter um arquivo docker-compose na raiz de um repositório para executar o código no repo local é muito popular caso de uso.

@ dc-pm escreveu: "Dado que o Kubernetes é agora a ferramenta de implantação de fato para docker"

Agora não escrevo mais arquivos docker-compose. Não há benefício suficiente para algo que não terá produção. O Kubernetes também tem suas peculiaridades. Mas é amplamente suportado por fornecedores de nuvem.

Verdade seja dita, até mesmo lidar com contêineres em meu ambiente de desenvolvimento é muito trabalhoso no dia-a-dia. Acabei de executar os programas ...

@ dc-pm escreveu:

Não acredito que estamos em 2020 e ainda não corrigimos esse enorme caso de uso.

Não é apenas que não foi corrigido, mas os desenvolvedores se recusam ativamente a corrigi-lo.

O problema, eu suspeito, é que os adolescentes que desenvolvem este software não têm experiência profunda para entender as implicações desse caso de uso, ou ouvir o grande número de seus usuários mais experientes solicitando que seja abordado. Nesse ponto, duvido que eles tenham trabalhado em um ambiente com mais de uma pilha, ou talvez até mesmo em equipes. Caso contrário, francamente, _esta seria uma melhoria perfeitamente óbvia! _

Alguns lembretes amigáveis ​​...
Desenvolvedores de código aberto não são seus "funcionários / faculdades", na maioria dos casos eles trabalham de graça.
Se for claramente um problema para você, reserve um tempo para investigar as soluções (e faça um PR).

Culpar não é a solução.

https://github.com/docker/code-of-conduct/blob/master/code-of-conduct-EN.md

É muito difícil forçar uma mudança quando os desenvolvedores são contra ...

No sábado, 14 de março de 2020 às 03:19, Antoine Gravelot [email protected]
escrevi:

Alguns lembretes amigáveis ​​...
Os desenvolvedores de código aberto não são seus "funcionários / faculdades", na maioria dos casos
eles estão trabalhando principalmente de graça.
Se é claramente um problema para você, reserve um tempo para investigar as soluções
e empurre um PR.

Culpar não é a solução.

https://github.com/docker/code-of-conduct/blob/master/code-of-conduct-EN.md

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/docker/compose/issues/745#issuecomment-598991880 ou
Cancelar subscrição
https://github.com/notifications/unsubscribe-auth/ABAXP2DRD7H4YI7KQ7B2URLRHLLQ5ANCNFSM4AZMCNWA
.

@agravelot Acho que houve alguns RPs, talvez não sejam o ideal. Mas, durante toda a discussão, os proprietários definiram claramente as expectativas de que não querem esse recurso. Não é uma questão de codificação.

@agravelot desculpe a demora. E eu realmente não quis desrespeitar as muitas pessoas incríveis e talentosas que contribuem aqui. Mas culpar a falta de esforço também não ajuda.

Destaco simplesmente o apoio a uma ideia que não foi ouvida em inúmeras ocasiões, apesar do apoio claro ao longo de um longo período de tempo. O objetivo principal disso (e do OSS em geral), conforme definido em nosso código de conduta, é permitir que as pessoas contribuam com o código e respeitem todas as ideias.

Já houve várias solicitações de pull criadas, mas se ajudasse a situação, estou muito feliz em criar outra.

Qual seria uma forma mais construtiva de avançar?

Já houve várias solicitações de pull criadas, mas se ajudasse a situação, estou muito feliz em criar outra.

Sim, os desenvolvedores devem continuar revisando-os ou encerrar como "Não consertará" (possivelmente argumentando) ... Manter isso aberto por anos, sem feedback oficial, é apenas perda de tempo dos colaboradores (no sentido mais amplo ) Isso também é desrespeito, IMO.

Ei, pessoal, como usuário, eu queria apenas compartilhar meu caso de uso. Portanto, tenho 2 arquivos docker-compose.yml, um para o ambiente de desenvolvimento e outro para a produção. Eles estão localizados na mesma pasta. Ambos possuem um serviço com o mesmo nome - denominado "banco de dados". Eu gostaria de implantar esses dois serviços ao mesmo tempo - só porque posso, é da conteinerização que estamos falando, posso escalar o quanto quiser. Eles têm valores diferentes de "container_name".

Então eu corro:

macbook@fuck-fuck autocat-server % docker-compose -f ./compose-dev.yml up -d database
Creating network "autocat-server_autocat-dev" with the default driver
Creating database-dev ... done
macbook@fuck-fuck autocat-server % docker-compose -f ./compose-prod.yml up -d database
Creating network "autocat-server_autocat-prod" with the default driver
Recreating database-dev ... done

Observe como diz "Recreating database-dev" enquanto me refiro claramente ao serviço localizado no projeto "prod". Na verdade, sobrescreve o contêiner existente. O banco de dados é encerrado e o contêiner é substituído pelo último.

Estou fazendo isso supondo que arquivos "docker-compose.yml" separados significam projetos separados, mas aparentemente isso não é uma coisa na vida real. O projeto no qual o serviço é implantado é determinado pela localização do "docker-compose.yml". Para torná-los parte de projetos separados, preciso especificar separadamente o nome do projeto em uma variável de ambiente. Finalmente funciona com isso:

macbook@fuck-fuck autocat-server % COMPOSE_PROJECT_NAME=autocat-prod docker-compose -f ./compose-prod.yml up -d database
Creating network "autocat-prod_autocat-prod" with the default driver
Creating database-prod ... done
macbook@fuck-fuck autocat-server % COMPOSE_PROJECT_NAME=autocat-dev docker-compose -f ./compose-dev.yml up -d database
Creating network "autocat-dev_autocat-dev" with the default driver
Creating database-dev ... done

Tanto para implantação de comando único, que piada absoluta. Na minha opinião, .yml é um ótimo lugar para especificar o nome do projeto neste contexto.

Como alternativa, consegui colocar os serviços em um único projeto - dando-lhes nomes diferentes: "database-dev" e "database-prod". O único problema com essa abordagem é que há um aviso sobre o serviço anteriormente instanciado se tornar um órfão porque não é mencionado no outro docker-compose.yml.

macbook@fuck-fuck autocat-server % docker-compose -f ./compose-prod.yml up -d database-prod                
Creating network "autocat-server_autocat-prod" with the default driver
Creating database-prod ... done
macbook@fuck-fuck autocat-server % docker-compose -f ./compose-dev.yml up -d database    
WARNING: Found orphan containers (database-prod) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
Creating database-dev ... done

Isso não faz sentido tbh, por que tem que ser assim. Por que de fato tem que ser assim?

EDIT1: @ dc-pm @CharlieReitzel whatchu acha? você pode comentar sobre meu caso de uso, apenas no caso de ser inválido :)
EDIT2: Coloquei os dois arquivos de composição em diretórios separados e voila

então?

mantenedores, alguém aqui?
os desenvolvedores esperam por 6 anos!

Oi! Eu criei um problema na especificação de composição para ter o nome do projeto adicionado ao esquema de composição, pois isso rege o que podemos adicionar ao arquivo de composição.
Depois que a propriedade project-name é adicionada à especificação de composição, podemos iniciar a implementação em docker-compose.