Compose: Adicione `copy` à configuração yaml

Qual é a semântica de copy aqui? Estamos copiando arquivos do host onde docker-compose é executado para o contêiner recém-executado usando docker cp ?

AFAIK, _nenhuma_ maneira atual de fazer isso:

Vejo:

`` `#! bash
$ docker cp -h

Uso: docker cp [OPÇÕES] CONTAINER: PATH HOSTDIR | -

Copie arquivos / pastas de um PATH no contêiner para um HOSTDIR no host
executando o comando. Use '-' para gravar os dados como um arquivo tar em STDOUT.

--help = false Uso de impressão
`` `

Qual é a semântica da cópia aqui? Estamos copiando arquivos do host onde docker-compose é executado para o contêiner recém-executado usando docker cp?

sim

AFAIK, não há maneira atual de fazer isso:

Vejo que o comando docker cp não é capaz de fazer isso. No entanto, ainda é possível acessar os dados do contêiner no lado do host (o que, acredito, é feio)

http://stackoverflow.com/a/24805696/210090

Sim, eu não vou defender que façamos isso. Isso quebrará muitas coisas e suposições sobre o Docker. Isso também depende muito do driver de armazenamento subjacente que está sendo usado. Docker foi feito para ser agnóstico. Acho que _devemos_ uma solução diferente para o seu problema :)

Agora que o docker-1.8 adicionou suporte para cópia em um contêiner por meio de docker cp e swarm-0.4.0-rc2 adicionou suporte para docker cp , seria ótimo revisitar esse problema no nível de composição. Aqui está o caso de uso (que reflete o que realmente fazemos na produção _quase_ agora):

Um arquivo docker-compose.yml que menciona muitos contêineres por tag de imagem construída em CI (ou seja, não usamos build: na produção; talvez pudéssemos agora, mas não funcionou bem com o swarm em versões anteriores) que todos precisam, por exemplo, de arquivos de configuração hadoop estáticos mapeados que correspondam exatamente ao ambiente de implementação. Atualmente, é necessário sincronizar manualmente o diretório no qual docker-compose.yml reside para o caminho exato em _cada_ docker-machine de destino no enxame. Em seguida, adiciona-se uma pilha de volume: linhas.

O suporte a docker cp permitiria a remoção de uma sincronização de arquivo de configuração personalizada em nosso método de implantação de sistema e permitiria um melhor controle de quando as alterações de configuração são injetadas (uma vez que qualquer pessoa que altere os arquivos mencionados nas linhas volume: está afetando todos os contêineres implantados anteriormente (e sempre que as implementações internas relerem a referida configuração, talvez apenas na próxima reinicialização do contêiner, talvez quando várias ferramentas dentro do contêiner forem iniciadas; o que pode ser inesperado) e futuro (o que é esperado).

OTOH, (como mencionado brevemente acima) talvez devêssemos usar build: . A desvantagem aqui é que precisamos escrever um Dockerfile extra por tipo de contêiner de implantação. Um para as imagens criadas pelo CI e um segundo para o injetor de arquivo de configuração estática. copy: na composição apoiada pelas mudanças recentes em docker cp nos permitiria evitar toda essa duplicação.

Ainda parece que usar um volume é a melhor maneira de fazer isso. Não precisa ser um volume de host, deve funcionar com um contêiner de volume de dados.

Bedies docker-machine tem docker-machine scp qualquer maneira que você pode fazer com a preparação da máquina; e então você pode fazer os volumes do host da maneira normal com docker ou docker-compose

"Ainda parece que usar um volume é a melhor maneira de fazer isso. Não precisa ser um volume de host, deve funcionar com um contêiner de volume de dados."
Não consigo ver como isso é melhor quando o alvo é um enxame. AFAICS, não há como expressar que um contêiner de volume de dados deve existir em todos os nós de enxame possíveis.

Você não pode implantar um contêiner de volume de dados no próprio nó via enxame, como faria com qualquer outra estratégia de programação de ala de contêiner?

"A docker-machine Bedies tem docker-machine scp de qualquer maneira, o que você pode fazer com a preparação da máquina; e então você pode fazer os volumes do host da maneira normal eith docker ou docker-compose"
Eu atualmente faço isso. É doloroso. As pessoas que gerenciam as implantações se esquecem de mover os arquivos de configuração. Se fosse compatível com docker-compose yml, isso aconteceria sempre que um contêiner fosse recriado sem a (s) etapa (s) manual (is).

"Você não pode implantar um contêiner de volume de dados no próprio nó via enxame, como faria com qualquer outra estratégia de programação de ala de contêiner?"
Talvez pudéssemos, mas admito que não vejo como em termos de escala.

"Você não pode implantar um contêiner de volume de dados no próprio nó via enxame, como faria com qualquer outra estratégia de programação de ala de contêiner?"
Humm, se eu sei que meu enxame tem tamanho de 10 nós; posso simplesmente dimensionar o contêiner de volume de dados para o tamanho 10 com uma política de que não são permitidos dups em um determinado nó do mecanismo do docker? O problema (a menos que eu tenha esquecido algo) é que, por exemplo, os contêineres que precisam fazer referência a esse volume de dados não têm como --volume-a partir de um contêiner com um índice correspondente. Gente, estou olhando esse problema há 2 meses. O melhor que pude fazer é criar um script que usa docker-machine scp . Mas é uma etapa manual após a edição de um arquivo de configuração e antes de docker-compose up . Também requer que se possa escrever o caminho exato nas máquinas alvo do enxame como a raiz do docker-compose.yml (ou seja, cheira a um grande hack).

Talvez meus esforços na fábrica possam ajudar a automatizar esse processo de girar máquinas docker e aglomerar os usuários com os dados "certos" prontos para uso? (_embora ainda esteja em desenvolvimento inicial e estou usando-o para combinar docker-machine e docker-compose em um único setp_0.

copy é uma operação, não faz parte da configuração do serviço, portanto, não pertence ao arquivo de composição.

O Docker 1.9 está adicionando uma nova API de volumes e os drivers de volume já estão disponíveis. Os volumes são realmente a maneira correta de apoiar isso. Não tentando copiar arquivos.

Obrigado pela sugestão! mas não acho que isso realmente se encaixa com o design de composição agora.

copiar é uma operação, não faz parte da configuração do serviço, portanto, não pertence ao arquivo de composição.

E se alguém quiser copiar apenas um arquivo de configuração? (para um docker enxame, então volume_from não funcionaria)

Eu tenho exatamente a mesma situação, quero copiar arquivos de configuração personalizados mysql, nginx, haproxy etc., temos clusters em produção, e em vez de apenas usar um comando de cópia para copiar configurações de local para remoto

Eu tenho que usar imagens, construir, puxar a cada vez, enquanto não há nenhuma necessidade e apenas o comando de cópia vai economizar muito tempo de implantação e desenvolvimento

Isso é muito surpreendente para mim que mais pessoas não tenham problema com isso não ser prontamente programável. Estou pensando errado no docker? Acho que minha solução agora seria usar ansible para copiar os arquivos de configuração para o host e, em seguida, montar o volume do host para o (s) contêiner (es) que precisam dele

Atingindo o mesmo problema. Estou reutilizando um Dockerfile para N serviços diferentes e não quero criar N diferentes Dockerfiles com seu próprio comando COPY ou criar um volume apenas para isso.

Btw, estou resolvendo isso executando dezenas de linhas de comandos sed - http://unix.stackexchange.com/questions/112023/how-can-i-replace-a-string-in-a-files

Talvez não seja a solução ideal, mas funciona considerando que docker-compose não suporta a cópia de arquivos.

Btw montagem e cópia, é claro que é possível, mas vai contra as ofertas de automatização docker-compose - se eu preferisse fazer tudo manualmente, não usaria docker-compose, não é?

Quanto mais eu cavei no Docker, mais parece que muitas dessas ferramentas são boas para "hello world" / "veja quão rápido eu posso girar essa coisa legal com comandos \ shell \ como \ this \" em um casos de uso de tipo de máquina única (docker-compose incluído). Se for muito além disso, as coisas começam a se tornar bastante complicadas e a IMO desmorona um pouco, e é aí que as ferramentas de provisionamento tradicionais podem entrar e salvar o dia quando usadas de forma adequada.

Descobri que usar o Ansible para configurar máquinas de uma forma idempotente é muito fácil quando tenho volumes específicos de máquina, arquivos e arquivos de configuração de modelo que devem existir para a imagem do docker iniciar. Então, no final, posso usar o Ansible para invocar docker-compse ou até mesmo usar o módulo docker Ansible cuja sintaxe é quase a mesma do docker compose com alguns recursos de bônus adicionais.

No final do dia, a abordagem acima permite que tudo seja programado, idempotente e, o mais importante, verificado no controle de origem.

@dnephin algumas pessoas acima sugeriram o caso de uso do CP sendo parte da configuração, faria sentido revisitar a suposição de que o CP é apenas para operações e não para configuração.

Um exemplo simples é criar um contêiner, copiando a configuração no local correto, iniciando o contêiner assim que a configuração tiver sido copiada.

Isso permite a criação de imagens que não incorporam a configuração real e apenas implementam a configuração quando o contêiner é iniciado.

Definitivamente, será muito útil. Estou trabalhando com a imagem do postgres como back-end do banco de dados agora e não quero reconstruí-lo, apenas para atualizar um script na pasta /docker-entrypoint-initdb.d .

Por que vocês não reabrem este problema até que o recurso seja implementado ou uma solução viável seja encontrada que as pessoas gostem, já que ninguém aqui gosta das opções sugeridas?

Este problema deve ser reaberto, como @ctindel mencionou.

+1 por ter o problema reaberto

1 para abrir também.

+1 para reabertura.

+1 para reabertura.

+1 para reabertura.

+1 para reabertura.

+1 para reabertura.

+1 para reabertura.

O que há de errado com um volume somente leitura?

myservice:
    image: foo/bar
    volume:
        - src:dest:ro

@michaelarnauts veja isso .

👍 para reabertura

+1 para reabertura.

+1 para reabertura.

+1 para reabertura

+1 para reabertura

+1 para reabertura

+1 para reabertura

+1 para reabertura

+1 para reabertura

Aqui está minha justificativa para permitir uma cópia no Compose.

Eu tenho um aplicativo que roda em vários Containers. Para fins de argumentação, vamos estipular que todos eles executam o Apache. Todos eles têm definições de DocumentRoot apontando para coisas como "/ var / www / partX". O Dockerfile não sabe nada sobre o conteúdo da configuração do Apache e o Compose define a referência de volume para / var / www / partX. Isso funciona muito bem para o desenvolvimento, porque posso depurar e ajustar o código sem modificar o conteúdo do contêiner.

O problema é quando eu quero implantar. Uma das principais atrações do Docker é que posso implantar um contêiner que é seu próprio universo. Para colocar tudo no contêiner, preciso copiar os arquivos, o que significa que precisaria separar as definições de Dockerfile e Compose daquelas que uso para desenvolvimento. Em um projeto grande, isso significa que preciso manter dois conjuntos de arquivos de definição, o que apresenta mais possibilidade de erros.

Minha preferência seria manter um único conjunto de Dockerfiles e fazer a orquestração no arquivo Compose. Compose seria onde eu defino se vou configurar / var / www / partX como um volume compartilhado ou se estou copiando arquivos para o contêiner.

A implantação com volumes compartilhados parece uma lata de vermes. Se estou atualizando uma versão existente em produção que depende de um volume compartilhado, não posso atualizar esse volume compartilhado sem configurar uma janela de manutenção ou criar um esquema para controlar a versão do meu volume compartilhado. Estou acoplando fortemente contêineres a arquivos externos e, se estou introduzindo esse tipo de complexidade, estou negando alguns dos benefícios de usar o Docker.

Parece que eu poderia fazer o script de alterações nas definições do Dockerfile para copiar arquivos condicionalmente, mas parece mais "lógico" lidar com toda a minha lógica Docker no universo Docker, e Compose parece um lugar lógico para fazer isso.

+1 para reabertura.

+1. Seria muito útil copiar um arquivo de configuração em docker-compose.yml file em vez de Dockerfile .

+1. Encontrei-o tentando fornecer um arquivo de configuração para o serviço. O volume somente leitura parece uma opção, mas prefiro copiá-lo.

Simplesmente montar um volume pode resolver o problema:

version: '2'
services:
  foobar:
    image: 'postgres:9.6-alpine'
    volumes:
      - './docker/schemas/foobar:/docker-entrypoint-initdb.d'

@raszi - Sim, a configuração montada é a direção que vamos seguir agora. Uma das coisas que eu realmente gostei no Docker foi a noção de um contêiner autocontido no qual eu poderia executar testes de integração, sem qualquer preocupação com dependências externas (como configuração vinculada). Se eu estiver fazendo implantações azul / verde ou A / B e houver diferenças nas configurações usadas por diferentes versões de contêineres, as coisas podem ficar um pouco frágeis. Posso contornar isso fazendo coisas como arquivos de configuração de versão em um volume compartilhado de cada um dos meus ambientes, mas simplesmente parece mais complexo ou frágil do que poderia ser.

"Os contêineres do Docker envolvem um pedaço de software em um sistema de arquivos completo que contém tudo o que é necessário para executar: código, tempo de execução, ferramentas do sistema, bibliotecas do sistema - qualquer coisa que possa ser instalada em um servidor. Isso garante que o software sempre será executado da mesma forma, independentemente de seu ambiente. " Para mim, o ideal seria incluir configuração. O Compose é uma espécie de "construir / compilar e executar", acho que alguns de nós aqui estão desejando que o Compose pudesse fazer um "construir / compilar, vincular e executar". Não é assim que funciona hoje, e posso entender a falta de entusiasmo em fazer esse caminho, mas hey, é um fórum, não custa perguntar;)

Eu concordo, seria ótimo ter esse recurso. Acabei de postar minha solução para ajudar outras pessoas.

+1 para reabertura.

+1

+1 para reabertura ou solução diferente sem volumes.

Atualmente usando variáveis ​​de ambiente em docker-compose.yml e j2 em docker-entrypoint.sh para analisá-los em arquivos de configuração antes de executar o aplicativo principal do contêiner. Funciona para mim, embora seja uma imagem personalizada e não possa ser usada fora da caixa com imagens completas já disponíveis.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 para reabertura

Para adicionar a possibilidade de ter um arquivo yaml diferente para cada contêiner em vez de uma configuração baseada em variáveis ​​de ambiente

+1 recurso muito necessário

1, bom ter recurso!

+1

+1

+1

+1

+1 reabertura. Marcado

+1, este é um recurso muito necessário.

Se houvesse alguma maneira de marcar um volume compartilhado como uma camada, de modo que o volume permanecesse RO, mas as gravações fossem aplicadas a uma camada acima, eu viveria feliz sem uma diretiva copy . Eu gostaria de compartilhar, por exemplo, um artefato de compilação extraído, mas o serviço grava nesse diretório (logs ou arquivo PID etc.).

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 para reabertura, pois seria um recurso muito útil

Talvez o recurso de modelo de https://github.com/jwilder/dockerize possa ajudar alguns de vocês

+1

+1

+1

+1

+1

+1 para reabrir o problema

+1

Use os segredos do docker, neste exemplo, os segredos são usados ​​com a imagem nginx para copiar o certificado do servidor e o arquivo de configuração
https://docs.docker.com/engine/swarm/secrets/#intermediate -example-use-secrets-with-a-nginx-service

Este é um bom ponto. Sinceramente, parece que como já temos segredos, deveríamos ter uma cópia, pois segredos são, de certa forma, apenas um tipo específico de arquivo que você copia. Ou seja, aquele que é provisionado com mais cuidado, o qual não precisamos para arquivos de configuração.

É melhor que o host montando um volume para cada arquivo de configuração que você deseja incluir.

Como disse antes:

...
volumes:
- ./nginx/default.conf:/etc/nginx/conf.d/default. conf: ro
- ./nginx/nginx.conf:/etc/nginx/nginx. conf: ro
...

A razão pela qual copiar é melhor, a) em ambientes swarm, onde os hosts são, na verdade, máquinas separadas, você não deve ter exatamente o mesmo arquivo no mesmo lugar em todas as máquinas. b) A cópia também pode ser restrita à pasta em que a composição está, ao passo que uma montagem de host requer um caminho absoluto. c) Acho que o objetivo do docker é minimizar o número de lugares em que o aplicativo contido invade o host. As montagens do host, mesmo quando configuradas como somente leitura, criam uma responsabilidade no host de manter e preservar os arquivos. Não deveríamos ter que usar montagens de host para resolver este problema simples.

Eu acho que a cópia poderia ser modelada de forma semelhante ao processo docker build , onde Dockerfile é geralmente enviado em um repositório git, junto com todos os arquivos que ele precisa enviar para o contexto de construção. O Dockerfile não tem permissão para enviar nada que exista fora de sua estrutura de diretório, mesmo se estiver com link simbólico correto. Poderíamos ter algo semelhante com o compose, onde src está restrito ao diretório (e aqueles abaixo) de docker-compose.yml . Basicamente, o fluxo de trabalho seria, docker-compose cria o contêiner e, em seguida, para cada src:dst par, encontre o src no diretório atual e copie-o para o contêiner não iniciado, em seguida, inicie o contêiner.

Atualmente, evitar montagens de host pode ser conseguido adicionando Dockerfiles e construindo os arquivos conf em imagens corrigidas, mas isso parece um exagero para mim, pois envolve remarcação de uma nova imagem ou forçar usuários para usar o atributo docker-compose build vez do atributo mais preferível (IMO) image . Se você já estiver usando o atributo build em sua definição de serviço e quiser fazer as coisas dessa maneira, será forçado a poluir seu criador de imagens, de outra forma agnóstico, com um arquivo de configuração altamente opinativo que deveria pertencer apenas para compor e o processo de implantação.

+1 para recurso de cópia docker-compose

+1

+1

+1

1 para cópia.

+1 para o recurso de cópia docker-compose. Acho que os argumentos a favor acima são convincentes.

+1 para cópia

1 para cópia.

Embora no meu POV. Pode ser útil, mas também pode ficar fora de controle ou abusado por muitos usuários e pode até tornar o volume obsoleto. Se você só precisa que os arquivos sejam colocados no contêiner especialmente para o swarm, você pode apenas usar configurações ou segredos; Mas, para o meu caso, como colocar pastas estáticas em um contêiner nginx, tenho que usar compilações de vários estágios em meu Dockerfile para colocar essas pastas estáticas no contêiner, o que exige muito processo antes que meu objetivo seja alcançado. Então, acho que adicionar uma opção de cópia pode ser muito útil

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 para reabertura

+1

+1 para reabertura

Um recurso que opera em um volume depois que o contêiner (ou ele mesmo) atinge determinado estado não funcionaria?
Pode ser um sinalizador como somente leitura, mas somente cópia ! Então você teria o pipeline / sintaxe de operações de volumes regulares com a funcionalidade adicional de remover o link após um estado de sincronização ser alcançado dentro do contêiner ...

+1 para reabertura. A montagem de volume nem sempre é uma opção. É por isso que estou postando aqui hoje. Preciso modificar um grande número de contêineres manualmente para copiar arquivos devido a um cenário único em que a montagem de volume é proibida.

+!

+1

+1 para recurso de cópia docker-compose

+1

+1

Estou começando a achar que isso é inútil. O Docker apenas adiciona recursos em torno do caso de uso específico para o qual eles criaram o docker - este é um dos recursos fora de seu caso de uso, então eles provavelmente nunca o adicionarão.

+1

@stuaxo Só porque muitas pessoas estão pedindo armas de

Neste caso, os arquivos que são necessários para a execução de um serviço devem ser incluídos na compilação (declarados no Dockerfile), disponibilizados por meio de volumes ou (no caso do modo docker stack / Swarm) existir como configuração ou objetos secretos. Copiar arquivos para destinos potencialmente múltiplos em tempo de execução é lento, sujeito a erros e não resiliente a falhas.

Saúde, desculpas se isso soou mal-humorado.
Quando você diz "executando um serviço", imagino que esteja se referindo a algo de longa duração, como um serviço da web, o Docker cobre isso bem.

As camadas de encaixe e o armazenamento em cache são úteis para outras coisas;

Coloquei meu antigo blog em WordPress no docker, mas só o executo algumas vezes por alguns minutos para que possa exportar dados ou verificar a aparência de uma postagem lá.

Isso deu um pouco de trabalho para usar docker compose para separar MySQL e Apache, mas eu não me importaria se eles estivessem todos juntos.

O armazenamento em cache do Dockers é divertido ao experimentar a construção de bibliotecas de desktop como o Cairo. Esqueci os detalhes da maioria das coisas que estava tentando fazer, mas estão mais relacionadas com a construção - algo do lado das coisas do que com a execução de serviços.

+1 cópia docker-compose precisa ser adicionada. Ele permite um fluxo muito mais fácil de arquivos de configuração e atualizações para contêineres.

Use docker cp e docker config

Na sexta-feira, 2 de março de 2018 às 21:19, James Hahn [email protected] escreveu:

+1 cópia docker-compose precisa ser adicionada. Permite um fluxo muito mais fácil
de arquivos de configuração e atualizações para contêineres.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/docker/compose/issues/1664#issuecomment-370055493 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ABOv-q5VO9n9HDvBP6YJ1BCePz5tGu-pks5tabdrgaJpZM4FTTPg
.

>

James Mills / prologic

E: [email protected]
W: prologic.shortcircuit.net.au

+1 para cópia docker-compose. A ideia é ter somente cópia para os arquivos, conforme descrito aqui

+1

+1

Nesse caso, os arquivos que são necessários para a execução de um serviço devem ser incluídos no build (declarado no Dockerfile), disponibilizados por meio de volumes ou (no caso do docker stack / modo Swarm) existir como objetos de configuração ou secretos. Copiar arquivos para destinos potencialmente múltiplos em tempo de execução é lento, sujeito a erros e não resiliente a falhas.

Exceto em muitos casos, tudo o que você deseja é atualizar um único arquivo de configuração, caso em que preparar sua própria imagem de uma imagem oficial padrão é uma prática ruim e cria muitos problemas técnicos para o futuro, os volumes são exagerados no X10 e você não deseja ou precisa que os arquivos continuem sincronizando para não mencionar os problemas de ter que lidar com toda a pasta e não apenas um único arquivo em um local padrão, e você precisa atualizar um arquivo de sistema, não apenas obter uma configuração.

Eu entendo suas preocupações, mas apenas dizer a todos que suas necessidades não são reais só afastará as pessoas de seu projeto e da comunidade que deseja usá-lo e apoiar seu trabalho. Queremos trabalhar com você aqui para encontrar uma solução que funcione, mas tudo o que você quer dizer é que não precisamos do que pensamos que precisamos.

Uau, não posso acreditar que isso ainda não foi feito. Achei que essa funcionalidade básica já estaria no docker-compose agora. Oh, a beleza dos projetos OSS ...

Resolvido com docker-compose --force-recreate --rebuild , ele copia os novos arquivos se eles foram alterados (ou assim parece). Não é o ideal, mas funciona.

+1

+1

+1

+1

+1 isso é baixo-chave me deixando louco, parece bobo ter que montar um volume apenas para um arquivo de configuração.

+1

Temos uma maneira de adicionar arquivos a um contêiner usando docker compose com volumes. Percebi que a documentação do Compose tem uma configuração configs agora, então podemos adicionar arquivos individuais também.

https://docs.docker.com/compose/compose-file/#configs

No entanto, o que eu acredito que as pessoas desejam é uma maneira de mesclar arquivos do host em um diretório no contêiner com preferência overwrite if exists , da maneira que você esperaria que uma cópia funcionasse.

É estranho para mim que a configuração volumes no arquivo de composição tenha uma opção nocopy :

https://docs.docker.com/compose/compose-file/#volumes

volumes:
  - type: volume
  source: mydata
  target: /data
  volume:
    nocopy: true

Que é descrito assim:
volume: configure additional volume options
nocopy: flag to disable copying of data from a container when a volume is created

Então, desativa exatamente o que é desejado?

Meu caso de uso desejado são aplicativos da web para desenvolvimento. Quero que a imagem contenha tudo de que precisa para servir a um site, incluindo um site padrão para servir, mas tenho a opção de mesclar / sobrescrever esses arquivos com o estado de trabalho atual de um site sem outra configuração (a chave) além de ter os arquivos em o lugar certo no host. Arquivos que, ao serem copiados para o contêiner, são efêmeros. Ou seja, não em um compartilhamento de rede.

Um exemplo de framework que se beneficiaria disso é algo como o Laravel. Onde eu faço uma imagem que será capaz de servir a página inicial do Laravel sem nenhuma outra configuração (volumes, compartilhamentos de rede, etc), mas o arquivo de composição é escrito para copiar arquivos do host para a raiz do Laravel do contêiner para que eles possam ser sobrescrito.

Usar um compartilhamento de rede para isso é uma manutenção extra para um ambiente efêmero (o desenvolvimento nem sempre é constante). Usar uma montagem de volume para ele, com uma estrutura como o Laravel, requer a construção do aplicativo naquele volume, o que significa instalar o PHP e o composer no host ou compartilhar o local no host em que o aplicativo seria criado. Ambos criando mais manutenção.

Editar:

Após o teste, parece que quando você monta um volume, os arquivos que existiam na imagem naquele local são copiados para o volume persistente com preferência para o conteúdo original do volume. Significa que não sobrescreve.

Na verdade, acho que essa é uma solução para o resultado desejado.

Ei, pessoal, apenas para sua informação, é melhor dar uma reação positiva à mensagem principal sobre este problema do que adicionar um comentário "+1", pois os problemas podem ser classificados por quantas reações eles receberam.

+1

+1 Por favor, equipe do Docker, considere sua comunidade.

@ shin- O problema agora é que o recurso de volumes torna impossível conectar um único arquivo de configuração de um volume externo em um contêiner.

Suponha que eu queira conectar um arquivo de configuração nginx em /etc/something/whatever.conf sem aniquilar tudo o mais que está nessa pasta. Você não pode criar um volume nomeado para um único arquivo (ver moby / moby # 30310), e você também não pode criar um volume de diretório contendo um único arquivo e, em seguida, montar esse arquivo específico no contêiner (ver moby / moby # 32582).

A única opção que resta é poluir locais fixos em seu host Docker real com os arquivos de configuração e, em seguida, vinculá-los à montagem. Isso, claro, se desintegra se você quiser se mover entre os hosts Docker ou trabalhar com um Docker host ao qual você não tem acesso ao sistema de arquivos (por exemplo, CI online), ou mesmo apenas executa várias pilhas em paralelo.

Algo precisa ceder aqui, ou o recurso de volumes no Docker precisa ser alterado para que possamos realmente usá-lo para realizar a injeção de arquivos de configuração em nossa pilha, ou precisamos contornar isso na composição usando algo como copy opção

FWIW Não sou mais um mantenedor do Compose, mas me parece que esse caso de uso seria mais bem atendido ao injetar o arquivo de configuração no momento da construção usando um Dockerfile.

@ shin- Infelizmente, os arquivos de configuração não são conhecidos no momento da construção, as imagens são preparadas em um servidor de CI muito antes de sabermos onde iremos implantá-las e em que configuração.

Estou com @masaeedu , entendo o ideal conceitual de manter a função de compor de rastejar e, portanto, não quero adicionar esse recurso, mas na vida real a perda desse recurso reduz MUITO as circunstâncias em que o compor pode ser usado sem

A) ter que remendar algum tipo de trabalho de script hediondo para levantar os contêineres em questão (a própria composição de composição foi feita para ajudar a padronizar e nos impedir de fazer isso),

B) ter que adicionar alguma outra ferramenta que lide com todas as nossas configurações (que embora viável adiciona uma grande quantidade de sobrecarga para projetos de pequeno a médio porte que realmente precisam apenas copiar um .conf e .env específicos para cada contêiner, algo que você não quero fazer no momento da construção da imagem, isso é equivalente a dizer que, em vez de seu software ter um arquivo de configuração, você deve codificar todas as suas opções em C ++, isso leva a dezenas de imagens extras para manter), ou

C) ter que manter uma imagem separada para cada configuração possível de um determinado software de que precisaremos / construir uma imagem personalizada toda vez que tivermos que fazer uma pequena alteração na configuração ... o que é impraticável no mundo real de software de produção e também torna impossível ter o tipo de QA robusto e pipeline de testes de que precisamos para o software de produção.