Module container 

Container backend — fire up an OCI container instance (e.g. a redis service) over a container runtime.

Draupnir does not reimplement a runtime. This backend is the thin adapter that maps a Draupnir BootSpec onto bollard — the async podman/Docker REST client jera already drives for its zero-shell container path — and runs the container lifecycle over it. Reusing bollard keeps one container engine across the constellation rather than a second bespoke one.

It sits behind the backend-oci feature so the default build stays pure-std; the trait wiring compiles unconditionally. Zero-shell: every operation is a Rust API call over the podman/Docker socket — never a podman/docker subprocess. If no daemon is reachable the backend degrades with a clear error (there is deliberately no CLI fallback), it never fakes a boot.

Structs

ContainerBoot

The OCI container boot backend.

RunOptions

Knobs for run_to_completion: how long to wait for the container to exit and how often to poll its state. Default waits indefinitely (parity with jera’s blocking wait_container) and polls every 200 ms.

RunOutcome

The terminal result of a run_to_completion job: the container’s exit code plus its captured logs, split into stdout / stderr.

Enums

ContainerState

The lifecycle state of a container as read from the engine — the richer projection a job runner (jera) needs, one level below the generic power Lifecycle (which collapses every non-running state to PowerState::Off and so cannot tell a clean exit from a crash). Mirrors jera’s own EngineState so a container boot’s status/log model is preserved verbatim when it delegates here.

Readiness

How draupnir decides a container is app-ready — one level above the bare running power state. ContainerBoot::wait_ready blocks on this until it holds or the timeout elapses.

Traits

ContainerControl

Container-specific control beyond the generic power Lifecycle: an exit-code-aware ContainerState and a streamed-log drain, plus a stop that removes the container. This is the seam a job handler (jera) maps onto its own boot status + log model, so the ONE bollard engine lives here in draupnir and jera keeps only job policy — no second engine.

Functions

run_to_completion

Run a container to completion in one call — start it, wait for it to exit, collect its logs, and return an exit-code-aware RunOutcome. This is the missing seam that lets jera’s run-to-completion run_container (and, above it, nornir::jobs::run_container) route through draupnir’s one OCI engine instead of jera’s duplicate BollardEngine — the run-to-completion analogue of how a VM/container boot already delegates through Boot.