Zgodovina težave s prenosom shrambe docker (docker root)

Pred nekaj dnevi smo se odločili, da bomo na enem izmed strežnikov prenesli docker storage (mapo, kjer docker shranjuje vse datoteke kontejnerjev in slik) na ločeno particijo, ki
je imela večjo zmogljivost. Naloga se je zdela trivialna in ni napovedovala težav...

Pričnimo:

1. Ustavimo in ubijemo vse kontejnerje naše aplikacije:

docker-compose down

če je kontejnerjev veliko in so v različnih compose, lahko to storimo takole:

docker rm -f $(docker ps -q)

2. Ustavimo docker demon:

systemctl stop docker

3. Premaknemo mapo na želeno mesto:

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

4. Sporočimo docker demonu, naj gleda v novo mapo. Tukaj je več možnosti: bodisi preko zastavice -g navedemo demonu novo pot, bodisi uporabimo konfiguracije systemd, kar smo tudi storili. Ali pa simlink. Ne bom podrobno opisoval tega, na spletu je obilje priročnikov o prenosu docker root na novo mesto.

5. Zagnamo docker demon in opazujemo, ali gleda na pravo mesto:

systemctl status docker

V eni od vrstic izhoda bi morali videti:

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

Prepričali smo se, da smo demonu poslali opcijo, zdaj preverimo, ali jo je uveljavil (hvala inkvizitor68sl)!

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

6. Zagnamo našo aplikacijo:

docker-compose up -d

7. Preverimo

In tukaj se prične najzanimivejše. SDB, MQ, vse v redu! Baza je cela, vse deluje... razen nginx. Imamo svojo različico nginx z Kerberos in kurtižankami. In pregledovanje dnevnikov kontejnerja je pokazalo, da ne more pisati v /var/tmp - Permission denied. Raztegujem prste na sencah in poskušam analizirati situacijo... Kako je to mogoče? Docker slika se ni spremenila. Le premaknili smo imenik. Vedno je delovalo, in zdaj naenkrat... Za eksperiment sem ročno vstopil v kontejner in spremenil pravice na tem imeniku, bile so root, root 755, dal root, root 777. In vse je zaživelo... V glavi se mi je porodila misel - kaj norost... Mislil sem, da morda česa nisem upošteval...

Odločil sem se, da smo izgubili pravice dostopa do datotek med prenosom. Ustavili smo aplikacijo, docker demon, izbrisali novo mapo in opravili kopiranje imenika /var/lib/docker že z uporabo rsync -a.

Mislim, da je zdaj vse v redu, zagnati docker, aplikacijo.

Итак… проблема осталась… У меня дергается глаз. Я быстро побежал к консоли своей виртуальной машины, где запускаю различные тесты. У меня был этот образ nginx, и я зашел внутрь контейнера, и вдруг увидел, что на каталог /var/tmp права стоят root, root 777. То есть такие же, какие мне пришлось выставлять вручную. Но ведь образы идентичны!

Везде использовалась файловая система xfs.

Я сравнил через команду

docker inspect my-nginx:12345

Все хеши идентичны, все один в один. Как на сервере, так и на моей виртуальной машине. Я удалил локальный образ nginx и скачал заново с реестра, который по ряду причин стоит на этой же машине. И проблема та же… Теперь у меня дергается второй глаз.

Я уже не помню, какие мысли были у меня в голове, помимо криков «ААААААА» и прочего. На улице четвертый час ночи, в ход пошли исходники Docker с целью понять принцип хеширования слоев образа. Открыл третью банку энергетика. И в итоге до меня дошло, что хеширование учитывает только файл, его содержимое, но НЕ ПРАВА ДОСТУПА! То есть, каким-то загадочным образом у нас сбились права, причем SELinux отключен, ACL не используются, sticky bit отсутствует.

Я удалил локальный образ, также удалил образ из Docker registry и запушил заново. И все заработало. Получается, что при переносе права сбились как внутри локального образа, так и внутри образа, лежащего в реестре. Как я уже говорил, по ряду причин он находился на этой же машине. И как следствие в одном каталоге /var/lib/docker.

И предвкушая вопрос, пробовали ли мы вернуть Docker к старому каталогу - нет, не пробовали, увы, обстоятельства не позволяли. Да и сильно хотелось разобраться.

После написания данной статьи, мне решение проблемы кажется очевидным, но на момент разбора таковым не казалось. Честно гуглил и не нашел схожих ситуаций.

Итог: проблему решил, причину так и не понял =(

Если кто-то знает или догадывается о возможных причинах данной проблемы — буду крайне рад вашим комментариям!

Izvor: habr.com