03 - Conceito geral de Volumes no Docker

Continuando a série sobre meus estudos em Docker, desta vez irei apresentar um pouco das minhas anotações sobre Volumes.

Volumes

Antes de entrarmos a fundo em volumes, precisamos entender como o sistema de arquivos funciona no Docker. Inicialmente, todas as imagens do Docker são armazenadas como séries de camadas somente leitura, quando é iniciado um container usando essa imagem, é criada uma nova camada com permissão de escrita. Quando um arquivo é modificado, ele será copiado para camada de leitura subjacente e também para a camada superior de leitura e gravação. Quando um container do Docker é destruído, a imagem continua ainda disponível para ser utilizada, porem ocorre um “reinicio” da imagem, excluindo todas as modificações do container anterior. Isso tudo funciona nas camadas do Union File System

Porem quando precisamos salvar arquivos persistentes e compartilhar arquivos e dados entre os containers, foi criado o conceito de Volumes, que são diretórios ou arquivos, que ficam fora das camadas do Union File System, ficando armazenados dentro do Host Docker.

Volumes: Anônimos ou nomeados

O volume ele pode ser do tipo anonymous ou named volume.

Os volumes anonymous, ele recebe uma ID comprida para identificação, no início pode ser fácil para administrar, mas conforme aumente a quantidade de containers em execução, pode dificultar a identificação do mesmo. É muito útil quando precisamos que o próprio Docker manipule os arquivos armazenados. Este tipo de volume é gerenciado pelo Docker Host.

Os named volumes, são muitos parecidos com os volumes anonymous, porem o Docker gerencia o local em que o volume será criado, mas ele recebe um nome para identificação. Ele pode ser criado sozinho ou no momento de iniciar um container. Dependendo totalmente de uma estrutura de diretório no Docker Host.

Abaixo comento cada um deles com mais detalhes.

Named volumes (Container de dados): É criado um container e dentro desse container é nomeado um volume para ser consumido. Todos esses volumes são gerenciados pelo Docker Daemon e armazenados em /var/lib/docker/volumes, onde toda a referência é feita para o container que irá utiliza-lo e não para a pasta em si. Eles podem ser criados manualmente ou no momento da criação do container. Devido a este fato, não precisa de uma estrutura de diretórios no host do docker.

Com o volume criado, é possível associá-lo a qualquer container:

-v ou — volume indica o volume que será usado.

— mount é composto por chave e valor, onde o primeiro vem identificado o volume, depois o volume nomeado no Docker Host (podendo ser identificado com source ou src), após o diretório interno do container (pode ser usado como destination, dst ou target) e por fim, permissões ( podendo ser read-only ou read-write, rw e ro, por default é rw).

Como o volume não está atrelado diretamente a um container, ele pode ser portável para qualquer outro, basta referencia-lo no momento da criação do container. Outro ponto é que no momento em que é parado ou removido o container, este volume continua ativo ainda para que possa ser usado em outra instancia, além de possuir a possibilidade de utilização do mesmo volume em vários containers. Um contra da utilização dos volumes, é a maior utilização de acessos a disco, pois há uma alta analise realizada pela libcontainer para verificação destes volumes mapeados, e pode gerar uma complexidade na administração de vários containers, já que requer alguns passos a mais gerencia-los.

Host volume — Bind mounts (Mapeamento de pasta do host): Em palavras mais simples, nada é que um compartilhamento de um diretório local do host para um diretório de um container. É necessário que o container tenha um diretório especifico para que o container funcione adequadamente e o mapeamento seja montado. Não podemos utilizar dentro do dockerfile, apenas quando iniciaremos o container com “docker container run”.

Nesse exemplo, seria mapeado a pasta c:/teste do host local para /tmp do container.

Já aqui, pegaremos o diretório local (variável $(pwd)) e mapearemos para /tmp dentro do container.

Também poderá aplicar as permissões neste tipo de volume, funcionando da mesma maneira do anterior, podendo ser read-only ou read-write, rw e ro, por default é rw.

Desta forma temos como ponto positivo que este volume não está atrelado ao container, sendo assim ele pode ser portável para qualquer outro container no momento desejado. Porem como contra, podemos encontrar dificuldade em administrar, já que é criado uma camada a mais para gerenciamento e também pode ser vulnerável a brechas de segurança a nível de permissões de arquivos, já que o ambiente não está sendo controlado pela libcontainer (https://github.com/opencontainers/runc/tree/master/libcontainer).

TMPFS: Quando rodamos Docker em ambientes Linux, temos ainda uma outra opção, chamada tmpfs. O container pode criar arquivos para armazenamento fora da camada de escrita. Este tipo de armazenamento, é temporário e ficando ativo somente na vida útil do container, assim que é parado ou removido, a montagem tmpfs é removida e os arquivos apagados da memória do host.

Para montar um armazenamento tmpfs, pode ser utilizado com a opção mount e sinalizamos tmpfs e destination para destino dentro do container. Pode-se utilizar as opções tmpfs-size e tmpfs-mode, onde configuramos o tamanho do diretório e o tipo descrita. Mais informações podem ser encontradas na documentação oficial. Não há opções de source para este tipo de montagens. Podemos ver o exemplo abaixo, uma montagem em um container nginx para a pasta /app.

Também temos a opção de executar somente passando o parâmetro tmpfs, onde nele não é possível passar nenhuma opção configurável e só pode ser utilizado em containers independentes.

Verificando e identificando os volumes criados

Caso tenha necessidade de verificar quais os volumes o container possui executando, basta utilizar o inspect. Lembrando que o container deverá estar iniciado. Sempre será identificado no campo Type.

Do tipo bind mount:

Do tipo Volume:

Aqui podemos ver o diretório padrão do armazenamento do volume /var/lib/docker/volumes.

Do tipo tmpfs usando — mounts:

Podemos notar que não há nenhum diretório source, ele apenas está executando dentro da memória.

Do tipo tmpfs usando –tmpfs:

Docker Volume Prune

Um Named Volume nunca é apagado ao fim do ciclo de vida de um container, ele sempre ficará disponível, isso poderá ser um incomodo após um período e poderá consumir muito recurso de disco a longo prazo. Neste caso poderá ser utilizado a ferramenta prune, que permite limpar volumes antigos que não estão sendo utilizados no momento. Apenas cuidado ao utilizar, porque se tiver algum container parado no momento e que possa ser utilizado posteriormente, ele será removido também.

Ate a proximal!!!

Monitoring, DevOps Student and content creation!

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store