Почему я выбрал WSL вместо полноценного Linux
Основная часть моей разработки завязана на Linux, но один из самых удобных вариантов для меня — использование WSL (Windows Subsystem for Linux), а не переход на полноценную 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. И знаете, я долго думал: "Почему именно скачивать?" Оказалось, это самый простой и удобный вариант, потому что нам при разворачивании ubuntu не придется ждать время скачивания образа, и это позволит нам даже автоматизировать процесс разворачивания проектов.
Скачать можно по ссылке с официального сайта 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.
Также ниже приведены команды для скачивания образов на ПК.
Чтобы открыть PowerShell, введите в любой папке pwsh, нажмите Enter — откроется терминал для выполнения команд.
Установка и настройка Ubuntu в WSL
Скачивание образа 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Создание WSL-окружения
Импортируем скачанный образ в WSL:wsl --import Ubuntu-24.04 .\Ubuntu-24.04 .\ubuntu-noble-wsl-amd64-24.04lts.rootfs.tar.gzЗапуск Ubuntu
После выполнения команды вы можете запустить окружение с помощью:wsl -d Ubuntu-24.04Терминал отобразит приветственное сообщение Ubuntu.
Создание пользователя
Для удобной работы рекомендуется создать отдельного пользователя. Для этого:Откройте проводник и перейдите в корневую папку 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Следуйте инструкциям на экране.
После настройки перезапустите 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 Studio 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 "из коробки" или изолированные контейнеры?
docker-install.sh
# Обновление списка пакетов
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
