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

Não mais do que alguns dias atrás, foi decidido em um dos servidores mover o armazenamento do docker (o diretório onde o docker armazena todos os contêineres e arquivos de imagem) para uma seção separada, que
tinha maior capacidade. A tarefa parecia trivial e não previa problemas...

Introdução:

1. Pare e elimine todos os containers da nossa aplicação:

docker-compose down

se houver muitos recipientes e eles estiverem em composições diferentes, você pode fazer o seguinte:

docker rm -f $(docker ps -q)

2. Pare o daemon do docker:

systemctl stop docker

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

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

4. Dizemos ao daemon docker para procurar no novo diretório. Existem várias opções: usar o sinalizador -g para apontar o daemon para um novo caminho ou configurações do systemd, que usamos. Ou um link simbólico. Não vou entrar em muitos detalhes sobre isso, está na Internet. cheio de manuais sobre como mover o docker root para um novo local.

5. Inicie o daemon docker e certifique-se de que ele esteja no lugar certo:

systemctl status docker

Em uma das linhas de saída devemos ver:

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

Certificamo-nos de que a opção foi passada para o daemon, agora vamos verificar se ela foi aplicada (obrigado inkvizitor68sl)!

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

6. Vamos iniciar nossa aplicação:

docker-compose up -d

7. Verifique

E aqui começa a diversão, SGBD, MQ, está tudo bem! O banco de dados está intacto, tudo funciona... exceto nginx. Temos nosso próprio nginx construído com Kerberos e cortesãs. E a visualização dos logs do contêiner indicou que não é possível gravar em /var/tmp - Permissão negada. Amasso as têmporas com os dedos e tento analisar a situação... Como isso é possível? A imagem do Docker não mudou. Acabamos de mover o diretório. Sempre funcionou, e aqui está para você... Para experimentar, entrei no container com as mãos e mudei os direitos deste diretório, havia raiz, raiz 755, deu raiz, raiz 777. E tudo começou... Um pensamento começou a soar na minha cabeça - uma espécie de bobagem... pensei, bom, talvez não tenha levado algo em consideração...

Decidi que nos apaixonamos pelos direitos de acesso aos arquivos durante a transferência. Paramos o aplicativo, o daemon docker, excluímos o novo diretório e copiamos o diretório /var/lib/docker usando rsync -a.

Acho que está tudo bem agora, vamos criar a aplicação Docker.

Eaand... o problema permaneceu... Meu olho estremeceu. Corri para o console da minha máquina virtual, onde executo vários testes, tinha essa imagem nginx, e subi dentro do container, e aqui os direitos do diretório /var/tmp são root, root 777. Ou seja, o mesmo que eu tive que definir manualmente. Mas as imagens são idênticas!

O sistema de arquivos xfs foi usado em todos os lugares.

Eu comparei usando o comando

docker inspect my-nginx:12345

Todos os hashes são idênticos, um por um. Tanto no servidor quanto na minha máquina virtual. Excluí a imagem nginx local e a extraí novamente do registro, que por vários motivos está na mesma máquina. E o problema é o mesmo... Agora meu segundo olho está tremendo.

Não lembro mais quais pensamentos passavam na minha cabeça, além de gritar “AAAAAAAA” e outras coisas. Eram 4 horas da manhã e o código-fonte do Docker foi usado para entender o princípio do hash das camadas de imagem. Abri a terceira lata de bebida energética. E no final me dei conta de que o hash só leva em consideração o arquivo, seu conteúdo, mas NÃO DIREITOS DE ACESSO! Ou seja, de alguma forma misteriosa, nossos direitos foram perdidos, o selinux está desabilitado, o acl não é usado e não há nenhum sticky bit.

Excluí a imagem local, também excluí a imagem do registro do docker e a enviei novamente. E tudo funcionou. Acontece que durante a transferência os direitos foram perdidos, tanto dentro da imagem local quanto dentro da imagem que estava no registro. Como já disse, por vários motivos estava localizado no mesmo carro. E como resultado, em um diretório /var/lib/docker.

E antecipando a questão de saber se eles tentaram devolver o olhar do estivador ao diretório antigo - não, eles não tentaram, infelizmente, as circunstâncias não permitiram. Sim, e eu realmente queria descobrir isso.

Depois de escrever este artigo, a solução para o problema me parece óbvia, mas no momento da análise não parecia assim. Sinceramente, pesquisei no Google e não encontrei situações semelhantes.

Resultado: resolvi o problema, ainda não entendi o motivo =(

Se alguém souber, adivinhar, tiver uma visão sobre as possíveis causas desse problema, ficarei extremamente feliz em receber notícias suas nos comentários!

Fonte: habr.com