Docker + WSL2 – to działa!

Przy okazji wpisu WIndows Terminal jeszcze raz wybadałem temat WSL2 i jego rzekomo niesamowitej szybkości środowiska we współpracy z Dockerem, którego do tej pory nie mogłem okiełznać.

Coś mi nie dawało spokoju

W środowisku programistów pojawiły się pozytywne opinie o webdev na podstawie takiego stacku technologicznego. Byli tacy, co przenieśli się z MacOS na Windows, od razu postawili na WSL2 i są z takiego rozwiązania bardzo zadowoleni.

Coś musiałem przeoczyć.

Tym razem zagadałem do kolegi po fachu i naprowadził mnie na pewien trop, który przyczynił się do rozwiązania problemów z responsywnością i wydajnością. Przy okazji odkryłem jeszcze jedną opcję, mającą ogromny wpływ na sam system Windows.

Lokalizacja projektu

Najważniejszy trop to lokalizacja projektu, nad którym pracuję.

Taki katalog powinien znajdować się wewnątrz środowiska WSL2 /home/$user a nie – jak do tej pory – w dowolnym miejscu w systemie Windows (w subsystemie są dostępne w podmontowanych katalogach /mnt/c czy tam /mnt/z.

Słowo klucz podmontowane ma ogromny wpływ na wydajność, na szybkość działania całego ekosystemu.

Głupia sprawa ale robi ogromną różnicę.

Docker – to naprawde działa

Co ciekawe, włączenie wsparcia WSL2 w Dockerze sprawa, że usługa ta jest dostępna zarówno dla WSL2, jak i Windowsa. W praktyce dostęp do środka wirtualnego środowiska jest możliwy zarówno z poziomu terminala WSL2, jak i np. PowerShell.

Odpowiednia konfiguracja ma znaczenie

Jest jeszcze jeden ważny aspekt, który rzutuje na wydajność WSL2 i całego systemu Windows.

Docker na WSL2 może przydzielić całą dostępną pamięć operacyjną a tym samym mocno spowolnić Windowsa. To są zalety i wady dynamicznych alokacji pamięci i mocy obliczeniowej procesora. Jest na to sposób.

Mowa o pliku konfiguracyjnym .wslconfig , który zawiera informacje (bardziej instrukcję), ile maksymalnie pamięci i mocy przydzielić wirtualnym środowiskom.

Procedura jest prosta. Wystarczy z poziomu Windows Terminal odpalić komendę

notepad "$env:USERPROFILE/.wslconfig"

Otwiera sie notatnik z pustą zawartością. Wypełniamy ją następującym fragmentem:

[wsl2]
memory=4GB   # Limit pamięci dla  VM w WSL 2 wynosi 4GB
processors=4 # WSL 2 VM będzie korzystać z 4 wirtualnych procesorów

Zapisujemy a następnie wsl --shutdown restartujemy WSL. Warto zapoznać się z listą dostępnych parametrów.

Moja wygląda mniej wiecej tak:

[wsl2]
memory=5GB
processors=4

Podsumowanie

Wreszcie mogłem skorzystać z dobrodziejstwa, jakim jest Remote WSL w VS Code. Pozwala na pracę nad kodem ze zdalnego zasobu bez większych strat, tak jakby to było środowisko lokalne. Aby to zainicjować, wystarczy w katalogu z projektem (sub system) odpalić komendę code ., po chwili uruchamia się VS Code z aktywnym rozszerzeniem Remote WSL. Możliwe, ze w międzyczasie doinstaluje potrzebne pakiety, by uruchomić całe środowisko.

Dostęp do katalogu domowego WSL jest możliwy z poziomu Windows Explorer poprzez wpisanie \\\\wsl$ w eksploratorze windows (zdalny zasób) oraz wpisanie polecenia explorer.exe . w terminalu VS Code. Zdalny zasób można zmapować jako dysk sieciowy, w konsoli wystarczy wpisać bash lub wsl

0 0 votes
Article Rating
Subscribe
Powiadom o
guest

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

4 komentarzy
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
wikiyu
wikiyu
3 miesięcy temu

Na nowszych buildach z Insiders nie musisz już kombinować z \\\\wsl$ bo masz normalnie dostępne w exploratorze foldery \\wsl\Dystrybucja włącznie z tym że jest w drzewku po lewej. A i „code ścieżka” działa pięknie też w powershellu (nawet bez wsl) do odpalania projektów itp :)

xpil
3 miesięcy temu

Docker pod WSL2 działa i to całkiem nieźle, prawda. Ale nie jest 100% kompatybilny z wersją linuksową jeśli chodzi o sieć. Niestety. Gdyby nie to, do dziś używałbym Windows.

4
0
Would love your thoughts, please comment.x
()
x
%d bloggers like this: