Files
lmxopcua/tests/Drivers/ZB.MOM.WW.OtOpcUa.Driver.Modbus.IntegrationTests/Docker/docker-compose.yml
T
Joseph Doherty fc08892eb3 fix(modbus-fixture): run pymodbus sim without asyncio debug mode; FC03 healthcheck + watchdog (#909)
Root cause: pymodbus 3.13's `pymodbus.simulator` console script hard-codes
asyncio.run(run_main(), debug=True). Debug mode captures a traceback per
scheduled callback and logs callbacks slower than 100 ms (the "took 0.146
seconds" lines in #909). Side by side on the shared docker host (closed-loop
FC03 clients, 2 s deadline): 100 clients got ~120-170 req/s, p99 1.6-1.9 s
with client timeouts in debug mode vs ~2400 req/s, p99 ~135 ms without it.
The shared sim also carries the docker-dev rig's 49 Modbus drivers on each of
central-1/central-2 (98 sockets, ~220 req/s at idle), which is above the
debug-mode capacity, so a test run on top was answered late ("Cancel send,
because not connected!") and timed out.

- run_simulator.py: same CLI as pymodbus.simulator, debug=False, plus a watchdog
  thread that exits after 3 failed FC03 probes so restart: unless-stopped
  replaces the container (docker has no restart-on-unhealthy).
- fc3_probe.py: stdlib FC03 read with a deadline (MBAP or RTU framing); the
  compose healthcheck.
- docker-compose.yml: shared anchor for every pymodbus service: new entrypoint,
  `project: lmxopcua` label, restart: unless-stopped, healthcheck, bounded
  json-file logs.
- README: why, the numbers, and how to diagnose load.
2026-11-13 11:03:08 -05:00

141 lines
4.7 KiB
YAML

# Modbus integration-test fixture — pymodbus simulator.
#
# One service per profile. Bring up only the profile a test class needs;
# they all bind :5020 on the host so can't run concurrently. The compose
# `profiles:` feature gates which service spins up via `--profile <name>`.
#
# Usage:
# docker compose --profile standard up
# docker compose --profile dl205 up
# docker compose --profile mitsubishi up
# docker compose --profile s7_1500 up
#
# #909 hardening, shared by every pymodbus service through the anchors below:
# * the simulator starts through run_simulator.py, never the stock `pymodbus.simulator`
# console script, because that script hard-codes asyncio debug mode (>10x slower; see
# run_simulator.py for the measurements);
# * a healthcheck that does a real FC03 read with a deadline (fc3_probe.py). A TCP
# connect is not enough: the #909 sim accepted connections and answered late;
# * run_simulator.py's in-container watchdog exits after 3 failed probes (~30 s), and
# `restart: unless-stopped` brings up a fresh container (docker has no
# restart-on-unhealthy, and an autoheal sidecar would need the docker socket);
# * bounded json-file logs (the old container had kept 440k+ lines since October).
x-pymodbus: &pymodbus
image: otopcua-pymodbus:3.13.0
build:
context: .
dockerfile: Dockerfile
labels:
project: lmxopcua
restart: unless-stopped
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"
x-healthcheck: &fc3-healthcheck
test: ["CMD", "python", "/fixtures/fc3_probe.py", "--port", "5020", "--deadline", "3"]
interval: 15s
timeout: 5s
retries: 3
start_period: 10s
services:
standard:
<<: *pymodbus
profiles: ["standard"]
container_name: otopcua-pymodbus-standard
ports:
- "5020:5020"
healthcheck: *fc3-healthcheck
command: [
"python", "/fixtures/run_simulator.py",
"--modbus_server", "srv",
"--modbus_device", "dev",
"--json_file", "/fixtures/standard.json"
]
dl205:
<<: *pymodbus
profiles: ["dl205"]
container_name: otopcua-pymodbus-dl205
ports:
- "5020:5020"
healthcheck: *fc3-healthcheck
command: [
"python", "/fixtures/run_simulator.py",
"--modbus_server", "srv",
"--modbus_device", "dev",
"--json_file", "/fixtures/dl205.json"
]
mitsubishi:
<<: *pymodbus
profiles: ["mitsubishi"]
container_name: otopcua-pymodbus-mitsubishi
ports:
- "5020:5020"
healthcheck: *fc3-healthcheck
command: [
"python", "/fixtures/run_simulator.py",
"--modbus_server", "srv",
"--modbus_device", "dev",
"--json_file", "/fixtures/mitsubishi.json"
]
s7_1500:
<<: *pymodbus
profiles: ["s7_1500"]
container_name: otopcua-pymodbus-s7_1500
ports:
- "5020:5020"
healthcheck: *fc3-healthcheck
command: [
"python", "/fixtures/run_simulator.py",
"--modbus_server", "srv",
"--modbus_device", "dev",
"--json_file", "/fixtures/s7_1500.json"
]
# RTU-over-TCP profile. Same pymodbus simulator, but the server is framed
# RTU (framer=rtu) instead of socket/MBAP — this is what a serial→Ethernet
# gateway presents. Binds :5021 (NOT the shared :5020) so it co-runs with
# the `standard` profile: two families, two ports, no conflict. Serves
# rtu_over_tcp.json (byte-for-byte standard.json + framer/port swap).
rtu_over_tcp:
<<: *pymodbus
profiles: ["rtu_over_tcp"]
container_name: otopcua-pymodbus-rtu_over_tcp
ports:
- "5021:5021"
healthcheck:
<<: *fc3-healthcheck
test: ["CMD", "python", "/fixtures/fc3_probe.py", "--port", "5021", "--framer", "rtu", "--deadline", "3"]
command: [
"python", "/fixtures/run_simulator.py",
"--modbus_server", "srv",
"--modbus_device", "dev",
"--json_file", "/fixtures/rtu_over_tcp.json"
]
# Exception-injection profile. Runs the standalone pure-stdlib Modbus/TCP
# server shipped as exception_injector.py instead of the pymodbus
# simulator — pymodbus naturally emits only exception codes 02 + 03, and
# this profile extends integration coverage to the other codes the
# driver's MapModbusExceptionToStatus table handles (01, 04, 05, 06,
# 0A, 0B). Rules are driven by exception_injection.json. No asyncio debug
# mode and no watchdog here; the FC03 healthcheck still applies (an
# exception reply counts as a timely answer).
exception_injection:
<<: *pymodbus
profiles: ["exception_injection"]
container_name: otopcua-modbus-exception-injector
ports:
- "5020:5020"
healthcheck: *fc3-healthcheck
command: [
"python", "/fixtures/exception_injector.py",
"--config", "/fixtures/exception_injection.json"
]