Os drivers de armazenamento do Docker controlam como as imagens e contêineres são armazenados em seu sistema de arquivos. Eles são o mecanismo que permite criar imagens, iniciar contêineres e modificar camadas graváveis. Aqui estão as diferenças entre cada driver e as situações onde eles devem ser usados.
Para que servem os drivers de armazenamento?
O driver de armazenamento ativo determina como o Docker gerencia suas imagens e contêineres. Os drivers disponíveis implementam estratégias diferentes para lidar com camadas de imagem. Eles terão características de desempenho exclusivas, dependendo do cenário de armazenamento em questão.
Os drivers de armazenamento estão intrinsecamente ligados à “camada gravável” de um contêiner. Este termo se refere ao nível superior do sistema de arquivos de um contêiner, que você pode modificar executando comandos, gravando arquivos e adicionando software em tempo de execução.
Embora os dados persistentes do contêiner do Docker devam sempre ser armazenados em volumes, as alterações no próprio sistema de arquivos do contêiner costumam ser inevitáveis. Você pode gravar arquivos temporários, armazenar variáveis de ambiente em um arquivo de configuração ou armazenar dados em cache para referência posterior.
Todas essas operações resultam no desvio do sistema de arquivos do contêiner em execução daquele definido por sua imagem. Sua escolha de driver de armazenamento lida com a discrepância e aplica a diferença.
O que acontece quando você inicia um contêiner?
Quando um novo contêiner é iniciado, o Docker primeiro puxa as camadas de imagem criadas ao construir seu Dockerfile. As camadas são armazenadas em sua máquina host, então você não precisa puxar a imagem novamente até que queira buscar atualizações. Como parte do processo de pull, o Docker identificará e reutilizará as camadas que já possui, evitando downloads redundantes.
Assim que as camadas da imagem estiverem disponíveis, o Docker iniciará o contêiner e adicionará uma camada extra na parte superior. Esta é a camada gravável que o contêiner pode modificar. Todas as camadas inferiores são imutáveis e derivadas de suas definições do Dockerfile.
A camada gravável funciona bem com alguns overheads quando você simplesmente adiciona arquivos ao sistema de arquivos de um contêiner. Eles acabam na camada gravável, no topo da pilha. Modificações em arquivos existentes são mais problemáticas: eles existem em camadas inferiores somente leitura, mas agora precisam ser gravados.
A abordagem do Docker é “copiar na gravação”, o que significa que o arquivo é copiado de sua camada original para a camada gravável no ponto de modificação. Esta é uma operação de E / S intensa que pode levar à degradação do desempenho.
Os diferentes drivers de armazenamento são responsáveis pela implementação do suporte à cópia na gravação. Cada driver oferece compensações exclusivas entre desempenho e eficiência de uso do disco.
Drivers de armazenamento disponíveis
O Docker usa uma arquitetura de driver de armazenamento conectável e oferece várias opções por padrão. Os drivers de armazenamento não afetam imagens ou contêineres individuais – você pode executar qualquer imagem Docker, independentemente do driver selecionado.
O driver de armazenamento ativo é uma configuração de nível de tempo de execução definida no arquivo de configuração do Docker daemon. Alguns drivers de armazenamento requerem provisionamento de sistema de arquivos especial antes de serem usados. Em seguida, você adiciona o driver de armazenamento selecionado para /etc/docker/daemon.json:
{
"storage-driver": "overlay2"
}
Você pode verificar seu driver atual executando docker info | grep "Storage Driver". Na maioria dos sistemas modernos, o padrão é overlay2.
Aqui está um resumo das opções que você pode escolher.
overlay2
o overlay2 driver agora é o padrão em todas as distribuições Linux com suporte ativo. Requer um ext4 ou xfs sistema de arquivos de apoio.
overlay2 oferece um bom equilíbrio entre desempenho e eficiência para operações de cópia na gravação. Quando uma cópia na gravação é necessária, o driver pesquisa nas camadas da imagem para encontrar o arquivo correto, começando pela camada superior. Os resultados são armazenados em cache para acelerar o processo da próxima vez.
Assim que o arquivo for encontrado, ele será copiado para a camada gravável do contêiner. A cópia é então modificada com as alterações solicitadas pelo container. A partir daqui, o contêiner vê apenas a nova versão copiada do arquivo. O original na camada inferior da imagem torna-se opaco para o contêiner.
overlay2 opera no nível do arquivo em oposição ao nível do bloco. Isso melhora o desempenho, maximizando a eficiência do uso da memória, mas pode resultar em camadas graváveis maiores quando muitas alterações são feitas.
Alternativas para este driver incluem aufs e o mais velho overlay. Nenhum deles é recomendado para uso em distribuições Linux modernas, onde overlay2 é suportado.
btrfs e zfs
Esses dois drivers funcionam no nível do bloco e são ideais para operações intensivas de gravação. Cada um deles requer seu respectivo sistema de arquivos de apoio.
O uso desses drivers resulta em seu /var/lib/docker diretório sendo armazenado em um btrfs ou zfs volume. Cada camada de imagem obtém seu próprio diretório no subvolumes pasta. O espaço é alocado para diretórios sob demanda conforme necessário, mantendo a utilização do disco baixa até que as operações de cópia na gravação ocorram.
Camadas de base de imagem são armazenadas como subvolumes no sistema de arquivos. Outras camadas tornam-se instantâneos, contendo apenas as diferenças que introduzem. As modificações de camada graváveis são tratadas no nível do bloco, adicionando outro instantâneo com espaço eficiente.
Você pode criar instantâneos de subvolumes e outros instantâneos a qualquer momento. Esses instantâneos continuam a compartilhar dados inalterados, minimizando o consumo geral de armazenamento.
O uso de um desses drivers pode fornecer uma experiência melhor para contêineres de gravação intensiva. Se você estiver gravando muitos arquivos temporários ou armazenando em cache muitas operações no disco, btrfs ou zfs pode superar overlay2. O que você deve usar depende do seu sistema de arquivos de apoio – geralmente zfs é preferido como uma alternativa mais moderna para btrfs.
fuse-overlayfs
Este driver de armazenamento fornece uma maneira de executar o Docker no modo sem raiz em uma máquina que não tem suporte para o overlay2 motorista. No entanto, como todas as distribuições Linux atualmente direcionadas agora funcionam com overlay2, fuse-overlayfs não é mais necessário ou recomendado.
Este driver funciona implementando um sistema de arquivos de sobreposição usando FUSE. Como um sistema de arquivos do espaço do usuário, ele funciona no modo sem raiz, mas incorre em penalidades de desempenho em comparação com um sistema de armazenamento no nível do kernel.
vfs
o vfs o driver é incluído apenas para fins de teste e não deve ser usado na produção. O desempenho deste driver é documentado como fraco.
vfs pode ser útil em alguns cenários especiais, pois não usa cópia na gravação. Em vez disso, cada camada obtém seu próprio diretório no disco. Quando um arquivo precisa ser movido entre camadas, ele simplesmente é copiado para um novo diretório.
Consequentemente vfs funciona com todos os sistemas de arquivos e se beneficia da simplicidade e facilidade de inspeção. Ele sofre com o uso intensivo de E / S e propenso a causar alto uso do disco, pois cada modificação de arquivo dispara uma cópia completa da camada de origem.
mapeador de dispositivos
Este já foi o driver recomendado para CentOS e RHEL, mas perdeu seu lugar para overlay2 em versões mais recentes do kernel. Este driver exigia um direct-lvm sistema de arquivos de apoio. devicemapper não deve mais ser usado – está obsoleto e será totalmente removido no futuro.
Resumo
Os drivers de armazenamento do Docker são usados para gerenciar camadas de imagem e a parte gravável do sistema de arquivos de um contêiner. Embora as mudanças nos sistemas de arquivos do contêiner sejam perdidas quando o contêiner para, elas ainda precisam ser persistidas durante a execução do contêiner. É o driver de armazenamento que fornece esse mecanismo.
Cada driver possui um conjunto diferente de otimizações que o torna mais ou menos adequado para diferentes cenários. Hoje em dia overlay2 é o driver padrão e a opção recomendada para a maioria das cargas de trabalho, embora opções alternativas como btrfs, zfs, e fuse-overlayfs possuem alguns recursos mais avançados e podem ser necessários em certos casos.
0 Comments