Контейнеры в IT давно норма: собрал образ, прогнал в CI, выкатил. В OT картина другая: рядом с циклом стоят уставки давления, а на шкафу появился «ещё один Linux» с Docker. Вопросы у заказчика предсказуемые: кто это поддерживает, что будет при обновлении, и не съест ли контейнер весь CPU в неудачный момент.
Эта статья про то, где контейнеры в промышленном контуре уже приносят пользу, а где граница ответственности должна быть нарисована жирной линией.
Короткий ответ
Контейнеры в OT уместны для edge-сервисов без прямого управления процессом в реальном времени: шлюзы протоколов, лёгкая аналитика, адаптеры к облаку, вспомогательные API. Не место контейнеру как среде исполнения критичного PLC runtime или certified safety-логики. Граница ответственности проходит между «сервис рядом с автоматизацией» и «автоматизация как таковая»: второе оставляют вендорским стекам и циклам ПЛК, первое - можно упаковать в образ, если сеть изолирована, обновления контролируются, а образы ведутся как артефакты проекта.
Что хорошо ложится в контейнер на границе OT
Протокольные шлюзы и нормализация данных. Контейнер с OPC UA client, MQTT publisher или драйвером «редкого» протокола на промышленном шлюзе - типичный кейс: зависимости изолированы, версию образа можно зафиксировать в Git и накатить на площадке с тем же digest.
Локальная аналитика и агрегация. Скрипты, которые читают historian или подписываются на поток, считают KPI и отдают результат в MES - не требуют жёсткого детерминизма, если вы явно ограничили CPU и память и не шарите с циклом ПЛК одно ядро без приоритетов.
Вспомогательные сервисы эксплуатации. Кэш для отчётов, локальный REST для мобильных нарядов, синхронизация с облаком в off-peak - всё, что можно остановить на час без остановки линии (и что задокументировано как такое).
Здесь Docker (или OCI-совместимый runtime) даёт повторяемость: dev/stage/prod с одинаковым содержимым слоёв, минус «у меня на ноутбуке работало».
Что не стоит тащить в контейнер без очень веской причины
Runtime логики ПЛК и задач с гарантированным циклом. Планировщик ОС и cgroups - не замена циклу исполнения ПЛК. Если кто-то предлагает «ПЛК в Docker», спросите про сертификацию, джиттер и поведение при 100% load соседнего контейнера.
Safety и SIL. Сертифицированные safety-стеки живут в железе и средах, которые прошли оценку. Контейнер как универсальная прослойка туда не лезет по определению ответственности: граница смещается на команду, которая не может дать тот же уровень доказательств.
Единственный канал критичного управления. Если отказ одного контейнера оставляет объект без единственного пути к безопасному состоянию, архитектура уже не та.
Обновления, сеть и модель «подвижной» vs «неизменяемой» системы
Обновления: в OT ценится предсказуемость. Контейнеры облегчают выкладку, но усложняют дисциплину: нужен регистр образов, политика тегов (не latest в проде), окна работ и откат на предыдущий digest. Связка с MOC и согласованием с эксплуатацией здесь обязательна.
Сеть: контейнеры должны жить в изолированных сегментах (отдельный VLAN, firewall, без прямого доступа из корпоративного Wi‑Fi на тот же хост, что крутит цикл). Идея «один Docker host на всё» без сегментации - частый источник инцидентов.
Mutable vs immutable: в зрелом подходе прод не патчат внутри контейнера - выпускают новый образ и переключают версию. Это ближе к immutable infrastructure и упрощает аудит: «что крутилось 3 мая» равно digest в реестре. Жизнь с docker exec и ручными правками внутри - это снова «снежинка», только в обёртке из модных слов.
Три сценария, где контейнеры в OT реально помогают
1.Edge-шлюз на линии: образ с адаптером полевого протокола + публикация в MQTT/OPC UA для верхнего уровня. Версия образа = версия интеграции, откат за минуты.
2.Песочница для интеграторов: отдельный хост или ВМ с Docker, куда поставщик кладёт свой сервис; производство не даёт root на SCADA, но получает предсказуемый контракт по портам и логам.
3.Пилот IIoT без переписывания ПЛК: новый сервис читает уже существующий поток данных, не вмешиваясь в цикл ПЛК - масштабирование через новые контейнеры, а не через правки вендорского проекта.
Три сценария, где контейнеры в OT несут избыточный риск
1.«Всё на одном промышленном ПК»: Docker + SCADA + камеры + инженерный RDP. Любой всплеск - конкуренция за диск и CPU, размытая граница поддержки: кто виноват, если зависло «всё сразу».
2.Критичный цикл внутри контейнера без резервирования и без расчёта нагрузки: обновление образа в неудачный момент, нехватка памяти, OOM killer - слишком высокая цена за удобство упаковки.
3.Нет реестра и SBOM, образы собираются «у кого-то на машине»: supply chain риск, неповторяемые сборки, невозможность доказать состав ПО перед аудитом.
Где уместен СТАБУР
В архитектурах на базе СТАБУР контейнеры разумны на границе данных и интеграции, а не как замена ядру управления. Чёткое разделение сегментов, версии образов и регламент изменений совпадают с тем, как обычно вводят в эксплуатацию промышленные объекты с долгим жизненным циклом.
Заключение
Docker в OT - не религия, а инструмент упаковки и изоляции для определённого класса задач. Польза максимальна там, где сервис не является единственным носителем безопасности процесса и где инфраструктура явно спроектирована: сеть, ресурсы, обновления, откат. Граница ответственности должна быть прописана: кто владеет образами, кто допускает релиз, что считается изменением конфигурации АСУ ТП.
FAQ
Можно ли официально крутить SCADA в Docker?
Зависит от вендора и лицензии. Часто есть поддержка или рекомендации только для конкретных редакций. Без явного «да» от поставщика вы берёте риск на себя.
Чем контейнер лучше виртуальной машины?
Быстрее выкладка и меньше оверхед, но слабее «железная» изоляция, чем у отдельной ВМ. Выбор - по модели угроз и требованиям заказчика.
Нужен ли Kubernetes в цеху?
Не обязательно. На edge часто достаточно одного runtime и systemd/compose-оркестрации. Kubernetes оправдан при множестве узлов и зрелой команде.
Как бороться с root внутри образа?
Политика минимальных привилегий, non-root user, read-only root filesystem где возможно, сканирование образов в CI.
Контейнеры помогают с кибербезопасностью?
Сами по себе нет. Они помогают воспроизводимости и обновлениям. Без сегментации и мониторинга вы только ускорили доставку уязвимого ПО.