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
https://bobiko.blog/2021/01/windows-terminal/ ↗
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