Контейнеры стали стандартом для веб-сервисов и микросервисной разработки. Логичный вопрос: почему бы не упаковать в Docker и сервер 1С с СУБД, чтобы не возиться с установкой на каждом стенде. Когда речь заходит про 1С в Docker, ответ оказывается не «да» и не «нет».
На практике 1С устроена так, что не любая её часть хорошо ложится в контейнер: программные лицензии привязаны к окружению, аппаратные HASP-ключи требуют физических USB-портов, кластер плохо живёт без стабильного состояния. При этом отдельные сценарии работают отлично - PostgreSQL для 1С, тест-стенды, CI/CD, микросервисы вокруг 1С.
Что подразумевается под «контейнеризацией 1С»
Шесть вариантов с разной сложностью и смыслом.
1. Сервер 1С:Предприятие в Docker - упаковываем ragent с менеджером кластера и рабочими процессами в контейнер на базе Linux.
2. СУБД (PostgreSQL для 1С) в Docker - отдельный контейнер с готовой сборкой Postgres Pro или 1C-PostgreSQL.
3. Сервер 1С плюс СУБД одновременно в Docker - два связанных контейнера, через docker-compose. Часто встречается в учебных и тестовых сборках.
4. Микросервисы вокруг 1С - REST/SOAP-обвязка, интеграционные шины, веб-формы. Сама 1С при этом может оставаться в классической установке.
5. CI/CD-обвязка - gitlab-runner, контейнеры со сборкой и проверкой конфигурации (1cv8.cf, .epf), линтеры, автотесты конфигурации.
6. Без смысла - тонкий и толстый клиент 1С в контейнере. Это десктопные приложения, контейнеризация им ничего не даёт.
Технические особенности 1С, которые мешают контейнеризации
Лицензирование и активация
Главный блокер для прода - лицензии, и каждая из трёх моделей по-своему конфликтует с Docker. Программные лицензии 1С привязываются к параметрам окружения: имени сервера, MAC-адресу, серийным номерам компонентов. В Docker эти параметры легко меняются при пересоздании контейнера, и активация слетает. Аппаратные HASP-ключи - USB-устройство. Пробросить его в контейнер технически можно через --device, но это привязывает контейнер к конкретному физическому хосту и убивает идею мобильности.
Сетевая активация через сервер лицензий 1С - рабочая схема для контейнеров, но требует отдельного сервера лицензий, который сам обычно стоит в классической установке. Сверху ещё юридический нюанс: лицензионное соглашение 1С формально не запрещает контейнеризацию, но и не описывает её. Все вопросы при инцидентах решаются индивидуально, и не всегда в пользу клиента.
Состояние, хранилища и сетевые ожидания
Вторая половина проблемы - архитектурные особенности. Сервер 1С stateful: рабочий каталог srvinfo хранит метаданные кластера, журнал, временные файлы. Это нужно мапить через volumes, иначе после рестарта данные кластера пропадают. Сам кластер 1С плохо переживает быстрые пересоздания узлов: рестарт «всё с нуля», как принято в Kubernetes для stateless-сервисов, ломает работу пользователей.
Сетевая модель Docker по умолчанию (NAT) скрывает реальные адреса контейнеров от внутренней маршрутизации 1С - платформа путается с DNS-резолвом и подключением клиентов. И отдельная боль - IO: журнал транзакций СУБД и журнал регистрации 1С генерируют большой объём операций, и на overlay-FS Docker это медленнее, чем на нативной файловой системе хоста.
Где Docker реально работает с 1С
Сценарии, где postgresql 1С docker и контейнерные сборки в целом дают ощутимую пользу.
1. PostgreSQL для 1С в контейнере. Готовая сборка PostgreSQL, адаптированная под 1С (от Postgres Pro или из дистрибутива 1С), тома для PGDATA и журналов транзакций. Для тестовых баз почти идеально, для прода спорно из-за overhead overlay-FS.
2. Сервер 1С для тест-стендов. Поднимаем 1С плюс PostgreSQL через docker-compose, разворачиваем эталонную базу, каждый разработчик за минуту получает свою чистую копию.
3. CI/CD для конфигурации 1С. Контейнер с EDT или командной строкой 1С запускается на каждый push, проверяет конфигурацию и прогоняет автотесты.
4. Демо-окружения для презентаций и обучения - поднял из образа, показал, выключил. Никаких остатков на хост-системе.
5. Микросервисы вокруг 1С - обмены, REST-шлюзы, конвертеры форматов. Это уже не сама 1С, а её обвязка, и она прекрасно живёт в контейнерах.
6. Прод-PostgreSQL для 1С на bare metal или в виртуалке - стандартный выбор. В контейнер его тащат только при сильной потребности в одинаковости стендов.
Где Docker не работает или работает плохо
Зеркальная сторона - сценарии, где контейнеризация себя не оправдывает.
1. Прод-сервер 1С в Docker - не рекомендуется. Лицензии слетают, кластер нестабилен, поддержка от 1С формально не предусмотрена. Если что-то сломается, разбираться будете сами по форумам.
2. Кластерная конфигурация 1С (несколько серверных узлов). Docker и K8s исходят из идеи stateless и быстрых рестартов, для кластера 1С это убийственно - после каждого рестарта переинициализация и потери сессий.
3. Большие базы (десятки и сотни ГБ) с активной нагрузкой. Контейнерная файловая система проигрывает по IOPS прямому доступу к диску. На больших отчётах разница ощутимая.
4. Серверы с аппаратными HASP-ключами. USB в контейнер пробросить можно, но это привязка к хосту: пропадает половина смысла Docker, сложность сетапа растёт.
5. HA через Docker Swarm или K8s для прод-1С - не работает. Платформа не рассчитана на горизонтальное масштабирование штатных rphost через оркестрацию.
6. Связки 1С с локальным оборудованием - кассы, сканеры, фискальные регистраторы. В контейнер их пробрасывать сложно, проще оставить классическую установку.
Kubernetes и 1С: имеет ли смысл
Где k8s даёт реальную пользу 1С-проектам
Kubernetes 1С - отдельная история, которую не стоит путать с обычным Docker. K8s оркестрирует stateless-сервисы, поэтому сам сервер 1С под управлением K8s ставить не нужно: платформа stateful, и перезапускать pod как обычный микросервис, значит ломать кластер 1С на каждом обновлении.
Реальная польза K8s для микросервисов вокруг 1С: REST-шлюзы для веб-форм, обработчики обменов с маркетплейсами, интеграционные шины с банками и налоговой. Это нормальные stateless-сервисы, и оркестрировать их в кластере удобно. Ещё один валидный сценарий - тестовые контуры разработчиков: каждый через CI получает namespace со своим сервером 1С и БД, после работы всё гасится. Лицензионные нюансы для тестов часто проще, чем для прода. А вот для прод-1С k8s обычно усложняет, а не упрощает: классическая виртуалка с сервером 1С работает спокойнее и без лишних слоёв.
Когда лучше остаться на классической установке
Если по списку выше получается, что прод и кластер про вас, разумнее не воевать с Docker, а посмотреть готовые серверы для 1С под текущее число пользователей и сделать классическую установку без лишних слоёв сложности.
Заключение
1С и Docker - не «несовместимы» и не «всё в контейнеры». Часть задач (тест-стенды, CI/CD, микросервисы вокруг 1С) контейнеризация реально упрощает. Часть (продакшен, кластер, лицензии) - наоборот, усложняет. Решение принимается по сценарию, а не по моде. Если сценарий - стабильный продакшен, спокойная классическая установка обычно выигрывает.
Если в проекте смешана классическая 1С и контейнерная обвязка вокруг неё, проектирование такой связки удобнее закрывать как интеграцию и обслуживание серверного оборудования: тогда границы ответственности и регламенты обновлений становятся обязательством подрядчика, а не задачей одного DevOps в компании.
