Docker для 1С-разработчика: где экономит часы, а где создаёт больше проблем, чем решает

13 мая 2026 · infolimp.ru

Автор: 1С Инсайдер · роль: практик 1С · проверка: типовые конфигурации и рабочие сценарии · 0 комментариев

Что Docker даёт 1С-нику на пальцах

Контейнер — это изолированный процесс с собственной файловой системой, сетью и портами, поднимаемый из заранее описанного образа. В 1С-контексте чаще всего речь идёт не о сервере 1С внутри контейнера, а о вспомогательной инфраструктуре: PostgreSQL для тестов, отдельный экземпляр nginx, фоновый Python-скрипт обработки выгрузок, AI-инструменты.

Главный практический выигрыш

На команду из 3–5 разработчиков типовая боль — «у Васи Postgres 14, у Пети 15, у Тани вообще файловая база». При воспроизводимом контейнере с компанейским docker-compose.yml все запускают одно и то же одной командой docker compose up. На разборе багов это снимает целый класс «у меня по-другому» и заметно сокращает время на воспроизведение.

Где Docker реально помогает

1. PostgreSQL под несколько проектов

Разработчик ведёт три проекта одновременно: типовая БП, доработанная УТ, нестандартная конфигурация заказчика. Каждому проекту — своя версия Postgres и свои базы. Без контейнеров это означает три установки Postgres на ноутбуке с конфликтами портов. С контейнерами — три изолированных compose-файла, каждый стартует независимо.

2. Тестовые контуры под разные релизы платформы

Заказчик присылает дамп с конфигурации, собранной на платформе 8.3.22. Ваша рабочая — 8.3.24. Поднять параллельную песочницу нужно за полчаса. Серверная часть 1С сама в контейнер по лицензии не помещается просто, но файловая база и клиент на хост-машине прекрасно работают с контейнеризованным Postgres под нужный релиз.

3. Воспроизводимая среда сборки и CI

Если у вас есть скрипты выгрузки конфигурации в файлы и обратной загрузки (типичный паттерн при использовании EDT или Git-интеграции), эти скрипты часто живут в контейнере. CI-сервер при коммите поднимает чистый контейнер с нужной версией платформы и проверяет, что выгрузка вообще читается. Это уровень для команд от 5 человек, но окупается резко.

Где Docker создаёт проблемы

1. Сервер 1С внутри контейнера — лицензионная тонкость

Речь о Linux-версии сервера 1С:Предприятие — на Windows-сервере в Docker сервер 1С официально не поддерживается. Если у вас Windows-сервер и HASP-ключ — этот раздел не про вас. Технически на Linux сервер 1С в Docker-образе работает. Юридически — сложнее: HASP-ключ или программная лицензия требуют машинной привязки, и пересоздание контейнера (а не просто restart) может выглядеть как смена железа для системы лицензирования. Это решаемо, но требует отдельной возни с лицензионным сервером и пробросом сокета. Если вы не уверены, что готовы поддерживать это решение — оставайтесь со стандартной установкой сервера.

2. Конфигуратор и тонкий клиент — это GUI-приложения

Конфигуратор 1С — это Windows-приложение с тяжёлым интерфейсом. Запуск его в Docker через X-server или через VNC — теоретически возможно, практически — мучение, которое окупается только в очень экзотических сценариях. Для повседневной разработки тонкий клиент и Конфигуратор живут на хост-машине, а Docker — на инфраструктуре под ними.

3. Когда команда из одного человека

Если вы единственный разработчик, у вас один Postgres на ноутбуке, и одна типовая конфигурация — вкладывать вечер в обучение Docker ради «правильности» сомнительно. Польза появляется от двух разработчиков и двух проектов.

Сценарии: подходит / не подходит

Минимальный пример: Postgres для 1С через compose

Простейший docker-compose.yml, который поднимает один экземпляр Postgres с настройками, дружелюбными к 1С:

services:
  postgres-1c:
    image: postgres:15-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: postgres1c
      POSTGRES_PASSWORD: examplePassword
      POSTGRES_DB: dev_demo
    ports:
      - "5433:5432"
    volumes:
      - ./pgdata:/var/lib/postgresql/data
    command:
      - "postgres"
      - "-c"
      - "max_connections=200"
      - "-c"
      - "shared_buffers=512MB"

Запуск: docker compose up -d. Через несколько секунд у вас на хосте слушает Postgres на порту 5433 (специально не 5432, чтобы не конфликтовать с локально установленным). К нему подключается сервер 1С обычным способом: если сервер на той же машине, что и контейнер — адрес localhost:5433; если на отдельной — IP или DNS-имя хоста, где запущен контейнер, с открытым 5433 на файрволе.

В коде самой 1С можно проверить, к какому экземпляру Postgres подключена база — через стандартную функцию платформы, которая возвращает строку соединения текущей информационной базы:

// Проверяем, к какому экземпляру Postgres подключена база
Строка = СтрокаСоединенияИнформационнойБазы();
Сообщить("Подключение: " + Строка);
// Для клиент-серверной базы строка содержит Srvr и Ref — это и есть
// адрес сервера 1С, который дальше общается с нашим контейнерным Postgres.

Если данные важны после остановки контейнера — монтируйте том (volumes в примере выше с путём ./pgdata). Без него docker compose down уносит всё содержимое базы вместе с контейнером. Для эфемерных тестовых прогонов том не нужен, но осознавайте, что данные после остановки исчезнут. Это самая частая утечка времени у тех, кто впервые ставит контейнер «попробовать»: «вчера всё было, сегодня пусто, что случилось?».

Чек-лист «решили внедрить Docker в команде»

1. Определите, сколько у вас разработчиков и проектов. Меньше двух из каждого — не торопитесь, окупаемость низкая.
2. Начните с одного сценария — обычно это PostgreSQL для разработки. Не пытайтесь сразу контейнеризовать всю инфраструктуру.
3. Положите docker-compose.yml в репозиторий проекта рядом с конфигурацией. Через год новичок в команде поднимает среду одной командой.
4. Сразу прописывайте монтирование томов под данные (volumes) — иначе перезапуск контейнера = потеря базы.
5. Зафиксируйте версии образов жёстко (postgres:15-alpine, не postgres:latest) — иначе через полгода у новичка поднимется Postgres 18, и поведение запросов изменится.
6. Документируйте порт-маппинг: какой контейнер слушает на каком хост-порту. Через три проекта вы сами запутаетесь.
7. Не лезьте в контейнеризацию сервера 1С на первой неделе. Доберитесь до неё только когда остальное стабильно работает.
8. Имейте план «как откатиться»: если завтра кто-то из команды не справляется с Docker — должна быть возможность работать по-старому, через локальный Postgres.

Типичные ошибки

• Без монтирования тома. Поднял контейнер, наполнил базу, остановил контейнер, удивляешься почему данных нет. volumes — это первое, что прописывают, не «потом разберёмся».
• postgres:latest в проде. Сегодня это Postgres 17, через год может быть Postgres 18, и план запроса работает по-другому. Версия — фиксированная.
• Контейнеризовать сразу всё. Команда из трёх человек впервые видит Docker, и кто-то предлагает обернуть сервер 1С, конфигуратор и тонкий клиент. Это путь к двум потерянным неделям.
• Игнор лицензионной части. Сервер 1С в Docker — это лицензионная задача, не только техническая. Сначала разберитесь с тем, как у вас лицензируется сервер, потом контейнеризуйте.
• Бэкапы только через Docker volume. Если падает диск хоста, контейнер с томом тоже теряется. Нужна вторая копия за пределами хоста.
• Конфликты портов. Локальный Postgres на 5432 + контейнерный на 5432 = непонятные ошибки подключения. Сразу выносите контейнер на другой порт (5433, 5434).