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

Не по-късно от преди няколко дни беше решено на един от сървърите да се изнесе docker storage (каталогът, в който 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 и го изтеглих отново от регистъра, който по ред причини е на същата машина. И проблемът е същият… Сега ми се зачерви и другото око.

Вече не помня какви мисли имах в главата си, освен викове „ААААААА“ и подобни. На улицата е четири часа през нощта, извадих източниците на Docker, за да разбера принципа на хеширането на слоевете на имиджа. Отворих трета банка с енергийна напитка. И накрая осъзнах, че хеширането взема предвид само файла, неговото съдържание, но НЯМА ПРАВА НА ДОСТЪП! Тоест, по някакъв загадъчен начин правата ни бяха нарушени, а SELinux е изключен, acl не се използват, sticky bit го няма.

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

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

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

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

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

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