WSL: Найшвидший спосіб отримати справжнє середовище розробки на Windows (без драми з віртуальними машинами)

Що таке WSL насправді (і чим воно не є)

WSL — це не «Linux-додатки, що запускаються у Windows-совісному шарі сумісності» (таке було про WSL1). WSL2 — це реальне ядро Linux, що працює всередині легковагового VM, яким керує Windows. Ваше Linux-середовище достатньо реальне, щоб запускати стандартні пакети, реальні системні виклики, повноцінні мережеві стекі та сучасні робочі процеси з контейнерами.

Це також не повноцінна серверна VM, яку слід розглядати як «питомця». Інстанси WSL — доволі одноразові. Вам потрібна відтворювана конфігурація, версіоновані dotfiles і бекапи, які реально відновити. Якщо ваш робочий процес будується на «я налаштував один раз і тепер боюся торкатися», ви відтворили ту саму VM-драму, від якої прийшли рятуватися.

WSL2 дає вам:

• Linux-файлову систему, що зберігається у VHDX (віртуальний диск) на Windows.
• Швидкі операції файлової системи з боку Linux.
• Інтероп: виклики Windows-бінарів з Linux і навпаки.
• Розумну інтеграцію з редакторами (особливо VS Code Remote).
• Достатньо налаштувань для CPU/пам’яті/swap, щоб зупиняти неконтрольовані збірки, які «з’їдають» ваш ноутбук.

WSL2 також додає нові способи помилитися. Здебільшого навколо файлових систем, мережевих припущень і налаштувань ресурсів. На щастя, це ті самі області, що кусають продакшен-системи, тож ви можете ставитися до робочої станції як до маленького дата-центру і поводитися відповідно.

Цікаві факти і коротка історія, які можна використати

• WSL1 і WSL2 — принципово різні істоти. WSL1 транслював Linux-системні виклики у Windows; WSL2 запускає реальне ядро Linux у керованому VM.
• WSL2 зберігає вашу дистрибуцію у файлі VHDX. Цей один файл — і благословення (легко робити бекап/експорт), і прокляття (його можна швидко наповнити сміттям).
• Ранні версії WSL1 не підтримували ключові функції ядра, які передбачає контейнерне середовище. WSL2 змінив гру для робочих процесів з Docker і Kubernetes.
• Microsoft офіційно додали підтримку systemd у WSL після років культурного спротиву «будь ласка, не запускайте init-системи тут». Тепер це стандартний варіант, а не хак.
• Продуктивність файлів залежить від того, де ви тримаєте код. Операції файлової системи Linux швидкі у ext4 всередині WSL; перехід у /mnt/c повільніший і має інші семантики.
• WSLg — це реальна фіча. Графічні Linux-додатки можуть запускатися інтегровано у Windows 11 без DIY-танців із X-сервером.
• Мережа WSL використовує NAT і віртуальні комутатори. Це робить localhost в більшості випадків дружнім, але «сервіс слухає не на тому інтерфейсі» стає частою загадкою на роботі.
• Windows і Linux мають різні правила щодо регістру букв у іменах файлів та інші файлові обмеження. Якщо ви бездумно змішуєте файлові системи, Git рано чи пізно зробить це персональним.
• WSL отримав модель версіонування через Store, тож оновлення можуть виходити швидше, ніж випуски ОС. Це важливо, коли ви налагоджуєте «в мене працює на цій версії Windows» відмінності.

Чому WSL2 швидкий (і коли ні)

WSL2 здається швидким, тому що ваші Linux-інструменти не емітуються; вони працюють проти реального ядра. Запуск процесів відчутно швидкий, менеджер пакетів поводиться належно, і типові задачі розробки — компіляція, тести, локальна база даних — працюють стабільно.

Найшвидше, що ви можете зробити для продуктивності WSL — це нудна, але правильна річ: тримайте репозиторії у Linux-файловій системі (~ або будь-де під /home) і вважайте Windows-монти (/mnt/c) лише для інтеропу. Якщо ви цього не дотримаєтеся, решту тижня витратите на «оптимізацію» неправильних речей.

Де може стати повільно або дивно:

• Перехід між файловими системами. Node/npm, Rust, Go, Python virtualenvs і Git створюють багато дрібних файлів. Робота з цим на /mnt/c — це податок, який ви сплачуєте за кожен системний виклик.
• Сканування антивірусом. Коли Windows Defender сканує ваші артефакти збірки, це як запуск хаос-інженерії на вашому ноутбуці.
• Тиск на пам’ять. WSL2 — це VM. Якщо дати йому розростатися або дозволити інтенсивний swap, ваше «швидке» середовище перетвориться на пригальмовуючий жах.
• Мережеві припущення. Прив’язка до localhost зазвичай працює, але вхідний трафік з інших машин вимагає явної уваги.

Операційна істина варта стенду: ваша робоча станція — мультиорендна система (Windows + WSL + можливо Docker). Ізоляція ресурсів не опціональна; це різниця між «продуктивно» і «чому Teams використовує 4GB».

Розумне налаштування WSL2 для реальної роботи

Виберіть дистрибутив як доросла людина

Використовуйте Ubuntu LTS, якщо немає сильної причини інакше. Він має найширшу екосистему пакетів і найменше «чому цей туторіал інший» моментів. Debian підходить, якщо ви його віддаєте перевагу. Alpine чудовий для контейнерів, але не для людей як щоденний драйвер.

Увімкніть systemd (якщо вам потрібні сервіси, що поводяться зазвичай)

Якщо ви запускаєте Docker Engine всередині WSL або хочете, щоб ssh-agent, postgresql, cron тощо поводилися як у реальному Linux — увімкніть systemd. Якщо воно вам не потрібне, не вмикайте — менше рухомих частин.

Користуйтеся Windows Terminal і VS Code Remote

Windows Terminal — правильний UI для шелу. VS Code Remote до WSL — правильна модель редагування. Редагувати Linux-файли Windows-процесами можна, але це відмінний спосіб отримати проблеми з кінцевими рядками і дивні поведінки спостерігачів файлів.

Тюнінг ресурсів: встановіть ліміти, поки їх не встановив за вас ноутбук

WSL2 може використовувати пам’ять опортуністично. Це чудово, поки ні. Встановіть межі через .wslconfig. Вам потрібно достатньо RAM для збірок і контейнерів, але також треба, щоб Windows залишався чутливим.

І цитата, яку варто пам’ятати, коли захочете «просто пофантазувати»:

«Надія — це не стратегія.» — парафразована ідея, яку часто цитують в інженерії та операціях

Жарт №1: WSL — як добре налагоджений on-call-розподіл — тихо, коли ви все робите правильно, і голосно, коли ви починаєте експериментувати.

12+ практичних завдань: команди, виводи, рішення

Це щоденні перевірки, які я використовую, коли налаштування WSL поводиться дивно. Кожне завдання включає: команду, що означає її вивід, і рішення на його основі.

Завдання 1: Перевірте, що ви на WSL2 (не WSL1)

cr0x@server:~$ wsl.exe -l -v
  NAME            STATE           VERSION
* Ubuntu-22.04    Running         2

Значення: VERSION 2 підтверджує, що ви на реальному WSL на базі ядра.

Рішення: Якщо ви бачите VERSION 1, конвертуйте (wsl.exe --set-version <distro> 2) перед тим, як робити бенчмарки.

Завдання 2: Підтвердіть ядро і середовище зсередини Linux

cr0x@server:~$ uname -a
Linux cr0x 5.15.133.1-microsoft-standard-WSL2 #1 SMP Wed Oct 11 16:01:22 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Значення: Ви на зібраному Microsoft-ядрі WSL2.

Рішення: Якщо бракує очікуваних функцій ядра, оновіть WSL з Windows і перезавантажте WSL.

Завдання 3: Перевірте використання диску всередині дистрибутиву (побачити прихований ріст VHDX)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc        251G   76G  163G  32% /

Значення: Коренева файловa система Linux має запас місця.

Рішення: Якщо зайнято багато, шукайте великі каталоги (наступне завдання) перед тим, як «виправляти» продуктивність випадковими твиками.

Завдання 4: Швидко знайдіть найбільших споживачів місця

cr0x@server:~$ sudo du -xhd1 /home | sort -h
4.0K    /home/lost+found
12G     /home/cr0x/.cache
38G     /home/cr0x/projects
50G     /home/cr0x

Значення: Кеші і директорії проектів домінують.

Рішення: Обережно чистьте кеші мов/інструментів (pip, npm, cargo) і подумайте про обрізку шарів контейнерів, якщо використовується Docker.

Завдання 5: Виміряйте, чи ваш репозиторій на Linux FS чи на Windows-монті

cr0x@server:~$ pwd
/home/cr0x/projects/api-service

Значення: Ви в Linux-файловій системі. Добре.

Рішення: Якщо ви бачите /mnt/c/..., перемістіть репозиторій у /home, якщо немає специфічних потреб інтеграції.

Завдання 6: Перевірте тип та опції монтажу (діагностика проблем з правами)

cr0x@server:~$ mount | grep -E '/mnt/c|/ '
C: on /mnt/c type drvfs (rw,noatime,uid=1000,gid=1000,metadata,case=off)
none on / type ext4 (rw,relatime,discard,errors=remount-ro)

Значення: Диск Windows змонтовано як drvfs; корінь Linux — ext4.

Рішення: Якщо відсутній metadata, у вас будуть проблеми з правами/битом виконання на /mnt/c. Виправте через опції монтажу WSL у /etc/wsl.conf.

Завдання 7: Підтвердіть перегляд CPU і пам’яті (і впіймайте неконтрольоване виділення)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           15Gi       6.2Gi       1.9Gi       128Mi       6.9Gi       8.5Gi
Swap:          8.0Gi       0.0Ki       8.0Gi

Значення: Достатньо вільної пам’яті; swap не використовується.

Рішення: Якщо swap гарячий, виправте ліміти пам’яті або припиніть одночасно запускати базу даних, три браузери і кластер контейнерів.

Завдання 8: Визначте, що гризе CPU (і чи це Windows чи Linux)

cr0x@server:~$ top -b -n1 | head -n 12
top - 14:22:01 up  2:11,  0 users,  load average: 2.31, 2.10, 1.88
Tasks:  95 total,   1 running,  94 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.5 us,  2.1 sy,  0.0 ni, 84.8 id,  0.2 wa,  0.0 hi,  0.4 si,  0.0 st
MiB Mem :  15360.0 total,   2048.0 free,   6360.0 used,   6952.0 buff/cache
PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
812 cr0x      20   0 2539888 312432  40288 R  78.2   2.0   0:34.12 node

Значення: Linux-процес node інтенсивно завантажує CPU; час очікування I/O низький.

Рішення: Якщо wa (I/O wait) високий, дивіться на розташування файлової системи і антивірус. Якщо CPU гарячий — швидше за все це збірка/тести.

Завдання 9: Перевірте поведінку DNS (поширене джерело «pip/npm не працює»)

cr0x@server:~$ resolvectl status | sed -n '1,30p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 172.24.112.1
       DNS Servers: 172.24.112.1

Значення: DNS надходить від віртуального шлюзу.

Рішення: Якщо розв’язування імен періодично падає, можливо, потрібно зупинити автогенерацію /etc/resolv.conf і задати стабільний DNS, особливо за корпоративного VPN/проксі.

Завдання 10: Підтвердьте локальні порти і прослуховувані сервіси

cr0x@server:~$ ss -lntp | head
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      4096   127.0.0.1:5432     0.0.0.0:*     users:(("postgres",pid=941,fd=7))
LISTEN 0      4096   0.0.0.0:8080       0.0.0.0:*     users:(("python",pid=1202,fd=3))

Значення: Postgres прив’язаний до localhost; ваш додаток слухає на всіх інтерфейсах.

Рішення: Якщо Windows не може дістатися до сервісу WSL — прив’язуйте до 0.0.0.0 (обережно) або налаштовуйте перенаправлення портів; не вгадуйте.

Завдання 11: Перевірте стан systemd (якщо увімкнено)

cr0x@server:~$ systemctl is-system-running
running

Значення: systemd здоровий; сервіси мають поводитися як зазвичай.

Рішення: Якщо бачите degraded, перевірте невдалі юніти; не ігноруйте це просто тому, що «це лише девбокс».

Завдання 12: Перевірте журнали для відмов сервісів

cr0x@server:~$ journalctl -u docker --no-pager -n 10
Feb 04 14:01:12 cr0x systemd[1]: Starting Docker Application Container Engine...
Feb 04 14:01:12 cr0x dockerd[1333]: time="2026-02-04T14:01:12.412" level=info msg="Starting up"
Feb 04 14:01:12 cr0x dockerd[1333]: time="2026-02-04T14:01:12.980" level=info msg="Loading containers: start."
Feb 04 14:01:13 cr0x systemd[1]: Started Docker Application Container Engine.

Значення: Сервіс Docker стартував чисто.

Рішення: Якщо бачите помилки storage-driver або проблеми з правами, виправляйте базову причину (розташування файлової системи, налаштування cgroup), а не перевстановлюйте все підряд.

Завдання 13: Перевірте, чи Git не мовчки бореться з регістром букв

cr0x@server:~$ git config --get core.ignorecase
false

Значення: Git трактуватиме зміни регістру як значущі, що відповідає поведінці Linux.

Рішення: Якщо це true і команда використовує чутливі до регістру шляхи, ви запрошуєте дивні дифі та відсутні файли — виправляйте на рівні репозиторію.

Завдання 14: Експорт дистрибутиву для бекапу (відновлення вашого dev-життя)

cr0x@server:~$ wsl.exe --export Ubuntu-22.04 D:\wsl-backups\ubuntu-22.04.tar
Exporting, this may take a few minutes...

Значення: Ви створили портативний архів бекапу.

Рішення: Якщо не можете швидко відновити середовище — у вас не налаштування, а сніжинка.

Завдання 15: Імпорт дистрибутиву на інший диск (керування місцем та продуктивністю)

cr0x@server:~$ wsl.exe --import Ubuntu-22.04-Work D:\WSL\Ubuntu-Work D:\wsl-backups\ubuntu-22.04.tar --version 2
Importing, this may take a few minutes...

Значення: Ви встановили новий екземпляр у вибраний шлях — корисно для швидкого NVMe або більшого диска.

Рішення: Якщо системний диск заповнений, перемістіть дистрибутив. Не чекайте на «диск заповнений» під час релізу.

Завдання 16: Перевірка інтеропу при виклику Windows-інструментів

cr0x@server:~$ powershell.exe -NoProfile -Command '$PSVersionTable.PSVersion.ToString()'
7.4.1

Значення: Ви можете викликати Windows PowerShell з Linux. Зручно для автоматизації-склеювання.

Рішення: Використовуйте інтероп свідомо. Якщо збірка залежить від нього, документуйте, бо хтось запустить на чистому Linux і прокляне ваші нащадки.

Правила зберігання та файлової системи, що запобігають жалю

Я працюю зі зберіганням. Я не довіряю «здається нормально» як метриці, і ви не повинні також. Продуктивність WSL2 живе і помирає за межами файлових систем.

Правило 1: Тримайте репозиторії всередині Linux-файлової системи

Робіть роботу під /home. Кладіть там код. Кладіть кеші залежностей там. Нехай Linux робить Linux-справи там, де діють Linux-семантики.

Коли ви розробляєте під /mnt/c, ви просите проблем:

• Повільні операції з метаданими (багато дрібних створень/перейменувань файлів).
• Заплутані біти прав (якщо не увімкнути metadata).
• Дивні поведінки спостерігачів файлів (особливо в Node, webpack і Python reloaders).
• Невідповідності регістру, що призводять до «працює в мене» багів.

Правило 2: Ставтеся до /mnt/c як до зони обміну

Використовуйте його для речей, що повинні бути видимі Windows-додаткам: експорт артефактів, скидання логів для переглядача Windows, копіювання дата-сетів або інтеграція з корпоративними інструментами, що працюють лише на Windows. Не робіть його робочою зоною збірки.

Правило 3: Плануйте ріст і прибирання VHDX

Диск вашої дистрибуції WSL — це віртуальний образ диска. Він росте, коли ви встановлюєте пакети і генеруєте артефакти збірки. Він не завжди автоматично стискається після видалення файлів. Це не моральний пробіл; це особливість thin-provisioned віртуальних дисків.

Операційний висновок: періодично витрівайте кеші і шари контейнерів. Якщо ви запускаєте важкі БД локально, подумайте про розміщення їхніх даних у окремому дистрибутиві або стратегії зберігання, щоб основне dev-середовище не перетворилося на смітник.

Правило 4: Знати, що означає «швидкий I/O» для вашого навантаження

Компілятори, менеджери пакетів і ранери тестів часто виконують багато дрібних випадкових I/O і операцій з метаданими (stat, open, close). Ось де шари трансляції файлових систем шкодять. Великі послідовні читання кількох файлів цього не покажуть. Отже, коли ви робите бенчмарк, бенчмаркуйте реальне навантаження: npm ci, pip install, go test ./..., ваш реальний крок збірки.

Мережа: localhost, DNS, проксі та гострі кути

Мережа у WSL2 достатньо хороша, щоб ви про неї забули — поки не підключитесь до корпоративного VPN, не запустите локальний проксі або не прив’яжете сервіс до неправильного інтерфейсу і не задастеся питанням, чому нічого не спілкується.

Localhost: загальний щасливий шлях

Більшість робочих процесів — «я запускаю сервер у WSL і звертаюся до нього з браузера на Windows». Це зазвичай працює, бо Windows і WSL співпрацюють у пересиланні localhost у типових сценаріях. Але не вважайте це магією; перевіряйте через ss і реальні запити.

Адреси прив’язки: обирайте свідомо

Прив’язка до 127.0.0.1 означає «тільки всередині WSL». Прив’язка до 0.0.0.0 означає «всі інтерфейси», що робить сервіс доступним з Windows і потенційно інших мереж залежно від брандмауера і маршрутизації.

Якщо ви працюєте з чутливими сервісами (бази даних, внутрішні адмін-інтерфейси), тримайте їх на localhost, якщо нема чіткої потреби. Розробники випадково, виставивши дебаг-порт, — ось як ви опинитесь на тренінгу з безпеки.

DNS: коли «періодично» — це ваш натяк

Корпоративні VPN-клієнти часто встановлюють свої DNS та політики маршрутизації. WSL може підхопити адресу stub-резолвера, яка іноді працює, а іноді ні, залежно від стану VPN. Коли ви бачите, що встановлення пакетів падає через помилки розв’язування імен, ставте DNS у першу чергу підозри.

Проксі: не налаштовуйте напівсерйозно

Якщо ваша мережа вимагає HTTP-проксі, налаштуйте його послідовно в таких місцях:

• Змінні середовища (HTTP_PROXY, HTTPS_PROXY, NO_PROXY)
• Налаштування Git для проксі, якщо потрібно
• Специфічні налаштування інструментів мов (npm, pip, cargo) при потребі
• Демон Docker / конфігурація збірки, якщо ви збираєте образи

Напівналаштовані проксі створюють «іноді працює» помилки, які витрачають найдорожчий ресурс в інженерії: вашу увагу.

Docker і контейнери на WSL2 без самосправ

Є два поширені підходи:

1. Docker Desktop з бекендом WSL2. Зазвичай найпростіше. Windows керує інтеграцією, і ваші Linux-інструменти говорять з Docker безшовно.
2. Docker Engine, встановлений всередині WSL-дистрибутиву. Працює добре, якщо ви хочете більш Linux-нативний досвід, особливо з systemd, але вам доведеться опікуватися більше про «планку» конфігурації.

Зберігання для контейнерів: невидимий пожирач диска

Шари контейнерів накопичуються. Вони завжди накопичуються. Якщо ви не чистите — VHDX росте, продуктивність падає, і зрештою отримаєте «no space left on device» посеред збірки.

Розташування файлової системи все ще має значення

Контексти збірки, що живуть на /mnt/c, можуть зробити Docker-збірки болісно повільними, бо відправка контексту збірки і читання метаданих перетинають межу. Тримайте контекст і Dockerfile у Linux-файловій системі.

Жарт №2: Шари Docker-образів — як офісні закуски: ніхто не зізнається, хто відповідальний, але вони повільно зникають до бюджетної наради.

Три міні-історії з корпоративного життя (з болем)

Міні-історія 1: Інцидент через неправильне припущення

Середня компанія впровадила «стандартне dev-середовище»: Windows-ноутбуки, WSL2 для бекенд-сервісів, спільний монорепозиторій і локальний контейнер Postgres. Здавалося, працює тижнями — доки під час релізного тижня кілька розробників не почали скаржитися, що міграції «випадково падають», а API «іноді не може підключитися до бази».

Неправильне припущення було тонким: вони вважали, що localhost має одне значення всюди, і якщо сервіс слухає localhost всередині WSL, він автоматично доступний для Windows-додатків. Деякі розробники запускали API у WSL і БД у Docker Desktop; інші — обидва у WSL; кілька запускали API у Windows, а БД у WSL. Строка підключення localhost:5432 трактувалась як універсальна істина.

Насправді мережевий шлях залежав від того, де клієнт жив. Windows-процес, що звертався до localhost, не завжди говорив з localhost WSL. Деякі конфігурації форвардили коректно; інші — ні, особливо коли VPN-клієнт міняв маршрути і Hyper-V virtual switch перезапускався.

Виправлення не було магічним реєстровим трюком. Вони стандартизували топологію: API і БД працюють в одному середовищі (обидва у WSL або обидва у Docker Desktop з бекендом WSL). Вони написали дві канонічні строки підключення і поклали їх у інструменти, що виявляють контекст виконання. Також додали простий health-check скрипт, який перевіряв з’єднання з боку реального клієнта, а не з «де ми думаємо, що він працює».

Після цього «випадковість» зникла. Це не було випадковим; це була неозвучена архітектура.

Міні-історія 2: Оптимізація, що відкотилася

Інша організація мала проблему продуктивності: npm install був повільним. Хтось вирішив «оптимізувати», тримаючи репозиторій на Windows-файловій системі, щоб Windows-індексація та корпоративні бекап-інструменти бачили його. Вони перемістили монорепозиторій під C:\dev і отримували доступ через /mnt/c/dev.

Спочатку все виглядало нормально. Збірки стартували, тести проходили, команда тішилася практичністю. Через два тижні почалися багрепорти: hot reload пропускав зміни, Jest-спостерігачі різко навантажували CPU, Git повідомляв про змінені файли, яких ніхто не чіпав, і TypeScript іноді падав з помилкою, що файл «не існує» на мілісекунду.

Вони оптимізували під невірного спостерігача. Windows-шлях файлової системи вніс затримки метаданих і семантичні невідповідності, особливо для інструментів, що відслідковують події файлів і очікують поведінки Linux. Оверхед був не просто у швидкості — у коректності. Розробники витратили години на «виправлення» коду, коли файлова система брехала їм.

Справжня оптимізація була зворотною: тримайте репозиторії у Linux-файловій системі заради коректності і швидкості, а артефакти синхронізуйте у Windows вибірково. Вони також виключили розташування WSL VHDX з агресивного сканування, де це можливо. У підсумку — швидші інстали і менше фантомних файлів.

Перемоги продуктивності, що ламають коректність, не є перемогами. Це борг із відсотками.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Велика команда в корпорації ставилася до WSL-девсередовищ як SRE до продакшену: як до одноразових, відтворюваних одиниць. Кожен розробник мав bootstrap-скрипт, що встановлював пакети, конфігурував шелл-інструменти, фіксував рантайми мов і налаштовував SSH-ключі та known_hosts політики. Це не було гламурно; це була купа скриптів і чекліст.

Одного понеділка оновлення Windows спричинило у підмножини машин дивну поведінку віртуалізації. WSL-дистрибутиви не стартували стабільно; деякі зависали у стані «Running», але не відповідали. Зазвичай це означало б втрату днів і купу індивідуальних ритуалів налагодження.

Відповідь цієї команди була практично нудною: експортуйте дистрибутив, якщо можливо, потім перебудуйте з нуля на уражених машинах за допомогою скрипта. Якщо експорт не вдався — відновіть з останнього архіву. Розробники повернулися до роботи того ж дня, і керівник команди не мусив просити IT про дива.

Практика, що їх врятувала, була проста: періодичний експорт WSL + відтворюване налаштування. Це перетворило інцидент на робочій станції на незначну незручність.

Говорячи мовою ops, у них було RTO для продуктивності розробника. Більшість команд такого не мають. Мали б.

Швидкий план діагностики: що перевіряти першим/другим/третім

Коли WSL «відчувається повільним» або «веде себе дивно», ви хочете ідентифікувати вузьке місце за хвилини, а не години. Ось порядок триажу, що працює на практиці.

По-перше: Підтвердьте, де відбувається робота (межа файлової системи)

1. Запустіть pwd. Якщо ви під /mnt/c, припускайте, що це підозрюваний, поки не доведіть інше.
2. Запустіть mount | grep /mnt/c і перевірте, чи увімкнено metadata, якщо ви покладаєтесь на права/exec-біт.
3. Перемістіть репо в /home і перезапустіть повільну команду. Якщо стало ок — зупиніться з діагностикою і прийміть фікс.

По-друге: Перевірте тиск на ресурси (пам’ять і swap)

1. Запустіть free -h. Якщо вільної пам’яті мало і swap використовується — очікуйте пригальмовувань.
2. Запустіть top. Якщо load average високий при низькому використанні CPU, це може бути I/O wait або контенція.
3. Рішення: встановіть розумні обмеження WSL, зменшіть слонячий профіль контейнерів або припиніть запускати ресурсомісткі сервіси локально.

По-третє: Перевірте вплив антивірусу і індексації (на боці Windows)

1. Якщо репо на Windows-файловій системі — очікуйте накладні витрати сканування — перемістіть його.
2. Якщо розташування VHDX вашої дистрибуції сканується агресивно, ви помітите періодичні стрибки під час збірок.
3. Рішення: координуйтеся з політикою корпоративного ентропоїнт-сканування, якщо дозволено; інакше проєктуйте робочий процес так, щоб мінімізувати поверхню сканування.

Четверте: Мережа і DNS (особливо за VPN)

1. Запустіть resolvectl status і перевірте наявність DNS-сервера.
2. Спробуйте розв’язування імен (getent hosts для відомого домену).
3. Рішення: закріпіть конфігурацію DNS, налаштуйте split-tunnel VPN, якщо дозволено, і забезпечте узгодженість проксі-перемінних.

П’яте: Дрейф версій (WSL, ядро, пакети дистрибутиву)

1. Запустіть wsl.exe --status на Windows і uname -a у Linux.
2. Оновіть WSL і пакети дистрибутиву, якщо ви ганяєтеся за відомим багом.
3. Рішення: стандартизуйте версії в команді; не відлагоджуйте «працює на моєму ноутбуку» різниці в ядрах вічно.

Поширені помилки: симптом → причина → виправлення

1) Симптом: Git status повільний, npm install тягнеться вічно

Причина: Репозиторій на /mnt/c (drvfs). Важкі метадані караються.

Виправлення: Перенесіть репозиторій у /home. Доступ з Windows через вибіркову синхронізацію (копіювання артефактів), а не розробка на drvfs.

2) Симптом: Permission denied / скрипти не виконуються під /mnt/c

Причина: drvfs змонтовано без metadata, тож біт виконання Linux не зберігається.

Виправлення: Налаштуйте /etc/wsl.conf для монтажу з metadata, або тримайте виконувані скрипти в Linux-файловій системі, де права працюють коректно.

3) Симптом: «Temporary failure resolving …» під час встановлення пакетів

Причина: Нестабільність перенаправлення DNS, часто спричинена VPN-клієнтами або зміною мережевих профілів.

Виправлення: Вимкніть автогенерацію /etc/resolv.conf і задайте стабільний DNS, або відрегулюйте політику VPN/проксі для послідовної роботи резолверів.

4) Симптом: Сервіс працює у WSL, але браузер у Windows не може до нього дістатися

Причина: Сервіс прив’язаний до 127.0.0.1 всередині WSL або перенаправлення портів не активне.

Виправлення: Для деву прив’язуйте до 0.0.0.0 за потреби, перевірте через ss -lntp, або налаштуйте явне перенаправлення портів для вашої конфігурації.

5) Симптом: Docker-збірки повільні; відправка контексту займає вічність

Причина: Контекст збірки на Windows-файловій системі; багато операцій з метаданими перетинають межу.

Виправлення: Тримайте Dockerfile і контекст у Linux-файловій системі. Регулярно чистьте образи і кеш збірника.

6) Симптом: Використання пам’яті WSL постійно росте і Windows сповільнюється

Причина: WSL2 VM опортуністично використовує RAM; пам’ять не завжди швидко звільняється під певними навантаженнями.

Виправлення: Встановіть ліміти у .wslconfig, перезапускайте WSL при потребі і уникайте запуску щодня тих стеків контейнерів, які вам не потрібні.

7) Симптом: Спостерігачі файлів пропускають зміни або навантажують CPU

Причина: Редагування Linux-файлів Windows-інструментами через межу файлових систем або спостереження файлів на drvfs.

Виправлення: Використовуйте VS Code Remote до WSL; тримайте файли, що спостерігаються, у Linux FS; зменшіть обсяг спостерігачів; використовуйте polling лише як останню інстанцію.

8) Симптом: «No space left on device» навіть після видалення файлів

Причина: VHDX виріс; видалення файлів не завжди одразу зменшує віртуальний диск.

Виправлення: Придушуйте кеші, експортуйте/імпортуйте для компактності, і тримайте важкі дані в запланованому місці. Не чекайте на кризу.

Чеклісти / покроковий план

Чекліст A: 30-хвилинне налаштування, яке не поставить вас у незручне становище пізніше

1. Встановіть WSL2 і оберіть Ubuntu LTS.
2. Оновіть пакети всередині дистрибутиву; встановіть основні інструменти (git, build-essential, curl, ca-certificates).
3. Вирішіть щодо systemd: увімкніть лише якщо потрібні довгоживучі сервіси.
4. Створіть ~/projects і тримайте там репозиторії.
5. Користуйтеся Windows Terminal як UI шелу.
6. Користуйтеся VS Code Remote до WSL для редагування і налагодження.
7. Налаштуйте SSH-ключі і стратегію агента (форвардинг Windows-агента або Linux-агента — але оберіть одне).
8. Встановіть межі пам’яті/CPU/swap у .wslconfig, відповідні до вашої машини.
9. Запустіть перевірки з «12+ завдань», щоб отримати базову лінію поведінки.
10. Експортуйте дистрибутив, коли він чистий. Це ваш золотий образ.

Чекліст B: Щоденні операційні звички (ті, що запобігають повільному налипання)

1. Тримайте кеші збірки під контролем (прибирайте старі virtualenv, node_modules у мертвих гілках, застарілі шари контейнерів).
2. Не запускайте важкі сервіси, які вам сьогодні не потрібні.
3. Переважно використовуйте Linux-нативні інструменти у WSL; інтероп застосовуйте помірно.
4. Коли щось ламається після зміни VPN, перевірте DNS перед перевстановленням тулчейнів.
5. Експортуйте дистрибутив періодично, якщо ваша робота залежить від локального стану.

Чекліст C: Коли продуктивність падає, робіть це в порядку

1. Підтвердьте місцезнаходження репозиторію: якщо він на /mnt/c, перемістіть.
2. Перевірте пам’ять/swap: якщо відбувається свопінг, встановіть ліміти і зменшіть навантаження.
3. Перевірте I/O wait і основних споживачів CPU.
4. Перевірте DNS і налаштування проксі, якщо мережеві операції повільні.
5. Лише потім розглядайте оновлення WSL, скидання або перебудову дистрибутиву.

Питання й відповіді

Чи є WSL2 «просто VM»?

Технічно так: легковагова VM з реальним ядром Linux. Практично воно поводиться як інтегрований підсистема з відмінним інтеропом і підтримкою інструментів.

Чи варто використовувати WSL1 для чогось?

Рідко. WSL1 може бути корисним для специфічних шаблонів доступу до файлів на Windows-дисках, але для сучасних Linux-інструментів і контейнерів WSL2 — дефолт.

Де мені тримати свій код?

Усередині Linux-файлової системи, під /home. Використовуйте /mnt/c для обміну з Windows-інструментами, а не для збірок і встановлення залежностей.

Чи можу я запускати Docker без Docker Desktop?

Так, встановивши Docker Engine всередині WSL-дистрибутиву. Це життєздатно, особливо з увімкненим systemd, але вам доведеться самим керувати конфігурацією і оновленнями.

Чому використання диска WSL не зменшується після видалення файлів?

Тому що віртуальний диск виріс під дані, і thin-provisioned диски не завжди автоматично стискаються. Плануйте прибирання і розглядайте export/import як практичний спосіб стискання.

Як зробити Windows доступною до сервісу, що працює в WSL?

Переконайтеся, що сервіс слухає на потрібному інтерфейсі (0.0.0.0 якщо потрібно) і перевірте через ss -lntp. Потім протестуйте підключення з Windows. Не покладайтеся на припущення про пересилання localhost.

Чи потрібен мені systemd у WSL?

Лише якщо ви хочете, щоб Linux-сервіси запускалися і керувалися як звично (Docker Engine, бази даних, фонові демони). Якщо ви лише запускаєте CLI-інструменти і епізодичні процеси, можна обійтися без нього.

Яка найнадійніша стратегія бекапу для WSL?

Використовуйте wsl.exe --export для періодичних архівів, а також тримайте конфігурацію у системі контролю версій (dotfiles, bootstrap-скрипти). Бекапи без практики відновлення — теоретичні.

Чому спостерігачі файлів поводяться дивно?

Часто тому, що файли живуть на drvfs (/mnt/c) або редагуються через межу. Тримайте файли, що спостерігаються, у Linux FS і використовуйте WSL-нативне редагування (VS Code Remote).

Чи можна запускати GUI Linux-додатки?

У Windows 11 з WSLg — так, і це досить зручно. Для професійної роботи з графікою все одно краще мати реальний Linux-десктоп або віддалене середовище, але для девтулів цього цілком вистачає.

Наступні кроки, що реально полегшують життя

Якщо ви хочете найкоротший шлях до «реального dev-середовища» на Windows, зробіть ці речі і припиніть імпровізувати:

1. Перемістіть репозиторії у Linux-файлову систему і ставтеся до /mnt/c як до зони підготовки.
2. Зробіть базову перевірку системи за допомогою завдань вище: перевірте WSL2, монтажі, поведінку пам’яті, DNS і прослуховувані порти.
3. Встановіть ліміти ресурсів WSL, щоб ваше dev-середовище не могло DOSнути ваш десктоп.
4. Оберіть одну стратегію контейнерів (Docker Desktop з WSL-бекендом або Docker всередині дистрибутиву) і стандартизуйте її для команди.
5. Зробіть середовище відновлюваним: експортуйте дистрибутив, коли все налаштовано, і тримайте відтворюваний bootstrap-скрипт, щоб перебудова була плановою, а не катастрофою.

WSL2 — не науковий проєкт. Це інфраструктура. Ставтеся до неї як до інфраструктури — і вона поводитиметься відповідно. Ставтеся до неї як до хобі на вихідних — і воно зламається просто перед понеділком.