História do problema da migração do armazenamento do docker (docker root)

Não faz muito tempo, foi decidido em um dos servidores transferir o armazenamento do docker (o diretório onde o docker armazena todos os arquivos de contêineres e imagens) para uma partição separada, que
tinha maior capacidade. A tarefa parecia trivial e não previa problemas...

Vamos começar:

1. Paramos e matamos todos os contêineres do nosso aplicativo:

docker-compose down

se houver muitos contêineres, e eles estão em diferentes composições, podemos fazer assim:

docker rm -f $(docker ps -q)

2. Paramos o daemon do docker:

systemctl stop docker

3. Movemos o diretório para o local desejado:

cp -r /var/lib/docker /docker/data/storage

4. Informamos ao daemon do docker para olhar no novo diretório. Existem algumas opções: ou através da flag -g indicar ao daemon o novo caminho, ou usar os arquivos de configuração do systemd, que foi o que utilizamos. Ou um symlink. Não vou me aprofundar muito nisso, na internet há muitos manuais sobre como mover a raiz do docker para um novo lugar.

5. Iniciamos o daemon do docker e verificamos se ele está olhando para o lugar certo:

systemctl status docker

Em uma das linhas de saída, devemos ver:

├─19493 /usr/bin/dockerd --data-root=/docker/data/storage

Confirmamos que passamos a opção para o daemon, agora vamos verificar se ele a aplicou (obrigado inkvizitor68sl)!

docker info | awk '/Root Dir/ {print $NF}' 

6. Iniciamos nosso aplicativo:

docker-compose up -d

7. Verificamos

E aqui começa a parte mais interessante, o SGBD, MQ, tudo bem! O banco está intacto, tudo funciona... exceto o nginx. Temos nossa própria compilação do nginx com kerberos e outra coisas. E a verificação dos logs do contêiner indicou que ele não consegue escrever em /var/tmp - Permissão negada. Estou massageando as têmporas e tentando analisar a situação... Como isso é possível? A imagem do docker não mudou. Apenas movemos o diretório. Sempre funcionou, e agora isso... Para experimentar, entrei manualmente no contêiner e mudei as permissões desse diretório, eram root, root 755, dei root, root 777. E tudo funcionou... Na minha cabeça soou um pensamento - que absurdo... Pensei, bem, talvez eu não tenha considerado algo...

Decidi que podíamos ter perdido as permissões de acesso aos arquivos durante a transferência. Paramos o aplicativo, o daemon do docker, excluímos o novo diretório e fizemos a cópia do diretório /var/lib/docker já utilizando rsync -a.

Agora eu acho que tudo está bem, iniciamos o docker, o aplicativo.

E aee... o problema persistiu... Eu estou com um espasmo no olho. Corri para o console da minha VM, onde executo vários testes, eu tinha essa imagem do nginx, e entrei no contêiner, e aqui no diretório /var/tmp as permissões estão root, root 777. Ou seja, as mesmas que eu tive que configurar manualmente. Mas as imagens são idênticas!

Em todos os lugares foi usada a FS xfs.

Eu comparei usando o comando

docker inspect my-nginx:12345

Todos os hashes são idênticos, todos iguais. Tanto no servidor quanto na minha VM. Eu removi a imagem local do nginx e puxei novamente do registry, que por vários motivos está na mesma máquina. E o problema é o mesmo... Agora estou com o segundo olho piscando.

Eu já não me lembro que pensamentos estavam na minha cabeça, além dos gritos de "AAAAAAA" e coisas do tipo. Na rua são 4 horas da manhã, comecei a examinar os fontes do docker com a intenção de entender o princípio de hashing das camadas da imagem. Abri a terceira lata de energético. E, no fim, percebi que o hashing leva em conta apenas o arquivo, seu conteúdo, mas NÃO AS PERMISSÕES! Ou seja, de alguma forma enigmática, nossas permissões foram corrompidas, sendo que o selinux está desligado, acl não estão em uso, sticky bit está ausente.

Eu excluí a imagem local, também removi a imagem do docker registry e fiz o push novamente. E tudo funcionou. Isso significa que, ao transferir, as permissões foram corrompidas, tanto dentro da imagem local quanto dentro da imagem que está no registry. Como já mencionei, por várias razões, ela estava na mesma máquina. E, como consequência, em um diretório /var/lib/docker.

E prevendo a pergunta, não tentamos devolver o docker ao antigo diretório — não, não tentamos, infelizmente, as circunstâncias não permitiram. E eu realmente queria entender.

Após escrever este artigo, a solução do problema parece óbvia para mim, mas no momento da análise não parecia. Honestamente, pesquisei, mas não encontrei situações semelhantes.

Resultado: resolvi o problema, mas não entendi a causa =(

Se alguém sabe ou tem ideias sobre as possíveis causas deste problema — ficarei extremamente grato nos comentários!

Fonte: habr.com