Historia problemu przeniesienia storage docker (docker root)

Nie dalej jak dwa dni temu podjęto decyzję na jednym z serwerów o przeniesieniu storage docker (katalog, w którym docker przechowuje wszystkie pliki kontenerów i obrazów) na oddzielną partycję, która
miała większą pojemność. Zadanie wydawało się trywialne i nie zapowiadało problemów...

Zaczynamy:

1. Zatrzymujemy i zabijamy wszystkie kontenery naszej aplikacji:

docker-compose down

jeśli kontenerów jest dużo, a są w różnych compose, można zrobić tak:

docker rm -f $(docker ps -q)

2. Zatrzymujemy demona dockera:

systemctl stop docker

3. Przenosimy katalog w odpowiednie miejsce:

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

4. Informujemy demona dockera, aby patrzył w nowy katalog. Są tu różne opcje: albo przez flagę -g wskazać demonowi nową ścieżkę, albo konfiguracje systemd, które wykorzystaliśmy. Można też użyć symlink. Nie będę tego mocno rozwijać, w internecie jest pełno instrukcji na temat przeniesienia docker root w nowe miejsce.

5. Uruchamiamy demona dockera i obserwujemy, czy patrzy tam, gdzie trzeba:

systemctl status docker

W jednej z linii wyjścia powinniśmy zobaczyć:

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

Upewniliśmy się, że przekazaliśmy demonowi opcję, teraz sprawdźmy, czy ją zastosował (dzięki inkvizitor68sl)!

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

6. Uruchamiamy naszą aplikację:

docker-compose up -d

7. Sprawdzamy

I tutaj zaczyna się najciekawsze – SGBD, MQ, wszystko w porządku! Baza danych jest nienaruszona, wszystko działa… poza nginx. Mamy własną wersję nginx z Kerberosem i kurtyzanami. A przeglądanie logów kontenera wskazało, że nie może pisać do /var/tmp – Permission denied. Rozmasowuję palce na skroniach i próbuję analizować sytuację… Jak to możliwe? Obraz dockera się nie zmienił. Przecież po prostu przenieśliśmy katalog. Zawsze działało, a tu nagle… Na próbę wszedłem do kontenera i zmieniłem prawa w tym katalogu, były root, root 755, dałem root, root 777. I wszystko ruszyło… W głowie zabrzmiała myśl – to jakieś szaleństwo… Myślałem, że może czegoś nie uwzględniłem…

Zdecydowałem, że źle ustawiliśmy prawa dostępu do plików przy przenoszeniu. Zatrzymaliśmy aplikację, demona dockera, usunęliśmy nowy katalog i zrobiliśmy kopiowanie katalogu /var/lib/docker korzystając z rsync -a.

Myślę, że teraz na pewno wszystko w porządku, uruchamiamy dockera, aplikację.

Ooo... problem pozostała... Mam drgający oko. Wskoczyłem do konsoli mojej wirtualnej maszyny, gdzie uruchamiam różne testy. Miałem ten obraz nginx i wszedłem do kontenera, a tu w katalogu /var/tmp prawa są ustawione na root, root 777. Czyli takie same, jakie musiałem ustawiać ręcznie. Ale obrazy są identyczne!

Wszędzie używana była FS xfs.

Porównałem za pomocą komendy

docker inspect my-nginx:12345

Wszystkie hasze są identyczne, wszystko jeden do jednego. Tak na serwerze, jak i na mojej wirtualce. Usunąłem lokalny obraz nginx i ściągnąłem go ponownie z registry, które z różnych powodów znajduje się na tej samej maszynie. I problem pozostaje... Teraz drga mi drugie oko.

Już nie pamiętam, jakie myśli były w mojej głowie, poza krzykami „AAAAAA” i innymi. Na dworze jest czwarta godzina w nocy, do akcji weszły źródła dockera, mając na celu zrozumienie zasady haszowania warstw obrazu. Otworzyłem trzecią puszkę energetyka. I w końcu zrozumiałem, że haszowanie uwzględnia tylko plik, jego zawartość, ale NIE UPRAWNIENIA! To znaczy, w jakiś tajemniczy sposób nasze uprawnienia się skasowały, mimo że selinux jest wyłączony, acl nie jest używane, sticky bit nie występuje.

Usunąłem lokalny obraz, również usunąłem obraz z docker registry i wypchnąłem go ponownie. I wszystko zaczęło działać. Okazuje się, że podczas przenoszenia uprawnienia zostały usunięte, zarówno wewnątrz lokalnego obrazu, jak i w obrazie znajdującym się w registry. Jak już mówiłem, z różnych powodów znajdował się na tej samej maszynie. I w konsekwencji w tym samym katalogu /var/lib/docker.

I wyczuwając pytanie, czy nie próbowaliśmy przywrócić dockera do starego katalogu — nie, nie próbowaliśmy, niestety, okoliczności na to nie pozwalały. I bardzo chciałem to zrozumieć.

Po napisaniu tego artykułu rozwiązanie problemu wydaje mi się oczywiste, ale w momencie analizy takie nie było. Szczerze guglowałem i nie znalazłem podobnych sytuacji.

Wynik: problem rozwiązany, przyczyny nie zrozumiałem =(

Jeżeli ktoś wie lub ma jakieś przemyślenia na temat potencjalnych przyczyn tego problemu — będę niezwykle wdzięczny za informacje w komentarzach!

Źródło: habr.com