14.1 Purpose of Containerisation in Phase 0 [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.1 Purpose of Containerisation in Phase 0 ======

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

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

Phase 0 uses containerisation to make the executable [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baseline]] easier to reproduce across developer workstations, test environments, CI runners, and demonstration environments. A container should package a defined runtime participant or support service with the dependencies it needs to run.

Containerisation should support the following goals:

  - Reduce differences between developer machines.
  - Package Nodes and support services consistently.
  - Make build and run workflows repeatable.
  - Keep runtime Configuration explicit.
  - Support controlled startup and shutdown.
  - Preserve logs and [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]].
  - Improve troubleshooting.
  - Prepare the project for later deployment refinement.

Containers should not hide architectural meaning. A container packages an implementation [[dido:99_annexes:annex-b-terms-and-definitions:a:artifact|Artifact]]. It does not define the logical architecture, Node Role, topic model, [[dido:99_annexes:annex-b-terms-and-definitions:l:lifecycle|Lifecycle]] semantics, or data-governance meaning. The Node Catalogue, Topic Catalogue, [[dido:99_annexes:annex-b-terms-and-definitions:i:idl|IDL]] definitions, [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]] files, and architecture documents remain the authoritative sources for those concerns.

----

<WRAP centeralign>

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

</WRAP>