====== 14.2 Container Design Principles ======

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

[[fxdemo:05-part:14-containerisation:start | Return to Containerisation ]]

The team should design containers around clear runtime responsibilities. In Phase 0, a container may package one [[dido:99_annexes:annex-b-terms-and-definitions:n:node|Node]], a support service, an observer, or a tooling function. The container name, image name, Configuration, logs, and documentation should make that responsibility clear.

Container design should follow these principles:

  - Keep container responsibilities clear and narrow.
  - Avoid bundling unrelated Nodes or tools into one container unless the phase Baseline requires it.
  - Keep runtime Configuration outside the image where practical.
  - Avoid embedding secrets, credentials, personal paths, or machine-specific settings in images.
  - Use reproducible build inputs.
  - Use approved generated [[dido:99_annexes:annex-b-terms-and-definitions:a:artifact|Artifacts]] and source files.
  - Keep image names and tags consistent with the naming conventions.
  - Make logs available outside the container where acceptance Evidence requires them.
  - Allow controlled startup and shutdown.
  - Avoid requiring manual steps inside a running container.

A container should run the same Artifact that the team documents in the Node Catalogue or support-service documentation. If a container image contains generated DDS types, Node code, scripts, or Configuration defaults, the build process should trace those inputs to Repository-controlled sources.

----

<WRAP centeralign>

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

</WRAP>