Qual é a diferença entre criar um volume ou uma montagem em contêineres docker?

Question

O Docker fornece 2 maneiras de fazer backup e sincronizar dados do contêiner na máquina local, ou seja, volume e montagem . Ambos se comportam da mesma maneira, exceto por algumas coisas que notei:

1. Um volume sempre mantém dados em / var / lib / docker / volumes, enquanto os pontos de montagem podem ser criados onde quisermos.
2. Se um contêiner ao qual é atribuído um ponto de montagem também for atribuído a um volume, todos os dados do ponto de montagem serão copiados para o volume automaticamente, enquanto o contrário não será verdadeiro.
3. Não podemos descrever um ponto de montagem em um Dockerfile, mas podemos fornecer volumes em um Dockerfile.

Ok, então podemos dizer que há algumas vantagens e desvantagens da metodologia, mas ainda há alguma classificação ou diferenças em termos de otimização.

Por favor, forneça uma resposta explicada.

    

Answer 1

Na verdade, existem três tipos de volumes:

• Volume do Host: ao que você se refere como uma montagem em um contêiner, o termo mais comum é uma montagem de ligação.
• Volume nomeado: qualquer volume gerenciado pelo docker ao qual você atribui um nome.
• Volume anônimo: qualquer volume sem uma origem, a janela de encaixe criará isso como um volume local com um ID exclusivo longo e se comportará como um volume nomeado.

Os volumes têm uma origem e um destino. A origem identifica o tipo de volume, portanto, um caminho (incluindo a barra inicial) para um arquivo / diretório resulta em um volume do host. Se você não fornecer uma fonte, receberá os volumes anônimos. Se você definir um volume dentro de um Dockerfile, não poderá especificar uma origem, portanto, por padrão, o docker criará volumes anônimos, a menos que você o direcione de outra forma no tempo de execução.

Para cada tipo, veja as vantagens / desvantagens:

• Anfitrião:
  • Pro: fácil acesso aos arquivos subjacentes do host
  • Con: problemas de permissão uid / gid ocorrem quando o uid do usuário do contêiner não corresponde ao host gid
  • Con: os dados não são inicializados
• Nomeado:
  • Pro: fácil criar uma reutilização entre diferentes contêineres / imagens. Se você atribuir apenas um nome a ele sem outras configurações, o driver local será padronizado para armazenar seus dados em / var / lib / docker / volumes, o que deve ser acessível somente pelo usuário root fora da janela de encaixe.
  • Pro: inicializa o conteúdo para o conteúdo da imagem quando está vazio / novo e o contêiner é criado. Essa inicialização inclui proprietários e permissões de arquivos da imagem, o que pode resolver a maioria dos problemas de uid / gid.
  • Pro: pode se conectar a qualquer coisa que um comando mount possa, incluindo uma montagem de ligação ou montagem NFS, com um driver local. Outros drivers permitem que você faça referência a dados em ainda mais locais (por exemplo, provedores de nuvem).
  • Con: o gerenciamento de conteúdo deve ser feito por meio de um contêiner.
• Anônimo:
  • Pro: não requer planejamento para usar
  • Con: normalmente, os dados vão aqui para serem perdidos, pois não há mapeamento do volume para o contêiner / imagem que o criou. Esta é a pior maneira de armazenar volumes, na minha opinião, e a razão pela qual ninguém deve definir um volume dentro de seu Dockerfile.

Quando possível, uso um volume nomeado. A inicialização de dados e o melhor tratamento de problemas de uid / gid superam a conveniência de um volume de host. Se eu realmente precisar acessar fora da janela de encaixe diretamente para os dados, tente usar um volume nomeado que aponte para uma montagem de ligação em vez das configurações do driver local padrão. Um exemplo simples disso é:

$ docker volume create --driver local \
  --opt type=none \
  --opt device=/home/user/test \
  --opt o=bind \
  test_vol

Para definir meus volumes, uma vez que você não deseja fazer isso em um Dockerfile, eu uso um docker-compose.yml e defino meus volumes lá. Se for implantado com o modo swarm, indicarei um servidor NFS com um volume nomeado para permitir que os dados sejam atingidos à medida que os contêineres migrarem para hosts diferentes. Caso contrário, é um volume nomeado local que pode ser facilmente usado com o docker-compose.

    

Answer 2

Os volumes no dockerfile permitem que um caminho seja especificado na imagem que sempre deve ser criado como um volume. Isso inerentemente ignora a união da janela de encaixe do sistema de arquivos.

Os usuários de tal imagem sempre obterão um volume nesse local ao executar

docker run <imagename>

i.e. não há razão para adicionar -v /my/mount/point:/mount/here e, assim, os usuários não precisam se preocupar com isso.

As montagens de ligação

(como o exemplo acima com -v ) sempre devem estar presentes se forem necessárias. e não são portáteis entre as imagens.

as diferenças efetivas para otimização são estas:

• volumes podem ser usados onde muitas operações de r / w são necessárias e tem gravação de negócios no sistema de arquivos de união (bancos de dados do think)
Os volumes
• são inúteis para montar coisas como volumes de dados. você pode fazer isso, mas você recebe um enorme r / w, porque não há razão para isso estar no sistema de arquivos da união.
• monta, no entanto, armazenará isso (o acima) muito bem, pois simplesmente monta o diretório existente em um lugar dentro do container e ignora o sistema de arquivos de união para aquele diretório todos juntos.

isso faz sentido?