Eu estava apenas olhando para isso

Uso: docker build [OPÇÕES] CAMINHO | URL | -

então se você correr

docker build -t my / thing my-dockerfile

reclama que o arquivo tar é muito curto.

Parece-me que a opção 'PATH' não está documentada, então pode ter algum significado legado?

Então - gostaria de saber se detectar se PATH é um arquivo e não um Tarfile.

Pessoalmente, tenho um conjunto de Dockerfiles que uso para testar e prefiro tê-los todos em um único diretório e também um contexto completo.

Esse PATH se refere a um diretório, não a um Dockerfile específico.

oh, e então Tars esse diretório para enviar para o servidor - legal!

portanto, é possível detectar o isafile, tar no diretório e, em seguida, substituir o Dockerfile nesse tarball pelo arquivo especificado.

ou usar -f da mesma maneira - permitindo que suas definições do Dockerfile vivam separadamente da carga útil

agora para descobrir como os testes funcionam, experimente e veja se funciona para mim

Ele não tar nada - o PATH é um diretório no qual ele assume que existe um Dockerfile

isso não é tudo que faz com esse PATH - lendo o código, o 'contexto' é enviado ao servidor tarando o diretório.

(ok, então eu ainda não sei, e só estou lendo o código nos últimos minutos, então aceite-o com um grão de ceticismo)

Correto, portanto, quaisquer arquivos não remotos referenciados via ADD também devem estar no mesmo diretório ou o daemon não poderá acessá-los.

Ah, entendo o que você está dizendo - sim - é exatamente o que eu quero - uma maneira de especificar um dockerfile com -f e, em seguida, o diretório PATH que pode ser separado.

então eu poderia ter:

docker build -t my/thing fooproj
docker build -t my/thing -f debug-dockerfile fooproj

2108 (adicionando uma diretiva de inclusão para Dockerfiles) adiciona uma ruga interessante

deve a inclusão ser relativa ao dockerfile especificado ou ao PATH. não é importante ainda.

Diversão:

docker build -t my/thing fooproj
docker build -t my/thing -f ../../debug-dockerfile fooproj
docker build -t my/thing -f /opt/someproject/dockerfiles/debug-dockerfile fooproj

como bônus extra - ainda não há testes do CmdBuild, então adivinhe o que vou aprender primeiro :)

@SvenDowideit você está trabalhando nisso? Eu estava pensando em talvez hackear hoje

Estou lentamente me familiarizando com o código e vou, então vá em frente - estou me divertindo muito apenas escrevendo os testes de unidade (talvez você possa usar os commits de teste para ajudar :)

Eu farei :)

Eu gostaria de ver essa funcionalidade também. Temos um sistema que pode ser executado em 3 modos diferentes e gostaríamos de implantar 3 containers diferentes - 1 para cada modo. Isso significa três arquivos docker virtualmente idênticos, com apenas o CMD sendo diferente. Mas, como os caminhos são apenas diretórios e os diretórios são o contexto dos comandos ADD, não consigo fazer isso funcionar agora.

Então: +1 de mim!

Parece que isso pode ter o mesmo objetivo final que # 1618 (embora com abordagens diferentes). A ideia é usar um único Dockerfile com várias instruções TAG que resultam em várias imagens, em vez de vários Dockerfiles e um sistema de inclusão, conforme descrito aqui. Pensamentos?

Parece que se você pode canalizar um Dockerfile, você também deve ser capaz de especificar um caminho. Interessado em ver o que vem de # 1618, mas acho que isso oferece muito mais possibilidades.

Aqui é onde estou: https://github.com/peterbraden/docker/compare/2112-specify-dockerfile?expand=1

Fiquei surpreso com o fato de que a documentação não afirma claramente que o diretório que contém o Dockerfile é o contexto de compilação - fiz a suposição errada de que o contexto de compilação era o diretório de trabalho atual, então, se eu passar um caminho para o Docerfile em vez disso de estar no diretório atual, os arquivos que tentei adicionar do diretório de trabalho atual bombardearam com erros "nenhum arquivo ou diretório".

Estou recebendo o mesmo erro, Quaisquer ideias

docker build Dockerfile

Carregando contexto

2013/12/11 21:52:32 Erro: Erro de compilação: Tarball muito curto

@bscott tente docker build . vez disso. A construção leva um diretório, não um arquivo, e esse é o "contexto de construção". :)

Worked Thx !, Eu só gostaria de escolher entre diferentes arquivos Docker.

+1 de mim.

Eu preciso criar várias imagens da minha fonte. Cada imagem é uma preocupação separada que precisa do mesmo contexto para ser construída. Poluir um único Dockerfile (como sugerido em # 1618) é complicado. Seria muito mais limpo para mim manter 3 arquivos <image-name>.docker separados em minha fonte.

Eu adoraria ver algo assim implementado.

Isso é mais difícil de implementar do que parece à primeira vista. Parece que ./Dockerfile está bem consolidado. Após a investigação inicial, pelo menos estes arquivos estão envolvidos:

api/client.go
archive/archive.go
buildfile.go
server.go

O client usa archive para tar build context e o envia para server que então usa archive para descompactar build context e passe os bytes para buildfile .

A implementação mais fácil parece envolver a alteração de client e archive para sobrescrever ./Dockerfile do tar com o arquivo especificado por meio desta opção. Vou investigar mais.

@thedeeno Vou dar uma olhada bem rápido e mostrar onde a mudança deve ser feita. Acho que está em apenas um lugar.

+1 de mim!

Tenho seguido os números 1618 e 2112 e esta é a solução mais elegante.

Há um caso de uso específico em meu desenvolvimento em que esse recurso seria incrivelmente útil ... Ao trabalhar em aplicativos que possuem funções "web" e "trabalhador". Eu gostaria de criar dois arquivos docker para esta situação "Dockerfile-web" e "Dockerfile-worker". Eu poderia então construir os dois, marcá-los e enviá-los para o meu repositório de imagens. Em seguida, eu executaria várias instâncias de front-end da web atrás de um balanceador de carga e vários trabalhadores para lidar com as tarefas que estão sendo colocadas nas filas.

+1 como alternativa a # 2745.

+1

Fiquei surpreso ao descobrir que Dockerfile está codificado, bem como que o contexto de construção é forçado a ser o diretório do Dockerfile e não pode ser substituído nem mesmo com sinalizadores de linha de comando. Isso limita severamente a utilidade e flexibilidade do Docker como ferramenta de desenvolvimento, teste e implantação.

+1
Eu apreciaria essa mudança

+1
Realmente preciso disso.

5033 deve permitir esse recurso. cc / @ crosbymichael

@shykes o que você acha dessa mudança? Acho que você não concordou ou talvez conheça uma solução melhor para resolver o mesmo problema.

Estou hesitante.

Por um lado, não quero limitar a capacidade das pessoas de personalizar suas construções.

Por outro lado, temo que aconteça o mesmo que acontece com _run -v / host: / container_ e _expose 80: 80_. Em outras palavras, permitirá a 1% que sabe o que está fazendo adicionar uma personalização legal - e os outros 99% então dar um tiro no próprio pé.

Por exemplo, temos muitos novos usuários do Docker que começam com volumes montados em host em vez de volumes regulares. E tivemos que descontinuar a sintaxe _expose 80: 80_ porque muitas pessoas publicaram imagens que não podiam ser executadas mais de uma vez por host, sem um bom motivo.

Portanto, minha pergunta é: não corremos o risco de ter muitos repositórios de origem que não podem ser construídos repetidamente com _docker build

@shykes Estou tendo o problema que você descreve _por causa_ desta limitação do Dockerfile. Aqui estão alguns casos de uso:

1. Eu tenho um ambiente de compilação baseado em Docker que produz um artefato (arquivo JAR, neste caso). O ambiente de construção é diferente do ambiente de execução (dependências diferentes, imagem maior, etc., então não quero herdar o ambiente de construção para o tempo de execução. Para mim, faz mais sentido ter a construção Dockerfile e execute o ambiente de execução em torno do JAR. Portanto, tenho um arquivo Dockerfile.build separado que constrói e executa o ambiente de construção e cria o JAR. Mas, como não posso especificar o Dockerfile, tive que criar um scripts/build arquivo que faz um docker build < Dockerfile.build e, em seguida, monta o volume do host w / docker run -v ... para executar a compilação (já que não posso usar ADD com Dockerfiles canalizados). Eu gostaria de fazer, em vez disso, apenas ser capaz de executar docker build -t foobar/builder -f Dockerfile.build , docker run foobar/builder , docker build -t foobar/runtime , docker run foobar/runtime e apenas usar comandos ADD em ambos os Dockerfiles.
2. Com as instruções ONBUILD, gostaria de poder colocar Dockerfiles em subdiretórios (ou ter arquivos Dockerfile.env, etc. na raiz) que têm o Dockerfile raiz em sua instrução FROM, mas ainda pode usar a raiz do projeto como seu contexto de construção. Isso é útil, por exemplo, para trazer parâmetros de configuração para diferentes ambientes. O Dockerfile raiz ainda produziria um contêiner útil, mas os outros criariam diferentes variantes de que precisamos.

Portanto, acho que o que eu realmente gostaria é poder separar os conceitos de "contexto de construção" de "local / nome do Dockerfile". Existem muitas maneiras possíveis de fazer isso, é claro, mas esta me parece relativamente simples.

@ cap10morgan alguma chance de você me indicar seu exemplo 1, ou algo que se aproxime dele? Assim, posso brincar e ter certeza de que estamos falando sobre a mesma coisa.

@shykes https://github.com/shykes não é exatamente esse sonho de portabilidade
é para isso que serve o índice de imagem? Por que os ambientes de construção precisam ser
portátil também?

Alguns processos de construção exigem mais do que é possível com o vanilla
Dockerfile. Além disso, a aplicação de um Dockerfile por contexto (que é o que
esta solicitação visa corrigir) é muito limitante.

Isso realmente afeta nossa equipe. Em nossa configuração, gostaríamos de produzir vários
imagens do mesmo "contexto". Adicionando a opção --file , podemos fazer
o que realmente queremos fazer - que é adicionar foo.docker e bar.docker
em nossa raiz de repositório. Em vez disso, acabamos escrevendo scripts bash para copiar
toneladas de arquivos em locais temporários para estabelecer um contexto e renomear nosso
arquivos docker nomeados na mágica Dockerfile apenas para que docker build possa
trabalhar.

Para mim, esses aros existem sem um bom motivo. Se alguém da nossa equipe quiser
para construir nossas imagens, eles precisam executar scripts personalizados para fazer o trabalho -
a coisa exata que você acha que pode evitar mantendo essa limitação.

Na segunda-feira, 7 de abril de 2014 às 16:23, Solomon Hykes [email protected] :

@ cap10morgan https://github.com/cap10morgan qualquer chance que você pudesse apontar
me ao seu exemplo 1, ou algo que se aproxime dele? Então eu posso jogar
ao redor e certifique-se de que estamos falando sobre a mesma coisa.

Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/dotcloud/docker/issues/2112#issuecomment -39778691
.

@shykes, já que isso parece estar ficando 'consertado', você pode apontar para a documentação ou uma explicação da maneira certificada do Docker de lidar com esse problema?

Meu caso de uso é que tenho um aplicativo que gostaria de construir com docker em que os testes têm requisitos diferentes dos de uma imagem de produção. Eu acho que isso é muito comum.

Este e o problema .dockerignore (https://github.com/dotcloud/docker/pull/3452) (copiar todo o meu diretório .git para o contexto de compilação) são os primeiros pontos críticos que atingi ao experimentar o docker para um de nossos projetos ao longo dos últimos dias e parece que não há cérebros para mim, mas parece haver retrocesso nessas questões.

+1 sobre a necessidade disso também - temos uma única base de código com vários micro-serviços sendo desenvolvidos lá. Gostaríamos de poder gerar várias imagens, por exemplo, uma imagem contendo services / base / * e services / fooservice / *; e outra imagem contendo services / base / * e services / barservices / * e também staticfiles / *.
Não podemos colocar Dockerfiles dentro da pasta de serviço porque o Docker trata essa pasta como um contexto e não podemos ADICIONAR nada que esteja acima na estrutura da pasta. Não podemos colocar dois Dockerfiles na raiz porque eles teriam o mesmo nome.
A única solução que temos é colocar o Dockerfile na pasta de serviço e, em seguida, escrever um script personalizado para analisar o Dockerfile selecionado, determinar quais caminhos ele deseja adicionar (todos especificados em relação à raiz do projeto) e, em seguida, copiá-los para um novo pasta temporária, copie o Dockerfile selecionado para a raiz dessa nova pasta e, finalmente, execute o "docker build tempfolder". Isso é mesmo necessário?
Teria sido muito mais simples se você pudesse simplesmente dizer para "construir docker" separadamente onde está o Dockerfile e onde está o contexto.

Também encontrando este problema ... adoraria ver algum tipo de solução.

+1, codificar em torno dessa limitação é uma dor enorme.

+1 para a sinalização -f que especifica o caminho do Dockerfile separado do contexto de construção

O Docker é uma ferramenta excelente, mas esse acoplamento estreito de contexto e Dockerfile específico definitivamente mancha um pouco a equipe do Docker. A estrutura do diretório nem sempre reflete exatamente a estrutura do 'contêiner / subsistema'.

Quão difícil pode ser consertar? E, houve alguns PRs para isso, mas eles foram ignorados.

Uma adição simples relacionada é ter um arquivo para ignorar coisas que não queremos adicionar ao contexto - sim, estou olhando para você, .git ...

Isso pode realmente me levar a pular o Docker por enquanto e voltar para o Vagrant + Ansible. Agradável.

@davber .dockerignore está em -> # 6579

Mas, sim, o gerenciamento de contribuições é um pouco doloroso agora e uma das raras coisas desanimadoras sobre o docker até agora. Eu estou pensando que eles estão apenas um pouco confusos.

Equipe Docker, como as pessoas podem fazer com que coisas assim sejam revisadas e publicadas? Se houver uma ideia clara sobre por que isso é realmente ruim e como os projetos devem evitar esse problema, adoraríamos saber disso, mas parece um problema simples de descrever e de resolver.

/ cc @shykes @creack @crosbymichael @vieux

+1 para o sinalizador -f. Além disso, uma variável de ambiente DOCKERFILE para substituir as configurações de construção.

@jakehow sim, definitivamente há um elemento de estar sobrecarregado, para cada mantenedor, há pelo menos 1.000 pessoas ativamente solicitando algo e exigindo uma explicação detalhada de por que ainda não foi feito. Estamos realmente fazendo o nosso melhor, e se você visitar os canais #docker e # docker-dev irc, verá a mangueira de fogo em primeira mão.

Mas, neste caso, houve uma resposta clara sobre por que é melhor manter o mapeamento 1-1 do Dockerfile e do diretório de origem. Vou repetir mais uma vez: queremos preservar a propriedade autoexplicativa das compilações docker. O fato de que você pode apontar para um diretório de código-fonte, _sem nenhuma outra informação fora da banda_, e construir uma imagem exatamente de acordo com a especificação do desenvolvedor upstream, é muito poderoso e um diferenciador chave do Docker.

Claro, ser capaz de combinar dinamicamente o diretório X com o Dockerfile Y on-the-fly é moderadamente conveniente (embora eu nunca tenha sentido uma necessidade urgente dele e eu use muito o Docker). Mas torna muito fácil fazer algo estúpido - ou seja, quebrar a natureza autodescritiva de sua construção. E isso parece uma troca extremamente pobre. Daí a decisão de não implementar esse recurso.

Quanto aos exemplos de "1 repositório de origem, várias imagens", sim, eu definitivamente concordo que é necessário. O que precisamos é uma maneira padrão do Docker para um único diretório de origem definir vários destinos de compilação. Isso pode ser feito com um Dockerfile de várias partes ou com vários Dockerfiles _ desde que haja uma convenção de nome de arquivo bem definida que permita que esses Dockerfiles sejam listados e selecionados de uma maneira não ambígua_.

Se alguém quiser contribuir com isso, adoraríamos fazer a fusão. E como de costume, ficaremos felizes em ajudar os contribuidores iniciantes, venha dizer oi no IRC e nós o ajudaremos a começar.

@davber Fiquei com a impressão de que o Vagrant tem a mesma restrição de 1 arquivo de descrição por projeto (presumivelmente por motivos semelhantes). Como voltar para o Vagrant resolverá exatamente o seu problema?

@gabrtv você quer tentar trazer de volta multi-imagens? Aqui está uma proposta provisória:

$ ls | grep Dockerfile
Dockerfile
db.Dockerfile
frontend-prod.Dockerfile
frontend-dev.Dockerfile
$ docker build -t shykes/myapp .
Successfully built shykes/myapp/db
Successfully built shykes/myapp/frontend-dev
Successfully built shykes/myapp/frontend-prod
Successfully built shykes/myapp
$ docker build -t shykes/myapp2 --only frontend-dev .
Successfully built shykes/myapp2/frontend-dev

Essa proposta funcionaria bem para nós e posso vê-la resolvendo outros problemas para outras pessoas também.

@shykes Não acho que acredite que aumentar a complexidade do formato Dockerfile seja uma troca válida por manter um Dockerfile.

Tome, por exemplo, makefiles - é mais comum do que não um projeto ter um 'Makefile', mas o make também permite que você especifique com '-f' um makefile diferente.

Também acho que o mapeamento 1: 1 entre a pasta de origem e a imagem é menos útil do que você entende - descobri que é comum gerar uma pasta de construção e construir a partir dela para manter a quantidade de dados copiados no contexto para um imagens mínimas e, portanto, menores.

você diz "Então, minha pergunta é: não corremos o risco de ter muitos repositórios de origem que não podem ser compilados repetidamente com o docker build,"

Mas acho que esse já é o caso, alguns requisitos de projeto significam que uma única maneira de construir não é prática e a sintaxe do Dockerfile não permite muita configuração (por design e eu não gostaria que isso mudasse ...).

Eu também não gosto particularmente da sugestão --only. Eu acho que o padrão que as pessoas / querem / quando constroem é que um determinado contexto seja construído, não tudo - quando eu executo o docker build, eu quero / apenas / Dockerfile para ser executado. Mas também quero a possibilidade de ter outra imagem que / possa / ser construída.

Pelo meu entendimento, a questão aqui reside no fato de que quando
canalizando um Dockerfile (cat Dockerfile | docker build -), perdemos o funcionamento
diretório para ADD e CP.

Resolverá o problema adicionando um sinalizador para docker build que nos permite
especificar onde reside o conteúdo da pasta de origem?

cat Dockerfile | docker build --cwd=~/my_docker_data_files -

Nesta proposta, a bandeira --cwd especifica a pasta base para ADD e CP
comandos.

29/06/2014 19:42 GMT + 10: 00 Peter Braden [email protected] :

você diz "Então, minha pergunta é: não corremos o risco de ter muitas fontes
repositórios que não podem ser construídos repetidamente com docker build, "

Mas acho que já é assim, alguns requisitos de projeto significam que
uma única maneira de construir não é prática, e a sintaxe do Dockerfile não
permitem muita configuração (por design e eu não gostaria
que mudar ...).

Eu também não gosto particularmente da sugestão --only. Eu acho que o padrão
que as pessoas / querem / quando constroem é para um determinado contexto a ser construído,
nem tudo - quando eu executo o docker build, eu quero / apenas / o Dockerfile para
ser executado. Mas também quero a capacidade de ter outra imagem que / pode / ser
construído.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/dotcloud/docker/issues/2112#issuecomment -47449994.

@llonchj na verdade https://github.com/dotcloud/docker/pull/5715 resolve isso (de certa forma) e isso já está mesclado com o master.

@shykes definitivamente está aberto para outro PR de várias imagens, embora depois de olhar para # 5715 eu esteja me perguntando se este PR em particular é mais relevante.

Com o comentário original de

Seria bom ser capaz de especificar [comando redigido] para que eu pudesse adicionar arquivos e também ter vários dockerfiles.

Por @ cap10morgan ...

Portanto, acho que o que eu realmente gostaria é poder separar os conceitos de "contexto de construção" de "local / nome do Dockerfile".

Não é exatamente o que # 5715 faz? Como eu entendo:

$ cd myapp
$ ls Dockerfile
Dockerfile
$ docker build -t gabrtv/myimage
Successfully built gabrtv/myimage
$ ls subfolder/Dockerfile
Dockerfile
$ tar -C subfolder -c . | docker build -t gabrtv/myotherimage -
Successfully built gabrtv/myotherimage

Eu sei que isso não resolve as compilações de várias imagens da raiz do repo (o que eu concordo que seria bom), mas estou me perguntando se essa implementação / PR em particular pode ser deixada de lado agora com o # 5715.

@gabrtv Parece-me que o # 5715 não se encaixa no critério tar -C subfolder -c . | docker build -t gabrtv/myotherimage - é, para mim, extremamente não óbvio.

Além disso, impõe restrições irritantes (se não onerosas) ao desenvolvedor em relação ao layout do repositório. Não é impossível de corrigir, mas "Ah, e terei que reorganizar todo o repositório" não vai ajudar ninguém a convencer seu chefe a mudar para o Docker.

Eu pessoalmente gosto bastante da sugestão mais recente de @shykes , com potencialmente vários arquivos .dockerfile (por que não apenas .docker?), Todos sendo construídos por padrão. Isso torna mais fácil começar a operar com um comando, não importa o que aconteça, e otimizar mais tarde.

Dependendo da implementação, pode-se fazer upload do contexto de construção apenas uma vez para isso em todas as imagens, o que reduziria o custo de construção de várias imagens. Como não tenho um .dockerignore, meu contexto de construção tem várias centenas de megabytes e tenho que esperar um pouco para que meu contexto seja carregado, então isso seria bom.

@rattrayalex acredite em mim, concordo com o objetivo de "ter um único comando que sempre funcionará". Há uma boa chance de acabar escrevendo o código e enviando o PR. :piscadela:

Meu ponto é do ponto de vista da organização do projeto, devemos ter essa discussão em outro lugar, e não em uma questão prolongada intitulada Allow specifying of a dockerfile as a path, not piping in :

1. A maior parte da discussão aqui não está relacionado com @shykes nova proposta em https://github.com/dotcloud/docker/issues/2112#issuecomment -47448314
2. O problema subjacente original (separar o contexto de compilação do Dockerfile) é abordado no nº 5715, embora talvez não seja do agrado de todos

Citando @llonchj ...

De acordo com meu entendimento, o problema aqui reside no fato de que, ao enviar um Dockerfile (cat Dockerfile | docker build -), perdemos o diretório de trabalho para ADD e CP.

Em outras palavras, se você concordou com docker build -t <image> -f <path-to-dockerfile> , você pode usar tar -C <path-to-context> -c . | docker build -t <image> - como uma solução alternativa funcionalmente equivalente até que possamos montar um PR para a proposta @shykes .

Sugiro que fechemos isso e iniciemos uma nova discussão em outro lugar (lista de e-mails? Novo problema?).

Obrigado a todos que colaboraram nesta questão hoje:

@shykes obrigado pelo raciocínio. Acho que nosso raciocínio para querer isso (outras pessoas podem intervir) está em nossa experiência: cada aplicativo requer informações fora da banda para ser executado em um contexto escolhido. Todos os nossos aplicativos têm mais de um contexto. A maneira como o docker build foi estruturado forçou os desenvolvedores de aplicativos a mover o conhecimento dessas informações para sua estrutura de repositório ou a fazer scripts de construção personalizados substituindo o comportamento do docker build que contém as informações.

@gabrtv Acho que quase toda a discussão aqui está relacionada especificamente a esse problema, e fico feliz em vê-lo finalmente sendo discutido aqui. O título da edição e algumas das postagens de 'descoberta' são provavelmente um pouco irrelevantes, portanto, uma nova edição ou RP com um início limpo que faça referência a este provavelmente é bom.

A proposta do comentário de @shykes soa como uma solução para mim. Houve algum trabalho anterior feito sobre isso em algum lugar que possa ser pesquisado ou consultado como referência?

"Dockerfile.frontend-prod" não seria melhor para que todos os Dockerfiles
em um diretório naturalmente ordenar juntos?

Desculpe, mas isso é bobagem. Se meu repo criar 100 serviços, certamente não quero ter 100 Dockerfiles na raiz. (Exemplo: o repositório PAAS dotCloud.)

Eu também não quero um único Dockerfile enorme com 100 seções.

Quero 100 Dockerfiles e os quero em diretórios separados.

(E não, não posso simplesmente construir cada serviço em seu próprio diretório, uma vez que quase todos os serviços usarão código comum e bibliotecas que vivem _fora_ do diretório de cada serviço.)

Novamente, não entendo por que ter um sinalizador extra para especificar o caminho para o Dockerfile (padronizado para apenas Dockerfile ) é um grande negócio?

Além disso, a proposta atual ( <imagename>.Dockerfile ) não mapeia de forma alguma com o design atual de compilações automatizadas. Se um repositório em qualquer um dos meus sistemas de compilação for comprometido, o invasor poderá sobrecarregar todos os meus repositórios ...?

@jpetazzo, como a maioria das pessoas razoáveis,

_Mais uma vez, não entendo por que ter um sinalizador extra para especificar o caminho para o Dockerfile (padronizando apenas para Dockerfile) é tão importante? _

Eu fiz um argumento específico acima. Sinta-se à vontade para lê-lo e apresentar um contra-argumento.

Re: desordem. @gabrtv teve a mesma preocupação no IRC. Depois de alguma discussão, chegamos a esta alternativa:

$ ls Dockerfile Dockerfiles/*
Dockerfile
Dockerfiles/frontend-prod
Dockerfiles/frontend-dev

Mesma ideia, mas menos arquivos individuais no repositório raiz.

Além disso, a proposta atual (.Dockerfile) não mapeia de forma alguma com o design atual de compilações automatizadas. Se um repositório em qualquer um dos meus sistemas de compilação for comprometido, o invasor poderá sobrecarregar todos os meus repositórios ...?

Bem, como eles são nomeados agora? Se você tiver um repo denominado "abc" com apenas um Dockerfile simples, ele faria sentido para a imagem gerada por aquele ser denominado "abc". Se você tiver um repo "xyz" com "Dockerfile.abc" e "Dockerfile.zzz", então faria sentido nomear as compilações como "xyz-abc" e "xyz-zzz".

Estou em uma situação semelhante à sua (muitos serviços, cada um em suas próprias subpastas com partes comuns) e a opção explícita de definir um Dockerfile para usar no momento da compilação tornaria meu pensamento mais fácil, mas também posso ver como posso combinar a proposta "Dockerfile. *" com o "arquivo tar como contexto" já lançado para conseguir o que desejo - os dockerfiles raiz para cada serviço gerariam suas imagens de construção (com compiladores e outras coisas) e quando esses são executados, eles geram um tar de contexto com executáveis ​​já compilados e um Dockerfile de produção (retirado da própria pasta de serviço) que descreveria uma imagem apenas com as dependências de tempo de execução.

Na verdade, agora estou até escrevendo isso com um único Dockerfile raiz porque meu ambiente de construção é mais ou menos o mesmo para todos os serviços e posso simplesmente passar um parâmetro em tempo de execução para informar qual tar de contexto de lançamento de serviço desejo criar.

@shykes bem, se chegamos tão longe a ponto de ter Dockerfile / *, então por que não dar um passo adiante e fazer "docker build" simplesmente procurar por arquivos chamados "Dockerfile. *" em todas as subpastas do diretório atual, recursivamente, e executar todos eles no contexto do diretório atual? E enquanto estamos em if, forneça uma opção para apenas construir um deles ... como "-f"? :)

... não gosto de ser chamado de bobo

Eu não sabia que "bobo" podia ser considerado ofensivo; Eu apenas quis dizer "desajeitado", talvez, e, portanto, peço desculpas por usar mal a palavra.

Acho que seu argumento específico foi "Não quero que as pessoas comecem a colocar Dockerfiles em lugares aleatórios e sistematicamente usando -f quando não for estritamente necessário". Isso está certo? Nesse caso, faz sentido impor um Dockerfile na parte superior do repo, listando os outros Dockerfiles. Se esse arquivo estiver ausente, o construtor pode se recusar a operar (ou emitir um aviso) e, se listar apenas um Dockerfile, o construtor também pode emitir um aviso. Não acho que o paralelo com -v e -p seja apropriado aqui.

@aigarius se fizéssemos isso, seria menos óbvio como mapear cada sub-Dockerfile para uma imagem filho. A vantagem de ./Dockerfile.* e ./Dockerfiles/* é que eles mapeiam para um único namespace que podemos usar para nomear as imagens resultantes. Por outro lado, se eu tiver ./foo/Dockerfile.db e ./bar/Dockerfile.db , e I docker build -t shykes/myapp . , qual deles será chamado de shykes/myapp/db ?

qual deles é chamado shykes / myapp / db?

Nenhum. Nesse cenário, você codificaria um caminho completo para o Dockerfile no nome, portanto, teria "shykes / myapp / bar / db" e "shykes / myapp / foo / db". Isso _fica_ desconfortavelmente perto do namespacing Java, mas deixarei para outros decidirem se isso é bom ou ruim.

@shykes : em relação ao Vagrant, bem, eu, e provavelmente alguns outros, uso o Vagrant para algumas funcionalidades sobrepostas do Docker. Então, para mim, preciso estar convencido de que minhas compilações multi-máquina atuais - que faço no Vagrant, com várias definições de máquina - não se tornam mais difíceis ao usar Dockerfiles. O fato é que o "contexto" é muito mais flexível no Vagrant, onde posso obter o contexto em tempo real de qualquer local por diretórios compartilhados, assim como a linguagem, então, se eu quiser apenas construir um serviço (ou máquina) Eu posso definir uma variável de ambiente e 'vagrant up / provision'. Eu uso esse método diariamente apenas para criar ou provisionar alguns dos serviços em meu sistema. E, se eu ficar muito irritado com o crescimento de um Vagrantfile, posso facilmente 'carregar' um sub-Vagrantfile que descreve um serviço ou aspecto individual.

Com relação às sugestões concretas para lidar com vários Dockerfiles, sim, isso nos permitiria dividir nossa lógica para serviços individuais. Excelente. Mas, muitas vezes eu quero ou preciso construir um serviço isolado, então ainda estou de volta à necessidade de especificar um Dockerfile específico ...

Então, meus problemas aqui são duplos:

1. Não obter um arquivo bagunçado enorme para todos os serviços
2. Ser capaz de construir um serviço específico naquele arquivo / cluster de arquivos

Novamente, o Docker é uma ideia e uma ferramenta geniais, então QUERO que pessoas como eu desistam do Vagrant para certos tipos de funcionalidades ou casos de uso.

Desculpe se eu repito algo tratado cuidadosamente acima, mas não consigo ver como qualquer solução é melhor do que suportar uma opção '-f'. Ou seja, problemas de implementação de módulo devido a alguma dependência profundamente enraizada no Dockerfile que reside na raiz de contexto, não vejo nenhuma desvantagem nisso.

Com uma opção '-f', pode-se definitivamente estruturar os subdiretórios e sub Dockerfiles da maneira que quiser, como os Dockerfiles / abordagens acima. Sim, seria necessário um basher simples de uma linha para imitar o comportamento exato ...

Parece haver tensão entre compartilhamento e flexibilidade.

Se o compartilhamento for o recurso mais importante, sim, um dockerfile padrão
faz sentido.

Não acho que compartilhar seja o recurso mais importante. Compartilhamento alcançado
via imagens.

Além disso, usamos docker em projetos que NÃO são explicitamente compartilháveis. No
a flexibilidade nesses casos é muito mais valiosa para nós. Parece que muitos em
os fios estão na mesma posição.

A opção -f proposta nos dá a flexibilidade de que precisamos. Por outro lado,
ser capaz de especificar um caminho absoluto para o contexto de construção também seria
trabalhar.
Em 3 de julho de 2014, às 18h, "David Bergman" [email protected] escreveu:

Desculpe se repito algo tratado minuciosamente acima, mas não consigo ver
como qualquer solução é melhor do que suportar uma opção '-f'. Ou seja, módulo
problemas de implementação devido a alguma dependência profundamente enraizada no
Dockerfile residente na raiz de contexto, não vejo nenhuma desvantagem com
isto.

Com a opção '-f', pode-se definitivamente estruturar os subdiretórios
e sub Dockerfiles como quiser, como o Dockerfiles /
abordagens acima. Sim, seria necessário um basher simples de uma linha para
imitar o comportamento exato ...

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/dotcloud/docker/issues/2112#issuecomment -47989616.

Concordou que -f fornece a maior flexibilidade com o mínimo de "surpresa" (eu pessoalmente presumi que havia tal sinalizador e tentei antes de entrar neste tópico).
Adicionar -c , seja de um diretório ou de um tar, para fornecer o contexto também parece uma adição excelente. Isso removeria a constante cd s de grandes processos de construção, por exemplo; nas empresas.

Além disso, um README que contém instruções para docker build -f foo/bar/Dockerfile -c foo/ simplesmente não parece ser desanimador para mim.
Também concordou que docker build poderia facilmente pesquisar Dockerfile s. Dessa forma, um repo estruturado como tal:

-- README
-- foo/
---- Dockerfile
---- etc
-- bar/
---- Dockerfile
---- etc
---- subbar/
------ Dockerfile
-- context/
---- etc

evitaria quaisquer possíveis conflitos de nomenclatura ( repo/bar/subbar ), seria uma quantia fácil de raciocinar e faria sentido em muitos contextos de desenvolvimento. Isso permitiria o uso fácil de docker build , que criaria muitos contextos, e docker build -f , que poderia deixar de fora o estranho Dockerfile na maioria dos contextos.

Se -f for um arquivo aa em vez de um diretório contendo o Docker, isso também deve funcionar, para que um desenvolvedor possa ter um dockerfile que não é compilado quando docker build é executado.

Para que isso não se perca, ontem na discussão do IRC com @shykes ele teve outra ideia sobre como implementar isso:

• Há um Dockerfile mestre na raiz do repositório que contém apenas várias linhas em um novo formato, como "INCLUIR foo / bar / Dockerfile AS bar-foo" para cada imagem a ser gerada
• Cada subprojeto (como o módulo bar do subprojeto foo), que precisa de uma imagem separada, mantém um Dockerfile regular em foo / bar / Dockerfile. Os caminhos nesse Dockerfile (para ADD e COPY) ainda são relativos à raiz de contexto, que é a raiz do repositório (onde reside o Dockerfile mestre)
• Chamada regular para "docker build -t mycorp / myapp." irá construir todas as imagens registradas no Dockerfile raiz e atribuir-lhes nomes como "mycorp / myapp / bar-foo" neste exemplo
• A opção de linha de comando adicional para "docker build" precisaria ser introduzida para construir apenas algumas das imagens declaradas, como "docker build -t mycorp / myapp --only bar-foo, baz-db"

Caso as pessoas ainda estejam procurando uma solução alternativa:

#!/bin/bash
ln -s Dockerfile-dev Dockerfile
docker build -t image/name-dev:latest .
rm Dockerfile

@shykes ping? Se houver uma aprovação do desenvolvedor principal para uma solução de design específica, é muito mais provável que alguém tente implementá-la e faça uma solicitação de pull.

+1 para a solução -f, embora eu concorde que cada repo deve, em teoria, implantar seu próprio serviço. Algumas pessoas não podem se dar ao luxo dessa solução. Meu problema específico é que tenho um repositório de chefs com vários livros de receitas e preciso ser capaz de criar muitos serviços. Mas eu preciso ser capaz de ADICIONAR diretórios acima. Portanto, é ideal manter o contexto na raiz e apontar para um arquivo docker em um subdiretório.

"-f" provavelmente não será implementado pelos motivos já fornecidos.

É imperativo que um build funcione exatamente da mesma forma de host para host, e ter coisas que dependem de ter o host configurado de uma maneira particular (ou seja, Dockerfile em algum lugar aleatório e contexto em algum outro lugar) quebra este contrato.

Acho que # 7115 é provavelmente a solução adequada para isso

Há também # 7204 que também caberia em grande parte do caso de uso para isso, eu acho.

Não gosto das duas soluções propostas envolvendo a adição de sintaxe ao dockerfile. Nenhum deles parece direto. # 7115 ainda não parece que resolveria o caso de uso em que eu queria gerar vários tipos de imagem a partir de um único repo, como estou, por exemplo, fazendo em um dos meus projetos para gerar uma imagem de 'teste' e uma imagem 'prod'. # 7204 parece uma solução muito complicada que resolve um problema diferente -f permite _configurabilidade_ para uma construção, enquanto ambas as soluções abordam _sub_builds_.

Eu realmente gostaria de uma explicação de "É imperativo que uma construção funcione exatamente da mesma forma de host para host". Não vejo por que esse princípio é tão importante.

Do jeito que está, estou usando make para gerar o ambiente docker como uma solução alternativa para todo esse problema, que parece que já viola seu imperativo de host para host.

Para mim, -f parece uma solução pragmática, mas se não for aceitável, talvez possamos pensar em uma solução que não envolva transformar o dockerfile em uma sintaxe de programação totalmente desenvolvida.

É imperativo que uma construção funcione exatamente da mesma forma de host para host

Eu também gostaria de ouvir mais sobre por que isso é fundamental. Nossa equipe está atualmente
forçado a criar um script do processo de construção - exatamente o que você está tentando evitar.

Quando eu baixa uma imagem de um registro, ela simplesmente funciona. Eu não preciso
construa. Isso não é alcançar a repetibilidade de host para host? Por que construir?
também tem que repetir de host para host?

Na segunda-feira, 28 de julho de 2014 às 10:43, Peter Braden [email protected]
escreveu:

Eu não gosto das duas soluções propostas envolvendo a adição de sintaxe ao
dockerfile. Nenhum deles parece direto. # 7115
https://github.com/docker/docker/issues/7115 ainda não parece
resolveria o caso de uso em que eu queria gerar vários tipos de imagem
de um único repo, como estou, por exemplo, fazendo em um dos meus projetos para
gere uma imagem de 'teste' e uma imagem de 'produção'. # 7204
https://github.com/docker/docker/pull/7204 parece um
solução muito complicada que resolve um problema diferente -f permite
_configurabilidade_ para uma construção, enquanto ambas as soluções abordam
_sub_builds_.

Eu realmente gostaria de alguma explicação de "É imperativo que uma construção funcione
exatamente o mesmo de host para host ". Não vejo por que isso é tão importante
princípio.

Como está, estou usando make para gerar o ambiente docker como um
solução alternativa para todo este problema, que parece que já viola o seu
host-a-host execute o mesmo imperativo.

Para mim, -f parece uma solução pragmática, mas se não for aceitável,
então talvez possamos pensar em uma solução que não envolva transformar o
dockerfile em uma sintaxe de programação totalmente desenvolvida.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/docker/issues/2112#issuecomment -50347483.

Pelo que eu entendo, a ideia principal é que você pode obter um repositório git e, se encontrar um Dockerfile lá, poderá executar "docker build -t mytag". nele e obtenha a construção completa esperada. A chave aqui é que não há instruções de construção personalizadas que as pessoas possam errar ou desconhecer.
O que _poderia_ ser um meio-termo é uma maneira de definir várias imagens do Docker em um único contexto onde, por padrão, todas elas são construídas com subtags predefinidas e então você poderia ter a opção de construir apenas uma das muitas imagens possíveis.
Desta forma, a sintaxe comum de construção é preservada, ao mesmo tempo que permite: 1) gerar muitas imagens diferentes de um contexto; 2) optar por gerar apenas um deles com uma opção "avançada".
A sintaxe proposta é descrita em meu comentário acima - https://github.com/docker/docker/issues/2112#issuecomment -48015917

@algarius obrigado, acho que agora devemos abrir uma nova proposta de design para a sintaxe _INCLUDE_. Para exemplos de propostas de design, consulte # 6802 ou # 6805.

O processo é assim:

• Enviar proposta de design
• Discuta a proposta de design
• Eu aprovo a proposta de design
• Enviar PR para proposta de design

Vamos ser honestos, as compilações não podem ser repetidas agora.

Se eu tiver RUN apt-get update && apt-get install build-essentials ruby python whatever em meu Dockerfile, então já estou à mercê de
tudo o que é "mais recente" nos repositórios no ponto em que construo a imagem. Se
VOCÊ constrói a imagem uma semana depois, você pode muito bem obter diferentes versões de
dependências para as que eu tenho.

@codeaholics Mas isso é

Provavelmente um comentário justo

@codeaholics, você está certo ao dizer que a repetibilidade das compilações não é perfeita, embora existam opções para controlá-la (como a fixação de versão) e deveríamos fornecer mais. Mas pelo menos a construção sempre tem o mesmo _ponto de entrada_, o que significa que _podemos_ introduzir uma melhor repetibilidade no futuro. No entanto, uma vez que sua compilação depende de uma ferramenta 3d-party upstream do próprio Docker, não há como voltar atrás: a repetibilidade de sua compilação é basicamente zero e nenhuma melhoria futura do Docker pode consertá-la.

Não se trata apenas de repetibilidade. Se sua construção depende de um determinado conjunto de argumentos, não detectável por _docker build_, então sua ferramenta customizada é a única ferramenta de construção no mundo que pode construí-la: você não pode mais se beneficiar das várias ferramentas CI / CD e plug-ins que assumem um _docker build_ nativo detectável.

@peterbraden em # 7115, depois de adicionar a capacidade para várias chamadas PUBLISH , agora você pode produzir várias imagens. Em seguida, você pode adicionar configurabilidade, permitindo a seleção de sub-imagens a serem construídas. A chave é que a configurabilidade ocorre _dentro do conjunto de sub-imagens detectáveis ​​pelo Docker_. Dessa forma, você preserva a descoberta.

@shykes > uma vez que sua construção depende de uma ferramenta 3d-party upstream do Docker
em si ... a repetibilidade da sua construção é basicamente zero.

Eu concordo. Acho que a maioria dos meus Dockerfiles dependem do apt e dos repositórios apt
estão mudando constantemente. Uma construção hoje não é o mesmo que uma construção
ontem. Uma imagem construída é o único padrão ouro imo.

Se a repetibilidade não for o principal motivo da restrição, o plug-in CI
o suporte parece um recuo muito fraco. Ferramentas de construção são projetadas para
suporte a casos de uso idiossincráticos. Um plugin que não faz nada mais do que
configurar um docker build cmd parece bastante inútil. Minha ferramenta de construção é
já é um ambiente de script. Pior, escavando todo o potencial
casos de uso no Dockerfile com o tempo parece uma maneira ruim de arquitetar
isto. O Dockerfile deve se concentrar em simplesmente produzir uma nova imagem por
adicionar camadas a uma imagem de base. Outro trabalho parece fora da banda.

Eu amo o Docker até agora. Ótimo trabalho, pessoal! Este problema específico simplesmente acontece
para ser um ponto de dor.

Na segunda-feira, 28 de julho de 2014 às 12h25, Solomon Hykes [email protected]
escreveu:

@peterbraden https://github.com/peterbraden em # 7115
https://github.com/docker/docker/issues/7115 , depois de adicionar a capacidade
para várias chamadas PUBLICAR, agora você pode produzir várias imagens. Então você
pode adicionar configurabilidade, permitindo selecionar quais sub-imagens construir.
A chave é que a configurabilidade ocorre _ dentro do conjunto de
sub-imagens detectáveis ​​pelo Docker_. Dessa forma, você preserva a descoberta.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/docker/issues/2112#issuecomment -50361586.

@thedeeno, o objetivo do Dockerfile é especificar como transformar um repositório de código-fonte em algo que o Docker possa executar.

Que tal "o objetivo do _a_ Dockerfile é especificar como transformar um repositório de código-fonte em algo que o Docker possa executar."

Acho que podemos concordar que existe uma necessidade real de uma maneira de ter vários repo-> mapeamentos de imagens. Como está, muitos de nós estamos abusando de scripts de shell e makefiles para fazer isso. Em minha experiência, não vi muitos Makefiles personalizados com o nome - a configuração e os padrões são uma força poderosa. Por isso, não estou convencido de que as pessoas que abusam das convenções sejam um cenário realista.

A alternativa que você propõe, adicionar uma palavra-chave à sintaxe do Dockerfile, torna a criação de Dockerfiles mais complexa. Sou a favor de manter essa sintaxe o mais simples possível. PUBLISH et al, parecem deselegantes em comparação com o resto da sintaxe do Dockerfile.

Também existe a ideia de seguir as convenções de ferramentas existentes. Como foi mencionado, -f é um padrão tão comum que as pessoas o tentam sem saber que funciona. Uma IU deve ser intuitiva e as pessoas _get_ -f sinalizam. A nova sintaxe do Dockerfile não é tão intuitiva.

@peterbraden @shykes Concordo em -f ser mais simples e intuitivo. Eu originalmente encontrei esse problema porque eu _esperei_ que o Docker já tivesse esse recurso e procurei por ele (provavelmente quando não funcionava por padrão) no primeiro dia em que comecei a testá-lo para nossos aplicativos.

Este não é um caso extremo, a menos que você esteja em uma situação em que não teste seu software ou execute-o em vários ambientes. Cada repo que toquei nos últimos 10 anos tem um requisito para poder ser executado em diferentes contextos. Acho que muitas pessoas neste tópico têm o mesmo problema. Estamos todos de acordo (eu acho) que ter convenção é obviamente valioso para o contexto padrão de seu aplicativo (supondo que você tenha um).

Eu li # 7115 (rapidamente) e não entendo como ele resolve esse problema para nós, talvez seja um problema de documentação no PR, mas se for difícil de se comunicar, vai causar frustração e erros IMO, enquanto -f ou um sinalizador semelhante exigiria pouco esforço para ser explicado e usado corretamente.

Criou uma nova proposta com essa ideia INCLUIR - https://github.com/docker/docker/issues/7277

Como uma observação lateral - pode valer a pena pensar em um comando "APT" mais eficiente em vez do desajeitado "RUN apt-get install -y ...." (e, posteriormente, YUM, EMERGE, PACMAN e tudo o mais)

Ah, e considerando que muitas pessoas realmente tentam a opção "-f" de qualquer maneira, seria interessante se, sempre que você tentar usá-la, obtivesse uma bela mensagem de erro direcionando-o para uma página na documentação que descreve a nova solução.

Eu realmente acho que todos nós estamos ignorando o elefante na sala.

@shykes está dizendo coisas como "O fato de você poder apontar para um diretório de código-fonte, sem outras informações fora da banda, e construir uma imagem a partir dele exatamente de acordo com as especificações do desenvolvedor upstream, é muito poderoso e principal diferenciador do Docker. "

Tenho certeza que isso é equivalente a dizer "digitar docker build . em um diretório deve absolutamente sempre fazer a coisa certa", o que é equivalente a dizer "Se você tem um projeto onde não há uma coisa certa óbvia para docker build . a fazer, você está errado "

Não posso falar sobre as motivações de outras pessoas que aderiram a esse problema, mas minhas próprias motivações para esse problema são exatamente aqueles casos em que docker build . não tem um comportamento óbvio. Eu queria uma versão de depuração ou de lançamento? Eu queria o postgres integrado ou devo emitir imagens separadas do app e do postgres? Eu queria que ele fosse carregado com dados de teste ou dados de produção? Eu quero fazer os testes?

Claro, eu gostaria de viver em um mundo onde as pessoas não precisassem responder a essas perguntas para obter uma construção. Mas eu não vivo nesse mundo. Claro que eu poderia escolher arbitrariamente algumas respostas para essas perguntas e definir um comportamento para docker build . . Mas o fato é que construir algo arbitrário quando o usuário digita docker build . não está "fazendo a coisa certa".

A realidade da situação é que há projetos em que não há nada óbvio que seja certo construir. Existem várias maneiras de resolver isso dentro do docker, como -f support, ou fazer o usuário escolher em uma lista de destinos importados de outro lugar, ou várias outras propostas. Mas todos eles

A ideia de que todo projeto pode escolher algo sensato para fazer por docker build . é uma fantasia. Projetos que possivelmente não podem fazer algo sensato existem, e em número. A única questão neste ponto é se o Docker vai suportar a natureza multi-buildproduct desses projetos diretamente ou se eles vão recorrer a ferramentas de construção tradicionais como make ou mesmo scripts de shell. Isso está acontecendo agora : por exemplo, Discourse, um dos maiores projetos distribuídos no Docker, usa um sistema de construção caseiro em parte para resolver esse problema.

@drewcrawford sabe, esse é exatamente o problema. "construção docker." deve construir _a_ imagem. A única imagem verdadeira. Você deve alterar os parâmetros de execução do docker para ajustar o comportamento da única imagem para ambientes diferentes.
Nesse contexto, você provavelmente deseja uma versão de lançamento, apenas o aplicativo, nada mais. Todas as outras coisas, como "a imagem do postgres" são coisas diferentes que são vinculadas ao seu aplicativo em tempo de execução. Você pode pegar a mesma imagem de lançamento e executá-la com um comando não padrão para executar seus testes nela.
Idealmente, com suporte a várias imagens, você não precisa nem escolher entre as compilações "liberar", "depurar" e "com testes" - você apenas tem todas elas com uma compilação base e 3 pequenas compilações de diferença no topo.
Se você tentar fazer com que o Docker volte à velha maneira de pensar, vai passar um mau bocado. Não tente martelar um parafuso com uma chave de fenda.

@algarius Acho que o problema é que esse pensamento não se aplica a aplicativos reais, e ninguém explicou como isso aconteceria se realmente deveríamos ter uma mudança de paradigma aqui.

Permitir várias imagens é a maneira mais simples e intuitiva de dar suporte ao requisito que a maioria dos aplicativos acessíveis de rede do mundo real têm (vários ambientes com dependências diferentes). É desejável tornar a gramática mais complicada de uma forma que não pode ser comunicada para resolver isso? No final, você está apenas reengenharia e ofuscando o fato de ter> 1 ambiente com dependências diferentes que podem ser facilmente expressas de uma maneira simples como vários Dockerfiles que quase não precisam de explicação para os usuários finais do software.

@drewcrawford forneceu um exemplo concreto de como isso é tratado em um aplicativo popular do mundo real atual que é distribuído com suporte Docker. Como eles deveriam estar fazendo isso?

@aigarius Não é que eu não entenda "o jeito docker". Eu só acho que está errado.

Por exemplo, os testes podem precisar de uma compilação diferente - um _recompile honesto-a-deus _-- porque determinado código de registro que é muito lento para produção deve ser compilado condicionalmente.

Se isso soa como um trabalho para um sistema de criação, você está certo - e isso é de fato o que pessoas como eu fazem, elas encontram maneiras de criar scripts de compilação do docker usando sistemas de compilação reais.

O problema aqui é que um Dockerfile não pode ser a interface de usuário preferida para construção e também substancialmente menos poderoso do que, por exemplo, make . Pode ser a interface de usuário preferencial para construção, com poder semelhante ao do makelike, ou pode ser uma ferramenta de baixo nível com make etc. como a interface de usuário real. Mas os sistemas de compilação "reais" não são arbitrariamente complicados - eles são complicados porque as pessoas usam os recursos e nenhuma quantidade de compilações docker simplificadas vai mudar isso. Tudo o que acontecerá é que o docker se tornará o novo cc , que as pessoas invocam com make .

@shykes @drewcrawford @aigarius Eu escrevi uma proposta para uma opção -f simples da mesma maneira que @shykes descrito anteriormente neste tópico aqui: # 7284

@drewcrawford você está certo, para ser a interface de usuário preferida para construção, docker build precisa ser pelo menos tão poderoso quanto, por exemplo. make . Existem 2 maneiras de fazer isso:

• 1) Poderíamos tentar reimplementar todos os recursos de cada variação do make, bem como todas as alternativas disponíveis: Maven, scons, rake e, claro, os bons e velhos scripts de shell.

OU

• 2) Podemos reconhecer que essas ferramentas de compilação são, elas mesmas, programas executáveis, o que significa que têm dependências de tempo de execução e foram construídas a partir de dependências de compilação - e assim por diante. E poderíamos fornecer uma maneira para você _realmente usar_ sua ferramenta de compilação favorita. Portanto, não precisaríamos reimplementar o make porque podemos realmente construir e executar o make.

Quando você diz make , a qual sabor do make você está se referindo? Qual versão? Construído a partir de qual checkout svn exatamente? Com quais opções de construção? A qual libc ele está vinculado? Mesma pergunta para cc que você também mencionou. Talvez isso não importe - talvez seu aplicativo saia exatamente da mesma forma, independentemente de qual versão aleatória de make eu acabar usando para construir. Mas, novamente, talvez isso importe. Talvez a única maneira de obter exatamente a mesma compilação que você é usar exatamente a mesma compilação de Make e Cc que você usou. E não há maneira fácil de fazer isso hoje - mas é o que eu gostaria de fazer.

Eu realmente não penso em docker build como uma ferramenta de construção, exatamente - mais como uma ferramenta de meta-construção: um ponto de partida conhecido a partir do qual você pode reconstituir qualquer ambiente de construção de forma confiável. Essa é a motivação para # 7115.

@shykes Não acho que seja necessário replicar _todo_ recurso do make, Maven, rake, etc. Afinal, essas ferramentas não replicam todos os recursos umas das outras e, de alguma forma, elas se dão bem.

No entanto, é necessário (se o Docker for a interface de usuário preferida para a construção de imagens) que o Dockerfile se torne uma linguagem mais expressiva do que é atualmente.

A proposta nesta edição é realmente um movimento modesto ao longo dessa linha: está dizendo "Precisamos de um equivalente para os _targets_ do make". A questão de "qual versão do make" realmente não entra em cena - o conceito de um "alvo" é comum para fazer, Maven, rake e todos os outros sistemas de construção sérios. Eles têm sintaxe diferente, mas o fato de o recurso em si ser universal deve ser uma pista de que isso é algo que as pessoas fazem com frequência quando constroem coisas.

Não importa se o que eles estão construindo é um programa C, uma imagem Docker ou qualquer coisa intermediária - você ainda está construindo algum destino. A ideia de um alvo de construção é tão fundamental que abrange implementações de sistemas de construção, linguagens de programação e sistemas operacionais. Não estamos falando sobre replicar algum recurso obscuro específico do GNU Make, estamos falando sobre algo que tem o acordo mais amplo possível.

Você está tentando introduzir algum conceito de "ferramenta de meta-compilação" aqui, mas não existe tal coisa. Assim como o docker pode orquestrar compilações do make, também pode orquestrar compilações do docker e, na verdade, o make está sendo usado exatamente dessa forma, porque não há como especificar um destino de compilação para o Docker. Mas, de qualquer forma, nenhum sistema é inerentemente mais ou menos meta do que o outro, eles são apenas sistemas de construção, que constroem alvos, mas no caso de Docker, você só tem permissão para um, que é o problema.

Propostas como o # 7115 são interessantes, mas, a menos que esteja faltando alguma coisa, elas não são um substituto eficaz para as metas. Um alvo diz a você o que construir. # 7115 oferece uma DSL mais flexível que ainda pode construir apenas uma coisa. Isso é alguma coisa, mas não é o que está sendo solicitado aqui.

docker build -t my_project_builder .
# Builds the builder container
docker run my_project_builder my_target | docker build -t my_project/my_target -< Dockerfile_MyTarget
# target is built, tarballed, and sent to stdout, then piped into a new docker build as the context and custom Dockerfile name

@drewcrawford apenas para confirmar, se docker permitia algo equivalente a Criar alvos, para que você pudesse 1) especificar qual alvo construir, por exemplo. make clean; make foo , 2) padrão para construir _todos_ os alvos e 3) tem uma maneira de enumerar os alvos ... Isso seria satisfatório para você?

Isso seria satisfatório ... Eu preferiria padronizar para um alvo escolhido pelo desenvolvedor em vez de padronizar para todos os alvos, mas eu aceitaria qualquer solução

Isso é bom.

@shykes @drewcrawford : +1:

Tudo o que acontecerá é que o docker se tornará o novo cc, que as pessoas invocam com o make.

A proposta nesta edição é realmente um movimento modesto ao longo dessa linha: está dizendo "Precisamos de um equivalente para fazer as metas". A questão de "qual versão do make" realmente não entra em cena - o conceito de um "alvo" é comum para fazer, Maven, rake e todos os outros sistemas de construção sérios. Eles têm sintaxe diferente, mas o fato de o recurso em si ser universal deve ser uma pista de que isso é algo que as pessoas fazem com frequência quando constroem coisas.

@drewcrawford : +1: +1.000.000

Esta é a situação que sempre enfrento:

Quero construir dois contêineres Docker a partir do meu repo. Talvez seja o servidor, é o banco de dados. Ou talvez um seja o servidor e o outro seja um cliente que executa testes automatizados no servidor por meio de chamadas de API.

Em qualquer caso, há alguns arquivos no repositório que preciso ADICIONAR para esses dois contêineres. No estado em que se encontra, é impossível fazer isso sem recorrer à cópia dos Dockerfiles separados um por vez em um script bash, fazendo a construção e, em seguida, substituindo ou excluindo o Dockerfile.

Eu preciso de:

1. O comando -f para especificar o arquivo a ser usado como Dockerfile.
2. A capacidade de ADICIONAR um arquivo, não no caminho do Dockerfile.

Como já foi dito repetidamente que o número um é proibido e presumo que o número dois seja ainda mais difícil tecnicamente, qual é a maneira "adequada" de fazer isso?

@ShawnMilo

O último comentário de

@jakehow Obrigado pela atualização. Portanto, parece que uma solução oficial para o problema ainda está longe. Nesse ínterim, existe uma "boa maneira" de fazer isso? A melhor ideia que tenho é um script bash que copia os arquivos um de cada vez para "Dockerfile" na raiz do repo e cria as imagens. Vai funcionar, mas parece sujo.

@ShawnMilo sim, acho que a maioria das pessoas está usando uma ferramenta de construção (make, rake, etc) ou apenas um script bash antigo para fazer isso.

Acima, alguém mostrou um snippet onde há uma imagem de construtor que também trata disso.

Esta é minha maneira de lidar com esse problema. Tenho que construir uma imagem para diferentes versões de uma plataforma, digamos v2 e v3. Então, eu tenho um Dockerfile.v2 e um Dockerfile.v3 Quando quero fazer uma compilação, executo primeiro ln -s ./Dockerfile.v3 ./Dockerfile depois docker build . Na verdade, tenho um script e acabei de executar ./build v3 ou ./build v2

Embora eu esteja usando atualmente um script que vincula um Dockerfile especificado a ./Dockerfile , este seria um bom recurso.

Criei um PR # 7995 para tentar resolver isso. Algumas das soluções que são discutidas neste tópico (longo :-)) parecem terrivelmente dolorosas para as pessoas usarem. Um dos maiores pontos de venda do Docker (para mim) era como ele é fácil de usar e, portanto, pedir para as pessoas passarem por esse tipo de obstáculos pelo que parece ser uma pergunta muito fácil não parece certo.

Agora, é possível que eu esteja faltando alguma coisa, mas há uma razão técnica pela qual ele deve ser chamado de "Dockerfile"? Ao criar o PR, não consegui encontrar um e fiquei agradavelmente surpreso com a facilidade de alteração.

@duglin você tem todo o meu apoio.

Isso é o que estamos fazendo para contornar a falta de uma opção -f em nosso projeto atual.

# build.sh
...
mv specialDockerfile Dockerfile
docker build -t $(PROJECT) .

Considere isso um +1 ao adicionar -f .

Atualmente também estou gerenciando coisas como kikito. Eu escrevi alguns scripts de shell para construir imagens diferentes do mesmo contexto, mas adoraria ver uma maneira de especificar um arquivo docker a partir do argumento CLI, conforme já sugerido. 1 para este pedido.

+1000

Eu me deparei com isso hoje ao tentar construir um projeto de plataforma cruzada golang usando docker. Isso funciona, consulte boot2docker , mas preciso de um Makefile para costurar o interior e o exterior do processo de compilação do docker, por exemplo, docker cp os artefatos de dentro do docker para o meu diretório de compilação.

No entanto, se eu tentar usar isso em um subdiretório do meu repo, meu GOPATH será corrompido, pois a pasta .git na raiz do repo está faltando. Preciso ADD a raiz do repo e, em seguida, construir dentro do meu subdiretório, mas isso não é permitido pelo docker.

Depois de ler este longo tópico, percebi uma preocupação em não ser capaz de reproduzir compilações. Uma maneira de atenuar isso é permitir que apenas a opção -f aponte dentro do contexto de construção ou para baixo. Dessa forma, você pode ter vários Dockerfiles em subdiretórios e criá-los a partir da raiz do repo. Além disso, você pode limitar isso para estar dentro dos limites do repo, por exemplo, no mesmo nível que .git / .hg / .foo e abaixo, mas não fora do repo.

Aqui está o que estou pensando

FROM scratch
BUILD myname1 path/to/dockerfile/in/context
BUILD myname2 path/to/dockerfile2/in/context

docker build -t myimage .

Isso produziria 3 imagens:

1. Imagem principal chamada "myimage", que não contém nada para servir de exemplo
2. Uma imagem chamada myimage-myname1
3. Uma imagem chamada myimage-myname2

A palavra-chave BUILD levaria um nome e um caminho para um Dockerfile. Este Dockerfile deve estar dentro do contexto original.
Cada instrução de construção teria acesso ao contexto completo da construção principal.
Embora possa valer a pena limitar o contexto à árvore dir na qual o Dockerfile está contido.

-1

Você poderia usar um alimentador de contexto para docker build - como dockerfeed para este caso especial.

@itsafire O objetivo é trazer esse tipo de funcionalidade para o Docker para que esta seja uma forma suportada de construir seu projeto. Tenho certeza que as pessoas adorariam que isso funcionasse com compilações automatizadas também.

Estou perdido aqui. Temos várias solicitações de pull para esse recurso adicionado, certo? E não parece tão difícil de fazer ... Pode-se até mesmo aplicar a regra que @maxnordlund mencionou: restringir o caminho para ser relativo ao contexto / raiz. Isso pelo menos faria com que funcionasse mais suavemente com boot2docket e outros, e o tornaria "portátil".

Esta é de longe a lacuna mais irritante no Docker, e à medida que mais e mais ferramentas começam a usar o Docker como parte de sua funcionalidade, é importante que adicionemos rapidamente a capacidade de um sinalizador '-f' para que essas ferramentas sejam preparadas para que antes de se tornar muito final ... Relacionado: ter um Dockerfile com várias imagens não é suficiente, já que essas ferramentas "meta" relacionadas geralmente assumem _uma_ imagem por Dockerfile! Além disso, o uso de '-' não funciona com essas ferramentas e restringe severamente a funcionalidade, como todos sabemos.

Alguém com autoridade pode explicar por que essa correção ainda não foi mesclada ou, pelo menos, por que esse recurso que está faltando ainda não está lá?

Começando a me sentir como Twilight Zone.

Acho que há uma falta de correspondência em como a equipe do Docker usa o Docker / deseja que o Docker seja usado e como uma grande parte da comunidade usa o Docker. Corrija-me se eu estiver errado.

A equipe do docker quer construir um repositório de software não muito diferente do repositório do projeto Debian. Onde as pessoas podem obter seu software favorito e executá-lo facilmente. O processo de construção do software deve ser repetível e óbvio.

Outros desejam automatizar a implantação de software interna existente, que já pode ser altamente complexa com muitas ferramentas de construção, sistema de CI etc. Para eles, o Docker é apenas mais uma ferramenta que deve se encaixar em sua infraestrutura. E eles precisam de um pouco mais de flexibilidade em como podem usar o Docker.

Acho que o Docker (como .deb) pode satisfazer as necessidades de ambas as partes, mas será preciso fazer concessões.

O problema básico é: onde isso termina? Completude de Turing para Dockerfile? Provavelmente não. Sempre haverá necessidade de mais flexibilidade para resolver um caso especial. Algumas ideias entrarão na linguagem Dockerfile, outras não. Como o docker é capaz de comer um contexto por meio de stdin em uma construção, a funcionalidade ausente pode ser implementada por meio de um pré-processador.

@itsafire Da última vez que verifiquei, o docker consegue comer um Dockerfile mas não um contexto. Na verdade, o contexto é ignorado quando você fornece um Dockerfile dessa maneira. Se eles adicionassem suporte para o que você sugeriu, este seria um problema encerrado.

Eu não olhei por um tempo, mas a solicitação básica é esta: nos dê uma maneira explícita de fornecer um Dockerfile E um context durante a compilação. Honestamente chocado, isso parece 8 meses depois e ainda está aberto.

@thedeeno isso é realmente possível
cat mystuff.tar.gz | docker build -

@ cpuguy83 mas não posso fornecer um Dockerfile explícito com esse comando. Direito?

@thedeeno sim, você tará qualquer Dockerfile que quiser com o contexto que quiser.

@ cpuguy83 @thedeeno Não, isso não funciona, porque você não pode ADICIONAR nenhum arquivo porque nenhum está no escopo "cwd" que você geralmente obtém com um Dockerfile.

Edit: Esta afirmação está errada; Eu entendi mal o exemplo de @ cpuguy83 .

@ShawnMilo sim, é. Qualquer coisa no tar está dentro do contexto.

@ cpuguy83 Desculpe, meu erro. Eu li apressadamente como apenas um piping no Dockerfile, não um tarball inteiro.

@ cpuguy83 Legal! Eu voto fechado, então, se funcionar como você sugere.

Pergunta lateral, em minha solução personalizada, os timestamps quebraram o cache durante a taragem. Isso ainda é um problema? Se eu tar a mesma pasta várias vezes, ele usará o cache na compilação?

Continue com o ótimo trabalho!

Canalizar todo um contexto não alivia de forma alguma o que falamos acima.

O que queremos e precisamos é uma maneira de usar o contexto _same_ com vários Dockerfiles. Tal como o já mencionado "construir com registro" e "construir sem registro", como imagens individuais. Tenho muitos outros casos de uso em que isso é necessário.

Não consigo ver como tar-ball um diretório ajudaria nisso. Sim, pode-se criar um diretório especial e copiar o Dockerfile específico para lá e, em seguida, todo o diretório de contexto, ou tar e anexar um novo Dockerfile e depois gzipar. Mas como isso é mais fácil do que a [terrível] solução alternativa que atualmente temos que empregar de ter um script de pré-processador colocando o Dockerfile correto no lugar antes de executar o docker?

E isso não ajudará na ecologia do Docker, como observei acima.

Eu perdi alguma coisa?

Novamente, uma opção '-f' simples. Por favor. Por favor, muito por favor. Force-o a ser um caminho relativo do contexto. Está bem.

@davber O que você realmente deseja é que o Docker lide com o tarball do contexto e do Dockerfile para você.
E não sou totalmente contra isso. Embora eu ache que as compilações aninhadas podem ser uma solução melhor para isso.

@ cpuguy83 : sim, então quero que o Docker cuide disso para mim, sim, o que incluiria escolher a parte do contexto de um lugar e o Dockerfile de potencialmente outro lugar, ou com um nome não padrão. Ou seja, para suportar um sinalizador '-f' separado :-)

As compilações aninhadas não resolvem os problemas que enfrentamos, que iniciaram este segmento e o mantém funcionando.

Ou seja, ainda queremos usar o mesmo contexto raiz.

Sim, podemos copiar arquivos e, sim, fazemos para contornar esse estranho acoplamento de contexto com um Dockerfile exato chamado 'Dockerfile'. Mas isso não é o ideal, e configurar o rsync para garantir que os arquivos sejam realmente idênticos aos originais é simplesmente estranho.

@ cpuguy83 : você pode explicar como as compilações aninhadas me ajudariam, ou qualquer outro "chorão" aqui? :-)

@davber
Minha opinião sobre isso é:

FROM scratch
BUILD myname1 path/to/dockerfile
BUILD myname2 path/to/another/dockerfile

E isto:

docker build -t myimage .

Resultaria em 3 imagens, "myimage", "myimage-myname1", "myimage-myname2".
Cada construção interna teria acesso ao contexto de construção completo como caminhos absolutos. Caminhos relativos seriam relativos ao Dockerfile.
E o "myimage" pode ter seu próprio material além das instruções de CONSTRUÇÃO.

Como mencionei antes, muitas das novas ferramentas na grande (e excelente!) Ecologia do Docker presumem que cada Dockerfile está associado a exatamente uma imagem do Docker. As várias ferramentas de orquestrador do tipo "Fig" por aí. E muitas das soluções de nuvem novas e antigas com suporte específico para Docker também têm essa suposição de um para um. Concedido, eles seriam criados por uma opção '-f' e teriam não apenas de obter um contexto - como um tar ball, por exemplo - mas também um Dockerfile potencialmente separado. Mas cada upload ainda corresponderia a exatamente uma imagem Docker.

Se seguirmos o caminho de separar potencialmente o Dockerfile da raiz de contexto, espero que essas ferramentas comecem a conviver com este cenário:

Each deployment/use of a Docker image is done with an upload of either:

   1. a Dockerfile solely, when no contextual operations are needed
   2. a context tar ball only, containing the context with a top-level Dockerfile
   3. both a context tar ball and a separate Dockerfile

Quanto mais tempo permanecermos com esse forte acoplamento de 'Dockerfile' no nível superior do contexto, mais arraigado estará na ecologia. Ou seja, devemos agir agora, pois o mundo Docker se move rapidamente, devido à grandiosidade geral.

E, honestamente, essa é uma suposição razoável e conceitualmente atraente, ter um isomorfismo entre Dockerfiles e imagens, mesmo que o primeiro seja estritamente um espaço de produto de diretórios de contexto (tared up ...) e Dockerfiles, padronizando para (null, ) se apenas o Dockerfile for fornecido e (contexto, contexto / 'Dockerfile') se apenas o contexto for fornecido.

E mesmo para implantação local: digamos que queremos usar o Fig para pelo menos orquestração local: como alguém faria isso? O que seria necessário fazer é pré-criar as imagens de um Dockerfile multi-build e, em seguida, consultar essas imagens na Fig. Não ideal.

um isomorfismo entre Dockerfiles e imagens

Essa suposição já foi quebrada em como as pessoas neste thread estão usando Dockerfiles. Ou seja, usando scripts para substituir o Dockerfile manualmente antes de executar a compilação do docker. Eles provavelmente também têm sua própria orquestração. Esta solicitação de recurso não se trata de alterar a paisagem do docker, trata-se de fazer o docker funcionar para um tipo específico de uso.

@hanikesn : dois comentários:

1. por que essa suposição é quebrada por ter que copiar Dockerfiles para o lugar antes de construir; ainda seria um Dockerfile <-> uma imagem?
2. o que estou argumentando é que quero qualquer solução que possamos encontrar aqui para _trabalhar com_ a paisagem Docker existente e em crescimento, sem a necessidade de grandes mudanças nessa paisagem; e eu acho que _ mantendo_ esse isomorfismo mencionado, nós o fazemos.

Outras sugestões aqui foram ter um Dockerfile de várias imagens, potencialmente chamando para sub-Dockerfiles. Isso não funcionaria com a forma como a maioria das ferramentas (Fig etc.) usa o Docker atualmente.

@davber

As compilações aninhadas não resolvem os problemas que enfrentamos, que iniciaram este segmento e o mantém funcionando.

Proponho esta solução que já indiquei anteriormente:

$ docker-pre-processor [ --options ... ] . | docker build -

Considerando que --options são as regras, o contexto no (aqui) diretório atual deve ser alterado e passado para o docker. Isso deve ser feito em tempo real, criando um arquivo tar temporário contendo o contexto. Dessa forma, o contexto de origem pode permanecer intocado. É mais fácil alterar o pré-processador do que a sintaxe do Dockerfile.

@itsafire

E as ferramentas que esperam Dockerfiles hoje? Eles estão se tornando mais abundantes, usando Amazon, Google ou outros. E Fig e estruturas de orquestração semelhantes.

Teríamos então que empurrar uma ferramenta padronizada de 'docker-pré-processador' e o uso de tal ferramenta para essas estruturas, provedores e ferramentas.

Com certeza seria muito mais fácil ter o suporte adequado para 'docker' pelo menos a opção que aciona este thread.

@itsafire todos com este problema que o resolveram já estão usando algum tipo de pré-processador ou wrapper em torno da construção do docker para atingir esse objetivo.

A fragmentação em torno dessa situação está em conflito com a meta declarada de 'repetibilidade' da equipe @docker . Esta discussão e as outras são para resolver esse problema.

Mais de 1 ano e mais de 130 comentários e contando para um problema simples que afeta a maioria dos usuários ... Estou impressionado. Continue com o bom trabalho, Docker!

+1

As ferramentas devem ajudar as pessoas a seguirem seus próprios caminhos, mas não a impor o caminho "certo". Um caso simples que me trouxe a esta discussão:

`-- project
     |-- deploy
     |    |-- .dockerignore
     |    |-- Dockerfile
     |    ...
     `-- src

Minha maneira é manter a raiz do projeto limpa. Mas ADD ../src e -f deploy/Dockerfile não funcionam. Por enquanto eu tenho Dockerfile e .dockerignore na raiz do projeto, mas é uma dor para mim.

De minha parte, criei um script que prepara uma pasta com os arquivos necessários e executa a linha de comando padrão docker build -t my/image . pois encontrei o problema de que o arquivo .dockerignore é ignorado pelo ADD ...

1 com certeza gostaria de poder ter vários Dockerfiles em um único repo. Meu caso de uso: uma imagem é para uso e implantação de produção, outra imagem é uma instância de relatório projetada para usar as mesmas ferramentas de back-end e conectividade de banco de dados, mas não requer front-end, web, serviço de sistema ou supervisão de processo ...

1 para isso. Preciso adicionar arquivos a imagens diferentes da mesma pasta, para servidores diferentes.

1 Estou gostando do Docker até agora, mas devido à maneira como minha equipe configurou, eu realmente preciso de uma maneira de construir diferentes implementáveis ​​que compartilhem um bom pedaço de código, a partir de um repo. Não estou particularmente interessado em construí-los todos em um contêiner uberdocker, já que seus ciclos de implantação / lançamento são desnecessariamente amarrados. Qual é a prática recomendada para contornar isso?

@jfgreen : Coloque vários Dockerfiles onde quiser e nomeie-os como quiser. Em seguida, tenha um script bash que os copia um de cada vez para a raiz do repo como "./Dockerfile", executa "docker build" e os exclui. Isso é o que faço para vários projetos e funciona perfeitamente. Eu tenho uma pasta "dockerfiles" contendo arquivos chamados coisas como banco de dados, base, testes, etc. que são todos Dockerfiles.

@ShawnMilo Obrigado, parece uma solução alternativa bastante razoável.

+1

+1

+1 para -f . Existe um padrão lógico que, se o sinalizador for omitido, o Docker fará _a coisa certa._ No caso de, por qualquer motivo, a visão muito específica da _a coisa certa_ ser para um usuário _a coisa errada_, existe -f . As comparações acima com ferramentas como make são razoáveis. make também é um utilitário muito opinativo, originalmente escrito em 1976 e, como tal, teve um tempo razoável para estabilizar um conjunto de recursos. Acho que é instrutivo que em man make a única bandeira que recebe uma menção na sinopse muito breve seja ... -f .

       make [ -f makefile ] [ options ] ... [ targets ] ...

Não há problema em utilitários opinativos e centrados no ux, mas algumas coisas como -f são acenos pragmáticos para o mundo real em que os usuários vivem. Uma ferramenta deve tornar sua vida mais fácil e não mais difícil. Se eu tiver que escrever um Makefile ou um script de shell para contornar uma ferramenta sem um -f isso é uma falha da ferramenta. Claramente, pelo número de usuários que reservaram um tempo para comentar e avaliaram para +1, o recurso tem uma utilidade significativa mesmo um ano depois de ter sido proposto inicialmente.

+1

+1 (ou uma postagem de blog oficial com a solução alternativa recomendada)

+1

+1

@crosbymichael Eu acredito que isso pode ser fechado agora devido ao # 9707 ser mesclado

VITÓRIA.

Se todos vocês desejam experimentar este novo recurso, você pode baixar os binários para o mestre em:

master.dockerproject.com

Obrigado @duglin !

:aplaudir:

Obrigado @crosbymichael pelo binário! : +1:

Muito bem, galera! :aplaudir:

Então é docker build -f Dockerfile.dev . ? editar: sim