BitrixEnv на Ubuntu и Debian: что делать, если сервер не на Rocky Linux

Omut

Если сервер стоит на Ubuntu или Debian, установщик BitrixEnv bitrix-env-9.sh дальше проверки системы не пройдёт. В нём прямо записано, на каких дистрибутивах он работает:

This script has been tested only on Rocky Linux, Alma Linux, Oracle Linux, CentOS Stream. Current OS:

Скрипт определяет систему по файлам /etc/rocky-release, /etc/almalinux-release, /etc/oracle-release и /etc/centos-release, требует девятую версию и дальше ставит пакеты через dnf. В документации 1С-Битрикс тот же список: CentOS Stream 9, Rocky Linux 9, AlmaLinux 9 и Oracle Linux 9, и обязательно чистая система.

Значит, на Ubuntu и Debian вариантов четыре. Какой выбрать, зависит от того, что это за сервер.

Если сервер боевой

Переустановите систему на Rocky Linux 9 или AlmaLinux 9 и поставьте BitrixEnv. У большинства хостеров смена образа занимает несколько минут, а вы получаете окружение, которое поддерживает 1С-Битрикс: меню сервера, пулы, балансировку, кластер MySQL, если до него дойдёт.

dnf clean all && dnf update
wget http://repo.bitrix24.tech/dnf/bitrix-env-9.sh && chmod +x bitrix-env-9.sh && ./bitrix-env-9.sh

Скрипт предложит выключить SELinux и попросит перезагрузку, после неё его запускают ещё раз. По умолчанию он ставит Percona Server 8.0, версию 8.4 можно выбрать ключом -m 8.4.

Собирать бой на Ubuntu руками я бы не стал: получится ваш личный BitrixEnv, и обновлять его, чинить и объяснять следующему разработчику придётся вам.

Если нужно поднять руками

Иногда систему сменить нельзя: сервер общий, образ выбирал не вы. Тогда минимальный набор такой:

• nginx и PHP-FPM нужной версии — в Ubuntu и Debian удобно брать PHP из репозитория Ondřej Surý, разные версии там ставятся рядом;
• MySQL 8.0 или 8.4 либо Percona Server той же версии;
• php.ini под Битрикс: memory_limit от 256M, max_input_vars от 10000, OPcache включён, session.save_path доступен на запись;
• конфигурация nginx, которая закрывает служебные папки Битрикса (/bitrix/modules, /bitrix/php_interface, кэш) — в BitrixEnv это делает его собственный конфиг, руками это забывают чаще всего;
• cron для bitrix/modules/main/tools/cron_events.php, если агенты должны работать без посетителей.

Проверяйте результат скриптом bitrix_server_test.php из дистрибутива и проверкой системы в админке. Push & Pull для чата Битрикс24 — отдельная задача: в BitrixEnv push-сервер ставится пакетом, руками придётся поднимать Node.js-сервер и проксировать на него nginx.

Если подходит Docker

Официальная сборка bitrix-tools/env-docker запускается везде, где есть Docker, в том числе на Ubuntu и Debian. Сами разработчики сборки называют её dev-окружением и прямо пишут в README, что для боя нужны дополнительные настройки безопасности. Для стенда команды это рабочий вариант, если кто-то в команде готов отвечать за compose-файл, обновления образов и бэкапы томов.

Если это dev или стенд для заказчика

Для копии сайта, на которой работает команда и которую смотрит заказчик, BitrixEnv избыточен, а ручная сборка — лишняя работа. Здесь подходит dev-сервер Omut: он ставится на Ubuntu 22.04, 24.04, 26.04, Debian 12 и 13 и управляется из того же приложения, в котором вы работаете с сайтом локально.

Подключение. Раздел «Серверы» → Подключить сервер: адрес, логин и пароль root или пользователя с sudo. Пароль нужен один раз — Omut добавит на сервер свой ключ и дальше ходит по нему.

Omut

До установки Omut проверит версию системы, свободные порты (80, 443, 3306), память и место на диске и покажет, что поставит. Нужен чистый сервер: если там уже стоит Apache или BitrixEnv, порты заняты и Omut не установится.

Копия сайта. На странице локального сайта: вкладка Dev-сервер → Создать на dev. Версии PHP и MySQL те же, что у сайта на компьютере. Домен с сертификатом Let’s Encrypt или адрес вида shop.203-0-113-7.sslip.io, если домена пока нет. Доступ — по паролю, по списку IP или для всех. Поисковики dev-сайт не индексируют.

Omut

Деплой. Кнопка Развернуть: отметьте код, upload/ и базу. До запуска видно, сколько файлов уедет и что удалится на dev. Едут только изменённые файлы. Если деплой сорвался на сервере, Omut вернёт dev в прежнее состояние: файлы на место, базу — из бэкапа, который он снял перед заменой.

Omut

Бэкапы и почта. На той же вкладке — бэкапы dev по кнопке и каждую ночь, со сроком хранения. Письма, которые отправляет dev-сайт, по умолчанию остаются в разделе «Почта» и наружу не уходят: на копии боевой базы клиенты не получат писем о заказах, которые оформляет тестировщик.

Omut

Что Omut делает на сервере

Программа с вашего компьютера получает root на сервере, поэтому:

• всё, что Omut запускает на сервере под root, подписано, подменённый файл не установится;
• sshd_config и firewall Omut не трогает, в authorized_keys добавляет одну строку — ключ с ограничениями, туннели только к MySQL и почте;
• каждое действие пишется в журнал на сервере, /var/log/omut/audit.log;
• полный список того, что Omut ставит и меняет, мастер показывает до установки, тот же текст — в документации.

Что выбрать

Боевой сайт можно оставить на BitrixEnv, а dev-копии держать на отдельном сервере с Ubuntu. Деплой Omut идёт на dev-сервер, бой он не трогает.