O que faz com que um contentor encha o disco do sistema quando os respetivos dados estão noutro local?

Um contentor pode encher o disco do sistema quando os registos, as caches, os ficheiros temporários ou gravações acidentais permanecem no armazenamento local do Docker.

Mover uma biblioteca multimédia ou um volume de base de dados para outro conjunto de armazenamento não move a imagem do contentor, a camada gravável, o registo JSON, a cache do BuildKit, os metadados nem qualquer caminho omitido da lista de montagens. Uma montagem externa que falhe também pode deixar vazio o diretório esperado no anfitrião, fazendo com que a aplicação grave novos dados no disco do sistema sem um erro evidente.

Meça a raiz do Docker antes de inspecionar os dados da aplicação

Verifique o sistema de ficheiros que contém a raiz de dados do Docker e compare os tamanhos dos diretórios no anfitrião com os registos de imagens, contentores, volumes e cache de compilação do Docker. Registe a utilização antes de eliminar qualquer coisa.

Um utilizador do Cloudron descobriu que /var/lib/docker/overlay2 consumia mais espaço do que todos os dados visíveis das aplicações, demonstrando por que motivo a raiz de armazenamento do Docker tem de ser medida separadamente das bibliotecas externas.

Se o disco do sistema estiver cheio mas o conjunto externo tiver espaço, determine se o crescimento está nos contentores, nas camadas overlay, nos volumes, nas imagens ou na cache de compilação. Não execute uma limpeza abrangente antes de classificar os dados ativos e recuperáveis.

Verifique se existem registos JSON de contentores sem limite

Inspecione o controlador de registos e o tamanho do ficheiro de registo de cada contentor. Um serviço pode armazenar os seus dados principais noutro local, enquanto a saída padrão e o erro padrão crescem indefinidamente no diretório local de contentores do Docker.

O Code Maven documenta um caso em que docker system df não revelou o problema principal porque o ficheiro de registo predefinido continuava a crescer fora desse resumo. O consumidor oculto era um registo de contentor em crescimento contínuo.

Encontre e corrija o erro ruidoso da aplicação antes de rodar ou truncar os registos. Configure a rotação limitada de registos para os contentores futuros e confirme que os novos ficheiros deixam de crescer ao atingir o limite esperado.

Encontre os dados gravados na camada gravável do contentor

Compare os caminhos persistentes previstos com as diretorias reais de cache, transcodificação, transferências, base de dados, miniaturas, cópias de segurança e ficheiros temporários da aplicação. Qualquer gravação sem montagem permanece na camada gravável do contentor, no disco do sistema.

Uma explicação num fórum do Docker observa que as gravações e os ficheiros de imagem alterados são armazenados na camada gravável, enquanto os registos grandes não rodados permanecem nos metadados do contentor. Ambos podem fazer com que um contentor consuma quase todo o espaço local, apesar de existir um volume de dados externo.

Utilize os relatórios de tamanho por contentor e inspecione os maiores caminhos alterados dentro do contentor. Adicione montagens bind explícitas ou volumes nomeados apenas para os dados que têm de persistir e, depois de salvaguardar tudo o que for importante, recrie o contentor para eliminar o conteúdo obsoleto da camada gravável.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Confirme que a montagem externa estava presente quando o contentor foi iniciado

Verifique se o SSD, a partilha NAS ou o conjunto de armazenamento estava montado no caminho esperado do anfitrião antes de o Docker iniciar o contentor. Compare a identidade do dispositivo e o resultado da montagem com a diretoria que o contentor vê.

Quando uma montagem externa está ausente, a diretoria subjacente vazia no sistema de ficheiros do sistema pode continuar a existir. O contentor pode gravar normalmente nessa diretoria de recurso, fazendo com que o disco do sistema cresça enquanto o conjunto externo parece não ser utilizado.

Pare o contentor antes de voltar a montar o armazenamento sobre dados de recurso já preenchidos. Mova ou reconcilie os ficheiros ocultos em segurança, adicione dependências de montagem ou verificações no arranque e impeça o arranque da aplicação quando o dispositivo esperado estiver em falta.

Inspecione as camadas das imagens, a cache de compilação e os objetos abandonados

Analise as imagens não utilizadas, os contentores parados, os volumes anónimos e a cache do BuildKit. As atualizações frequentes ou as compilações locais podem acumular muitas camadas, mesmo quando os dados persistentes da aplicação estão corretamente montados noutro local.

Uma explicação num fórum do projeto Moby esclarece que as montagens overlay podem tornar confusos os valores de espaço em disco e que a utilização do sistema de ficheiros subjacente tem de ser interpretada cuidadosamente. Um caso separado do Home Assistant também mostrou o crescimento de overlay2 devido a registos e camadas ao longo do tempo.

Remova apenas os objetos confirmados como não utilizados pelos projetos Compose atuais e pelas cópias de segurança. Nunca elimine manualmente diretórios individuais de overlay2, pois as referências dos metadados do Docker podem ficar inconsistentes.

Valide a correção com uma linha de base de crescimento

Depois de corrigir o caminho responsável, registe a utilização da raiz do Docker, os tamanhos dos registos, os tamanhos graváveis dos contentores e a utilização do conjunto externo em intervalos regulares, durante a carga de trabalho que anteriormente causava o crescimento.

O fluxo de trabalho do ZimaSpace para preparar uma transferência NAS de grande dimensão fornece uma carga repetível para confirmar que os dados chegam ao conjunto pretendido.

O problema só está resolvido quando o crescimento do disco do sistema corresponde ao comportamento esperado das imagens e dos registos, os dados persistentes da aplicação crescem no conjunto externo e a ausência de uma montagem externa provoca uma falha segura no arranque, em vez de gravações silenciosas no sistema de ficheiros raiz.