Använda WSL för icke-uppenbara uppgifter: en komplett guide för utvecklare på Windows

Om du arbetar med Windows-utveckling och ofta stöter på dokumentation utformad för Linux, har du förmodligen hört talas om WSL men är ännu inte helt klar över dess dagliga tillämpningar utöver att bara "ha bash ". Sedan finns det Docker, virtuella maskiner, företags-VPN, brandväggar, Node, NVM... och det är förståeligt att allt känns som en lite kaotisk röra.

Målet med den här artikeln är att ge dig en tydlig förståelse för vad WSL är, hur WSL 1 skiljer sig från WSL 2, vilka verkliga problem det hjälper dig att lösa och hur du använder det utan att överbelasta ditt Windows-system . Vi kommer också att titta på mindre uppenbara scenarier (nätverk, DNS, VPN, Docker, säkerhetskopior, migreringar etc.) och när det kan vara mer fördelaktigt att byta och använda Linux som ditt primära operativsystem, och behålla Windows i en virtuell maskin.

Vad är WSL och varför är det så viktigt för utvecklare på Windows?

WSL står för Windows Subsystem för Linux , den mekanism som erbjuds av Microsoft för att köra GNU/Linux-distributioner integrerade i Windows 10 och Windows 11, utan behov av att konfigurera dubbelstart eller en klassisk virtuell maskin med VirtualBox eller VMware.

I praktiken innebär det att du kan ha Ubuntu, Debian, Kali, openSUSE och andra distributioner körda parallellt med ditt Windows, dela filer och låta dig starta typiska Linux-verktyg (bash, ssh, apt, Python, Node, Docker, etc.) från ditt vanliga skrivbord, med en mycket hög grad av integration.

Sedan starten har WSL genererat en mängd olika åsikter: vissa ser det som den definitiva anledningen att fortsätta använda Windows utan att överge Linux-ekosystemet , medan andra uppfattar det som ett strategiskt drag från Microsoft för att behålla sin dominans på skrivbordsmarknaden. Utöver debatten är det säkert att det avsevärt har förändrat hur utvecklare som lever på Windows men distribuerar på Linux arbetar.

För närvarande är den allmänna rekommendationen att använda WSL 2, som inte längre bara är ett översättningslager utan kör en riktig Linuxkärna i en lättviktig virtuell maskin. Microsoft insisterar på att "det inte är en traditionell virtuell maskin" eftersom den automatiserar dess skapande och hantering, men tekniskt sett förlitar den sig på virtualiseringstekniker som Hyper-V.

WSL 1 vs WSL 2: Viktiga skillnader, krav och begränsningar

Det är viktigt att förstå skillnaden mellan de två versionerna, eftersom det direkt påverkar prestanda, kompatibilitet och de hårdvarukrav du behöver för att allt ska fungera smidigt.

WSL 1 fungerade genom att översätta Linux-systemanrop till Windows, utan en fullständig Linuxkärna under. Detta gav mycket bra prestanda med diskoperationer på Windows filsystem , men det saknade kompatibilitet med mer komplex programvara, särskilt verktyg som arbetade på en låg nivå med systemet.

Med WSL 2 förändras tillvägagångssättet radikalt: en komplett Linuxkärna körs inuti en mycket optimerad virtuell maskin . Resultatet är att nästan allt som fungerar på ett "native" Linux-system också fungerar på WSL 2: Docker, typiska Linux-filsystem, avancerade nätverksverktyg och så vidare.

Nackdelen är att WSL 2 har strängare krav. Du behöver en processor med virtualiseringsstöd och SLAT (Second Level Address Translation) , vilket finns i moderna processorer (vanligtvis Intel-processorer från Nehalem och framåt och AMD-processorer av motsvarande generationer). Mycket gamla system, som vissa Core 2 Duo-processorer, är inkompatibla med WSL 2 även om du aktiverar alla nödvändiga alternativ i BIOS.

Det är också viktigt att ha en relativt ny version av Windows: Windows 10 1903 (version 18362) eller senare, eller Windows 11. På datorer med tidigare versioner är du begränsad till WSL 1, med dess inneboende begränsningar. Det betyder att du på sätt och vis fortfarande är bunden till Windows livscykel: om systemet inte längre stöds kommer även din WSL att påverkas.

Snabb WSL-installation: Första steg och inledande beslut

I moderna versioner av Windows har Microsoft förenklat processen avsevärt. Idag behöver du bara öppna PowerShell eller Kommandotolken som administratör och köra:

wsl –installera

Med det enda kommandot installerar Windows WSL-komponenten, laddar ner kärnan och lägger till en Ubuntu-distribution från Microsoft Store som standard, och hanterar de nödvändiga valfria funktionerna och tillhörande nedladdningar på egen hand.

Vid första uppstarten av distributionen kommer du att bli ombedd att skapa ett användarnamn och lösenord för Linux-systemet . Detta konto är separat från ditt Windows-användarkonto och fungerar som den primära användaren inom distributionen, vilket ger ett bekvämt isoleringslager för att separera "Linux" från "Windows".

Om du vill gå vidare kan du lista de tillgängliga distributionerna med:

wsl –lista –online

och installera sedan till exempel Debian, Kali eller andra Ubuntu-varianter med:

wsl –install -d DISTRIBUTIONSNAMN

Varje distro finns i sin egen isolerade container, så du kan ha flera Linux-miljöer parallellt utan att de överlappar varandra, vilket är användbart om du samarbetar i projekt med olika krav.

Var WSL lagrar dina data och hur mycket det "belamrar" Windows

En ganska vanlig fråga är hur mycket WSL rör på ditt system, var filerna lagras och hur man rensar upp allt om man bestämmer sig för att bli av med delsystemet en dag.

Varje WSL-distribution lagras i en användardatamapp inom %LocalAppData%\Packages . Inuti den här mappen finns en LocalState-katalog som innehåller en virtuell disk i VHDX-format med hela Linux-filsystemet: rotkatalogen, /home, /var, databaser, servrar, kod, etc. I huvudsak motsvarar det en virtuell maskins "hårddisk", men hanteras av Windows.

Så länge du inte rör något utanför det är påverkan på dina vanliga Windows-sökvägar minimal: du kommer inte att få halva disken full av spridda Linux-mappar . Om du vill granska eller säkerhetskopiera VHDX kan du göra det från Utforskaren eller med tredjepartsverktyg, men normalt är det alltid bäst att hantera det inifrån själva Linuxdistributionen.

För att WSL ska fungera måste vissa Windows-funktioner vara aktiverade, till exempel "Windows Subsystem for Linux" och, för WSL 2, "Virtual Machine Platform" . Detta görs automatiskt med `wsl --install`, men det kan också hanteras från det grafiska gränssnittet ("Turn Windows features on or off") eller med PowerShell (`Enable-WindowsOptionalFeature`).

Dessutom installeras WSL Linux-kärnan i systemsökvägar som %SystemRoot%\System32\lxss\tools. När dessa funktioner är aktiverade blir de en del av operativsystemet och finns kvar tills du inaktiverar dem manuellt.

Om du någonsin vill återställa Windows till sitt ursprungliga tillstånd, som om du aldrig hade haft WSL, måste du avinstallera distributionerna (wsl --unregister), inaktivera valfria funktioner och, om nödvändigt, ta bort kärnpaketet . Det är inte så enkelt som att ta bort en mapp, men det är inte heller en särskilt komplicerad process.

Typiska och mindre uppenbara användningsområden för WSL för utveckling

Det mest kända användningsfallet är "Jag vill ha bash på Windows", men där WSL verkligen lyser är när du behöver en utvecklingsmiljö som är väldigt lik produktionsmiljön på Linux samtidigt som du fortfarande använder ditt Windows-skrivbord.

Tänk på projekt som kombinerar Docker, ramverk som Flask eller Django, databaser som Postgres eller ArangoDB och andra typiska backend-tjänster. Istället för att kämpa med Windows-specifika versioner eller ett ostadigt Docker-skrivbord kan du installera hela stacken direkt i din WSL 2-distribution och dra nytta av att Linuxkärnan är "riktig".

I det här scenariot körs Docker naturligt på WSL 2, Linux-tjänster beter sig på samma sätt som de skulle göra på en fjärrserver, och du kan fortsätta använda VS Code, webbläsare och andra grafiska verktyg från Windows , och peka på koden som finns på Linux-filsystemet eller i en delad mapp.

Det finns också mindre uppenbara fördelar: du kan använda administrativa skript, verktyg som bara är tillgängliga på Linux, bra Node-versionshanterare som NVM, och hela ekosystemet av konsolverktyg som ofta saknas eller släpar efter på Windows.

Tack vare filsystemintegration monterar WSL dina Windows-diskar till /mnt (till exempel /mnt/c för enhet C:). Detta gör att du kan redigera kod med din Windows-editor och köra den i Linux utan att duplicera projektet eller radikalt ändra ditt arbetsflöde.

Omvänt kan du från Linux-skalet anropa Windows-körbara filer som notepad.exe, powershell.exe eller någon annan .exe-fil på systemet . De behöver helt enkelt finnas i PATH (Win32-sökvägar monterade i /mnt/c/Windows/System32, etc.) och du får inte ha skrivit över den variabeln i din distributions startskript.

Windows Terminal: den perfekta följeslagaren till WSL

För att göra upplevelsen trevlig och undvika att hamna med tio olika konsolfönster rekommenderar Microsoft att du använder Windows Terminal , en modern applikation som låter dig öppna flikar i olika skal: PowerShell, CMD och var och en av dina WSL-distributioner.

Med Windows Terminal kan du ha Ubuntu-, Debian- eller Kali-flikar i samma program , kombinera paneler, anpassa färger, teckensnitt och kortkommandon och glömma den gamla cmd.exe-filen eller föråldrade, dåligt konfigurerbara konsoler.

Dessutom, genom att kunna öppna en WSL-session direkt, är det inte längre meningsfullt att förlita sig på verktyg som PuTTY för de flesta SSH-anslutningar : du kan ansluta till fjärrservrar från själva Linux-distributionen med samma nyckelkonfiguration och verktyg som du skulle använda i produktion.

Ett vanligt arbetsflöde bland Windows-utvecklare idag ser ungefär ut så här: kod i VS Code, huvudterminal i Windows Terminal och backends, containrar och konsolverktyg i WSL . Den här kombinationen känns väldigt lik den att arbeta på macOS eller en native Linux-skrivbordsmiljö, men utan att lämna Windows.

Nätverk, DNS, VPN och andra huvudvärk med WSL 2

De vanligaste problemen uppstår inom nätverksområdet, särskilt med WSL 2. När man använder en lätt virtuell maskin är man beroende av ett virtuellt nätverkskort, brandväggsregler och en liten intern NAT, vilket i företagsmiljöer kan kollidera med säkerhetspolicyer, aggressiva VPN-tjänster eller antivirusprogram med integrerade brandväggar.

Ett typiskt scenario: WSL Linux-systemet startar, men har ingen internetåtkomst och kan inte matcha domännamn . I många organisationer blockerar eller ignorerar brandväggsregler som definieras via gruppolicy lokala regler. Eftersom undantaget som skapas av HNS för att tillåta DNS-trafik från det virtuella WSL-gränssnittet är en lokal regel, åsidosätts den om profilen har `AllowLocalFirewallRules` eller `AllowInboundRules` inställt på `False`.

I detta sammanhang innebär lösningen att administratören skapar en lämplig företagsregel som tillåter nödvändig trafik eller, om möjligt, aktiverar WSL:s DNS-tunnelfunktion med hjälp av det experimentella alternativet dnsTunneling i .wslconfig-filen . Med detta alternativ skickas DNS-frågor från det interna Linux-systemet direkt till Windows-resolvern via virtualiseringslagret, vilket minskar beroendet av traditionella brandväggsregler.

Det finns också kända konflikter med vissa VPN:er: Cisco AnyConnect, specifika OpenVPN-klienter, Zscaler-liknande lösningar, McAfee Safe Connect eller Bitdefender som manipulerar rutter, NRPT eller proxyservrar på sätt som bryter WSL NAT eller stör trafiken.

I dessa fall fungerar det ibland att ändra WSL-nätverksläget till networkingMode=mirrored (speglat läge) i .wslconfig, andra gånger att inaktivera dnsTunneling och återigen att justera autoProxy-alternativet för att säkerställa att HTTP_PROXY/HTTPS_PROXY-spridningen i Linux matchar företagskonfigurationen. Beteendet hos DNS-suffix, antalet tillgängliga resolvers och proxyhantering varierar beroende på om du använder klassisk NAT, NAT med DNS-tunnling eller speglat läge.

WSL och Docker: integration, fördelar och typiska problem

En av de tydligaste anledningarna att använda WSL 2 är att det radikalt förbättrar Docker-upplevelsen på Windows . Microsofts och Dockers officiella strategi är att Docker Desktop ska använda WSL 2 som backend istället för att kommunicera direkt med Hyper-V som tidigare.

Den största fördelen är att containrar körs på en riktig Linuxkärna, inom din WSL-distribution , vilket eliminerar många kompatibilitets- och prestandaproblem som fanns med tidigare lösningar. Dessutom kan du använda Docker direkt från Linux-skalet, precis som du skulle göra på en server, och fortsätta hantera avbildningar, nätverk och volymer med samma kommandon.

Allt är dock inte perfekt. Problem har upptäckts vid användning av WSL:s speglade nätverksläge (networkingMode=mirrored) och start av containrar med publicerade portar. I dessa fall kan Docker Desktop misslyckas med att skapa containrarna om standardnätverksnamnrymden används.

En tillfällig lösning är att starta containrarna med –network host (och dra nytta av att du befinner dig i en utvecklingsmiljö) eller lägga till de konflikterande portarna i parametern ignoredPorts i .wslconfig så att systemet inte försöker omdirigera dem problematiskt.

Det finns också potentiella konflikter med containrar som inkluderar Network Manager eller andra komplexa nätverkstjänster som körs i dem . Dessa kan förhindra att WSL:s nätverkskonfiguration fungerar korrekt, särskilt om du vill returnera anslutningar från containrarna till värden. Den vanliga rekommendationen är att inaktivera dessa daemoner när de inte är absolut nödvändiga.

Om ditt företag också använder en HTTP/S-proxy kan du aktivera autoProxy i WSL för att automatiskt fylla i variabler som HTTP_PROXY, HTTPS_PROXY, NO_PROXY och WSL_PAC_URL . Tänk på att alla användardefinierade variabler i skalet prioriteras framför de genererade, och att Linux inte har inbyggt stöd för PAC-filer, så du kan behöva anpassa skript eller inaktivera funktionen i vissa miljöer.

Vanliga fel i Linux-distributionen och hur man åtgärdar dem

När du väl är installerad i din distribution kommer de "klassiska" Linuxproblemen att börja dyka upp, ibland förstärkta av WSL:s särdrag . Att känna till dem i förväg sparar dig mycket tid.

Ett mycket vanligt fel är meddelandet "kommandot hittades inte" när man försöker köra notepad.exe, powershell.exe eller andra Windows-kommandon från Linux-shellet. Detta beror vanligtvis på att ett startskript (till exempel /etc/profile i Debian eller shell-filer) omdefinierar PATH, skriver över värdet som skickas av WSL och därmed förlorar sökvägar till /mnt/c/Windows och liknande platser.

Det korrekta tillvägagångssättet är inte att skriva över PATH, utan snarare att utöka den samtidigt som det ursprungliga värdet respekteras (med PATH="$PATH:/new/path" istället för att tilldela den från grunden) eller att ta bort de motstridiga raderna. Det är också en bra idé att kontrollera /etc/wsl.conf och verifiera att appendWindowsPath=false inte är satt , eftersom detta skulle förhindra att Windows PATH läggs till automatiskt.

Ett annat återkommande problem uppstår när man kör `apt-get upgrade` eller `apt full-upgrade` , där vissa paket försöker starta systemtjänster som är irrelevanta i WSL (det finns ingen klassisk init). För att undvika fel med udev och liknande paket är det vanligt att installera ett `policy-rc.d`-skript i `/usr/sbin` som returnerar `exit 101` , markerar det som körbart och använder `dpkg-divert` för att omdirigera `/sbin/initctl` till `/bin/true`, vilket förhindrar att inkompatibla daemoner startar.

Det finns också viktiga detaljer att tänka på med SSH. Om du ser varningar som "UNPROTECTED PRIVATE KEY FILE!" och behörigheterna 0777 när du ansluter till en fjärrserver, finns dina nycklar förmodligen i en katalog monterad från Windows med alltför milda behörigheter. För att WSL ska kunna hantera POSIX-liknande behörigheter på Windows-filer korrekt är det lämpligt att lägga till monteringsalternativ som metadata, uid, gid och umask till /etc/wsl.conf för att simulera strängare behörigheter.

Omvänt, om du konfigurerar en OpenSSH-server i din distribution och får meddelandet "Connection closed by 127.0.0.1 port 22" när du ansluter från Windows , kontrollera loggarna genom att köra sshd i felsökningsläge och se till att värdnycklar finns i /etc/ssh. Om de har tagits bort kan du generera dem igen eller, ännu enklare, rensa och installera om openssh-server-paketet så att det återskapar dem automatiskt.

WSL i äldre versioner av Windows och äldre delsystem

På mycket gamla Windows 10-system (Creators Update, Anniversary Update och liknande versioner) var WSL-stödet mycket mer rudimentärt. Detta involverade bash.exe, lxrun och en första generationens implementering, med kommandon och sökvägar som inte exakt matchar den nuvarande Microsoft Store-baserade upplevelsen.

I den modellen lagrades distributioner under %LocalAppData%\lxss och interoperabiliteten med Windows var mer begränsad. Linux-kommandon startades vanligtvis med bash -c "command" , och anpassnings- och kompatibilitetsalternativen var betydligt färre än med moderna versioner.

Om du kommer från den eran och fortfarande har den "äldre" WSL aktiverad rekommenderas att du migrerar dina data till en modern distribution från Store, verifierar att allt fungerar och avinstallerar den gamla. Du kan använda `wsl --unregister Legacy` eller, med extrem försiktighet, manuellt radera mappen `%LocalAppData%\lxss` (vilket tar bort allt gammalt Linux-innehåll på en gång).

Dessa äldre system saknar WSL 2, officiellt stöd för integrerade grafiska Linux-applikationer, förenklad WSL-installation och modern Docker Desktop-integration. Om din hårdvara tillåter det är det bästa alternativet att uppgradera till en nyare version av Windows 10 eller ta steget till Windows 11 för att dra nytta av alla delsystemets förbättringar.

Avancerade användningsområden: säkerhetskopior, migreringar och produktion

Förutom sin dagliga användning för utveckling, låter WSL dig hantera dina miljöer ganska snyggt. Med moderna kommandon kan du exportera och säkerhetskopiera hela distributioner med hjälp av:

wsl –exportera DISTRIBUTIONSNAMN fil.tar

och återställ dem på samma maskin eller på en annan med:

wsl –importera NEW_NAME destination_folder file.tar

På så sätt kan du överföra din arbetsmiljö, inklusive hela filsystemet och inställningarna, mellan datorer utan att behöva upprepa installations- och konfigurationsprocessen steg för steg. Det är också en bra strategi för att flytta en Linuxdistribution till en annan enhet med mer utrymme.

När det gäller produktionsanvändning positionerar Microsoft WSL främst som ett utvecklings- och testverktyg . Det kan användas i mycket specifika produktionsscenarier för skrivbordsmiljöer, men när det gäller kritiska tjänster och servrar är det förnuftiga tillvägagångssättet att använda native Linux på traditionellt hanterade fysiska eller virtuella maskiner.

Slutligen, om din dator börjar inte uppfylla de nuvarande Windows 11-kraven och du inte vill hålla jämna steg med hårdvaruuppgraderingar, är ett alltmer rimligt alternativ att installera Linux som ditt huvudsakliga operativsystem och degradera Windows till en virtuell maskin (med VirtualBox, VMware, GNOME Box, etc.). På så sätt behåller du de program som bara körs på Windows, men drar nytta av Linux stabilitet och lättviktiga egenskaper som ditt bassystem.

I slutändan fungerar WSL utmärkt när man förstår det som ett flexibelt verktyg för att föra Linux-världen närmare utvecklare som fortfarande är bekanta med Windows , vilket gör att man kan replikera produktionsmiljöer, arbeta med Docker och dra nytta av konsolverktyg utan att lämna sitt vanliga skrivbord. Om man vet hur det integreras med systemet, var det lagrar saker, vilka nätverksproblem som kan uppstå och hur man åtgärdar dem, blir det en mycket kraftfull allierad för ditt dagliga arbetsflöde.