Рабочая среда Linux/Ubuntu из под WSL2 в Windows10

Рабочая среда это важно, чем проще и быстрее вы можете развернуть рабочую среду, тем эффективнее будет строится ваша работа.

В первое время, я делал много ошибок работая под Linux потому что привык к MacOS. Все дело в том, что я практически не касался серверных конфигураций на своем компьютере, у меня стоял Valet и он решал 90% всех проблем. И даже сумел настроить его для работы с Битрикс, что для меня уже говорит о многом. Битрикс капризна и тянет за собой устаревшие настройки (на данный момент директива mbstring.func_overload более не требуется для работы Битрикс) несовместимые с современными системами. Строить контейнеры мне не очень удобно, но о контейнерах я еще обязательно напишу.

Мне как программисту хотелось бы как можно реже сталкиваться с настройками сервера, но построить рабочую среду под windows это, скажу я вам, то еще развлечение. Сразу оговорюсь, я категорически не приемлю OpenServer, Denwer и прочие «джентельменские наборы», в том числе и так полюбившийся мною Valet. По историческим причинам и потому, что они решают лишь часть возникающих задач, а если есть необходимость в гибкой настройке сервера, джентельменские наборы ничем не помогут. Я вообще рекомендую отказываться от подобных схем и осваивать настройки *-nix систем и серверов на их основе. Знание того как работает сервер для web программиста является строго обязательным.

Установка подсистемы Windows для Linux

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

Шаг первый и самый простой. Подробнее написано на сайте мелкомягких в официальной документации.

Собственно, включаем поддержку подсистемы:

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

1	dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

PowerShell — должен быть запущен от имени администратора.

Далее нам необходимо обновиться до WSL2.

Как уже говорил, WSL 1-й редакции нам не интересен. А WSL2 может быть установлен только для 64-разрядных систем версии >=2004. Проверьте версию и при необходимости обновитесь.

Перед установкой включаем компонент «Платформа виртуальных машин».

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

1	dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

Далее, скачиваем пакет обновления ядра Linux в WSL2 ссылка взята из официальной документации. Запускаем и дожидаемся окончания установки.

Следующее что необходимо сделать это установить WSL2 в качестве версии по умолчанию:

wsl --set-default-version 2

1	wsl --set-default-version 2

Если wsl --set-default-version выполняется как недопустимая команда, введите wsl --help. Если --set-default-version нет в списке, это указывает на отсутствие поддержки в ОС. Вам нужно выполнить обновление до версии 1903, сборки 18362 или выше.

После выполнения команды может появиться следующее сообщение: WSL 2 requires an update to its kernel component. For information please visit https://aka.ms/wsl2kernel. Это значит, что вам по-прежнему нужно установить пакет обновления MSI для ядра Linux.

Если все прошло успешно, то можно заняться установкой дистрибутива Linux.

Как видите, выбор не так уж и велик. Любителям CentOS придется заплатить за нее пару баксов, а чтобы настроить Kali пришлось повозиться с репозиториями и ключами, с той же проблемой столкнулся и при установке Debian. Интересно, с чего бы это :).

Что касается Ubuntu, то она ведет себя на удивление стабильно и проблем с ней замечено не было. Я установил версию 20.4, пользуюсь ею и очень доволен. Но никто не мешает установить параллельно несколько разных версий, главное не забыть при этом указать ту, которая будет установлена по умолчанию. Дистрибутивы устанавливаются в Windows как отдельные приложения и могут работать параллельно совершенно не мешая друг другу.

Эмулятор консоли для Windows

Еще один важный вопрос который предстоит решить. Использовать стандартную консоль Windows мне не хотелось. Благо, в сети есть немало эмуляторов которые великолепно работают под виндой, сохраняя при этом немало функций стандартной консоли nix-ов.

Я остановился на ConEmu и пользуюсь им для решения повседневных задач: ssh, wsl. Понравился он мне количеством настроек, скоростью работы и, собственно, тем, что по всем признакам не отличим от стандартной консоли Linux.

Во время работы, я пользуюсь встроенным терминалом VSCode, но недавно обнаружилась досадная проблема. Набор расширений Remote (wsl, ssh, containers), разгоняют процессор сервера до 100%, если подключаться к корневой директории. Когда я подключался к папке проекта, VSCode вел себя нормально, но иногда все же начинал кушать ресурсы процессора, о чем я узнавал по свисту кулера (моего не самого слабого компьютера). В связи с этим, пришлось установить VSCode insiders (по совету на StackOverflow), с ним подобных странностей пока не замечено.
В любом случае, дополнительный терминал позволяет мне работать в терминале VSCode только с проектом, а если нужно быстро подключиться к удаленному серверу или другой WSL системе, я пользуюсь ConEmu.

Управление дистрибутивами WSL

Управлять дистрибутивами мне проще через ConEmu, который интерпретирует команды *nix под Win стандарт.

Мы можем установить несколько дистрибутивов. Список всех дистрибутивов получаем командой wsl --list (-l).

Если вы не выбрали дистрибутив по умолчанию, то им будет тот, который вы установили первым. Назначить дистрибутив по умолчанию легко:

wsl -s <DistributionName>, wsl --setdefault <DistributionName>

Войти в конкретный дистрибутив WSL так же просто:

wsl -d <DistributionName>, wsl --distribution <DistributionName>

Интересный момент, что WSL позволяет использовать команды LInux за пределами дистрибутива. Да, мы можем взаимодействовать с файловой системой маздая через терминал, используя привычные команды. Но разработчики пошли еще дальше. Команды можно смешивать.

Подробнее о том как миксовать команды WSL (Linux) и команды PowerShel можно почитать в официальной документации.

Установка PHP7.4 на WSL2

Начнем покорение нашего Эвереста с установки PHP. Я ставлю последнюю версию, у меня нет проектов привязанных к старым версиям, да и под них всегда можно создать отдельную систему на Ubuntu18 или используя любой-другой дистрибутив из доступных.

<span class="token function">sudo</span> <span class="token function">apt</span> <span class="token function">install</span> php-fpm php-mysql

1	<span class="token function">sudo</span> <span class="token function">apt</span> <span class="token function">install</span> php-fpm php-mysql

Будет установлена последняя актуальная версия.

Установка сервера NGINX

Для демонстрации веб-страниц посетителям нашего сайта мы будем использовать современный и эффективный веб-сервер Nginx. Мы будем использовать диспетчер пакетов apt для получения этого программного обеспечения.

Поскольку в этом сеансе мы будем использовать apt впервые, нужно обновить указатель пакетов вашего сервера. После этого вы можете использовать apt install для установки Nginx:

sudo apt update
sudo apt install nginx

1 2	sudo apt update sudo apt install nginx

При получении запроса введите y для подтверждения того, что вы хотите установить nginx. После завершения установки веб-сервер Nginx будет активирован и будет работать на вашем сервере Ubuntu 20.04.

Если у вас включен брандмауэр ufw, как рекомендуется в руководстве по первоначальной настройке сервера, вам нужно разрешить подключение к Nginx. После установки Nginx регистрирует несколько разных профилей приложений UFW. Чтобы проверить, какие из профилей UFW доступны, выполните команду:

sudo ufw app list

1	sudo ufw app list

Output
Available applications:
  Nginx Full
  Nginx HTTP
  Nginx HTTPS
  OpenSSH

Output

Available applications:

Nginx Full

Nginx HTTP

Nginx HTTPS

OpenSSH

Рекомендуется применять самый ограничивающий профиль, который будет разрешать желаемый трафик. Поскольку мы не настроили SSL для своего сервера, нам нужно будет разрешить трафик только на порту 80.

Для этого введем команду Awf — разрешить NGINX использовать протокол HTTP:

sudo ufw allow 'Nginx HTTP'

1	sudo ufw allow 'Nginx HTTP'

По сути, наш сервер уже запущен и работает, введите service nginx status, чтобы убедиться в этом.

Проблемы 80-го порта

Если после установки NGINX сервер работает, но никак не обнаруживается в нашей «сети» то скорее всего Windows уже использует его. Проверить используется ли 80-й порт можно командой:

netstat -tulnp | grep httpd

1	netstat -tulnp \| grep httpd

Как видите он занят. Использовать 80-й порт я не стал, в настройках сервера открыл порт :8080 и спокойно работаю. Если же вы перфекционист и лишние 5 цифр для вас головная боль, то придется освобождать порт. Проблема в том, что использовать его могут очень многие программы. Чаще всего это Skype и системный процесс System с PID 4. Но общий список программ которые занимают 80-й порт внушителен и установив одну из них вам придется каждый раз чистить системные процессы отыскивая их по PID (тем более, если программа не позволяет сменить порт, как было у меня). Что тут скажешь, быть перфекционистом это нелегкий труд в нашем несовершенном мире.

Далее я буду давать установки с указанием порта 8080, но вам никто не мешает поэкспериментировать, заменив порт на 80-й или любой-другой на ваш вкус.

Настройка NGINX

Есть несколько путей по которым можно настраивать сервер NGINX для локальной среды, точнее путей невообразимое множество, есть несколько путей, которыми пользуюсь лично я. Вариант первый, классический: настроить сервер стандартным образом, создавая конфигурационный файл для каждого сайта. Второй способ заключается в том, чтобы перенаправлять сайты при помощи регулярного выражения.

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

Далее я приведу настройку NGINX для работы с PHP. Используя классический способ настройки, вы сможете применять уникальные настройки среды для каждого сайта. Если вы разрабатываете на PHP и на Python или хотите работать в Laravel и Битрикс, то этот способ предпочтительнее.

Для начала перейдите в директорию cd /etc/nginx/sites-available. В ней должен лежать единственный файл default. Этот файл из папки sites-available удалять необязательно. Все файлы которые вы поместите в эту директорию работать не будут до тех пор пока мы не создадим на них символьную ссылку из директории sites-enabled. Но даже когда мы это сделаем, сервер не будет работать с загруженными файлами, пока мы не перезапустим сервер. Но давайте по порядку:

cd /etc/nginx/sites-available
vim my-domain.local

1 2	cd /etc/nginx/sites-available vim my-domain.local

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

Обратите внимание на то, что я прописал путь для фреймворка Laravel, ее точка входа (файл index.php) располагается в директории /public. Для CMS, у которых точка входа находится в корне, вы создавать папку /var/www/my-domain.local/public/ и уже в нее устанавливать ваш WordPress или Bitrix. Так же, в секции php обратите внимание на версию сокета, она может отличаться в вашей установке.

server {
        listen 8080; # порт, прослушивающий nginx
        server_name my-domain.local www.my-domain.local; # доменное имя, относящиеся к текущему виртуальному хосту

        root /var/www/my-domain.local/public/; # каталог в котором лежит проект, путь к точке входа

        index index.php index.html;
        # add_header Access-Control-Allow-Origin *;

        client_max_body_size 100m;

        # serve static files directly
        location ~* \.(jpg|jpeg|gif|css|png|js|ico|html)$ {
                access_log off;
                expires max;
                log_not_found off;
        }

        location / {
                # add_header Access-Control-Allow-Origin *;
                try_files $uri $uri/ /index.php?$query_string;
        }

        location ~* \.php$ {
                try_files $uri = 404;
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass unix:/var/run/php/php7.4-fpm.sock; # подключаем сокет php-fpm
                fastcgi_index index.php;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                include fastcgi_params;
    }

 location ~ /\.ht {
                deny all;
        }
}

server {

listen 8080; # порт, прослушивающий nginx

server_name my-domain.local www.my-domain.local; # доменное имя, относящиеся к текущему виртуальному хосту

root /var/www/my-domain.local/public/; # каталог в котором лежит проект, путь к точке входа

index index.php index.html;

# add_header Access-Control-Allow-Origin *;

client_max_body_size 100m;

# serve static files directly

location ~* \.(jpg|jpeg|gif|css|png|js|ico|html)$ {

access_log off;

expires max;

log_not_found off;

}

location / {

# add_header Access-Control-Allow-Origin *;

try_files $uri $uri/ /index.php?$query_string;

}

location ~* \.php$ {

try_files $uri = 404;

fastcgi_split_path_info ^(.+\.php)(/.+)$;

fastcgi_pass unix:/var/run/php/php7.4-fpm.sock; # подключаем сокет php-fpm

fastcgi_index index.php;

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

include fastcgi_params;

}

location ~ /\.ht {

deny all;

}

Конфигурируем NGINX при помощи регулярный выражений

Второй способ идеален для тех, кто разрабатывает много проектов на одной системе и не хочет заморачиваться с настройками для каждого сайта. Если вы посмотрите внимательно на этот конфиг, то увидите, что в сущности это тот же самый конфигурационный файл, но вместо домена мы используем переменную. Теперь наш сервер NGINX отслеживает запросы и если он получает запрос на домен для которого создана директория на сервере (в данном случае идентичная имени домена), то он отдает нам содержимое сайта. Остальные запросы будут проигнорированы.

server {
listen 80;
# регулярное выражение для работы с несколькими проектами 
    server_name ~^(www\.)?(?<domain>.+)$;
    root C:/nginx/sites/$domain;
# указываем точку входа: index
   try_files $uri $uri/ /index.php?$query_string;
   index index.html index.htm index.php;
# Подключаем обработку php
   location ~ \.php$ {
      fastcgi_pass 127.0.0.1:9000;
      fastcgi_index index.php;
      include fastcgi_params;
      fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
      fastcgi_param SERVER_NAME $domain;
      fastcgi_param QUERY_STRING $query_string;
   }
   location ~ /\.ht {
   deny all;
   }
}

server {

listen 80;

# регулярное выражение для работы с несколькими проектами

server_name ~^(www\.)?(?<domain>.+)$;

root C:/nginx/sites/$domain;

# указываем точку входа: index

try_files $uri $uri/ /index.php?$query_string;

index index.html index.htm index.php;

# Подключаем обработку php

location ~ \.php$ {

fastcgi_pass 127.0.0.1:9000;

fastcgi_index index.php;

include fastcgi_params;

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

fastcgi_param SERVER_NAME $domain;

fastcgi_param QUERY_STRING $query_string;

}

location ~ /\.ht {

deny all;

}

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

Настройка файла Hosts в Windows

Сейчас мы настроили локальный сервер, но наш компьютер пока ничего не знает о его существовании. В сети Интернет за указание адресов серверов отвечают серверы DNS, нам же придется прописывать пути вручную (или один путь, в зависимости от выбранных установок).

После добавления всех настроек, настало время проверить работает ли сервер, указав в браузере http://localhost.

В браузере вы должны увидеть приветственное сообщение NGINX.

Проблемы выбора домена для внутренней сети

Мое чутье подсказывало мне, что лучшим выбором будет домен *.dev сервер ведь для разработки. Но чутье меня обмануло. Если вы попытаетесь настроить Hosts для этого домена, то ничего у вас, скорее всего, не заработает. Связано это с тем, что доменная зона .dev зарегистрирована Google. Браузер Hrome, похоже об этом что-то знает, так как именно с браузерами на движке Hrumium возникли основные проблемы, а точнее, ни один из сервисов не подключился. Как свидетельствует StackOverflou, проблемы с доступностью .dev начались задолго до его официальной регистрации.

Я уверен, что и у этой проблемы есть решение и можно переопределить домены .dev на работу в localhost, но зачем? Я просто настроил доменную зону .local.

Установка сервера MySQL

Мы запустили веб-сервер, и теперь нам нужно установить СУБД, которая может хранить данные вашего сайта и управлять ими. MySQL — популярная СУБД, используемая в средах PHP.

Используйте apt для получения и установки этого программного обеспечения:

Подключение VSCode к WSL

Для работы в файловой системе нашего WSL контейнера нужен будет специальный плагин Visual Studio Code Remote.

Подключаемся через нижнюю панель Remote (синяя кнопка в левом нижнем углу), по клику на нее открывается панель выбора способа удаленного подключения. Выбираем WSL.

Автоматически Remote загрузит нам директорию пользователя Ubuntu. Жмем «Open folder» в правом боксе, указав косую черту в списке открывшихся каталогов, попадем в корень диска.

Выбираем директорию нашего проекта, жмем «Ок» и можем работать с файлами.

Вывод

Мы создали полноценную рабочую среду, настроили сервер NGINX, PHP и MySQL и все это в полноценной Linux работающей на WSL!

А вместе с этим, завершились и мои мучения с настройкой WSL. Могу с уверенностью заявить, что до появления WSL2 он не работал, от слова совсем. Мы могли скачать какие-то простенькие консольные утилитки, но о том, чтобы поднять полноценный сервер для разработки не было и речи. Выход WSL2 все изменил. Я так спешил установить себе оболочку Linux, что даже согласился на установку бетты десятки и… Ждал еще несколько месяцев, пока мелкомягкие доведут все до ума.

Но в итоге, свершилось! Что ж, надеюсь статья была хоть кому-то полезна. Я потратил на нее довольно много времени и буду рад, если вы поделитесь своим мнением в комментариях. Мне правда интересно, использует ли кто-то еще WSL для работы или Docker окончательно поглотил мир.