Test Container Isolation
Relevant source files
The following files were used as context for generating this wiki page:
Test Container Isolation in the mt5linux project ensures that the MetaTrader 5 (MT5) environment used for automated testing is completely segregated from production environments and other concurrent test instances. This is achieved through a combination of parametrized Docker Compose configurations, unique network namespaces, and dedicated storage volumes. The primary goal is to prevent port collisions, data leakage, and state pollution between different testing scenarios.
The system relies on MT5Settings as the single source of truth for configuration, defining specific port ranges and naming conventions for containers. Each test session automatically provisions an isolated container instance (typically named mt5linux-test) which runs the MT5 terminal via Wine and exposes a gRPC interface for the Python client.
Sources: DOCKER_COMPOSE_USAGE.md:3-8, tests/conftest.py:10-18, docker-compose.yaml:3-23
Architecture and Components
The isolation architecture is built upon three pillars: Port Strategy, Volume Isolation, and Network Segregation. Each container instance is a self-contained unit running the marlonsc/mt5-docker:debian image.
Port Strategy
The project uses distinct port ranges to differentiate between production, generic Docker usage, and isolated test runs. This allows developers to run tests on a local machine without interrupting a live trading instance.
| Environment | gRPC Port | VNC Port | Health Port |
|---|---|---|---|
| Production | 8001 (Internal) | 3000 (Internal) | 8002 (Internal) |
| Default Docker | 38812 | 33000 | 38002 |
| Isolated Test | 28812 | 23000 | 28002 |
Sources: mt5linux/constants.py:22-30, docker-compose.yaml:7-12, tests/conftest.py:46-51
Volume and Data Isolation
Volumes are dynamically named based on the MT5_CONTAINER_NAME environment variable. This ensures that even if multiple containers are running, their settings, downloads, and cache files are stored in separate Docker volumes.
The diagram above illustrates how the container name parameter dictates volume mapping to prevent data overlap.
Sources: DOCKER_COMPOSE_USAGE.md:83-93, docker-compose.yaml:73-77
Implementation Logic
The isolation logic is implemented primarily within tests/conftest.py through pytest fixtures. These fixtures manage the container lifecycle before and after test execution.
Automated Provisioning
The ensure_docker_and_codegen fixture follows a specific hierarchy to ensure a clean test environment:
- Check Docker Availability: Skips if Docker is not installed or
SKIP_DOCKER=1is set. - Environment Loading: Loads
.env.testfirst (isolated defaults), then overrides with.envfor credentials. - Command Execution: Runs
docker compose up -dwith environment variables mapping host ports to the container's internal ports. - Health Verification: Performs a gRPC
GetConstantscall to verify the service is not just listening, but fully initialized.
Sources: tests/conftest.py:34-44, tests/conftest.py:176-215, tests/conftest.py:290-305
Network Segregation
Each container instance is assigned a per-instance network. This prevents cross-talk and collisions when running several instances of the bridge in parallel.
The textual representation shows that even on the same Docker host, the networks are logically separated based on the container name.
Sources: docker-compose.yaml:81-86
Configuration Parameters
The following variables control the isolation behavior and can be passed at runtime or defined in .env.test.
| Variable | Default | Source of Truth |
|---|---|---|
MT5_CONTAINER_NAME | mt5linux-test | MT5Settings.test_container_name |
MT5_GRPC_PORT | 28812 | MT5Settings.test_grpc_port |
MT5_VNC_PORT | 23000 | MT5Settings.test_vnc_port |
MT5_HEALTH_PORT | 28002 | MT5Settings.test_health_port |
Sources: DOCKER_COMPOSE_USAGE.md:20-28, tests/conftest.py:46-54
Volume Naming Convention
Volumes follow the pattern ${MT5_CONTAINER_NAME}_settings. In an isolated test run, this defaults to mt5linux-test_settings. This separation is critical for maintaining "Clean startup" and "Clean teardown" phases, where fixtures can remove old volumes without affecting production data.
Sources: DOCKER_COMPOSE_USAGE.md:83-88, DOCKER_COMPOSE_USAGE.md:95-101
Conclusion
Test Container Isolation provides a robust framework for reliable CI/CD and local development. By parametrizing container names, ports, and networks, the mt5linux project ensures that the gRPC bridge and MT5 terminal remain in a predictable, isolated state, regardless of other activities on the host system.
Sources: DOCKER_COMPOSE_USAGE.md:104-112, tests/integration/test_fixture_resilience.py:97-120