5.6 Docker / Container Environment [Dido Solutions, Inc Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 5.6 Docker / Container Environment ======

[[fxdemo:05-part:start | Go To Top ]]

[[fxdemo:05-part:05-development-environment:start | Return to Development Environment ]]

The Phase 0 development environment should use containers to make the [[dido:99_annexes:annex-b-terms-and-definitions:n:node|Node]] network easier to build, run, stop, inspect, and reproduce. The team should define the supported container runtime, container build commands, networking assumptions, volume mappings, image naming conventions, and cleanup procedures.

The container environment should support [[dido:99_annexes:annex-b-terms-and-definitions:r:reproducibility|Repeatable]] execution. Developers should be able to build the required images, run the Node network, observe logs, stop the network, and remove temporary runtime [[dido:99_annexes:annex-b-terms-and-definitions:a:artifact|Artifacts]] using documented scripts.

Container definitions should not hide architectural meaning. A container packages and runs implementation Artifacts; it does not define the [[dido:99_annexes:annex-b-terms-and-definitions:l:logical_architecture|Logical Architecture]]. The team should keep Node Roles, topics, [[dido:99_annexes:annex-b-terms-and-definitions:l:lifecycle|Lifecycle]] behaviour, and [[dido:99_annexes:annex-b-terms-and-definitions:c:control_plane|Control Plane]] semantics traceable to the architecture and the handbook, rather than burying them solely in container files.

The team should document whether Phase 0 uses Docker, Docker Compose, Podman, or another container mechanism. If the team supports multiple tools, the handbook should identify the primary [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baseline]] tool and any supported alternatives.

----

<WRAP centeralign>

© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.

</WRAP>