Como decidir entre um contêiner de volume da docker e um volume da docker?

Depois de ler os documentos, fiquei um pouco confuso sobre a melhor forma de gerenciar dados produtivos de aplicativos / serviços.

Parece haver três opções:

Simplesmente mapeie o volume para o diretório host (ou seja, -vargumento para docker run)
Crie uma imagem de contêiner de janela de encaixe para dados (por exemplo, contêiner separado e --volumes-from)
Criando um volume da janela de encaixe (ou seja docker volume create)

Agora, parece que a prática aceita é a opção 2, mas depois me pergunto qual é o propósito da 3.

Especialmente como você lida corretamente com esses cenários docker volumee é melhor usar um contêiner de volume de dados ou isso para cada situação?

Você precisa de dados do aplicativo em um volume e / ou camada de armazenamento separados no servidor
Fazendo backup
Restaurando dados

storage docker

— dukeofgaming
fonte

serverfault.com/q/576490/126632

— Michael Hampton

@MichaelHampton eu percebi que eu deveria reformular a minha pergunta

— dukeofgaming

# 1 não é uma opção séria para produção; basicamente nunca deve ser feito se existir uma alternativa.

— Michael Hampton

Dados @MichaelHampton por quê ?, não pode ser dockerized mas o sistema operacional hospedeiro continua a ser gerido por uma equipe de infra-estrutura que monitora e backups

— dukeofgaming

@dukeofgaming Sem mencionar que você pode executá btrfs scrub-lo para encontrar e corrigir arquivos danificados. Não tenho certeza de como as coisas encaixadas funcionam, mas acho que elas não protegem contra a podridão de dados; portanto, sempre preciso de uma restauração completa se algo de ruim acontecer, em vez de apenas restaurar arquivos individuais. Outro pensamento é que ele adiciona outra camada de abstração, tornando mais lenta a leitura e a gravação de arquivos. De alguma forma, não vejo as vantagens dos itens 2 e 3, mas não tenho experiência com o docker, portanto isso pode mudar.

— Inf3rno 22/11/2017

Respostas:

Eu acho que os números 2 e 3 são praticamente a mesma coisa, a principal diferença é que não há contêiner parado com o número 3 (é literalmente, apenas um volume nomeado). Por exemplo, você pode criar um volume nomeado e fazer da mesma forma o que faria com o nº 2 -v.

Crie um volume nomeado:

$ docker volume create --name test

Monte e grave alguns dados nesse volume a partir de um contêiner:

$ docker run -v test:/opt/test alpine touch /opt/test/hello

Você pode montar o mesmo testvolume em outro contêiner e ler os dados:

$ docker run -v test:/opt/test alpine ls -al /opt/test     
total 8
drwxr-xr-x    2 root     root          4096 Jan 23 22:28 .
drwxr-xr-x    3 root     root          4096 Jan 23 22:29 ..
-rw-r--r--    1 root     root             0 Jan 23 22:28 hello

A vantagem aqui é que o volume não desaparecerá acidentalmente se você remover o contêiner somente de dados. Agora você o gerencia com o docker volumesubcomando.

$ d volume ls
DRIVER              VOLUME NAME
local               test

Ele também abre as possibilidades para os drivers de volume mais adiante, para que você possa fazer volumes compartilhados entre hosts (ou seja, volumes nomeados pelo NFS). Exemplos disso podem ser Flocker e Convoy . A seu ponto, especificamente sobre mover ou fazer backup de dados, o Convoy possui subcomandos específicos para fazer backup de dados e permite o armazenamento em NFS ou EBS externo ao seu host.

Por esse motivo, acho que a maneira mais recente (Docker 1.9+) é usar um volume nomeado em vez de um contêiner somente de dados.

— Andy Shinn
fonte

Obrigado, você respondeu à maioria das minhas perguntas, mas o ponto de gerenciar dados de contêiner em um nível de volume físico diferente ainda não foi respondido e esse é o crítico ... suponha que essa seja uma solução de gerenciamento de repositórios git e que eu precise dessa parte do contêiner dados (que é um volume definido em um arquivo docker) no armazenamento de camada 0, localizado em um volume físico diferente do host (ou seja, outra partição, disco físico ou o que for)

— dukeofgaming

Eu meio que fiz com a menção de drivers de volume. No momento, para armazenar dados fora do driver de armazenamento local físico, você precisaria usar um que fizesse especificamente o que você deseja fazer. Em cima da minha cabeça, há github.com/rancher/convoy e github.com/ClusterHQ/flocker . O comboio tem suporte para NFS e GlusterFS no momento, o que soa mais próximo do que você procura. Modificarei a resposta para esclarecer isso.

— Andy Shinn

O uso do driver devicemapper parece responder à minha pergunta, obrigado! docs.docker.com/engine/userguide/storagedriver/…

— dukeofgaming

the volume won't accidentally disappear if you remove the data-only container. Você poderia elaborar? Obrigado.

— Stephane

No Docker 1.9, a criação de Volumes Nomeados com a API Volumes ( docker volume create --name mydata) é preferível a um Contêiner de Volume de Dados. Em fevereiro de 2016, a documentação dos volumes do Docker estava desatualizada. O pessoal do Docker sugere que os Data Volume Containers “ não são mais considerados um padrão recomendado ”, “os volumes nomeados devem poder substituir os volumes somente de dados na maioria dos casos (se não todos) ” e “ não há motivo para usar. contêineres somente para dados ".

— Quinn Comendant
fonte