RISH выходит на новый уровень (виртуализация)

Давайте разберем плюсы и минусы каждого подхода.

Это традиционный подход, который часто выбирают начинающие разработчики. Он отличается простотой старта — достаточно установить готовый пакет вроде OSPanel, XAMPP, MAMP или Denwer, и всё “заработает из коробки”.

На этом в принципе все преимущества и кончаются. Дальше начинаются проблемы о которых почему-то не принято упоминать при установке таких программ.

Среда не совпадает с хостингом. Подавляющее большинство хостингов — Linux. На Windows иная модель прав, иные пути (\ vs /), в Windows регистрозависимость файловой системы отсутствует, тогда как в Linux имена файлов чувствительны к регистру, иначе работают симлинки, маски и inotify-события (watchers). Отсюда в работе сайта появляется «мистика»: на Windows всё ок, а на сервере не работает.

Переводы строк в файлах (CRLF vs LF). На Windows каждая строка заканчивается CRLF, а shell и линуксовые утилиты на сервере ожидают LF. Это может приводить к странным последствиям.

Модули/библиотеки. Версии OpenSSL/ICU/libzip, PHP-расширения и модули Apache/Nginx на Windows отличаются — баги и несовместимости превращают разработку в кошмар.

На Windows нет POSIX-прав, а в Linux проекту важны владельцы user:group, setfacl и т.п. На локалке всё “едет” из-за отсутствия тех же ограничений. В результате программы работают не так как ожидается. А некоторые вещи вообще невозможно отладить ввиду отсутствия некоторых параметров. Например, в Linux нет “даты создания” (creation time) файла, а в Windows “creation time” всегда есть. Таких тонкостей множество и все они копятся, чтобы потом как снежный ком накрыть с головой. А главное — ты не понимаешь этого, пока не столкнешься.

Конфликты портов. 80/443/3306/6379 могут быть заняты (Skype/мессенджеры/IIS/«что-то от ОС»). Начинаются пляски с нестандартными портами → ломаешь себе привычный стек.

Ненамеренная публикация сервисов. Локальный MySQL/Redis/Elasticsearch может слушать 0.0.0.0 и внезапно стать доступным из LAN/VPN. Это риск и головная боль для фаервола.

Вмешательство системного ПО. Антивирусы/файерволы/прокси/VPN перехватывают трафик и файловые операции — в результате ты плохо понимаешь, что в реальности происходит в системе.

По итогу я даже новичку не советую связываться с таким вариантом. Лучше любой другой вариант.

Сейчас как-то модно стало на все вопросы отвечать одним словом — докер, даже не понимая что это и как работает.

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

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

На Linux это ещё более-менее нативно, но если ваш хост — Windows или macOS, то Docker фактически запускает скрытую виртуальную машину Linux внутри себя. Вы думаете, что работаете с контейнером, но на деле вы работаете через прослойку — внутри мини-Linux, которую Docker Desktop создал специально для контейнеров.

И ещё важный момент: Docker активно использует открытые порты. Каждый контейнер, который вы “пробрасываете” наружу (-p 8080:80), реально открывает порт на вашем основном компьютере. Если у вас стоит антивирус, VPN или корпоративный фаервол, возможны конфликты, блокировки, ложные срабатывания. А если вы работаете из-под ноутбука, подключенного к публичной сети, то теоретически любой сервис из контейнера может оказаться доступен снаружи, если неправильно настроить сети.

Кроме того, Docker не учит работать с реальными серверами. В контейнере нет systemd, нет полноценного cron, логирование работает иначе, а многие конфигурации (например, Apache или MariaDB) упрощены или адаптированы под контейнерную среду.

То есть именно те самые основные сервисы с которыми имеют дело веб-разработчики либо не работают в контейнере, либо работают иначе. Я бы не назвал это легким способом отладки.

В результате проект “в докере” часто не переносится на реальный VPS один в один — приходится переписывать конфиги под нормальный Linux.

И наконец — Docker добавляет слой абстракции, который нужно понимать, иначе могут появляться неожиданные сложности. Чтобы просто “запустить сайт”, нужно:

• написать Dockerfile,
• собрать образ,
• написать docker-compose.yml,
• пробросить порты,
• подключить тома,

и не забыть всё это корректно удалить потом.

Нельзя просто "зайти в систему" как в обычный Linux. Порт-маппинг (-p 8080:80) — не то же самое, что реальный сетевой интерфейс в ВМ. Контейнеры изначально временные, их файловая система часто живёт до перезапуска и приходится прибегать к монтированию volume, чтобы избежать стирания данных.

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

Казалось бы — идеальный вариант. Точно такой же сервер, как и для сайта. Что может пойти не так?

Дьявол, как всегда кроется в мелочах.

Главная ловушка для разработчиков — привычка подключать Xdebug удалённо. При удалённой отладке Xdebug должен “открыть канал” (порт 9003 или другой), по которому ваша IDE подключается к серверу. И если этот порт открыт наружу — он становится потенциальной дырой безопасности. Любой сканер в сети может найти открытый порт Xdebug и вызвать его вручную, получив доступ к информации о вашем коде, путях и переменных. Xdebug на сервере в интернете — это всегда удобная лазейка для взлома.

К тому же обмен файлами между удаленным сервером и вашим компьютером — это всегда очень медленно. Особенно это разражает в процессе разработки.

Ну и последний аргумент — такой сервер стоит денег. И стоимость этого сервера за год составляет примерно стоимость одного мини ПК, который можно использовать в своей локальной сети для разработки.

Тогда зачем платить больше?

Это золотая середина между удобством и простотой работы для веб-разработчика. Можно создать виртуальную машину в KVM, VirtualBox, VMware или UTM, установить AlmaLinux, Rocky или RHEL и настроить сервер так, как на продакшене. Это не требует никаких дополнительных денег и особых познаний.

Изначально RISH создавался в расчете именно на такой сценарий использования. Это очень удобный и простой способ как для новичков, так и для опытных пользователей. И я до сих пор рекомендую его как основной способ для веб-разработки. Он с точностью воспроизводит среду на вашем хостинге и позволяет легко переносить сайт с продакшена на локальную машину.

Правда есть и несколько минусов.

Первое — для создания виртуальной машины требуется определенное количество ресурсов. Если вы работаете с браузером, IDE и еще одновременно запустите виртуальную машину — нужно не менее 16 гигабайт и то это не будет производительным решением. Если захочется запустить еще одну машину одновременно — все это будет отжирать ресурсы у основной машины. И здесь все зависит от ее производительности.

Второе — сама система виртуализации может вступать в конфликт с основной системой. Например в Windows, если вы установите WSL2 — он вступит в конфликт с виртуальной машиной VMWare и ей придется отключить аппаратную виртуализацию, поскольку WSL2 сам по сути является виртуальной машиной. Это приведет к деградации производительности.

На Mac все работает более предсказуемо и надежно, но виртуализация архитектуры, отличной от родной, например на Apple Silicon x86_64 работает настолько медленно, что практически неприменима. И это приводит к выводу о том, что неплохо бы рассмотреть вариант своего сервера.

С одной стороны это идеальный вариант, но с другой стороны при словах «свой сервер» воображение рисует что-то дорогое, шумное и сложное.

К счастью времена сейчас изменились и если не требовать от сервера слишком многого, то оказывается есть очень приличные варианты.

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

Сейчас на Алиэкспресс и Озоне появилось множество мини ПК, которые обеспечивают очень неплохую производительность при пассивном охлаждении — то есть в абсолютной тишине! А цены начинаются от 6000 руб! (на момент написания статьи).

Для экспериментов я приобрел 4 разных устройства и на личном опыте проверил их возможность использования в разработке. Главное их преимущество — они абсолютно бесшумные! Второе преимущество — они реально маленькие — их размер сравним с размером роутера!

Приобрести подобные можно на Алиэкспресс и на Озоне за разумную стоимость от 6 000 до 11 000 руб (за 11 000 можно взять современный процессор N150 и 16 гигабайт памяти с диском на 512 Гигабайт например тут). Вообще какие мини ПК можно покупать и как выбрать свой вариант это отдельный вопрос, который требует написания еще одной статьи. Не буду сейчас подробно на этом останавливаться.

Свой собственный сервер открывает широкие возможности в веб-разработке и вообще жизни продвинутого айтишника.

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

Единственное чего не хватало — скрипта для превращения этого сервера в систему виртуализации. Чтобы можно было использовать главное преимущество виртуальных машин — возможность отката к предыдущему состоянию. Ну и конечно возможность работы с разными системами и конфигурациями.

С идеей расширения RISH для использования в качестве системы виртуализации я ношусь уже давно (наверное года два). В качестве основы еще очень давно решил использовать штатную систему KVM ОС семейства RHEL — она потребляет мало ресурсов и очень проста в управлении. Можно было конечно использовать Proxmox, но там реально огромный комбайн. Он не предназначен для домашнего использования. Я проверил как работает KVM в командной строке и с одной стороны это действительно работает, но с другой стороны это мучительно тяжело. Такое не то что новичку — самому себе не удобно пользоваться.

С одной стороны хотелось сохранить основной подход RISH в качестве интерфейса, но с другой стороны я понимал, что объем кода становится какой-то сильно большой. Да и не было это все в приоритете. Поэтому идея очень долго висела в воздухе, мини ПК пылились без дела и весь проект стоял на паузе.

Так продолжалось до тех пор, пока случайно, в процессе общения с chatGPT не выяснилась одна очень интересная деталь — штатная система управления сервером AlmaLinux (и любыми RHEL совместимыми) Cockpit умеет управлять виртуальными машинами, которые развернуты с помощью KVM!

Прекрасно! Осталось дело за малым — написать скрипт установки необходимых плагинов, проверки наличия нужных пользователей и затем описать весь процесс управления KVM в руководстве! А само управление виртуальными машинами и обмена файлами можно возложить на cockpit с установленными нужными плагинами.

Прекрасная идея, которая казалось займет пару дней растянулась на две недели.

В процессе тестирования выяснилось, что не все компьютеры пригодны для установки AlmaLinux 10. Пришлось исследовать этот вопрос. Было найдено решение (благодаря опять же разработчикам Alma Linux) и подробно описано в статье.

Затем делалась куча скриншотов, которые демонстрируют процесс установки ОС и все это тщательно документировалось в руководстве.

Но теперь процесс завершен и я счастлив представить вам возможность использования собственного простого, нетребовательного, производительного и надежного решения виртуализации RISH KVM!

Подробно описанный процесс установки и сам скрипт установки есть по ссылке:

Скрипт устанавливает Cockpit, систему виртуализации KVM, нужные плагины для работы с ней и создает еще одного пользователя для авторизации в ней, если его еще нет.

Собственно основную ценность представляет собой именно руководство, которое описывает как правильно работать и как разворачивать виртуальные машины.

Если будут вопросы или заметите какие-то баги – пишите в наш дружелюбный телеграм чат и подписывайтесь на телеграм канал новостей RISH.