Docker в BIM: зачем контейнеры проектной компании

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

Первый сервис у нас работал на компьютере BIM-менеджера. Скрипт по расписанию собирал отчёт качества моделей и слал его в почту. Работало полгода.

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

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

Когда контейнеры нужны, а когда нет

Пока у вас скрипты, которые запускает человек руками, никакой Docker не нужен. Dynamo-граф на рабочей станции живёт прекрасно, и усложнять там нечего.

Разговор начинается, когда появляется хотя бы одно из трёх:

• Что-то должно работать по расписанию без участия человека: ночная проверка, выгрузка, рассылка.
• Инструментом пользуются несколько человек: внутренний сайт, дашборд, бот, API.
• Сервисов стало больше одного, и они цепляются друг за друга: база, обработчик, интерфейс.

Три ситуации сводятся к одному требованию: нужен сервер и повторяемое окружение. Контейнер это способ описать окружение файлом, а не устной инструкцией «поставь питон, потом библиотеки, потом вот эту версию».

Что в BIM-инфраструктуре живёт в контейнерах

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

Практический вывод: всё, что не требует Revit, выносится на сервер, а связь с моделями идёт через выгрузки. Как эти выгрузки хранить, разбиралось в статье про PostgreSQL.

Как выглядит стек на практике

Файл описания на четыре сервиса, читается почти как список. Ниже сокращённый вариант того, что стоит у нас на внутренних проектах.

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_DB: bimdata
    volumes:
      - ./data/pg:/var/lib/postgresql/data   # данные вне контейнера
    restart: unless-stopped

  api:
    build: ./api            # проверки качества, выгрузки, отчёты
    depends_on: [db]
    restart: unless-stopped

  dashboard:
    build: ./dashboard
    ports: ["8080:80"]
    restart: unless-stopped

  bot:
    build: ./bot            # уведомления команде в Telegram
    env_file: .env          # токены только здесь, в git не кладём
    restart: unless-stopped

Одна строка тут важнее прочих: restart: unless-stopped. Сервис поднимается сам после перезагрузки сервера. Тот самый отпуск BIM-менеджера перестаёт быть событием.

Вторая важная строка - том ./data/pg. Контейнер можно снести и пересобрать, база останется. Кто этого не сделал, узнаёт про особенность контейнеров ровно один раз.

Что это меняет в работе

Инструменты перестают быть личными. Скрипт на чужом ноутбуке это риск, сервис на сервере это актив компании. Разница видна в момент, когда человек уходит.

Обновление перестаёт быть подвигом. Новая версия собирается рядом, переключается одной командой, откатывается назад так же. Не надо вспоминать, что было настроено полгода назад.

Появляется место для мелочей. Бот, который пишет в чат «модель АР синхронизирована 4 дня назад», стоит день работы. Пока нет сервера, такие штуки не делают, потому что негде запускать.

Уходит вопрос «а у меня не работает». Окружение одно на всех, а не своё на каждой машине.

Пять ошибок, которые обошлись дороже всего

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

Забили диск логами. Сервер на 40 ГБ встал за месяц: контейнеры писали журналы без ограничения. Лечится тремя строками настройки, но узнаёшь об этом обычно после падения.

Открыли базу наружу. Порт 5432 смотрел в интернет. Попытки подбора пароля начались через сутки после запуска. Наружу должен смотреть только веб-интерфейс, и то через обратный прокси с сертификатом.

Сложили токены в образ. Ключ бота попал в собранный образ и уехал в общий реестр. Секреты живут в файле окружения на сервере, и этот файл в репозиторий не кладётся никогда.

Взяли слишком слабый сервер. Парсер IFC на файле в 900 МБ съел всю память, и контейнер убило системой. Запас по памяти для BIM-задач нужен вдвое больше ожидаемого.

Где это не работает

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

Не поможет он и с лицензиями Autodesk. Мечта «запустим двадцать Revit в контейнерах и обработаем пачку моделей» разбивается о лицензионное соглашение и о требования к графике.

Не стоит начинать с контейнеров, если в компании нет ни одного человека, готового зайти на сервер по SSH. Инфраструктура требует хозяина. Без него через полгода это будет чёрный ящик, который боятся трогать, и любая мелкая правка превратится в вызов подрядчика.

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

Первый сервис за неделю

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

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

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

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

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

Сколько стоит

Виртуальный сервер под всё перечисленное: от 600 до 2500 ₽ в месяц, в зависимости от памяти. Отдельная машина с видеокартой под локальную языковую модель дороже на порядок, и брать её стоит только после расчётов из дорожной карты.

Первичная настройка: от трёх дней до двух недель, в зависимости от числа сервисов. Поддержка потом - пара часов в месяц, если сделано аккуратно.

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

Короткие ответы

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

Можно ли поставить на свой сервер в офисе? Можно, если он не выключается и есть внешний доступ. Резервные копии всё равно должны уезжать в другое место.

Нужен ли системный администратор? Для запуска и первой настройки - да, дальше справляется подготовленный BIM-специалист. Команд, которые он будет использовать, штук восемь.

Что с безопасностью данных заказчика? Свой сервер тут выигрывает у публичных сервисов: вы контролируете доступ. Ответственность за пароли и обновления тоже ваша.

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

Что дальше

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

Данные, которые эти сервисы обрабатывают, обычно приходят из выгрузок Revit, а показывать их удобнее на дашборде. Инфраструктуру и внутренние сервисы мы собираем как отдельную работу, коротко об этом в услугах, типовые вопросы - в FAQ. Обсудить задачу можно в Telegram.