Ułatwienia dostępu

FUSE dla Dockera na LXC

Domyślnie Docker podczas pobierania i budowania obrazów używa mechanizmu kontroli wersji i warstw (jak cebula lub ogry 😉 ) nazywanego overlay fs. W przypadku pobierania obrazów są to zmiany naniesione w czasie lub w przypadku budowania obrazów samodzielnie tymi zmianami są kolejne instrukcje RUN, COPY i ADD zawarte w .dockerfile. Każda z warstw a tym samym kolejnych plików zwiera tylko zmiany względem poprzedniej, co znacząco zmniejsza zużycie przestrzeni dyskowej oraz przyśpiesza operacje. Likwiduje rónież duplikaty plików z każdej kolejnej wersji gdybyśmy kopiowali za każdym razem obraz.

Domyślnym mechanizmem śledzenia zmian i wspomnianych warstw obrazów dockera jest overlay2. Działa on rewelacyjnie na maszynach „bare metal” lub VM ale jest on związany z bezpośrednim dostępem do mechanizmów jądra linuxa. Tutaj pojawia się problem – co w przypadku kiedy chcielibyśmy wykorzystać kontenery LXC do odseparowania środowiska dockera?

Docker wykrywa brak uprzywilejowanych uprawnień i powraca do uproszczonego sterownika VFS. Uruchamianie kontenera LXC jako uprzywilejowany mija się z ideą separacji systemu od hosta. VFS w przeciwieństwie do overlay2, działa znacznie prościej wykonując pełną kopię poprzedniej warstwy i dodając do niej kolejne zmiany. W efekcie każda kolejna warstwa zawiera zduplikowane pliki poprzedniej zwiększając kilkukrotnie wykorzystanie miejsca na dysku. Podczas budowania obrazów, wielokrotne kopiowanie zajmuje znaczącą ilość większą ilość czasu niż w overlay2.

Kontener LXC i co teraz?

Nawet jeśli wymusimy użycie sterownika overlay2 to otrzymamy poniższy komunikat od dockera:

ERRO[XXX] failed to mount overlay: invalid argument storage-driver=overlay2
ERRO[xxx] [graphdriver] prior storage driver overlay2 failed: driver not supported failed to start daemon: error initializing graphdriver: driver not supported

Rozwiązania są zasadniczo 2. Pierwsze to wykorzystać maszynę wirtualną a nie kontener LXC. Niestety tracimy przy tym całe zalety wirtualizacji LXC jakimi są bezpośredni dostęp do jądra pracującego sytemu na hoście, brak pośredniczących emulacji sprzętu i opóźnienie.

Drugim jest zastosowanie innego, podobnego do overlay2 w działaniu, sterownika jakim jest fuse-overlayfs.

Rozwiązanie FUSE

Jeśli wcześniej na w kontenerze LXC działał docker i są jakieś volumy, należy wykonać i backup. Również wszystkie istotne informacje zawarte w /var/lib/docker.

Aby użyć fuse-overlayfs należy zacząć od samego kontenera lxc. W zakładce Opcje kontenera, należy uzupełnić dodatkowe opcje o wpis fuse=1 lub przez gui:

Po wprowadzeniu zmian konieczne jest wykonanie restartu kontenera LXC. Następnie w zależności od systemu uruchomionego w kontenerze, należy doinstalować fuse-overlayfs. W przypadku Debiana:

apt update && apt install fuse-overlayfs -y

Aby docker wykorzystał zainstalowany sterownik, należy zmienić lub utworzyć plik /etc/docker/daemon.json o nowy driver:

{
  "storage-driver": "fuse-overlayfs"
}

Po wykonaniu zmian należy uruchomić ponownie daemona dockera.

W przypadku jeśli wcześniej działał docker (tak było w moim przypadku), aby unikąć problemów i błędów konieczne było wyczyszczenie wszystkich plików dockera, oczywiście po zatrzymaniu go wcześniej.

service docker stop
rm -r /var/lib/docker/*
service docker start

Po operacji konieczne jest odtworzenie volumów dockera jeśli takowe były wcześniej utworzone, oraz wykonanie pull wszystkich obrazów.

Polecam sprawdzenie zajmowanego miejsca w GUI Proxmoxa lub za pomocą du -hs <katalog> ew. za pomocą prostego df -h. W moim przypadku dysk 20GB kontenera LXC można było bez problemu zmniejszyć do 6GB.

Update 2023-08

Po wielu bojach w końcu doszedłem do momentu gdzie okazało się iż źródłem wszelkiego zła i problemów był… moduł FUSE.

Co się stało? Jeden z serwerów na którym był min. proxy bazujący na NGINX wieszał cały GUI Proxmox oraz część funkcjonalności. Zdalnie byłem w stanie zalogować się jeszcze konsolą i wymusić restart z linii poleceń, jeśli tego nie zrobiłem i próbowałem coś ratować narzędziami proxmox totalnie zawieszałem maszynę. Moduł FUSE, (który odradzają na forach proxmox) w kombinacji z wykonywaniem zrzutu vzdump przy wykonywaniu backup nie udawał się, pozostawiając maszyny w stanie nieustalonym.

Rozwiąznie? Wraz z Debianem 12 i Proxmox 8 lepiej zaczęła działać opcja „keyctl”. Ostatecznie jednak sam zdecydowałem się na konsolidacje kontenerów i wirtualną maszynę w ich miejsce. A więc wrócił overlay2. Rozwiązało to problemy z zawieszaniem i kilka innych problemów. Największym ograniczeniem teraz są rozmiary partycji, których zmiana będzie większa gimnastyką niż jest to przy kontenerach.

LINKI

Komentarze

Dodaj komentarz