WSL, Docker, Linux и виртуални машини… Изглежда като сложен свят за тези, които работят по проекти за разработка на Windows. Много разработчици чуват прекрасни неща за… Подсистема на Windows за LinuxНо когато седнат пред компютъра, те не са наясно какъв реален проблем ще реши той, какви рискове крие или как да почистят всичко след това.
В тази статия ще разгледаме по-подробно какво е WSL, за какво служи отвъд очевидното и най-вече, Как да го използвате по начин, който възможно най-малко „затрупва“ инсталацията на WindowsЩе видим и кога може да се интересувате от промяна на нещата и използване на Linux като основна система, оставяйки Windows във виртуална машина.
Какво точно е WSL и защо толкова много хора говорят за него?
WSL означава Подсистема на Windows за Linux, подсистемата на Windows за изпълнение на Linux дистрибуции интегриран в Windows 10 и 11. Идеята на Microsoft е проста: да ви предостави „истинска“ Linux среда, без да ви принуждава да използвате двойно зареждане или да настройвате класическа виртуална машина с VirtualBox или VMware.
На практика, с WSL можете да имате дистрибуция като Ubuntu, Debian или Kali, работеща успоредно с Windows, да споделяте файлове между двете системи и стартиране на типични Linux инструменти (bash, ssh, apt, Python, Node, Docker…) без да напускате обичайния си работен плот. Всичко това с доста висока степен на интеграция с хост системата.
От стартирането си WSL генерира силно поляризирани мнения. Някои разработчици го смятат за абсолютен успех и убедителна причина да продължат да използват Windows. Други, особено от по-пуристката Linux общност, го виждат като маневра от страна на... „adopt-extend-extinguish“ за поддържане на хегемонията на Microsoft в настолните компютриОтвъд противоречията, реалността е, че WSL промени начина, по който работят много разработчици.
Препоръчителната версия в момента е WSL 2Това вече не е просто слой за съвместимост; използва се лека виртуална машина с истинско Linux ядро. Microsoft настоява, че „това не е традиционна виртуална машина“, защото я създава, конфигурира и оптимизира вместо вас, но отдолу се крие виртуализация с технологии като Hyper-V.
WSL 1 срещу WSL 2 и изисквания, които трябва да имате предвид
Днес е важно да се разбере разликата между WSL 1 и WSL 2. Особено по отношение на въпросите, свързани с производителност, съвместимост и хардуерни изискванияWSL 1 извърши превод на системните повиквания на Linux към Windows; работеше добре за много неща, но не успя да се справи с по-напредналите инструменти.
С WSL 2, Microsoft променя подхода си: Той изпълнява пълноценно Linux ядро във високо оптимизирана виртуална машинаТова значително подобрява съвместимостта (Docker, типичните файлови системи на Linux и др.) и повечето софтуер, който работи на „истински“ Linux, работи и в рамките на WSL 2.
Недостатъкът е, че WSL 2 има повече зависимости. Изисква поддръжка за виртуализация на процесора и SLAT (преобразуване на адреси от второ ниво)Тази функция е налична в сравнително съвременните процесори (Intel Nehalem и по-нови модели, AMD Opteron и наследниците им). По-старите процесори, като например някои Core 2 Duo процесори, просто няма да могат да използват WSL 2, дори ако активирате всички функции.
Освен това, за да използвате WSL 2, ви е необходима достатъчно скорошна версия на Windows: Windows 10 1903 (компилация 18362) или по-нова версия, или Windows 11В по-старите системи трябва да се придържате към WSL 1, с неговите ограничения. Това означава, че по някакъв начин, Все още влачите изискванията и жизнения цикъл на WindowsАко вашата машина вече не се поддържа, WSL също ще бъде.
Бърза настройка на WSL и първи решения
В текущите версии на Windows, Microsoft значително е опростила процеса. От конзолата на PowerShell с администраторски права, просто изпълнете Командата wsl –install ще инсталира WSL и Ubuntu система по подразбиране.Системата сама изтегля необходимите компоненти и дистрибуцията от Microsoft Store.
По време на първото зареждане на дистрибуцията ще бъдете помолени да създадете потребителско име и парола за Linux систематаТози потребител е вашият основен акаунт в дистрибуцията, напълно независим от вашия акаунт в Windows, което помага да се поддържа определено ниво на изолация.
Ако искате да отидете малко по-далеч, можете да изброите всички налични дистрибуции с wsl –списък –онлайн и изберете например Debian, Kali, openSUSE или други варианти на Ubuntu. Инсталацията се извършва с wsl –install -d ИМЕ_НА_РАЗПРОСТРАНЕНИЕ и всяка дистрибуция живее в собствена изолирана „кутия“.
По подразбиране, на новите системи, самата команда wsl –install Конфигурирайте WSL 2 като базова версияНо можете да осигурите това с `wsl --set-default-version 2`. Ако вече имате дистрибуции, създадени с WSL 1, можете да ги мигрирате поотделно с wsl –set-version ИМЕ_НА_РАЗПРОСТРАНЕНИЕ 2, за сметка на кратко време за преобразуване.
Как WSL влияе на вашата Windows система и къде съхранява информация
Едно от основните ви притеснения вероятно е колко WSL „затрупва“ вашата Windows система и къде се озовава всичко, което инсталирате на Linux. Най-важното е, че Всяка WSL дистрибуция се съхранява в папка с потребителски данни в %LocalAppData%\PackagesИ ако предпочитате да управлявате файлове извън класическия Explorer, можете да използвате алтернативни файлови мениджъриНе освобождава файлове по целия диск, както би направила класическа инсталация на Linux.
В тази папка има директория LocalState с виртуален диск (VHDX), който съдържа цялата файлова система на Linux: /, /home, /var и др.С други думи, уеб сървърът, Docker, базите данни, кодът на проекта – всичко се намира в този контейнер. Стига да не докосвате нищо извън него, въздействието върху типичните пътища на Windows е минимално.
WSL обаче изисква активиране на определени системни функции: „Подсистема на Windows за Linux“ и, за WSL 2, „Платформа за виртуални машини“Това може да се направи чрез PowerShell (Enable-WindowsOptionalFeature) или от графичния интерфейс „Включване или изключване на функциите на Windows“. Той също така инсталира Linux ядро за WSL в %SystemRoot%\System32\lxss\tools.
Тези компоненти стават част от Windows след активиране, така че ако в даден момент искате Оставете системата така, сякаш никога не сте докосвали WSLЩе трябва да деинсталирате дистрибуциите, да деактивирате допълнителните функции и, ако е необходимо, да премахнете пакета с ядрото. Това не е прост процес от типа „просто изтрийте папка и сте готови“, но не е и особено сложен.
Също така имайте предвид, че WSL създава виртуален мрежов интерфейс, настройва правилата на защитната стена и, в случая на WSL 2, разчита на услуги като ICS (Споделяне на интернет връзка) и HNS за управление на вътрешни NAT, DNS и DHCPВсичко това е прозрачно в ежедневните операции, но обяснява защо някои корпоративни VPN мрежи или защитни стени понякога се сблъскват с WSL.
Използване на WSL за уеб разработка и по-малко очевидни задачи
Отвъд типичното „Искам да имам bash на Windows“, WSL блести, когато имате нужда Пресъздайте производствени Linux среди, без да напускате работния плот на WindowsНапример, случаят, който споменахте: FOSS проект, който използва Docker, Flask, ArangoDB и други backend услуги.
Вместо да се мъчите със странни версии на Windows или Docker Desktop на оригиналния Windows (което исторически е било доста болезнено), можете да инсталирате целия стек директно във вашата WSL дистрибуция. Docker работи естествено на ядрото на WSL 2Linux услугите функционират както на истински сървър, а вие продължавате да използвате VS Code или други графични инструменти от Windows.
Има и по-малко очевидни предимства. Можете да бягате скриптове за администриране, специфични за Linux инструменти за команден ред, добри версии на Node и NVM, мениджъри на пакети като aptи като цяло цялата екосистема от помощни програми, с които разработчиците на сървъри са свикнали.
Благодарение на интеграцията с файлова система, WSL монтира вашите Windows дискове под /mnt (например /mnt/c за устройство C:). Това ви позволява да Редактирайте кода с вашия Windows редактор и го стартирайте в Linux, без да дублирате проекти.
Друго интересно нещо е оперативната съвместимост от другата страна: от Linux shell можете да извикате Изпълними файлове на Windows, като например notepad.exe, powershell.exe или който и да е системен .exe файлАко вашата променлива PATH включва пътища за Win32, като /mnt/c/Windows/System32, простото въвеждане на името на изпълнимия файл ще го стартира, освен ако вашата обвивка случайно не е презаписала PATH.
Windows Terminal: перфектният партньор за WSL
За да направите вашето WSL преживяване по-комфортно, Microsoft препоръчва да използвате Windows Terminal (Windows Terminal на испански)Това е модерно приложение, което ви позволява да отваряте раздели от различни обвивки: PowerShell, CMD и, което е много важно, от всяка от вашите WSL дистрибуции.
С Windows Terminal можете да създавате сесии на Ubuntu, Debian или Kali от една програма, с раздели и панели, да конфигурирате клавишни комбинации и персонализиране на шрифтове, цветове и профили без да е необходимо да поддържате хиляда отделни прозореца на cmd.exe. Освен това, елиминира зависимостта от остарели инструменти като PuTTY за SSH връзки, тъй като можете да се свързвате с отдалечени сървъри директно от WSL дистрибуция.
Типичният работен процес за много разработчици на Windows днес е: Код във VS Code, главен терминал в Windows Terminal и backend и инструменти в WSLТази комбинация предлага изживяване, много близко до работа на macOS или директно на настолна Linux дистрибуция.
Мрежа, DNS, VPN и други главоболия в WSL
WSL 2 обикновено причинява най-много проблеми в мрежата: когато се използва лека виртуална машина, тя зависи от... виртуален адаптер, правила за защитна стена и малък вътрешен NAT които понякога се сблъскват с корпоративни конфигурации, VPN мрежи, антивирусни програми със защитни стени или строги политики за сигурност.
Често срещан проблем е, че WSL няма достъп до интернет на компютрите на компаниятаВ много домейни на Active Directory, правилата за защитна стена, дефинирани от организацията, блокират локалните правила. Тъй като изключението, което HNS създава, за да разреши DNS трафик от WSL vNIC, е локално, то се презаписва. Ако `AllowLocalFirewallRules` или `AllowInboundRules` са зададени на `False` в съответния профил (чрез `Get-NetFirewallProfile`), WSL няма да разрешава имена.
Решението се крие в това администраторът да определи подходящо корпоративно правило. Или, алтернативно, Активиране на WSL DNS тунелиране с помощта на експерименталната опция dnsTunneling във файла .wslconfig. Тази функция кара вътрешните DNS заявки на Linux да отиват директно към резолвера на Windows през слоя за виртуализация, без да са необходими класически мрежови пакети, които биха могли да конфликтират със защитната стена.
Някои VPN мрежи също причиняват проблеми. Известни са случаи с Cisco AnyConnect, OpenVPN клиенти, решения като ZScaler, McAfee Safe Connect или Bitdefender които манипулират маршрути, NRPT или прокси сървъри по начин, който нарушава NAT или пречи на WSL трафика. Понякога решението е да се активира networkingMode=mirrored, друг път да се деактивира dnsTunneling или дори да се настрои конфигурацията на autoProxy, така че огледалното отразяване на HTTP_PROXY/HTTPS_PROXY в Linux да отговаря на вашия сценарий.
В класическия NAT режим има ограничения, като например Можете да дефинирате само три DNS сървъра в /etc/resolv.confТова е нещо, което dnsTunneling също помага да се реши: Linux използва всички DNS сървъри, конфигурирани от Windows. Освен това, DNS суфиксите се обработват по различен начин в зависимост от това дали използвате чист NAT, NAT с DNS тунелиране или огледален режим. В огледален режим всички DNS суфикси на Windows се отразяват в търсенето в resolv.conf и се актуализират автоматично, когато се променят на хоста.
Съвместимост на Docker и контейнери в WSL
Една от основните причини за приемането на WSL 2 е драстичното подобряване на Docker преживяването. Официалната идея на Microsoft и Docker е, че Docker Desktop използва WSL 2 като бекенд, вместо директен Hyper-V или стария му двигател.
Въпреки това, не всичко е перфектно. Проблеми са открити например, когато Използвате огледален мрежов режим (networkingMode=mirrored) и изпълнявате контейнери с публикувани портовеВ тези случаи Docker Desktop може да не успее да създаде тези контейнери, ако използвате мрежовото пространство от имена по подразбиране. Временното решение е да стартирате контейнерите с `--network host` или да добавите проблемните портове към `ignoredPorts` в `.wslconfig`.
Има и инциденти с контейнери, превозващи Мрежов мениджър или други активни сложни мрежови услуги Те могат да попречат на правилната работа на мрежовата конфигурация на WSL, особено за обратни връзки към хоста. Microsoft препоръчва деактивирането на тези типове демони, когато не са строго необходими.
Ако освен това корпоративната ви среда добавя HTTP/S прокси и активирате autoProxy в WSL, променливи като HTTP_PROXY, HTTPS_PROXY, NO_PROXY и WSL_PAC_URLОбърнете внимание, че дефинираните от потребителя променливи имат предимство пред автоматично генерираните. Linux не поддържа PAC, така че може да се наложи да адаптирате скриптове или да деактивирате функцията.
Често срещани грешки в Linux дистрибуцията и как да ги решим
Веднъж щом се инсталирате в дистрибуцията, могат да се появят и типични за Linux проблеми, някои от които се утежняват от особеностите на WSL. Класически пример е, че Команди на Windows като powershell.exe или notepad.exe не са намерени като ги извикате от bash със съобщение „команда не е намерена“.
В повечето случаи това се дължи на стартов скрипт (като /etc/profile в Debian) предефиниране на PATH без да се взема предвид стойността, предадена от WSLТова може да доведе до загуба на пътища като /mnt/c/Windows и подобни местоположения. Правилният подход е да не се презаписва PATH, а по-скоро да се разшири или просто да се премахнат проблемните редове. Препоръчително е също да се провери дали `appendWindowsPath=false` в `/etc/wsl.conf`.
Друг повтарящ се проблем е Грешки при надстройка на apt-get, свързани с udev и системни услуги Тези не се поддържат в WSL, тъй като не е цялостна система с традиционна init команда. Обичайното решение е да се инсталира скрипт policy-rc.d в /usr/sbin, който връща изход 101, за да се предотврати стартирането на услуги, да се добавят разрешения за изпълнение и да се използва dpkg-divert за пренасочване на /sbin/initctl към /bin/true.
SSH също има своите особености. Ако при опит за свързване с отдалечен сървър срещнете предупреждения като „НЕЗАЩИТЕН ФАЙЛ С ЛИЧЕН КЛЮЧ!“ и разрешения 0777, най-вероятно е това Запазвате ключове в директория, монтирана от Windows с прекалено слаби разрешения. За да може WSL правилно да управлява POSIX разрешенията за Windows файлове, се препоръчва да добавите раздел към /etc/wsl.conf с опции като metadata,uid=1000,gid=1000,umask=0022.
Обратно, ако настроите OpenSSH сървър във вашата WSL дистрибуция и когато се свързвате от Windows, видите „Връзката е затворена от 127.0.0.1 порт 22“, проверете лог файловете, като стартирате sshd в режим на отстраняване на грешки и се уверите, че Има хост ключове в /etc/ssh, които не са изтрити.Ако липсват, те могат да бъдат регенерирани или, по-просто казано, пакетът openssh-server може да бъде изчистен и преинсталиран.
Използване на WSL в по-стари версии на Windows и стария вариант
В отбори с Много стари версии на Windows 10 (Creators Update, Anniversary Update) Поддръжката на WSL е значително по-ограничена. Използваше bash.exe, lxrun и по-незряла имплементация. Командите и пътищата са различни. Linux командите се предаваха с bash -c, дистрибуциите се съхраняваха в %LocalAppData%\lxss, а оперативната съвместимост с Windows беше по-рудиментарна.
Ако идвате от този етап и все още имате „старата версия“ на WSL, Microsoft препоръчва Мигрирайте данните си от Store към модерна дистрибуция и деинсталирайте старата. Можете да направите това с wsl –unregister Legacy или като ръчно изтриете папката %LocalAppData%\lxss (внимавайте, това изтрива цялото старо Linux съдържание).
В тези системи, функции като WSL 2, официална поддръжка за графични приложения за Linux, интеграция с Docker Desktop и опростяване на wsl –install Те не са налични. Ако вашият хардуер го позволява, най-добре е да надстроите до скорошна версия. Или отидете директно на Windows 11, за да се възползвате от текущата версия на подсистемата.
Във всеки случай, ако преди всичко искате да сведете до минимум въздействието върху Windows или компютърът ви изостава по отношение на изискванията, има все по-солидна алтернатива: Използвайте Linux като основна система и преместете Windows на виртуална машина (Например, с VirtualBox, VMware или GNOME Boxes). По този начин избягвате зависимостта от нарастващите изисквания на Windows 11. И поддържате хардуера си жив по-дълго.
