The convergence of Information Technology (IT) and Operational Technology (OT) presents organizations with new challenges in deploying industrial software systems. Traditional OT systems are monolithic, difficult to update, and often bound to proprietary hardware. Docker for IT/OT architectures offers a solution: container technology enables modular, versioned, and reproducible deployment of Unified Namespace (UNS) components—from message brokers to edge gateways. This article demonstrates the concrete advantages Docker provides in industrial environments, proven architecture patterns, and best practices IT/OT architects must consider during implementation.
What is Docker? – Fundamentals for the OT Context
Docker is a platform for developing, distributing, and running applications in isolated containers. Unlike virtual machines (VMs), each containing a complete operating system, containers share the host operating system’s kernel. The result: significantly reduced resource overhead and faster startup times.
Containers vs. Virtual Machines
| Property | Docker Container | Virtual Machine |
|---|---|---|
| Startup Time | < 1 second | 30-60 seconds |
| Resource Overhead | Minimal (MB) | High (GB) |
| Isolation | Process-level | Hardware-level |
| Portability | High | Medium |
| Density | 100+ containers/host | 10-20 VMs/host |
Core Docker Concepts
Four concepts are central to deploying Docker in IT/OT architectures:
- Images: Immutable templates containing an application and all dependencies. An Eclipse Mosquitto image, for example, includes the MQTT broker, configuration files, and all required libraries.
- Containers: Running instances of an image. A container is isolated, has its own network interfaces, and can be stopped, restarted, or deleted at any time—without affecting the host system.
- Volumes: Persistent data storage that exists independent of the container lifecycle. Critical for OT applications: MQTT broker persistence, database data, or log files are stored in volumes.
- Networks: Docker-native networks for inter-container communication. Enables isolation: an OT container can run in a separate network from an IT dashboard container.
Three properties are particularly relevant for OT environments: determinism (identical runtime environments across sites), isolation (faulty components don’t affect other containers), and reproducibility (rapid recovery after hardware failures through image-based deployment).
Why Docker for IT/OT Architectures?
Adopting Docker for IT/OT architectures is not an end in itself. Container technology solves concrete problems that regularly occur in industrial environments.
Advantage 1: Consistent Deployment Environments
A classic OT problem: a protocol converter works flawlessly on the development system but fails in the plant because a different library version is installed there. Docker eliminates this “works on my machine” problem. A container image contains the exact runtime environment—identical in development, test, and production.
OT Relevance: Manual configuration is eliminated during commissioning of new sites. The same docker-compose.yml deploys the complete UNS stack: message broker, OPC UA connector, edge gateway for data harmonization, and Grafana for monitoring.
Advantage 2: Versioning and Rollback
Docker images are versioned like software artifacts. An MQTT broker runs with image eclipse-mosquitto:2.0.18. Problems occur after updating to 2.0.19? Rolling back to the previous version takes seconds:
docker-compose down
docker-compose up -d eclipse-mosquitto:2.0.18
OT Relevance: Rapid rollback is critical in production-adjacent systems. While traditional software updates cause hours of downtime, Docker enables zero-downtime updates through blue-green deployments.
Advantage 3: Isolation and Security
A compromised container remains isolated. Even if an attacker takes over a dashboard container, they have no direct access to the message broker container—provided network segmentation is correctly configured.
OT Relevance: Defense in depth is a core principle for secure UNS architectures. Docker enables separation by security levels: edge connectors with direct OT access run in a separate network from IT-side analytics containers.
Advantage 4: Resource Efficiency
An edge gateway with 8 GB RAM can easily operate five to ten containers: message broker, OPC UA connector, Modbus gateway, Telegraf for metrics, and i-flow Edge for local data processing. The same stack with VMs would require dedicated hardware.
OT Relevance: Edge hardware is expensive. Docker maximizes utilization of existing resources and reduces the number of devices required per production line.
Advantage 5: Scaling and Orchestration
When a message broker reaches capacity limits, Docker enables horizontal scaling: additional broker instances are automatically started. Orchestration tools like Kubernetes automate this process.
OT Relevance: Global production networks with dozens to hundreds of edge gateways require centralized management. Docker Swarm or Kubernetes enable deployment and monitoring of all containers from a central location.
Use Cases: Docker in the UNS Stack
Docker in IT/OT architectures is not a theoretical concept. The following use cases demonstrate how container technology is concretely applied in Unified Namespace implementations.
Message Brokers (NATS, MQTT)
The message broker is the heart of a UNS. NATS as a Docker container offers several advantages: minimal resource footprint, high-performance messaging, and flexible persistence via JetStream. MQTT with Eclipse Mosquitto is frequently used as an alternative. A detailed comparison can be found here.
docker run -d \
--name nats-server \
-p 4222:4222 \
-p 8222:8222 \
-v ./nats/config:/etc/nats \
-v nats_data:/data \
nats:2.10-alpine \
-c /etc/nats/nats-server.conf
Configuration resides in a volume—updates to the broker image don’t overwrite it. JetStream persistence, TLS certificates, and access control remain intact. NATS is particularly suited for cloud-native UNS architectures with high throughput requirements.
Edge Gateways (OPC UA, Modbus, Siemens S7 Connectors)
Protocol converters are ideally suited for container deployment. An OPC UA connector reads data from a PLC, transforms it to JSON, and publishes it via MQTT or NATS into the UNS. As containers:
- Simple updates without PLC interruption
- Multiple connectors on one gateway (OPC UA + Modbus + S7)
- Restart policies: automatic restart on failures
Typical multi-container setup: opcua-connector, mqtt-broker, telegraf (monitoring)—orchestrated via Docker Compose.
Data Processing (i-flow Edge)
Data harmonization is a core requirement in the UNS: raw data from PLCs is normalized, units are converted, and context is enriched. i-flow Edge is well-suited for this—and is particularly practical as a container. Container updates don’t overwrite existing configurations and processing pipelines.
Time-Series Databases (InfluxDB, TimescaleDB)
Historicizing UNS data requires time-series databases. InfluxDB as a container enables:
- Separate volumes for data and configuration
- Backup strategies via volume snapshots
- Upgrade testing in isolated environments
Critical: set memory and CPU limits to prevent resource starvation on edge devices.
Visualization (Grafana, Custom Dashboards)
Grafana containers with pre-configured dashboard setups can be replicated across hundreds of sites. A dashboard template as a JSON file is baked into the image—every new site receives identical visualizations.
docker run -d \
-p 3000:3000 \
-v grafana-storage:/var/lib/grafana \
grafana/grafana:latest
Architecture Patterns for Docker in IT/OT
Selecting the appropriate architecture pattern depends on scaling requirements, availability requirements, and network structure.
1. Single-Host Setup (Edge Gateway)
The simplest pattern: an edge gateway with Docker Compose orchestrates all containers locally.
Typical Components:
- NATS or MQTT broker (Eclipse Mosquitto)
- Protocol converter (e.g., i-flow Edge)
Use Case: Single production line with 10-50 machines. No redundancy required.
Advantages: Simple, maintainable, no external orchestration needed.
Limitations: Single point of failure. Data collection stops if the gateway fails.
2. Multi-Host Setup with Docker Swarm
Docker Swarm distributes containers across multiple hosts. Services can be replicated—if a host fails, Swarm restarts containers on another node.
Use Case: Multi-line factory with availability requirements. MQTT broker as a three-node cluster.
Advantages: Service replication, automatic failover, load balancing.
Limitations: More complex than single-host. Requires network overlay configuration.
3. Kubernetes for Enterprise-Scale
Kubernetes orchestrates containers at the data center level. Horizontal scaling, rolling updates, and service meshes enable highly available UNS infrastructures.
Use Case: Global UNS architecture across 20+ sites. Central broker cluster in the data center, edge gateways bridge locally.
Advantages: Maximum scalability, mature ecosystem (Helm charts, operators).
Limitations: High complexity. Requires dedicated DevOps/platform engineering teams.
4. Hybrid Edge-Cloud Architecture
The reality of many production networks: edge gateways with Docker Compose for local processing, Kubernetes in the data center for central services.
Data Flow:
- Edge containers collect data locally (OPC UA, Modbus)
- If required for the use case, a local edge message broker aggregates messages (typically MQTT)
- Bridge sends filtered data to central NATS broker cluster (Kubernetes)
- Cloud containers process data (analytics, ML inference, long-term storage)
Advantage: Optimal cost-benefit balance, edge autonomy, and centralized analysis.
Best Practices for Docker in OT Environments
When implementing Docker for IT/OT architectures, requirements differ significantly from traditional IT deployments in some aspects. The following best practices address OT-specific challenges.
Security Best Practices
- Principle of Least Privilege: Never run containers as
root. Images should define a dedicated user. Example for Mosquitto:USER mosquittoin the Dockerfile. - Network Segmentation: Separate Docker networks for OT and IT containers. A dashboard container must not run in the same network as a connector with direct PLC access.
- Image Scanning: Use tools like Trivy or Clair to identify known vulnerabilities in images—before deployment.
- Secrets Management: Don’t hardcode passwords or API keys in images. Use Docker Secrets (Swarm) or external secrets managers (HashiCorp Vault).
- Read-Only Filesystems: Start containers with the
--read-onlyflag when possible. Write access only via explicit volumes.
Persistence and Data
- Volumes Instead of Bind Mounts: Named volumes are more portable and performant.
-v mosquitto_data:/mosquitto/datainstead of-v /home/user/data:/mosquitto/data. - Backup Strategy: Automated volume backups via cron jobs or dedicated backup containers. Critical for MQTT retained messages and databases.
- Retained Messages: MQTT brokers must have persistence enabled (
persistence trueinmosquitto.conf), combined with volume mapping for/mosquitto/data. - Database Volumes: InfluxDB or TimescaleDB require separate volumes. Memory-mapped files benefit from SSD-backed storage.
Networking
- Host Network Mode: Use
--network hostonly when absolutely necessary (e.g., multicast for OPC UA discovery). Default: bridge networks with explicit port mapping. - Bridge Networks: Standard for multi-container setups. Containers can reach each other via service names:
mqtt://mosquitto:1883. - Port Mapping: Only expose ports that must be externally accessible. Internal container-to-container communication runs via Docker-internal DNS names.
- MQTT over TLS: Mount certificates via volumes. Mosquitto config:
cafile /mosquitto/certs/ca.crt,certfile /mosquitto/certs/server.crt,keyfile /mosquitto/certs/server.key.
Resource Management
- Memory Limits: Set
--memory 512mfor each container. Prevents out-of-memory kills on resource-constrained edge devices. - CPU Limits:
--cpus 1.5ensures fair sharing when multiple containers run on one host. - Restart Policies:
restart: unless-stoppedfor production containers. Automatic restart after host reboot or container crash. - Health Checks: Define health checks for critical services. Example for Mosquitto:
mosquitto_sub -t '$SYS/#' -C 1verifies broker availability.
Updates and Lifecycle
- Blue-Green Deployments: For critical brokers: start the new container (green) parallel to the old one (blue), test functionality, then switch. Zero downtime.
- Rolling Updates: In Kubernetes:
kubectl rollout restart deployment/mosquittorestarts pods successively—no interruption. - Image Versioning: Use semantic versioning.
eclipse-mosquitto:2.0.18, notlatest. Reproducibility is more important than recency. - Automated Updates: Watchtower can automatically update containers—but only in development environments. Production: manual updates after testing phase.
Monitoring and Logging
- Container Logs: Centralized logging via ELK stack or Grafana Loki. Logs persist even when containers are deleted.
- Metrics: Prometheus exporters for MQTT broker metrics (connections, messages/sec, topics). cAdvisor for container resources (CPU, RAM, network).
- Health Monitoring: Docker health checks combined with alerting (Prometheus Alertmanager, PagerDuty). Notification on container restarts.
- Performance: InfluxDB-Telegraf-Grafana stack (TIG) for long-term monitoring. Identifies performance degradation over weeks.
Challenges and Limitations
Docker is not a panacea. Certain OT requirements cannot be met with container technology, or only with limitations.
Real-Time Requirements
Docker containers run on standard Linux kernels. This means: process scheduling is subject to the operating system, not deterministic real-time guarantees. Soft real-time (response times < 100 ms) is not a problem—UNS components like MQTT brokers or OPC UA connectors work flawlessly. Hard real-time (< 1 ms, guaranteed) requires RTOS or bare-metal deployments.
Clarification: Most UNS components are not time-critical. Data collection from a PLC with a 100 ms polling interval benefits from Docker without violating RT requirements.
Complexity
Docker adds an abstraction layer. OT teams that previously installed directly on machines must learn Docker Compose, volumes, networking, and image management. Initial learning curve: 1-2 weeks for basics, several months for advanced orchestration.
Trade-off: Higher complexity in the short term, significantly reduced maintenance effort in the long term. A well-configured Docker setup is more maintainable than manually installed services.
Legacy Systems
Not all OT software can be containerized. Proprietary Windows applications without Linux equivalents are problematic. GUI-based SCADA systems requiring X11 only work in containers with considerable additional effort.
Solution: Hybrid architectures. Legacy systems remain bare-metal or in VMs, new components are deployed as containers.
Edge Device Limitations
Old edge gateways with 2 GB RAM or ARM CPUs without Docker support are not container-capable. Docker Desktop requires modern hardware; older industrial PCs fall short.
Alternative: Lightweight container runtimes like Podman (more resource-efficient) or balenaOS (specifically for edge IoT devices).
Conclusion
Docker for IT/OT architectures is more than a trend—it’s a fundamental improvement in how industrial software systems are deployed and operated. Container technology solves real problems: inconsistent runtime environments, lengthy updates, lack of modularity, and insufficient scalability. Three key advantages:
- Consistent Deployments Across Sites: A
docker-compose.ymlworks in plant 1 exactly as in plant 20. No manual installation errors, no version conflicts. - Modular UNS Components with Clear Interfaces: MQTT brokers, connectors, databases, and dashboards as isolated containers—interchangeable, testable, maintainable.
- Simplified Updates and Maintenance: Rollbacks in seconds, blue-green deployments without downtime, centralized orchestration across hundreds of gateways.
Container technology is therefore becoming the standard for edge deployments in Industrial IoT. Docker for IT/OT architectures is not the future, but already the present. Those who lay the groundwork today are prepared for the next generation of industrial software architectures.
