O Docker fornece 2 maneiras de fazer backup e sincronizar dados de contêiner na máquina local, ou seja, volume e montar. Ambos se comportam da mesma maneira, exceto por algumas coisas que notei:
- Um volume sempre mantém os dados em/var/lib/docker / volumes, enquanto os pontos de montagem podem ser criados onde quisermos.
- Se um contêiner ao qual é atribuído um ponto de montagem também receber um volume, todos os dados do ponto de montagem serão copiados para o volume automaticamente, enquanto o oposto não é verdadeiro.
- Não podemos descrever um ponto de montagem em um Dockerfile, mas podemos fornecer volumes em um Dockerfile.
Ok, então podemos dizer que existem algumas vantagens e desvantagens da metodologia, mas ainda existem algumas classificações ou diferenças em termos de otimização.
Forneça uma resposta explicada.
Na verdade, existem três tipos de volumes:
- Volume do Host: o que você chama de montagem em um contêiner, o termo mais comum é uma montagem de ligação.
- Volume nomeado: qualquer volume gerenciado pelo docker que você dá um nome.
- Volume anônimo: qualquer volume sem uma fonte, o docker criará isso como um volume local com um id exclusivo longo e se comportará como um volume nomeado.
Os Volumes têm uma fonte e um alvo. A fonte identifica o tipo de volume, portanto, um caminho (incluindo a barra principal) para um arquivo/diretório resulta em um volume de host. Se você não fornecer uma fonte, obterá os volumes anônimos. Se você definir um volume dentro de um Dockerfile, não poderá especificar uma fonte lá, portanto, por padrão, o docker criará volumes anônimos, a menos que você o direcione de outra forma em tempo de execução.
Para cada tipo, aqui estão os prós / contras:
- Hospedar:
- Pro: Fácil de acessar os 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 GID do host
- Con: os dados não são inicializados
- Chamar:
- Pro: Fácil de criar uma reutilização entre diferentes contêineres/imagens. Se você fornecer apenas um nome sem outras configurações, o driver local será o padrão para armazenar seus dados em /var/lib/docker/volumes que só devem ser acessíveis por root de fora do docker.
- Pro: inicializa o conteúdo para o conteúdo da imagem quando ele está vazio / novo e o contêiner é criado. Essa inicialização inclui proprietários de arquivos e permissões da imagem, que podem resolver a maioria dos problemas de uid/gid.
- Pro: pode se conectar a qualquer coisa que um comando de montagem Pode, 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: os dados normalmente vão aqui para serem perdidos, pois não há mapeamento do volume de volta 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, eu uso um volume nomeado. A inicialização de dados e o melhor tratamento dos problemas uid/gid superam a conveniência de um volume de host. Se eu realmente precisar de acesso fora do docker diretamente aos dados, tento usar um volume nomeado que aponta para uma montagem bind em vez das configurações padrão do driver local. 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, já que você não quer fazer isso em um Dockerfile, eu uso um Docker-compose.yml e definir meus volumes lá. Se for implantado com o modo swarm, apontarei para um servidor NFS com um volume nomeado para permitir que os dados sejam alcançados à medida que os contêineres migram para hosts diferentes. Caso contrário, é um volume nomeado local que pode ser facilmente usado com docker-compose.
Os Volumes no dockerfile permitem que um caminho seja especificado na imagem que sempre deve ser criado como um volume. Isso ignora inerentemente os usos do Docker do sistema de arquivos union.
Os usuários dessa imagem sempre receberão um volume nesse local ao executar
docker run <imagename>
ou seja, não há razão para adicionar -v /my/mount/point:/mount/here e, portanto, os usuários não precisam se preocupar com isso.
montagens de ligação (como o exemplo acima com -v) deve estar sempre presente se for necessário. e não são portáteis entre imagens.
as diferenças efetivas para a otimização são estas:
- os volumes podem ser usados onde muitas operações de r / w são necessárias e tem Redação Comercial no union file system (pense em bancos de dados)
- os volumes são inúteis para montar coisas como volumes de dados. você pode fazer isso, mas você pega um enorme hit r/w porque não há razão para isso estar no sistema de arquivos union.
- as montagens, no entanto, armazenarão isso (o acima) muito bem, pois simplesmente montam o diretório existente em um local dentro do contêiner e ignoram o sistema de arquivos union para esse diretório todos juntos.
isso faz sentido?