Adquira conhecimento sobre como usar as funcionalidades básicas da Docker para conectar contêineres com sistemas de arquivos locais.

Contêineres Docker são projetados para permanecerem inalterados, o que implica que o conteúdo do código e dos dados neles contidos permanece constante. A imutabilidade é benéfica quando se deseja garantir que o código em execução na produção seja idêntico ao código testado em QA; no entanto, pode não ser tão útil quando é necessário gravar e persistir dados em ambientes de aplicativos ativos.
Na maioria das situações, é comum lidar com a persistência de dados ao utilizar um banco de dados externo. No entanto, em certos casos, um aplicativo em um contêiner pode apenas necessitar de um sistema de arquivos local ou algo semelhante a ele.
Reprodução: Os volumes do Docker são uma ferramenta interna que o Docker oferece para gerenciar o armazenamento local. Eles facilitam a escrita e recuperação de dados por aplicativos contêineres, usando um sistema de arquivos local ou similar. No entanto, é importante lembrar que os volumes do Docker não resolvem todos os problemas de gerenciamento de estado e devem ser usados com cautela.
Qual é o funcionamento dos volumes no Docker?
Os volumes do Docker permitem que um caminho de arquivo dentro de um recipiente, conhecido como ponto de montagem, seja vinculado a um caminho do sistema de arquivos ou a um objeto semelhante a um arquivo fora do recipiente. Tudo o que for escrito no volume do Docker será armazenado externamente, garantindo sua persistência ao longo da vida de um ou mais recipientes. Além disso, é viável que múltiplos recipientes acessem simultaneamente o mesmo volume (com algumas ressalvas).
Os volumes no Docker são controlados por um driver de volume que determina a localização dos dados armazenados. Um exemplo disso é o Blockbridge, que permite o acesso direto aos alvos iSCSI por meio do driver de volume. Outro exemplo é o REX-Ray, que é um sistema de armazenamento mais abrangente, compatível com diversos fornecedores de armazenamento e padrões. O REX-Ray oferece conectividade por meio do sistema de plug-in de volume do Docker ou do padrão Container Storage Interface.
Elaborando contenedores de Docker de forma manual.
Uma forma simples de adicionar um volume é utilizando a opção -v ou -volume, especificando o ponto de montagem e o destino ao iniciar um contêiner.
Isso gera um volume sem identificação que contém os dados websvcdata no ponto de montagem, armazenados em um diretório aleatório criado para ser utilizado pelo Docker.
Você tem a possibilidade de fazer a mesma ação em um Dockerfile, adicionando uma instrução VOLUME que especifica onde um volume está localizado.
Essa seria uma forma eficaz de rapidamente e de forma improvisada criar um local para armazenar dados durante uma sessão específica de contêineres. No entanto, não é adequada para manter o estado dos dados entre diferentes sessões de contêineres, pois o nome do volume não é previamente conhecido e o volume não pode ser reaproveitado de maneira eficaz.
Utilizando a interface de programação de aplicativos (API) de controle de volume do Docker.
Uma alternativa mais eficaz para a questão seria empregar a API de volume do Docker para gerar volumes com nomes específicos. Esses volumes podem ser facilmente conectados a um ou mais contêineres, facilitando a reutilização.
Isso resulta na criação de um volume Docker denominado websvcdata. No entanto, o volume Docker não possui um ponto de montagem em um contêiner, o que significa que o contêiner não poderia acessá-lo automaticamente. Para estabelecer um ponto de montagem, seria necessário iniciar o contêiner com um comando semelhante a este:
Essa instrução é similar ao exemplo anterior de execução do docker, porém, em vez de criar um volume com um nome anônimo, é criado com o nome websvcdata no host. Para confirmar se as montagens estão conforme o desejado, você pode executar o comando docker inspect no contêiner e verificar a seção “Mounts” na saída resultante.
Observa-se que é impossível designar um nome a um volume por meio de um Dockerfile, pois os nomes dos volumes do Docker devem ser definidos durante a execução. Essa restrição é intencional, pois os Dockerfiles não podem prever um host específico e seus caminhos de volume correspondentes, já que são projetados para serem executados em qualquer sistema com qualquer configuração de caminhos de volume. Um volume especificado em um Dockerfile será criado em um local que garanta a persistência dos dados armazenados por ele durante a vida do contêiner.
Ao utilizar o comando docker volume create com parâmetros específicos relacionados ao driver de armazenamento Docker, é possível personalizar diversas opções para a criação do volume. Por exemplo, ao usar o driver de sistema de arquivos local, é viável especificar a localização do volume, o dispositivo ou sistema de arquivos a ser utilizado (como NFS ou um sistema de arquivos temporário), e diversas outras configurações. Dessa maneira, é possível alocar o volume no dispositivo mais adequado para a aplicação específica.
Paráfrase: Uma sugestão prática é vincular um volume a um caminho dentro de uma imagem de base já preenchida com dados. Isso fará com que os dados da imagem de base sejam copiados para o volume no momento da conexão, o que pode ser útil para preparar previamente o volume com um conjunto de dados desejado. No entanto, é importante ressaltar que é sua responsabilidade limpar os dados do volume após a cópia.
Compartilhando containers Docker entre si.
Se desejar utilizar mais de um contêiner com o mesmo volume no Docker, basta criar o volume e conectá-lo a diferentes contêineres.
Isso estabelece três recipientes, instância1 por meio da instância3, e associa DataVoll a todos eles. O recipiente da instância3 possui DataVol1 conectado como somente leitura, indicado pelo :ro após o nome do volume.
É importante estar ciente de que o Docker não resolve automaticamente os conflitos entre containers que utilizam o mesmo volume. Isso pode variar de acordo com a sua aplicação. (Mais informações sobre esse assunto serão apresentadas mais adiante.)
Retirando contêineres Docker.
Os volumes não são retirados do disco automaticamente ao remover um recipiente. Isso foi planejado assim, pois não se deseja remover um volume que possa ser utilizado por outro recipiente que ainda não foi utilizado no futuro. Portanto, é responsabilidade do usuário realizar a limpeza do volume e do disco.
Docker inclui recursos internos que simplificam a limpeza de volumes. O comando de volume do Docker possui um subcomando chamado “docker volume prune”, que exclui todos os volumes não utilizados por nenhum contêiner no sistema. É possível ajustar o escopo da exclusão, como remover todos os volumes relacionados a um contêiner específico, utilizando flags na linha de comando.
Os volumes do Docker têm restrições em relação ao seu tamanho máximo.
Os volumes do Docker não são uma solução definitiva para o armazenamento local. Por causa da maneira como os contêineres se relacionam com os sistemas de arquivos locais, os volumes do Docker podem gerar mais desafios do que soluções.
Uma das limitações importantes do Docker é que não gerencia o bloqueio de arquivos em volumes compartilhados por diversos contêineres. Essa responsabilidade recai sobre o aplicativo em uso. Se houver dúvidas sobre a capacidade desse aplicativo de escrever em um sistema de arquivos compartilhado, existe o risco de corrupção de arquivos nesse volume. Uma alternativa viável seria optar por um servidor de armazenamento de objetos, como o Minio, em vez do sistema de arquivos local.
Outra questão com volumes Docker é que eles podem dificultar a portabilidade do aplicativo. A estrutura de armazenamento de cada máquina é diferente, o que pode resultar em suposições incorretas ao criar volumes com base na localização dos arquivos no sistema. Isso pode ser menos complicado se os contêineres forem utilizados apenas em sistemas em que a topologia é estritamente controlada, como em um cluster privado interno. No entanto, pode se tornar um problema se você decidir reestruturar as coisas posteriormente.
Por fim, é recomendável não utilizar volumes para armazenar dados stateful que podem ser mais bem gerenciados por outros mecanismos nativos no Docker. Por exemplo, os segredos da aplicação devem ser tratados pelo sistema de segredos do Docker ou por ferramentas de terceiros como o Vault da HashiCorp, em vez de serem armazenados em volumes ou camadas de imagem de contêineres.