14.4 Container Runtime Configuration [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.
====== 14.4 Container Runtime Configuration ======

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

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

Containers should receive runtime [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]] through approved mechanisms, such as Configuration files, environment variables, command-line arguments, mounted volumes, or container orchestration settings.

Runtime Configuration should identify:

  - [[dido:99_annexes:annex-b-terms-and-definitions:n:node|Node]] Identity.
  - Node Role.
  - Runtime profile.
  - [[dido:99_annexes:annex-b-terms-and-definitions:d:dds|DDS]] Configuration.
  - Topic Configuration.
  - QoS profile references.
  - Logging Configuration.
  - Input and output locations, where applicable.
  - [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] or log export locations.
  - Required credentials or secret references, where applicable.

The team should distinguish [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baseline]] Configuration from local overrides. Baseline Configuration should support repeatable execution. Local overrides should remain clearly marked and should not be entered into the controlled Baseline unless the team explicitly approves them.

Containers should not require developers to edit files inside a running container. Developers should modify Repository-controlled Configuration, rebuild the image where needed, and rerun the container through the approved scripts.

----

<WRAP centeralign>

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

</WRAP>