Не далей, чым пару дзён таму было вырашана на адным з сервераў вынесці docker storage (каталог, дзе докер захоўвае ўсе файлы кантэйнераў, выяў) на асобную частку, які
валодаў большай ёмістасцю. Задача, здавалася б, трывіяльная і не прадвяшчала бяды…
Прыступаем:
1. Спыняем і забіваем усе кантэйнеры нашага прыкладання:
docker-compose downкалі кантэйнераў шмат, і яны ў розных compose, можна так:
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