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.
Dodaj komentarz
Musisz się zalogować, aby móc dodać komentarz.