Histórico de problemas de migração do Docker storage (docker root)

Até alguns dias atrás, foi decidido em um dos servidores mover o armazenamento do docker (o diretório em que o docker armazena todos os arquivos de contêineres e imagens) em uma partição separada, que
possuía mais capacidade. A tarefa, ao que parece, é trivial e não pressagia problemas ...

Introdução:

1. Pare e mate todos os contêineres de nosso aplicativo:

docker-compose down 

se houver muitos contêineres e eles estiverem em composição diferente, você poderá 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. Informamos o demônio da janela de encaixe a procurar em um novo diretório. Existem várias opções: use o sinalizador -g para apontar o daemon para um novo caminho ou as configurações do systemd, que usamos. Bem, ou link simbólico. Não vou pintar muito, a Internet está cheia de manuais sobre como transportar a raiz do docker para um novo local.

5. Iniciamos o demônio do docker e vemos que ele parece onde deveria estar:

 systemctl status docker 

Em uma das linhas de saída, devemos ver:
 ├─19493 /usr/bin/dockerd --data-root=/docker/data/storage 

Garantimos 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. Iniciamos nossa aplicação:
 docker-compose up -d 

7. Verifique

E aqui começa a diversão, DBMS, MQ, está tudo bem! A base está intacta, tudo funciona ... exceto o nginx. Nós temos nossa própria montagem nginx com kerberos e cortesãs . E a visualização dos logs do contêiner indicava que ele não pôde gravar em / var / tmp - permissão negada. Estico os dedos com uísque e tento analisar a situação ... Como é isso? A imagem da janela de encaixe não mudou. Acabamos de mudar o diretório. Sempre funcionou, e aqui está para você ... Por uma questão de experimento, entrei no contêiner com canetas e alterei os direitos para esse diretório, havia raiz, raiz 755 , raiz de raiz 777 . E tudo começou ... Um pensamento soou na minha cabeça - algum tipo de absurdo ... pensei, bem, talvez não levasse em conta alguma coisa ...

Decidi que gostávamos dos direitos de acesso aos arquivos durante a transferência. Eles pararam o aplicativo, o daemon do docker, excluíram o novo diretório e fizeram uma cópia do diretório / var / lib / docker já usando o rsync -a .

Acho que agora está tudo bem, estamos aumentando a janela de encaixe, o aplicativo.

III ... o problema permanece ... Meus olhos se contraíram. Corri para o console da minha máquina virtual, onde estou executando vários testes, tinha essa imagem nginx e subi no contêiner, e aqui os direitos de root 777 estão no diretório / var / tmp, ou seja, os mesmos que eu tive que configurar com as mãos . Mas as imagens são idênticas!

Em todos os lugares usado FS xfs.

Eu comparei através do comando

 docker inspect my-nginx:12345 

Todos os hashes são idênticos, todos um para um. Tanto no servidor quanto na minha virtualka. Excluí a imagem local do nginx e coloquei no spool novamente o registro, que por várias razões está na mesma máquina. E o problema é o mesmo ... Agora meu segundo olho se contraiu.

Não lembro quais pensamentos estavam na minha cabeça, além dos gritos de "AAAAAAA" e outras coisas. Na rua, às 4 horas da manhã, as fontes do docker foram usadas para entender o princípio do hash de camadas de imagem. Ele abriu a terceira lata de energia. E, no final, percebi que o hash leva em consideração apenas o arquivo, seu conteúdo, mas NÃO O DIREITO DE ACESSO ! Ou seja, de alguma maneira misteriosa, os direitos foram vencidos e o selinux é desativado, o acl não é usado, o bit pegajoso não está presente.

Excluí a imagem local, também a imagem do registro do docker e a iniciei novamente. E funcionou. Acontece que durante a transferência os direitos foram vencidos, tanto dentro da imagem local quanto dentro da imagem que está no registro. Como eu disse, por várias razões, ele estava localizado no mesmo carro. E, como resultado, em um diretório / var / lib / docker.

E antecipando a questão de se eles tentavam devolver o olhar do estivador ao catálogo antigo - não, infelizmente, as circunstâncias não permitiam. Sim, e realmente queria descobrir.

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

Conclusão: resolvi o problema, 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 vê-lo nos comentários!

Source: https://habr.com/ru/post/pt462013/


All Articles