История на проблема с миграцията на докер хранилището (докер корен)

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

Да започваме:

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

docker-compose down

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

docker rm -f $(docker ps -q)

2. Спрете докер демона:

systemctl stop docker

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

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

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

5. Стартирайте докер демона и се уверете, че изглежда на правилното място:

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. Проверка

И тук започва забавлението, DBMS, MQ, всичко е наред! Базата данни е непокътната, всичко работи... с изключение на nginx. Имаме собствена компилация на nginx с Kerberos и curtisans. И преглеждането на регистрационните файлове на контейнера показва, че не може да пише в /var/tmp - разрешението е отказано. Мачкам слепоочията си с пръсти и се опитвам да анализирам ситуацията... Как е възможно това? Изображението на Docker не се промени. Току-що преместихме директорията. Винаги е работело и ето го за вас... В името на експеримента влязох в контейнера с ръцете си и промених правата върху тази директория, имаше корен, корен 755, даде корен, корен 777. И всичко започна... Една мисъл започна да звучи в главата ми - някаква глупост... Помислих си, добре, може би не съм взел нещо предвид...

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

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

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

Файловата система xfs се използваше навсякъде.

Сравних с помощта на командата

docker inspect my-nginx:12345

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

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

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

И очаквайки въпроса дали се опитаха да върнат погледа на докера към старата директория - не, не опитаха, уви, обстоятелствата не го позволиха. Да, и наистина исках да го разбера.

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

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

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

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