Не далі, ніж кілька днів тому було вирішено на одному із серверів винести docker storage (каталог, де докер зберігає всі файли контейнерів, образів) на окремий розділ, який
мав більшу ємність. Завдання, здавалося б, тривіальне і не віщувало біди ...
приступаємо:
1. Зупиняємо та вбиваємо всі контейнери нашої програми:
docker-compose downякщо контейнерів багато, і вони в різних складах, можна так:
docker rm -f $(docker ps -q)2. Зупиняємо докер демон:
systemctl stop docker3. Переносимо каталог у потрібне місце:
cp -r /var/lib/docker /docker/data/storage4. Повідомляємо докер демону, щоб дивився у нову директорію. Тут кілька варіантів: або через прапор -g вказати демону новий шлях, або конфіги systemd, які ми використовували. Ну чи симлінк. Сильно розписувати це не стану, в інтернеті мануалів про перенесення docker root у нове місце
5. Стартуємо демон докера, і спостерігаємо, щоб він дивився куди треба:
systemctl status dockerВ одному з рядків виводу ми маємо побачити:
├─19493 /usr/bin/dockerd --data-root=/docker/data/storageПереконалися, що демону опцію передали, тепер перевіримо, чи він застосував її (дякую) )!
docker info | awk '/Root Dir/ {print $NF}' 6. Стартуємо наш додаток:
docker-compose up -d7. Перевіряємо
І ось тут починається найцікавіше, СУБД, MQ, все гаразд! База ціла, все працює… крім nginx. У нас своє складання nginx з керберос та куртизанками. І перегляд логів контейнера вказав на те, що він не може писати /var/tmp — Permission denied. Розминаю пальцями віскі та намагаюся аналізувати ситуацію… Як так? Докер образ не змінювався. Ми ж просто перенесли директорію. Завжди працювало, і тут на тобі… Заради експерименту зайшов ручками в контейнер і змінив права на цей каталог root, root 755дав root, root 777. І все завелося… У голові зазвучала думка — маячня якась… Думав, ну може я чогось не врахував…
Вирішив, що ми полюбили права доступу на файли під час перенесення. Зупинили додаток, докер демон, видалили нову директорію та здійснили копіювання директорії /var/lib/docker вже використовуючи rsync -a.
Думаю, тепер точно все добре, піднімаємо докер, додаток.
ІІІ... проблема залишилася... У мене засмикнуло око. Я метнувся до консолі своєї віртуалки, де ганяю різноманітні тести, у мене був цей образ nginx, і я заліз усередину контейнера, і тут на каталог /var/tmp права стоять root, root 777. Тобто такі ж, які мені довелося виставляти руками . Але ж образи ідентичні!
Всюди використовувалася ФС xfs.
Я порівняв через команду
docker inspect my-nginx:12345Всі хеші ідентичні, все один на один. Як на сервері, так і на моїй віртуалці. Я видалив локальний образ nginx і спустив знову з registry, який з ряду причин стоїть на цій же машині. І проблема та сама… Тепер у мене засмикнуло друге око.
Я вже не пам'ятаю, які думки були в моїй голові, окрім криків «ААААААА» та іншого. На вулиці четверта година ночі, в хід пішли вихідні докери з метою зрозуміти принцип хешування шарів образу. Відкрив третю банку енергетика. І в результаті до мене дійшло, що хешування враховує лише файл, його вміст, але НЕ ПРАВА ДОСТУПУ! Тобто якимось загадковим чином у нас побилися права, причому selinux відключений, acl не використовуються, sticky bit немає.
Я видалив локальний образ, також видалив образ з docker registry і запустив заново. І все запрацювало. Виходить, що при перенесенні права побилися, як усередині локального образу, так і всередині образа, що лежить в registry. Як я вже казав, через кілька причин він розташовувався на цій же тачці. І як наслідок в одному каталозі /var/lib/docker.
І передчуваючи питання, чи не пробували повернути погляд докера на старий каталог - ні, не пробували, на жаль, обставини не дозволяли. Та й дуже хотілося розібратися.
Після написання цієї статті, мені вирішення проблеми здається очевидним, але на момент розбору таким не здавалося. Чесно гуглив, і не знайшов подібних ситуацій.
Підсумок: проблему вирішив, причину не зрозумів =(
Якщо хтось знає здогадується, було бачення про можливі причини цієї проблеми — буду вкрай радий вам у коментарях!
Джерело: habr.com