История на проблема с преноса на docker storage (docker root)

Не по-късно от преди няколко дни беше решено да се прехвърли Docker хранилището (директорията, в която Docker съхранява всички файлове на контейнерите и образите) на отделен дял, който
имаше по-голям капацитет. Задачата изглеждаше тривиална и не предвещаваше беда…

Започваме:

1. Спираме и убиваме всички контейнери на нашето приложение:

docker-compose down

ако контейнерите са много и са в различни compose, може така:

docker rm -f $(docker ps -q)

2. Спираме Docker демона:

systemctl stop docker

3. Преместваме директорията на нужното място:

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

4. Информираме Docker демона да насочва новата директория. Тук има няколко варианта: или да зададем било чрез флаг -g новия път на демона, или конфигурации на systemd, които използвахме. Или симлинк. Няма да навлизам в дълбочина, в интернет има много ръководства за прехвърляне на Docker root на ново място.

5. Стартираме Docker демона и наблюдаваме дали проверява правилното:

systemctl status docker

В една от линиите на изхода трябва да видим:

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

Убеден, че опцията е предадена на демона, сега да видим дали е приложена (благодарности на inkvizitor68sl)!

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

6. Стартираме нашето приложение:

docker-compose up -d

7. Проверяваме

И тук започва най-интересната част, СУБД, MQ, всичко е наред! Базата е непокътната, всичко работи... освен nginx. Имаме наша собствена версия на nginx с Kerberos и куртизанки. И преглеждането на логовете на контейнера показа, че той не може да пише в /var/tmp — Permission denied. Загрявам пръстите си и се опитвам да анализирам ситуацията... Какво става? Docker образът не беше променян. Просто прехвърлихме директорията. Винаги е работило, и изведнъж... За експеримента влязох ръчно в контейнера и промених правата на тази директория, бяха root, root 755, дадох root, root 777. И всичко тръгна... В главата ми прозвуча мисъл — абсурд… Помислих си, може би не съм нещо пропуснал...

Реших, че сме загубили правата за достъп до файловете при прехвърлянето. Спираме приложението, Docker демона, изтриваме новата директория и правим копие на директорията /var/lib/docker, като вече използваме rsync -a.

Мисля, че сега всичко е наред, стартираме Docker, приложението.

И така... проблема остана... Имам учестен рефлекс. Поспеших към конзолата на своята виртуалка, където правя различни тестове, имам този образ на nginx и влязох вътре в контейнера, и тук в папката /var/tmp правата са настроени на root, root 777. Тоест, същите, които ми се наложи да задам ръчно. Но образите са идентични!

Навсякъде беше използвана ФС xfs.

Сравних чрез командата

docker inspect my-nginx:12345

Всички хешове са идентични, абсолютно същите. Как на сървера, така и на моята виртуалка. Изтрих локалния образ на nginx и го свалих отново от registry, който по ред причини е на същата машина. И проблемът е същият… Сега второто ми око започна да трепери.

Вече не помня какви мисли бяха в главата ми, освен викове „ААААААА“ и подобни. На улицата е 4:00 часа през нощта, започнах да анализирам изходния код на docker, с цел да разбера принципа на хеширане на слоевете на образа. Отворих третата кутия с енергийна напитка. И в крайна сметка осъзнах, че хеширането отчита само файла, неговото съдържание, но НЕ ПРАВА ДОСТУПА! Тоест, по някакъв загадъчен начин правата бяха нарушени, като selinux е изключен, acl не се използват, sticky bit няма.

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

И в предвкусването на въпроса, не пробвахме ли да върнем docker на стария каталог — не, не пробвахме, за съжаление, обстоятелствата не позволяваха. Но много исках да разбера.

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

Резултат: проблема решен, причината не разбрах =(

Ако някой знае или се досеща за възможни причини за този проблем — ще бъда изключително благодарен, ако коментирате!

Източник: habr.com