1С в контейнерах. Практическое руководство – 1

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

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

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

Стоп, скажет иной читатель, а как быть с «операционной системой» в контейнере? На самом деле это не полноценная операционная система, а просто набор библиотек, предоставляющий приложению требуемое окружение.

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

При контейнеризации мы будем исходить из соображений: одна служба – один контейнер. Таким образом у нас напрашивается минимум три контейнера: Сервер 1С:Предприятие, PostgreSQL и веб-сервер.

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

Веб-сервера тоже стоит разделять, как минимум на обслуживающие клиентские подключения и веб-сервисы.

С этим разобрались. Теперь перейдем к распространенным ошибкам. Не следует выбирать для 1С контейнеры с неподдерживаемой системой внутри. Это ничего вам не даст, кроме лишней головной боли.

Скажем, сервер 1С в контейнере с Debian 13 не будет работать лучше, чем с Debian 12, а вот головной боли добавить может и это будет именно ваша головная боль, потому что платформа не поддерживается. У вас даже багрепорт не примут, по этой самой причине.
Но основной смысл перехода от монолита к контейнерам – это, конечно же, гибкое управление ресурсами. Оно же становится основной сложностью для начинающих. Начнем с процессора.

Платформа 1С:Предприятие уровня ПРОФ ограничена по лицензионным соображениям 12 процессорными ядрами (не важно физическими или виртуальными). Таким образом любой современный процессор предоставляет нам ядер больше, чем требуется для 1С.

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

После чего также явно привязываем ядра к остальным контейнерам. Если этого не сделать, то может оказаться так, что какие-то ядра загружены, а какие-то простаивают. Также для процессоров Intel последних поколений критически важно для производительности выполнить привязку контейнера сервера 1С к продуктивным, а не энергоэффективным ядрам.

При этом не забывайте про базовые настройки железа, рекомендованные для серверов 1С. В частности, это включение Turbo-bust на все ядра, отключение режимов энергосбережения процессора C-State (выключаем или выбираем C0), а также отключаем управление питанием и частотой процессора P-states (выбираем наиболее производительный режим P0).

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

Игнорирование данной настройки может приводить к серьезным просадкам производительности сервера 1С:Предприятия и являются очень частой ошибкой конфигурирования.