Почему я выбрал WSL вместо полноценного Linux

В этой статье я хочу поделиться своим опытом настройки WSL для комфортной разработки, а также размышлениями о том, почему такой подход оказался для меня оптимальным. На это влияет несколько факторов.

Во-первых, иногда требуется специфический софт, который доступен только под Windows. Да, в других ОС могут быть аналоги, но зачастую они менее удобны или требуют дополнительной настройки.

Во-вторых, для разных проектов нужно разное окружение. WSL позволяет легко изолировать среды разработки, настраивая их под конкретные задачи или группы проектов. Это гораздо удобнее, чем держать несколько физических машин или постоянно переустанавливать систему.

Наконец, есть и субъективный фактор — привычка. Я с самого начала работал с Windows, и, несмотря на все преимущества Linux, полностью перестроить рабочий процесс оказалось сложно. WSL в этом плане — идеальный компромисс: Linux-окружение под рукой, но без необходимости отказываться от удобств Windows.

Преимущества WSL для разработки

В первую очередь — разработчикам, которые постоянно осваивают новые технологии, знакомо чувство, когда нужно вернуться к старому проекту, а там — специфическая версия языка, странные зависимости или забытые настройки? Можно просто развернуть нужное окружение за пару минут, не ломая голову над тем, "как же это у меня работало в прошлый раз".

Ещё один сценарий — когда есть хобби-проекты, совсем не связанные с работой. Например, вы пишете на Python для аналитики, но вдруг решили попробовать Rust для embedded-разработки. Настраивать всё в одной среде — это риск получить "салат" из зависимостей, который потом придётся разгребать. Гораздо удобнее иметь две изолированные среды: одну — для рабочих задач, другую — для экспериментов.

Про боль Windows

Работая с Windows, многие сталкивались с ситуацией, когда проще переустановить систему, чем чинить сломанное. Но после этого — прощайте, все настройки, тулзы и скрипты! Если вы работаете годами, восстановление окружения может занять не день и даже не неделю, а кучу нервов и "танцев с бубном". WSL здесь — как страховка: даже если Windows "умрёт", ваши Linux-среды останутся целы.

Для кого WSL не подойдёт?

Опытные админы и DevOps, у которых под рукой кластеры, облака и пара домашних серверов "на подхвате", наверняка лишь улыбнутся. Но новичкам, которые только погружаются в разработку, такой подход может сэкономить кучу времени и избавить от типичных ошибок.

Этот материал — не истина в последней инстанции, а мой субъективный опыт, собранный из проб, ошибок и статей коллег. Если у вас есть более эффективный способ, буду рад почитать в комментариях! Ведь идеального workflow не существует, есть только тот, который работает лично для вас.

Сравнение подходов: физические машины, контейнеры, виртуальные машины

Давайте для начала сравним несколько подходов и решений, которые я перепробовал и рассматривал как возможные варианты.

Первый и самый идеальный вариант — конечно же, иметь несколько физических машин под рукой. Подключаться к ним с основной рабочей станции, построить домашнюю сеть с развертыванием сервисов и удаленным управлением каждой машиной. Такой подход действительно позволяет не бояться поломок и быстро перестраиваться при необходимости.

Но давайте смотреть правде в глаза: многие из нас не живут на одном месте, часто путешествуют или работают из разных локаций. Да и в быту есть нюансы: жена, дети, домашние животные могут случайно повредить это "добро". А еще — куча проводов, сборщиков пыли, которые не особо радуют вторую половину, особенно если вы живете не в стометровой квартире.

Разместить такое оборудование удобно и безопасно получается далеко не у всех. Добавьте сюда косые взгляды домочадцев из-за вечно пылящихся жужжащих коробок и проводов, вечный вопрос: "И долго еще это будет тут стоять?", и энтузиазма заметно поубавится.

Проблемы контейнеризации (Docker и аналоги)

Так давайте подумаем, как можно решить эту проблему. Один из вариантов — использовать контейнеризацию, например Docker или аналогичные решения. Мы, как разработчики, можем настроить такие контейнеры для развертывания изолированных сред разработки.

Однако у этого подхода есть ряд существенных недостатков, особенно если мы работаем под Windows или macOS. Когда нам нужно примонтировать директорию с проектом и работать в обособленной среде, могут возникнуть сложности.

Главная проблема: при работе с большим количеством файлов (что совсем не редкость в популярных фреймворках или CMS) мы сталкиваемся с необходимостью конвертации файлов между разными файловыми системами. Это может существенно замедлить как запуск проекта, так и саму работу с ним, что негативно сказывается на скорости разработки.

Еще один нюанс — дополнительные сложности с запуском программ, использующих графический интерфейс. Яркий пример — попытка запуска Android-эмулятора через Android Studio в такой среде. Полноценно работать не получается, а значит, мы теряем часть необходимого функционала. 

Виртуальные машины (VirtualBox) и их ограничения

Еще одной альтернативой могли бы стать виртуальные машины — взять хотя бы VirtualBox. Он же бесплатный для домашнего использования, позволяет развернуть виртуалку, которая ничем не будет отличаться от реального Linux. И, если честно, этот способ мог бы быть почти идеальным вариантом, особенно если использовать в связке Vagrant: написал конфиг один раз и потом хоть на старом ноутбуке, хоть на новом компьютере разворачиваешь идентичное окружение за пару команд.

Но вот тут есть один момент, который лично для меня стал стоп-фактором. В VirtualBox нет нормальной поддержки GPU-ускорения. А для меня это критично, потому что я занимаюсь машинным обучением и постоянно использую видеокарту для тестирования моделей. Вот так вот: вроде бы отличное решение, но из-за этой одной особенности пришлось искать другие варианты. Хотя, если вам интересно, я могу потом подробнее рассказать про этот подход. Может быть, для ваших задач он как раз подойдет идеально.

Почему WSL — мой оптимальный выбор (и его недостатки)

Вот мы и подошли к варианту, который лично для меня оказался самым удобным, — WSL. Честно говоря, он реально выручает в большинстве ситуаций. С ним можно легко создавать окружения, приостанавливать их когда нужно и без проблем переносить между компьютерами. Особенно радует, как хорошо Windows и Linux работают вместе: файлы доступны с обеих сторон, что очень экономит время.

Но не всё так гладко, конечно. Во-первых, это всё же не совсем настоящий Linux, хотя и очень близко. Во-вторых, с USB-устройствами бывают проблемы: например, когда я работал с Nvidia Jetson, пришлось изрядно повозиться с настройками. Да и с подключением отдельных дисков иногда нужно "потанцевать с бубном".

Настройка WSL: загрузка и установка образа Ubuntu

Теперь о настройке. Начинается всё с загрузки образа Linux. И знаете, я долго думал: "Почему именно скачивать?" Оказалось, это самый простой и удобный вариант, потому что нам при разворачивании unvuntu не придется ждать время скачивания образа, и это позволит нам даже автоматизировать процесс разворачивания проектов. 

Скачать можно по ссылке с официального сайта ubuntu

https://cloud-images.ubuntu.com/wsl/

Например, можно зайти по адресу
https://cloud-images.ubuntu.com/wsl/releases/24.04/20240423/ и скачать ubuntu-noble-wsl-amd64-wsl.rootfs.tar.gz   файл обрати внимания на архитектуру сейчас бурно развеваются решения на мобильных процессорах и тогда вам нужно будет скачать версия для arm, так же ниже приведен ряд команд для скачивания образов на свой пк, можно открыть PowerShel введя в любой папки pwsh и нажать Enter и откроется терминал в котором можно выполнить команды 

Установка и настройка Ubuntu в WSL

1. Скачивание образа Ubuntu
   Выполните команду для загрузки образа:

   Invoke-WebRequest https://cloud-images.ubuntu.com/wsl/releases/noble/20240423/ubuntu-noble-wsl-amd64-24.04lts.rootfs.tar.gz -OutFile .\ubuntu-noble-wsl-amd64-24.04lts.rootfs.tar.gz

2. Создание WSL-окружения
   Импортируем скачанный образ в WSL:

   wsl --import Ubuntu-24.04 .\Ubuntu-24.04 .\ubuntu-noble-wsl-amd64-24.04lts.rootfs.tar.gz
   

3. Запуск Ubuntu
   После выполнения команды вы можете запустить окружение с помощью:

   wsl -d Ubuntu-24.04

   Терминал отобразит приветственное сообщение Ubuntu.

   

4. Создание пользователя
   Для удобной работы рекомендуется создать отдельного пользователя. Для этого:

   • Откройте проводник и перейдите в корневую папку WSL (она появится в разделе Linux).

   • Создайте файл create_wsl_user.sh и вставьте в него

   

   create_wsl_user.sh

   #!/bin/bash
   
   # Проверка прав root/sudo
   if [ "$(id -u)" -ne 0 ]; then
       echo "Ошибка: Скрипт требует root-прав. Запустите через sudo." >&2
       exit 1
   fi
   
   # Запрос имени пользователя
   read -p "Введите имя нового пользователя: " username
   
   # Проверка существования пользователя
   if id "$username" &>/dev/null; then
       echo "Ошибка: Пользователь '$username' уже существует." >&2
       exit 1
   fi
   
   # Запрос пароля (скрытый ввод)
   read -s -p "Введите пароль для '$username': " password
   echo
   
   # Создание пользователя
   useradd -m -s /bin/bash "$username" || {
       echo "Ошибка при создании пользователя '$username'." >&2
       exit 1
   }
   
   # Установка пароля
   echo "$username:$password" | chpasswd || {
       echo "Ошибка при установке пароля." >&2
       exit 1
   }
   
   # Добавление пользователя в группу sudo (Ubuntu/Debian)
   if usermod -aG sudo "$username"; then
       echo "Пользователь '$username' добавлен в группу 'sudo'."
   else
       echo "Ошибка: не удалось добавить пользователя в группу 'sudo'." >&2
       exit 1
   fi
   
   # Предложение сделать пользователя по умолчанию в WSL
   read -p "Сделать '$username' пользователем по умолчанию в WSL? (y/N): " set_default
   if [[ "$set_default" =~ [yY] ]]; then
       # Установка пользователя по умолчанию для WSL
       echo "[user]" > /etc/wsl.conf
       echo "default=$username" >> /etc/wsl.conf
       echo "Пользователь '$username' установлен как default в WSL."
       echo "Перезапустите WSL для применения изменений:"
       echo "  wsl --shutdown"
       echo "  wsl"
   fi
   
   # Итоговый вывод
   echo "--------------------------------------------------"
   echo "Пользователь '$username' успешно создан:"
   id "$username"
   echo "Группы: $(groups "$username")"
   if [[ "$set_default" =~ [yY] ]]; then
       echo "Статус: установлен как default в WSL."
   else
       echo "Статус: обычный пользователь (не default)."
   fi

   Затем выполните в терминале WSL:

   

   cd ~
   chmod +x ./create_wsl_user.sh
   ./create_wsl_user.sh

   Следуйте инструкциям на экране.

1. Перезапуск WSL
   После настройки перезапустите WSL, и окружение будет готово к работе.

Установка и настройка Node.js через NVM для frontend разработки

Для JavaScript-разработки критично иметь возможность быстро переключать версии Node.js. Лучший способ — NVM

1. Установка NVM в WSL

Актуальную версию можно посмотреть на сайте репозитория
https://github.com/nvm-sh/nvm

sudo apt update
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash

После установки перезагрузите терминал (source ~/.bashrc).

2. Работа с версиями Node.js

• Установка LTS-версии:

  nvm install --lts

• Переключение между версиями:

  nvm install 18.
  nvm use 18.

• Установка версии по умолчанию:

  nvm alias default 18

3. Создания и запуск проекта

Я считаю что уже установлен visual studeo code если нет можно установить с официального сайта https://code.visualstudio.com/download

• Создания проекта на vue с vite и следуем инструкции

  npm create vue@latest

• Запуск проекта в ide vs code

  cd ./demo
  code .

• Установка зависимостей через терминал и приступаем к работе

  npm istall 
  npm run dev

4. Преимущества NVM

• ✅ Нет конфликтов — каждая версия Node.js изолирована.

• ✅ Быстрое переключение — nvm use 16 / nvm use 20 без переустановки.

Настройка Docker для backend-разработки на PHP

Я долго выбирал между чистым WSL и Docker-контейнерами, и для серьёзных проектов теперь предпочитаю Docker. Контейнеры дают полную изоляцию окружения, позволяют одновременно работать с разными версиями софта и гарантируют идентичность среды на всех машинах. При этом файлы проекта остаются доступными, а само окружение всегда остаётся чистым. Главный плюс Docker — возможность создать именованный контейнер, который сохраняет все настройки между сеансами работы. Это особенно удобно при поддержке нескольких проектов с разными требованиями. А какой подход предпочитаете вы — WSL "из коробки" или изолированные контейнеры?

# Обновление списка пакетов
sudo apt-get update

# Обновление установленных пакетов (без запроса подтверждения)
sudo apt-get upgrade -y

# Установка необходимых зависимостей:
# - ca-certificates: SSL сертификаты
# - curl: утилита для загрузки файлов
# - gnupg: менеджер ключей
# - lsb-release: информация о версии ОС
# - mkcert: создание локальных SSL сертификатов
# - apache-utils: утилиты Apache (включая htpasswd)
sudo apt-get install -y ca-certificates curl gnupg lsb-release mkcert apache-utils

# Создание директории для ключей APT с правильными правами
sudo mkdir -m 0755 -p /etc/apt/keyrings

# Загрузка и сохранение GPG-ключа Docker
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor --output /etc/apt/keyrings/docker.gpg

# Установка прав на чтение для всех пользователей
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Добавление репозитория Docker в sources.list.d
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Обновление списка пакетов после добавления репозитория Docker
sudo apt-get update

# Установка Docker и сопутствующих компонентов:
# - docker-ce: Docker Community Edition
# - docker-ce-cli: CLI для Docker CE
# - containerd.io: контейнерная среда выполнения
# - docker-buildx-plugin: расширение для сборки образов
# - docker-compose-plugin: плагин для Docker Compose
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Проверка работы Docker запуском тестового контейнера
sudo docker run hello-world

Создайте файл docker-install.sh в папки с именем пользователя которого мы совздале ранее в моем случае user1 так же можно это сделать через проводник windows

• После этого устанавливаем Docker, введя пароль администратора, который мы задали ранее. Не забудьте предварительно дать права на выполнение установочному скрипту, чтобы система могла установить все необходимые зависимости.

  chmod +x docker-install.sh
  sudo ./docker-install.sh

После вывполенения мы увидим вот такой результат хоть в конце мы видим ошибку это нормально сейчас я покажу как это исправить

• "Далее, после открытия окна редактора, нам нужно: 1. Несколько раз нажать Enter, чтобы переместиться на следующую строку. 2. Кликнуть правой кнопкой мыши для вставки (или подтверждения). После этого настройки должны выглядеть, как показано на экране. Затем нажимаем: - Ctrl + X (для выхода), - Y (чтобы сохранить изменения), - Enter (для подтверждения).

  sudo nano /etc/wsl.conf

• Можно просто попробовать выйти и зайти заново но лучше перезагрузить wsl в powershell

   wsl --shutdown

После этого можно запустить образ

В следующей статье вас ждет:

• Работа с Git в WSL2 - особенности и лучшие практики

• Упрощенное управление Docker-контейнерами через WSL

• Развертывание PHP-окружения в Docker

• Запуск Android Studio и эмулятора в WSL