Ошибка для гарантированной работы 1с битрикс24 необходимо его устанавливать на веб окружении битрикс

Обновлено: 08.07.2024

Собственно, если мы обратимся на сайт вендора, то там увидим что:

«1С-Битрикс»: Веб-окружение» — Linux служит для быстрой и простой установки всего ПО, необходимого для работы продуктов и решений «1С-Битрикс» на Linux-платформах CentOS 6 (i386, x86_64) и CentOS 7 (x86_64). Устанавливать необходимо на «чистый» CentOS, без уже установленного веб-сервера.

По сути, данный комплекс ПО содержит в себе настроенный LAMP, консольную панель управления сервером, плюс дополнительные, необходимые для работы некоторых модулей 1C-Bitrix, пакеты. Весь софт настроен с учётом особенностей 1C-Bitrix, а именно:

установлены необходимые расширения (gd, zip, socket, mbstring)
включена поддержка short-тегов
заданы необходимые значения для параметров memory_limit, max_input_vars, safe mode, opcache.validate_timestamps, opcache.revalidate_freq, mbstring.func_overload, default_charset, display_errors и др.
установлен одинаковой часовой пояс для БД, php и на самом сервере
и др.

Итак, у нас было 2 app сервера (назовём их app01 и app01), 2 db сервера (db01, db02), 1 сервер под кэширование (cache01, ну вы поняли), точнее была идея реализовать структуру кластера подобным образом. Под этот план были получены 5 серверов, с установленными на них последними версиями centos7 (к сожалению, debian, ubuntu, fedora, rhel и др. не подходят), кроме os на серверы больше ничего не устанавливалось.

В дальнейшем работа пошла по следующему плану:

1. Установить bitrixenv

Установка не подразумевает сверхъестественных знаний linux или администрирования. Заходим на каждый сервер через ssh и выполняем такие команды:

Ставить bitrixenv необходимо на все серверы, которые планируется использовать в кластере. Даже если сервер будет работать только как инстанс memcached, bitrixenv необходим, т.к. позволяет управлять всем кластером из основного сервера.

2. Настроить bitrixenv

Т.к. использовать весь этот зоопарк мы будем как кластер, то производить настройку серверов можно через меню окружения на app01. Для этого заходим на сервер через ssh, и запускаем файл /root/menu.sh. При первом запуске необходимо задать пароль для пользователя bitrix (аналогичную операцию необходимо провести на всех серверах, где планируется запуск сайта):

Собственно, это тот пользователь, под которым будет работать приложение. После этого мы видим экран, предлагающий создать пул серверов:

Тут нам необходимо выбрать первый пункт меню. В процессе создания окружение запросит имя текущего сервера, тут то мы и указываем app01:

После того, как пул будет создан, нас возвращают на первый экран окружения, но на этот раз там доступно куда больше пунктов:

В общем окружение уже готово и можно им пользоваться. Если кластер нам не нужен, то на этом можно было бы и заканчивать, но мы пойдём дальше.

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

Настройку ролей серверов пока отложим на следующий шаг.

3. Перенос проекта

Т.к. наше приложение изначально работает на одном сервере, то модуль масштабирования и управления кластером отключены, база не реплицирована. Сам перенос ничего сверхъестественного из себя не представляет — упаковали папки bitrix и upload, сняли дамп БД.

После того, как архивы и дампы готовы, заходим на app01, и тянем через git код проекта в дефолтную папку сайта в bitrixenv — /home/bitrix/www, скачиваем wget-ом или curl-ом архивы и дамп БД, распаковываем архивы и заливаем дамп в БД на app01, переносим записи cron.

Если ваше приложение использует дополнительный софт, то самое время его установить и настроить. В нашем случае были установлены и настроены supervisord и RabbitMQ, т.к. приложение работало с использованием очередей.

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

4. Включение кластерного режима работы

После того, как приложение было перенесено на app01, и мы проверили корректность его работы, пришла пора заняться самым интересным — масштабированием. Для начала необходимо установить модули scale и cluster в админ-панели 1C-Bitrix. Во время установки ничего особо делать не нужно, вся работа происходит далее.

и видим запрос имени сервера, который будет выполнять роль memcached-сервера. У нас уже есть заготовленный для этого сервер cache01, поэтому смотрим в список доступных серверов. Если cache01 есть в списке, значит никаких проблем с установкой нет, и мы можем дать серверу выбранную роль.

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

Пришло время добавить второй app-сервер. Для этого переходим по пути

где нам необходимо указывать имя сервера и способ синхронизации между основной и новой web-нодой. Исходя из документации bitrixenv и предварительных испытаний, нашему проекту было достаточно выбрать первый вариант (за один шаг происходит и копирование проекта и настройка конфигов ноды). После того, как фоновые работы закончатся, мы должны увидеть в главном меню примерно такую картину:

Обратим внимание на то, что в колонке Roles напротив сервера app02 указана роль web.
Осталось разобраться с БД, её настройка занимает больше всего времени. Для начала вкратце объясню, как раздаются роли mysql в контексте bitrixenv. По-умолчанию на основном сервере кластера стоит master версия БД. В нашем случае необходимо было вынести БД на отдельный сервер и добавить ещё один сервер с slave-версией БД. В bitrixenv нельзя просто так взять и перенести master с одного сервера на другой)

Даём роль mysql_slave серверу, на который мы планируем перенести БД
На целевом сервере меняем роль mysql_slave на роль mysql_master (автоматом старый mysql_master переходит в режим mysql_slave)
Удаляем роль mysql_slave на исходном сервере, бывшем master
…
PROFIT.

Указали сервер, которому хотим дать роль mysql_slave — db01. Дожидаемся окончания фоновых работ и видим такой результат:

Отлично, теперь переходим в

Указываем app01 и ждём. В итоге должны увидеть примерно такой результат:

Медленно и неотвратимо мы подошли к установке последней роли — mysql_slave. Для этого необходимо повторить действия, которыми мы устанавливали такую роль для db01, но указать уже db02.

Наконец, все серверы подключены и настроены.

5. Тюнинг производительности

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

Прокачиваем работу с сессиями. Подробно описано здесь. Вкратце — переключаем хранение сессий в memcached.
Удаляем файлы /bitrix/php_interface/after_connect_d7.php и /bitrix/php_interface/after_connect.php, т.к. команды из них обрывают конвейер кластера (если не используется bitrixenv, то их лучше оставить).
Увеличиваем количество памяти, выделяемое memcached, и устанавливаем процент использования серверов с ролью memcached до 100%.
Отключаем модули php: apcu, ldap
Отключить модули БУС «Компрессия», и “Веб-аналитика” (по возможности).
Рассмотреть вариант использования локального кэша. Подробнее описано тут. В нашем случае прироста не было, но идея интересная. Решение имеет пару особенностей:

Количество инстансов memcached должно равняться количеству web-нод.
Для отдачи композитного кэша nginx-ом напрямую из локального memcached придётся поковырять конфиг nginx, из коробки не работает.

Выводы

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

Для работы открытых линий в «Битрикс24 в коробке» необходимо сделать предварительные настройки сервера и модуля портала.

Внимание! Данные настройки должен выполнять Администратор системы.

Общие серверные настройки

Для начала необходимо убедиться в правильности серверных настроек:

Должен быть действующий лицензионный ключ.

Параметр Nginx: nginx proxy_ignore_client_abort on необходимо включать для конкретного location .

Если используется php-fpm, вместо nginx proxy_ignore_client_abort on нужно использовать параметр fastcgi_ignore_client_abort on .

Для работы коннектора Онлайн-чат: для location /online/(/?)([^/]*) разрешить X-Frame-Options SAMEORIGIN (открывать эту страницу как фрейм из любого сайта или только того, где будет расположен фрейм). Такие настройки могут быть в Nginx и в модуле Проактивная защита в разделе Защита от фреймов (Настройки > Проактивная защита > Защита от фреймов);

Для работы коннектора Битрикс24.Нетворк:

Примечание: В некоторых случаях может потребоваться отключить редиректы для файла коннектора вида

Настройка модуля Коннекторы для внешних мессенджеров

Настройка модуля Коннекторы для внешних мессенджеров (Настройки > Настройки продукта > Настройки модулей > Коннекторы для внешних мессенджеров) проста:

Публичный адрес сайта – нужно убедиться, что после установки был верно определен адрес портала. Он должен быть указан вместе с адресом портала и протоколом. Закрывающий слэш не обязателен.

Включить режим отладки – эта опция включает лог ошибок работы коннекторов в файл /bitrix/modules/imconnector_error.log .

Список используемых коннекторов – здесь выбираются коннекторы (каналы), доступные к подключению.

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

Настройка модуля Открытые линии

Для ведения лога ошибок самого модуля Открытые линии (Настройки > Настройки продукта >Настройки модулей > Открытые линии) можно также включить Режим отладки:

Внимание! При работе Открытых линий для каждого внешнего клиента на портале создается пользователь типа экстранет. Так отображаются экстранет-пользователи в списке пользователей

Настройка модуля Чат-боты Битрикс24

Настройки модуля Чат-боты Битрикс24 (Настройки > Настройки продукта >Настройки модулей > Чат-боты Битрикс24) также особой сложности не вызывают:

Публичный адрес сайта – также должен быть правильно определен адрес портала. Он должен быть указан вместе с адресом портала и протоколом. Закрывающий слэш не обязателен.

Режим отладки – опция включает логгирование работы модуля в файле /bitrix/modules/imbot.log .

Чат боты – опции включения чат-ботов. По умолчанию есть возможность включить чат-боты Giphy, Реквизиты контрагента и Поддержка Битрикс24 в коробке.

С 30 сентября 2021 17:01 (МСК) могут наблюдаться проблемы у клиентов со старой версией браузеров или операционной системы, а также на собственных серверах или хостинге:

при подключении к сайтам и магазинам Битрикс24;
при подключении к Битрикс24 с услугой «собственный домен» (тарифы «Профессиональный» и архивный «Компания»);
при выполнении API REST-запросов со своего сервера к Битрикс24.

Это связано с тем, что срок действия корневого сертификата DST Root CA X3 истек, но он участвует в цепочке выдаваемых нами клиентских сертификатов от Let's Encrypt и остается до 2024 года для поддержки устройств с Android версий 2.3.6-7.1.1.

Что делать?

Единственное верное решение – использование актуального ПО клиентами. Иными словами, обновите ваши устройства и браузеры до последних версий.

Если вы используете виртуальную машину VMBitrix на своем сервере, то необходимо обновить пакет ca-certificates с помощью команды:

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

Подключение к сайтам и порталам

Проблема не касается:

Windows >= XP SP3 (с автоматическим обновлением)
macOS >= 10.12.1
iOS >= 10
Android >= 7.1.1
Mozilla Firefox >= 50.0
Ubuntu >= xenial / 16.04 (с обновлениями)
Debian >= jessie / 8 (с обновлениями)
Java 8 >= 8u141
Java 7 >= 7u151

Работа браузеров Chrome, Safari, Edge, Opera, Vivaldi будет зависеть от версии ОС, на которой они установлены.

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

Выполнение REST/API запросов

Проблема будет, в основном, затрагивать клиентов при выполнении API-запросов с серверов со старым ПО, которые используют:

openssl-1.0.1 – полностью несовместим и работать не будет без сбора собственных пакетов (CentOS 6).
openssl-1.0.2 – необходимо обновить пакет ca-certificates на серверах (CentOS 7).
openssl-1.1.x – полностью совместим.

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

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

Предыстория

Несколько месяцев назад перед нами встала задача обновления PHP до версии 7.4 на одном из наших проектов. Проект был расположен внутри виртуальной машины с развернутой на ней BitrixVM версии 7.2.2. Заглянув в меню Битрикс при обращениях к скрипту /root/menu.sh было обнаружено, что обновление PHP невозможно без обновления Битрикс окружения. При этом само обновление окружения выполняется из бета репозиториев, так как текущая стабильная версия не поддерживала работу с PHP версии 7.4 согласно курсу:

Прошерстив форумы Битрикс, мы не нашли конкретного ответа, когда будет выполнено обновление BitrixVM до стабильной версии с поддержкой с PHP 7.4. В связи с чем, нами было принято решение обновить версию окружения до актуальной беты на одном из виртуальных серверов разработки, предварительно сделав snapshot.

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

BitrixVM хранит лог выполняемых задач по пути /opt/webdir/temp/, в ходе выполнения обновления окружения в логе возникали различные ошибки, вызывавшие нарушение процесса обновления. Поиск и решение подобных ошибок занимало достаточный период времени. Как пример, возникали ошибки подключения репозитория:

Второй проблемой было то, что в случае если обновление из Бета репозиториев было выполнено неудачно и нарушало работу проекта, скрипты BitrixVM не предусматривают откат до стабильной версии, согласно информации:

Обратного отката установленной бета-версии к текущей стабильной нет, т.е если вы перешли, например, на бету 7.4.13, то вернуться к стабильной 7.4.4 нельзя. В этом случае чтобы перейти на стабильную версию, нужно дождаться релиза стабильной версии, новее беты, или установить стабильную версию заново. Например для бета-версии 7.4.13, нужно ждать стабильную версию 7.5.

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

Когда обновление до Бета версии прошло удачно, всплыла проблема при разворачивании новой версии PHP. Ansible роли виртуальной машины Битрикс предусматривают откат до предыдущей версии PHP, для этого в меню виртуальной машины есть, например следующие пункты:

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

После нескольких часов работ и восстановлений состояния виртуальной машины из снэпшота, было принято решение отказаться от обновления окружения BitrixVM и развернуть отдельный сервер под управлением ОС Debian по общим стандартам с требуемым ПО. И выполнить переезд проектов на него. От себя хочу добавить, что данный вариант, при выполнении работ по обновлению BitrixVM, считаем оптимальным, а именно переезд на новый сервер, либо с уже установленной новой версией BitrixVM, на борту, или на новый сервер под управлением другого дистрибутива Linux.

После задача была закрыта и проект работал в штатном режиме. Однако, буквально через несколько месяцев перед нами вновь встала задача обновления PHP до версии 7.4 для BitrixVM, в этот раз с CRM Битрикс24 на борту. Ситуация усложнялась тем, что обновление необходимо было выполнить в течении нескольких дней, а сам сервер располагался физически в офисе заказчика, что означало для нас невозможность переезда на новую инфраструктуру в кратчайшие сроки.

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

Времени на детальное составление плана не было, первоначальным вариантом было выполнить обновление стандартными средствами Битрикс при этом на случай появления проблем, решить которые не удастся, использовать lvm snapshot для отката состояния сервера.

Также рассмотрен вариант разворачивания Docker контейнера c необходимой версией PHP7.4 и настроенный для работы с BitrixVM. Данный вариант показался для нас более выгодным, так как исключал все потенциальные проблемы, которые могли возникнуть при обновлении BitrixVM, а также предусматривал минимальный простой в работе проекта (в последствии простой был, однако он составил не более 5 минут, это то время, которое потребовалось для переключения Nginx для работы с Apache2 в контейнере).

Имея большой опыт работы с Docker мы не видели проблемы в разворачивании контейнера, также в отличии от BitrixVM, с Docker мы могли полностью контролировать процесс обновления, а в случае появления проблем изучать логи Apache в контейнере и сервисов установленных на сервере, которые более информативны, чем логи Ansible ролей виртуальной машины Битрикс. После небольших консультации внутри команды было принято решение развернуть контейнер. На сервере была установлена БитриксВМ 7.3.4, под управлением Centos7.4. Данные работы будут описаны в статье ниже. Я постарался максимально подробно описать проделанные нами шаги, для тех, кому это решение окажется полезным. Также в конце статьи будет приложена ссылка на github с конфигурацией контейнера.

Ход работ

Перед началом работ ставим пакеты docker-ce, docker-ce-cli, containerd.io для Centos7 согласно инструкции:

После устанавливаем docker-compose (на момент публикации статьи актуальной версией является 1.29.2):

Подготавливаем docker-compose файл где описываем контейнер. Контейнер был собран но основании php:7.4-apache, в Dockerfile были включены все необходимые PHP модули. За основу виртуального хоста Apache был взят оригинальный файл BitrixVM, с небольшими правками, учитывающими работу в контейнере. В частности, вам придется указать AssignUserId в конфигурации виртуального хоста Apache, в виду отсутствия пользователя bitrix в контейнере. Добавлю, что apache2 в нашем случае работает с модулем mpm_prefork настройки для которого также прокинуты в контейнер.

Для корректной работы в docker-compose файле потребуется прокинуть в контейнер стандартные директории площадки для bitrix. В целом блок volumes в нашем варианте выглядит следующим образом:

Логи apache2 для площадки были прокинуты на сервер в стандартную директорию, что также учтено в виртуальном хосте:

Логи самого apache2 в контейнере расположены в /volumes/var/log/apache2.

Также потребуется внести ряд правок в php.ini и прокинуть файл в контейнер, эти шаги я опишу ниже, в рамках части про Битрикс оптимизацию.

Для решения проблем с правами необходимо добавить в описание контейнера в docker-compose строки:

Для удобства указания общения контейнера с сервером присваиваем ему IP:

и настраиваем сеть:

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

Для корректной отправки почты, необходимо будет настроить почтовый сервер таким образом, что бы он мог принимать и ретранслировать почту отправленную из контейнера. В нашем случае для отправки почты использовался exim настроенный для работы в режиме smarthost, поэтому потребовалось добавить адрес контейнера (172.24.1.4) в следующие строки:

Битрикс оптимизация

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

Для решения этих задач была создана отдельная тестовая площадка на основном сервере, в которую был помещен установочный скрипт Битрикс. Площадка развернута через стандартное меню Битрикс /root/menu.sh.

Для тестовой площадки настраиваем проксирование на уровне Nginx в контейнер, потребуется изменить переменную proxyserver в файлах виртуального хоста площадки.

После прокидываем созданный скриптом Битрикс виртуальный хост для apache2 в контейнер, при этом обязательно указываем UID пользователя Bitrix:

В нашем случае apache2 работает на стандартном 80 порту в контейнере, поэтому в виртуальном хосте указываем:

После меняем параметры подключения к БД в файлах dbconn.php и .settings.php c 127.0.0.1 на 172.24.1.1

После внесения всех этих изменений переходим в административную панель тестовой площадки, а далее заходим в Проверка системы > Тестирование конфигурации. В первую очередь всплывет ошибка работы с сокетами, для ее решения прописываем в docker-compose.yml параметр extra_hosts, указав внешний IP сервера и доменное имя площадки:

Перезапускаем контейнер. Также для корректной отправки почты, потребуется указать в настройках PHP sendmail_path:

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

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

Дополню, что в случае использования контейнера с Битрикс24 будет всплывать предупреждение вида:

Ошибка! Для гарантированной работы "1С-Битрикс24" необходимо его устанавливать на веб-окружении Битрикс, у вас используется собственное серверное окружение.

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

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

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

Заключение

Целью данной статьи не является пропаганда такого решения, оно будет полезно тем, кому жизненно важно обновление PHP на текущем этапе работы проекта, при этом нет возможности переехать на новую инфраструктуру, а также нет уверенности в том, что обновление Битрикс из бета репозиториев пройдет гладко.

BitrixVM является простым в установке решением, однако в случае администрирования кастомной конфигурации решение проблем и проведение каких-либо обновлений проходит сильно проще.

Для удобства выложили конфигурацию нашего контейнера на GitHub, вы всегда можете ознакомится с ней по мере необходимости. Там же расположен отредактированный виртуальный хост площадки, все вносимые в PHP и Apache2 настройки и docker-compose.yml.

В заключении от себя хочется сказать, что в процессе администрирования мы видим больше минусов, чем плюсов в разворачивании BitrixVM в качестве окружения, в частности это связано со следующими пунктами:

Сложность внесения каких-либо настроек в систему и установки нового ПО. Запутанность файлов конфигураций ПО в BitrixVM, а также использование ansible-скриптов для управления сервером через меню с псевдографическим интерфейсом приводит к тому, что внесение даже самых элементарных настроек требует большого количества времени со стороны администраторов, которое уходит именно на то, чтобы понять где именно необходимо внести данные изменения, чтобы в дальнейшем они не были перезаписаны ansible-скриптами, а так же не имели негативного влияния на работу других элементов системы.

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

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

Также как показывает наш опыт, интеграция со сторонними сервисами в случае с BitrixVM зачастую очень сложна или невозможна.

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

Читайте также: