Jaki jest najbardziej wydajny sposób zamontowania systemu plików w kontenerze?

Czytam w dokumentacji dockera, że można zamontować folder w kontenerze tak:

$ docker service create \
    --mount 'type=volume,src=<VOLUME-NAME>,dst=<CONTAINER-PATH>,volume-driver=local,volume-opt=type=nfs,volume-opt=device=<nfs-server>:<nfs-path>,"volume-opt=o=addr=<nfs-address>,vers=4,soft,timeo=180,bg,tcp,rw"'
    --name myservice \
    <IMAGE>

Są type: bind, volume, tmpfs. I mają też różne drivery, np volume-driver=local.

Uruchomiłem swój kontener na windowsie, i strasznie wolno działa - pracuję nad apką która pracuje z systemem plików. Jak odpalam ją normalnie, nie w dockerze, to śmiga, jakieś 10ms. Kiedy odpaliłem ją na dockerze, to trwa 8-10 sekund. Uruchomiłem profiler aplikacji i widzę że operacje które operują na blikach trwają bardzo długo. Myślę że to przez WSL2 na windowsie, albo mapowanie NTFS na system plików kontenera.

Jakie zamontowanie systemu plików w kontenerze sprawi że dostęp do plików będzie jak najszybszy pod windowsem? Może być read-only, może zjeść dużo ramu, nie istotne - chciałbym żeby system plików w kontenerze działał najszybciej jak się da, jakieś rady?

PS: I bardzo proszę się wstrzymać z radami: "przesiądź się na linuxa/maca".

Riddle napisał(a):

PS: I bardzo proszę się wstrzymać z radami: "przesiądź się na linuxa/maca".

Jeśli nie chcesz przesiadać się na Linuxa, to może alternatywą byłaby praca zdalna?

Alley Cat napisał(a):

Riddle napisał(a):

PS: I bardzo proszę się wstrzymać z radami: "przesiądź się na linuxa/maca".

Jeśli nie chcesz przesiadać się na Linuxa, to może alternatywą byłaby praca zdalna?

Błagam... na temat. Albo się wypowiadasz o tym jak wydajnie podpiąć system plików pod dockera, albo się nie wypowiadaj proszę.

Myślę że to przez WSL2 na windowsie prawdopodobnie tak. U mnie na WSL2 niektóre polecenia gita na trochę większym repo działają tragicznie wolno (jakiś git status czy coś w tym stylu).

Tylko to chyba w przypadku jak te operacja są na folderze podmontowanym z Windowsa. Jak to jest na systemie plików WSL2 to chyba nie ma tego problemu.

Riddle napisał(a):

Uruchomiłem swój kontener na windowsie, i strasznie wolno działa - pracuję nad apką która pracuje z systemem plików. Jak odpalam ją normalnie, nie w dockerze, to śmiga, jakieś 10ms. Kiedy odpaliłem ją na dockerze, to trwa 8-10 sekund. Uruchomiłem profiler aplikacji i widzę że operacje które operują na blikach trwają bardzo długo. Myślę że to przez WSL2 na windowsie, albo mapowanie NTFS na system plików kontenera.

Jest jeszcze opcja, że Windows Defender sobie musi w nich pogrzebać. Nie, żebym miał z tym do czynienia sam, albo wiedział, jak to naprawić, ale widziałem tu i ówdzie na różnych prezentacjach w sieci, że prelegenci mają z tym problem… W każdym razie, wg mnie warto sprawdzić i tę możliwość.

Riddle napisał(a):

Błagam... na temat. Albo się wypowiadasz o tym jak wydajnie podpiąć system plików pod dockera, albo się nie wypowiadaj proszę.

Przecież napisałem koledze na temat: rozwiązaniem jest praca zdalna - tym sposobem na desktopie będziesz miał system Windows (nie będziesz musiał się przesiadać na Linuksa), a dockera odpalisz sobie na maszynie zdalnej.

Chociaż obawiam się, że to jest kolejny temat z serii podam rozwiązanie swojego problemu w pierwszym poście i pójdę w zaparte, że nie :(

Mapowanie volume jest koszmarnie powolne w WSL2 (i co za tym idzie, w Dockerze), niestety: https://github.com/microsoft/WSL/issues/4197

Możesz używać Dockera wewnątrz WSL2 (w VM-ce) i przenosić pliki z- i do- VM-ki poprzez \\wsl.localhost zamiast montować bezpośrednio twoje foldery na hoście.

A próbowałeś zwyczajnie po "sambie"?
Sporo wirtualek używam na co dzień np. z proxMox po sieci a na lokalnym Windows z VmWare. Zasoby zawsze udostępniam z linuxów po NFS albo z Windows po sambie. Nie wiem co robisz i jakie systemy są najwydajniejsze ale nie odczuwam żadnych niedogodności z w/w metodami.

Jedyna słuszna opcja to trzymanie plików na samym WSL i montowanie ich do dockera z tego miejsca.