Historie problému s přesunem docker storage (docker root)

Před pár dny bylo rozhodnuto přesunout docker storage (adresář, kde Docker ukládá všechny soubory kontejnerů a obrazů) na samostatnou partition, která
měla větší kapacitu. Úkol se zdál být triviální a nijak neohrožoval...

Začínáme:

1. Zastavíme a zabijeme všechny kontejnery naší aplikace:

docker-compose down

pokud je kontejnerech mnoho a jsou v různých compose, můžeme to udělat takto:

docker rm -f $(docker ps -q)

2. Zastavíme docker démon:

systemctl stop docker

3. Přesuneme adresář na požadované místo:

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

4. Řekneme docker démonu, aby se díval do nového adresáře. Existuje několik variant: buď přes příznak -g zadat démonu novou cestu, nebo konfigurační soubory systemd, které jsme použili. Nebo symlink. Rozepisovat to nebudu, na internetu je spousta návodů na přesun docker root na nové místo.

5. Spustíme docker démona a sledujeme, aby se díval, kam má:

systemctl status docker

V jednom z řádků výstupu bychom měli vidět:

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

Ujistili jsme se, že jsme démonovi předali možnost, nyní zkontrolujeme, zda ji aplikoval (děkujeme inkvizitor68sl)!

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

6. Spustíme naši aplikaci:

docker-compose up -d

7. Kontrolujeme

A tady začíná to nejzajímavější, DB, MQ, všechno je v pořádku! Databáze je celá, všechno funguje… kromě nginx. Máme svou sestavu nginx s Kerberosem a kurtižankami. A prohlížení logů kontejneru ukázalo, že nemůže zapisovat do /var/tmp — Permission denied. Protahuji prsty přes spánky a snažím se analyzovat situaci… Jak to? Docker image se přece neměnil. My jsme jen přesunuli adresář. Vždy to fungovalo, a teď najednou… Pro experiment jsem vstoupil do kontejneru a změnil práva na tento adresář, byla root, root 755, dal root, root 777. A všechno se rozjelo… V hlavě mi zazněla myšlenka — nějaký nesmysl… Myslel jsem si, že možná něco podceňuji…

Rozhodl jsem se, že jsme ztratil práva přístupu k souborům při přesunu. Zastavili jsme aplikaci, docker démona, smazali novou adresář a provedli kopírování adresáře /var/lib/docker již s použitím rsync -a.

Myslím, že teď je všechno v pořádku, zvedáme docker, aplikaci.

Aaa… the problem remains… My eye is twitching. I rushed to the console of my virtual machine where I run various tests; I had this nginx image, and I went inside the container, and here in the directory /var/tmp the permissions are set to root, root 777. That is, the same ones I had to set manually. But the images are identical!

XFS file system was used everywhere.

I compared it using the command

docker inspect my-nginx:12345

All hashes are identical, all exactly the same. On the server and on my virtual machine. I deleted the local nginx image and pulled it again from the registry, which for various reasons is on the same machine. And the problem is the same… Now my second eye is twitching.

I don’t even remember what thoughts were in my head besides screams of 'AAAAAA' and the like. It’s 4 a.m. outside, and I dug into the Docker source code to understand the principle of hashing image layers. I opened my third energy drink. And in the end, it dawned on me that hashing only takes into account the file, its content, but NOT ACCESS PERMISSIONS!So somehow mysteriously our permissions got messed up, and selinux is disabled, acl is not used, and there’s no sticky bit.

I deleted the local image, also removed the image from the docker registry and pushed it again. And everything worked. It turns out that during the transfer, the permissions got messed up, both inside the local image and inside the image stored in the registry. As I mentioned, for various reasons it was located on the same machine. And thus in the same directory /var/lib/docker.

And anticipating the question, haven’t we tried pointing Docker back at the old directory — no, we haven’t tried, unfortunately, circumstances did not allow it. Moreover, I really wanted to figure it out.

After writing this article, the solution to the problem seems obvious to me, but at the time of the investigation, it did not seem so. Honestly, I googled and did not find similar situations.

In conclusion: I solved the problem, but I still do not understand the reason =(

If anyone knows, suspects, or has an idea of possible reasons for this problem — I would be extremely grateful if you share in the comments!

Zdroj: habr.com

Koupit spolehlivý hosting pro webové stránky s ochranou proti DDoS, VPS VDS servery 🔥 Koupit spolehlivý hosting pro webové stránky s ochranou proti DDoS, VPS VDS servery | ProHoster