Multi-container

Multi-container¶

For isolation and distribution, OEDI-SI can run each component in its own container. Instead of local processes coordinated by a local broker, the components talk to an orchestrator over a small REST contract while HELICS still handles the co-simulation messaging between them.

The REST contract¶

Every containerized component exposes the three endpoints from Build a component:

Method & path	Purpose
`GET /`	Health check — returns the container’s hostname and IP.
`POST /configure`	Receive a `ComponentStruct`; write `input_mapping.json` + `static_inputs.json`.
`POST /run`	Receive a `BrokerConfig`; launch the federate.

1. Add hosts and ports to the wiring diagram¶

In multi-container mode each Component needs a host and a container_port so the orchestrator can reach it:

{
  "name": "feeder",
  "type": "LocalFeeder",
  "host": "feeder",
  "container_port": 5678,
  "parameters": { "feeder_file": "..." }
}

2. Build the container artifacts¶

Pass -m/--multi-container to oedisi build. Instead of a single system_runner.json, it generates per-component Dockerfiles, a docker-compose.yml, and Kubernetes manifests:

oedisi build -m --system scenario.json --component-dict components.json

See oedisi build for all options (target directory, broker port, simulation id).

3. Launch¶

Run the generated system with either backend:

oedisi run-mc --runner build/docker-compose.yml -d   # Docker Compose
oedisi run-mc --runner build/kubernetes -k           # Kubernetes

oedisi run-mc prunes stale Docker systems/networks first, then brings the containers up. See oedisi run-mc.

How it fits together¶

The wiring diagram and data types are identical to the single-container path — only packaging and transport change.