Introdução detalhada ao driver de armazenamento do Docker
Recentemente, trabalhei em um projeto e não sabia como usar o driver de armazenamento do Docker durante esse período, então procurei informações on -line e resolvi. Vou gravar aqui.
Propósito
O Docker é um mecanismo de contêiner de aplicativo de código aberto que usa principalmente o espaço para nome do kernel Linux para obter isolamento de sandbox e usa o CGROUP para obter limitação de recursos. O Docker é um contêiner Linux leve usado para desenvolvimento e implantação unificados, tentando resolver o problema da "dependência do inferno", combinando serviços e componentes dependentes, semelhantes aos contêineres usados pelos navios e alcançando a rápida instalação e implantação.
1. A arquitetura básica do Docker - cliente e daemon
Vamos primeiro entender o processo básico de arquitetura e inicialização do Docker. De fato, o Docker adota uma arquitetura C/S, incluindo o cliente e o servidor. O Docker Daemon aceita solicitações dos clientes como servidor e processa essas solicitações (crie, execute, envie contêineres). O cliente e o servidor se comunicam na mesma máquina através da API RESTful. No processo específico de uso, após a execução do Docker de serviço, o processo do Docker Deamon Daemon é gerado no host, executado em segundo plano e aguarde o recebimento de mensagens do cliente (ou seja, comandos de entrada do docker, como o Docker Pull XXX, o Docker Run…, Docker Commit XXX) para obter o Docker Dock Dock Docker. Depois de iniciar o serviço do Docker, você pode ver o processo do Docker.
Padrão
[root@localhost ~]# ps -aux | Grep Dockerroot 11701 0,0 0,4 359208 16624? SSL 21:05 0:00/usr/bin/docker -d -h fd: // ---selinux -inabled --insecure-registry 186.100.8.216:5000root 11861 0,0 0,0 113004 2256 PTS/0 S+ 23:01 0:00 -corp -cors = cors
Isso ocorre principalmente porque, ao especificar o sistema de arquivos posteriormente, você precisa configurar o driver de armazenamento específico em/etc/sysconfig/docker (isso escreverá um blog especial) e depois iniciará o Docker Daemon e não pode operar através dos parâmetros do comando Run. Você também pode configurá -lo diretamente da linha de comando do host através do Docker D.
2. Método de armazenamento do docker - Driver de armazenamento
A parte central do modelo Docker é utilizar efetivamente o mecanismo de espelhamento hierárquico. O espelho pode ser herdado através da hierarquia. Com base na imagem básica (sem a imagem pai), várias imagens de aplicativos específicas podem ser feitas. Diferentes contêineres do Docker podem compartilhar algumas camadas básicas do sistema de arquivos e, ao mesmo tempo, juntamente com suas próprias camadas de mudança exclusivas, melhorando bastante a eficiência de armazenamento. O mecanismo principal é o modelo hierárquico e montar diretórios diferentes para o mesmo sistema de arquivos virtual (unir vários diretórios em um único sistema de arquivos virtual, neste artigo). Vários drivers de armazenamento diferentes são usados para o Mirror Storage Docker, incluindo: AUFs, DeviceMapper, BTRFs e Sobreposição (do site oficial). A seguir, é apresentada uma breve introdução a diferentes drivers de armazenamento.
AUFS
AUFS (outrounionfs) é um sistema de arquivos conjuntos. AUFS suporta definir permissões readonly, readWrite e Whiteout Inable para cada diretório de membros (semelhante ao Git). Ao mesmo tempo, existe um conceito semelhante nos AUFs, onde ramificações com permissões somente leitura podem ser modificadas logicamente incrementalmente (não afetando a parte somente leitura). O único driver de armazenamento da AUFS pode realizar o compartilhamento de bibliotecas de tempo de execução executáveis e compartilháveis entre os contêineres; portanto, quando você executa centenas de tempos de execução com o mesmo código do programa ou bibliotecas de tempo de execução, o AUFS é uma opção muito boa.
Mapper de dispositivo
O Mapper de dispositivo é um mecanismo de estrutura de mapeamento, desde dispositivos lógicos até dispositivos físicos fornecidos no kernel Linux 2.6. Sob esse mecanismo, os usuários podem formular facilmente estratégias de gerenciamento para implementar recursos de armazenamento de acordo com suas necessidades (consulte os detalhes). O driver de mapeador de dispositivos criará um arquivo simples de 100g que contém suas imagens e contêineres, cada contêiner é limitado a um volume de tamanho de 10g (Nota: Este é um arquivo escasso criado automaticamente usando loopback, especificamente dados e metadados em/var/lib/docker/deviceMapper/deviceMapper, que podem ser expandidos dinâmico). Você pode ajustar o tamanho do contêiner do docker, para referência específica). Primeiro feche o serviço do Docker e execute o comando:
Padrão
[root@localhost ~]# Docker -d -s devicemapperInfo [0000] +wob serveapi (unix: ///var/run/docker.sock) info [0000] ouvindo para http no unix (/var/run/docker.sock) [0000] +trabalho init_etwnern (/run/docker.sock) [0000] +trabalhador = OK (0) Informações [0000] Carregando recipientes: Iniciar. .... Info [0000] Carregando recipientes: Concluído. Info [0000] Docker Daemon: 1.4.0 4595d4f/1.4.0; execriver: nativo-0.2; GRAPHDRIVER: INFO DEVICEMAPPER [0000] +Job AcepConnections () info [0000] -job aceitConnections () = OK (0)
Além disso, o Docker pode especificar o parâmetro Storage-OPT ao iniciar o contêiner, mas agora apenas o DeviceMapper pode aceitar configurações de parâmetros. Haverá displays de blog direcionados mais tarde.
BTRFS
O driver BTRFS pode ser muito eficiente na construção do Docker. No entanto, como o DeviceMapper, ele não suporta armazenamento compartilhado entre dispositivos (participe do site oficial). O BTRFS suporta instantâneos e clones e também pode gerenciar facilmente vários dispositivos físicos. (Para detalhes, consulte a introdução da IBM ao BTRFS)
sobreposição
A sobreposição é muito semelhante aos AUFs, mas seu desempenho é melhor que o AUFS e possui boa utilização de memória. Agora foi fundido no Linux Kernel 3.18. Comando de uso específico: sobreposição do Docker DS
Nota no site oficial: atualmente não é suportado no BTRFS ou em qualquer cópia no sistema de arquivos de gravação e deve ser usado apenas em partições ext4.
Estrutura do diretório de 3 docker
Os dois conceitos mais importantes de Docker são espelhos e recipientes. Então, onde está a imagem que puxamos para baixo armazenada? Após o início do contêiner Run Run, onde está modificado o conteúdo de nossa operação? Como os drivers específicos são diferentes, o efeito final da implementação é diferente. Vamos analisar a estrutura de armazenamento do Docker usando o driver de armazenamento de mapeador de dispositivo como exemplo.
1. Digite o diretório/var/lib/docker e liste o conteúdo:
Padrão
[root@localhost ~]# cd/var/lib/docker/[root@localhost docker]# lscontainers deviceMapper execriver gráfico init linkgraph.db repositórios
De acordo com o conteúdo do diretório, é óbvio que o driver deviceMapper é usado.
NOTA: As pastas mostradas abaixo estão todas abaixo/var/lib/docker.
2. Qual pasta o arquivo de imagem de tração existe? (consulte)
As informações da imagem de puxar são salvas na pasta gráfica e o conteúdo da imagem existe no DeviceMapper/ DeviceMapper/ Data.
3. Onde o contêiner iniciado é executado?
As informações de configuração de contêiner iniciadas são salvas em contêineres e o Execdriver/ Native/ também é visualizado.
O conteúdo da operação no contêiner é salvo em DeviceMapper/DeviceMapper/Data.
4. O papel do gráfico
Na arquitetura do Docker, ele interpreta o custodiante da imagem do contêiner baixada e o gravador do relacionamento entre a imagem do contêiner baixado. No diretório local do gráfico, as informações específicas armazenadas para cada imagem do contêiner são: os metadados (JSON) da imagem do contêiner, o tamanho da camada (tamanho em camada) informações da imagem do contêiner e os rootfs específicos representados pela imagem do contêiner.
5. Teste experimental:
- Inicialmente, nenhum contêiner está ativado:
Padrão
[root@localhost Docker]# LL RECORCENTES/TOTAL 0
- Inicie um contêiner:
Padrão
[root@localhost Docker]# Docker Run -i -t - -rm Centos: 7 /bin /Bash [raiz@187A8F9D2865 /]#
O uuid do contêiner iniciado = 187a8f9d2865
- Antes de iniciar o contêiner, verifique o tamanho real do arquivo em/var/lib/docker/deviceMapper/deviceMapper/
Padrão
[root@bhdocker216 docker]# du -h devticemapper/devticemapper/*2.1g devticemapper/devticemapper/data3.5m devticemapper/devticemapper/metadata
- Ver no host
Padrão
[raiz@bhdocker216 docker]# ls contêineres/187a8f9d2865c2ac *** 91b981
Verifique o conteúdo do contêiner iniciado abaixo da pasta UUID:
Padrão
[raiz@bhdocker216 contêineres]# ll 187A8F9D2865C2AC *** 91B981TOTAL 24-RW -----. 1 raiz 273 5 de março 23:59 187A8F9D2865 ***-JSON.LOG-RW-R--. 1 raiz de raiz 1683 5 de março 23:58 config.json-rw-r--. 1 raiz raiz 334 5 de março 23:58 hostconfig.json-rw-r--. 1 raiz raiz 13 mar 5 23:58 hostname-rw-r--. 1 raiz raiz 174 5 de março 23:58 hosts-rw-r--. 1 raiz raiz 69 5 de março 23:58 Resolv.conf- Adicionar arquivo no contêiner de inicialização e visualizá-lo.
Primeiro, crie um arquivo no contêiner em execução:
Padrão
[raiz@8a1e3ad05d9e/]# dd if =/dev/zero de = fluppy.img bs = 512 contagem = 57605760+0 registros in5760+0 registros out2949120 bytes (2,9 mb), 0,0126794 s, 2333 mb/s)
Em seguida, veja o arquivo em/var/lib/docker/deviceMapper/devticemapper/:
Padrão
[root@bhdocker216 docker]# du -h devticemapper/devticemapper/*5.5g devticemapper/devticemapper/data4.6m devticemapper/devticemapper/metadata
O tamanho deste local é um pouco diferente porque eu executei o #DD se =/dev/zero de = test.txt bs = 1m count = 8000 para criar um arquivo de tamanho 8G. Eu o encerrei porque estava muito lento, mas posso ver claramente que as duas pastas mudaram (adicionadas) ao operar no contêiner em execução.
- Verifique o gráfico. Quando apenas uma imagem (Ubuntu14.10) é puxada, 7 diretórios nomeados de comprimento aparecem. Como isso aconteceu?
Use a árvore de imagens do docker para listar a estrutura da árvore do espelho, e podemos ver a estrutura de armazenamento hierárquica do espelho. O Ubuntu final (camada 7) é baseado nas alterações da camada 6, ou seja, a camada n-fés nesta árvore lógica é baseada nas alterações N-1 e a camada N depende da imagem N-1. A camada 0ª, o tamanho é 0, é chamada de imagem base.
- Qual é o conteúdo no diretório gráfico/uuid?
Padrão
[ROOT@localhost gráfico]# ll 01bf15a18638145eb *** -Htotal 8.0K-RW -----. 1 raiz raiz 1.6k 5 de março 18:02 JSON-RW -----. 1 raiz raiz 9 mar 5 18:02
Veja o conteúdo do Layersize: o tamanho da camada de representação digital (unidade: B). JOSN: Salve os metadados desta imagem (como: tamanho, arquitetura, configuração, contêiner, ** uuid **, etc.).
- Exibir pasta DevticeMapper/DeviceMapper
Existem duas pastas, dados e metadados. De fato, o Driver de Mapper do dispositivo armazena os arquivos de espelho e contêiner no arquivo ** DATA **. Você pode visualizar o tamanho dos dados e os metadados através do Docker Info. Além disso, você pode usar o du h (usado acima) para visualizar os tamanhos reais desses dois arquivos esparsos.
- Execdriver
Padrão
[raiz@bhdocker216 docker]# ls execriver/nativo/8a1e3ad05d9e66a455e683a2c *** 2437bdcccdfdfa // visualize o conteúdo interno: [root@bhdocker216 8a1e3ad05d9e6a6a6a6ain45d.
- volumes
Os volumes sem o parâmetro -v estão vazios. Após o teste, se o contêiner for iniciado, adicione o parâmetro -v, um UUID será exibido na pasta Volumes. Uma pesquisa global será realizada no host e encontrada apenas em volumes. Não tem nada a ver com a imagem e o UUID do contêiner.
Padrão
[root@bhDocker216 docker]# find / -name 86eb77f9f5e25676f100***d5a/var/lib/docker/volumes/86eb77f9f5e25676f100***d5a//View the content inside: [root@bhDocker216 volumes]# ls 86EB77F9F5E25676F100 *** d5aconfig.json [root@bhdocker216 volumes]# cat 86eb77f9f5e25676f100 *** d5a /config.json {"ID":"86eb77f9f5e25676f100a89ba727bc15185303236aae0dcf4c17223e37651d5a","Path":"/home/data","IsBindMount":true,"Writable":true} Descrição da tabela da função da pasta
Faça um resumo, organize uma tabela e explique as funções de diferentes pastas em/var/lib/docker:
Obrigado pela leitura, espero que isso possa ajudá -lo. Obrigado pelo seu apoio a este site!