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

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

Parece haver 3 opções:

  1. Simplesmente mapeie o volume para o diretório host (ou seja , -v argumento para docker run)
  2. Crie uma imagem de contêiner do docker para dados (ou seja, contêiner separado e --volumes-from)
  3. Criando um volume docker (ou seja , docker volume create)

Agora, parece que a prática Aceita é a opção #2, mas então me pergunto Qual é o propósito de #3.

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

  • Você precisa de dados de aplicativos em um volume e/ou camada de armazenamento separados em seu servidor
  • Fazer
  • Restaurar dados

A partir do Docker 1.9, criando Volumes nomeados com o API Volumes (docker volume create --name mydata) são preferidos em vez de um contêiner de volume de dados. Em fevereiro de 2016, o Docker volumes documentação é lamentavelmente desatualizado. As próprias pessoas do Docker sugerem que os contêineres de volume de dados "não são mais considerados um padrão recomendado,” “volumes nomeados devem ser capazes de substituir volumes somente de dados na maioria (se não em todos) casos,” e “não há razão para usar contêineres somente de dados.”

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

Crie um volume nomeado:

$ docker volume create --name test

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

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

Você pode então montar o mesmo test volume em outro contêiner e leia os dados:

$ docker run -v test:/opt/test alpine ls -al /opt/test     total 8drwxr-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ê gerencia com o docker volume Sub-comando.

$ d volume lsDRIVER              VOLUME NAMElocal               test

Ele também abre as possibilidades para motoristas de volume na estrada para que você possa fazer volumes compartilhados entre hosts (ie. volumes nomeados sobre NFS). Exemplos disso podem ser Flocker e Comboio. Para o seu ponto especificamente sobre mover ou fazer backup de dados, O Convoy tem subcomandos específicos para fazer backup de dados e permite armazenamento em NFS ou EBS externos ao seu host.

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

@ MichaelHampton Por Quê?, os dados podem não ser dockerizados, mas o sistema operacional host ainda é gerenciado por uma equipe de infraestrutura que monitora e faz backups

@ MichaelHampton percebi que deveria reformular minha pergunta

@ dukeofgaming sem mencionar que você pode executar Btrfs scrub nele para encontrar e corrigir arquivos danificados. Não tenho certeza de como as coisas dockerizadas funcionam, mas acho que não protegem contra o apodrecimento dos dados, então sempre preciso de uma restauração completa se algo ruim acontecer em vez de apenas restaurar arquivos individuais. Outro pensamento de que ele adiciona outra camada de abstração, então retarda a leitura e a escrita de arquivos ainda mais. De alguma forma, não vejo as vantagens de #2 e #3, mas não tenho experiência com docker, então isso pode mudar.

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