Historien om flytningen af docker storage (docker root)

For just a couple of days ago, it was decided to move the docker storage (the directory where Docker keeps all container files and images) to a separate partition on one of the servers, which
had greater capacity. The task seemed trivial and didn’t foresee any troubles...

We begin:

1. Stop and kill all containers of our application:

docker-compose down

if there are many containers and they are in different composes, you can do it like this:

docker rm -f $(docker ps -q)

2. Stop the Docker daemon:

systemctl stop docker

3. Move the directory to the desired location:

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

4. Inform the Docker daemon to look in the new directory. There are several options: either specify the new path to the daemon with the -g flag, or use systemd configs, which is what we used. Or a symlink. I won’t go into detail here; there are plenty of manuals on the internet about moving the Docker root to a new location. 5. Start the Docker daemon and check to see if it’s pointing where it should:

systemctl status docker

In one of the output lines, we should see:

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

We confirmed that the option was passed to the daemon, now let's check if it was applied (thanks to

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

6. Start our application: 

7. Check

docker-compose up -d

And here is where the most interesting part begins, the DB, MQ, everything is fine! The database is intact, everything works… except for nginx. We have our own nginx build with Kerberos and courtesans. And looking at the container logs indicated that it cannot write to /var/tmp — Permission denied. I’m rubbing my temples and trying to analyze the situation… How could this happen? The Docker image hasn’t changed. We simply moved the directory. It always worked, and now this… As an experiment, I manually entered the container and changed the permissions of this directory. They were

root, root 755 , I gave itroot, root 777 . And everything started working… A thought echoed in my head — this is ridiculous… I thought, maybe I overlooked something…I decided that we lost access rights to the files during the transfer. We stopped the application, the Docker daemon, deleted the new directory, and copied the directory /var/lib/docker using

rsync -a I think now everything is definitely fine, let's start Docker and the application..

Думаю, теперь точно все хорошо, поднимаем докер, приложение.

Og... problemet er stadig der... Mit øje er begyndt at trække. Jeg sprang hen til konsollen på min virtuelle maskine, hvor jeg kører forskellige tests. Jeg havde dette nginx-billede, og jeg gik ind i containeren, hvor kataloget /var/tmp har rettighederne root, root 777. Altså de samme, som jeg var nødt til at sætte manuelt. Men billederne er identiske!

XFS-filsystemet blev brugt overalt.

Jeg sammenlignede ved hjælp af kommandoen

docker inspect my-nginx:12345

Alle hashes er identiske, alle er helt ens. Både på serveren og på min virtuelle maskine. Jeg slettede det lokale nginx-billede og hentede det igen fra registry, som af en række grunde ligger på den samme maskine. Og problemet er det samme… Nu begynder mit andet øje også at trække.

Jeg kan ikke huske, hvilke tanker der var i mit hoved, ud over skrig som 'AAAAAAA' og lignende. Klokken er 4 om natten, og jeg kiggede på Docker-kildeteksterne i håbet om at forstå princippet for lagene i billedhastigheden. Jeg åbnede den tredje energidrik. Og til sidst gik det op for mig, at hashing kun tager højde for filen, dens indhold, men IKKE RETTIGHEDER! Så på en eller anden mystisk måde er vores rettigheder blevet korrupte, skønt selinux er slået fra, acl ikke bruges, og sticky bit ikke er tilgængeligt.

Jeg slettede også det lokale billede, samt billedet fra Docker-registry og pushede det igen. Og så virkede det. Det viser sig, at rettighederne blev korrupte ved overførslen, både inde i det lokale billede og inde i billedet, der lå i registry. Som jeg nævnte, lå det af flere grunde på den samme maskine. Og som et resultat i det samme katalog /var/lib/docker.

Og forudse spørgsmålet om vi havde forsøgt at vende Docker tilbage til det gamle katalog — nej, vi har ikke prøvet, desværre tillod omstændighederne ikke det. Men jeg ønskede virkelig at forstå.

Efter skrivning af denne artikel virker løsningen på problemet åbenlys, men på tidspunktet for analysen virkede den ikke sådan. Ærligt, jeg googlede, og fandt ikke lignende situationer.

Resultat: Problemet blev løst, men jeg forstod ikke årsagen =(

Hvis nogen har nogle ideer om mulige årsager til dette problem — ville jeg være meget glad for jeres kommentarer!

Kilde: habr.com