From 2da217c0cefd736ed2485a77ff850b4c66294b47 Mon Sep 17 00:00:00 2001 From: deeaitch Date: Mon, 3 Aug 2026 21:10:49 -0400 Subject: [PATCH] conters-based updates --- adr/ADR-006-container-based-updates.md | 177 +++++++++++++++++++++++++ 1 file changed, 177 insertions(+) create mode 100644 adr/ADR-006-container-based-updates.md diff --git a/adr/ADR-006-container-based-updates.md b/adr/ADR-006-container-based-updates.md new file mode 100644 index 0000000..b0078f4 --- /dev/null +++ b/adr/ADR-006-container-based-updates.md @@ -0,0 +1,177 @@ +# ADR-006: Container-Based Updates + +## Status + +Accepted + +## Context + +An OTA architecture must define the unit of update. + +One possible approach is to distribute software as a container that includes an application together with the user-space environment required to run it. + +Unlike a package-based update, a container is treated as a self-contained delivery unit that may include the application, libraries, runtime components, configuration, and other dependencies. + +In embedded Linux, container-based delivery is usually less common than in server environments and should be introduced only when it solves a clear architectural or organizational problem. + +## Decision + +Use container-based updates only when an application or subsystem must be delivered and maintained as an independent software product with minimal dependence on the target platform's user-space environment. + +Do not use containerization as a substitute for a well-designed system architecture. + +## Decision Drivers + +Container-based updates are preferred when: + +- the software subsystem is owned and maintained by a different organization; +- the supplier must support multiple compatible target platforms; +- the application must be delivered with its own user-space environment; +- changes to the host platform should have minimal impact on the delivered subsystem; +- the application or subsystem is maintained as an independent software product; +- the additional storage and runtime overhead are acceptable. + +## Consequences + +### Positive + +- The application is delivered together with its required user-space environment. +- Dependence on the host system's user-space libraries is reduced. +- A supplier can maintain a single delivery for multiple compatible platforms. +- Independent subsystems can follow their own release lifecycle. +- Conflicts between library versions used by separate subsystems are less likely. +- The ownership boundary between the subsystem supplier and the device integrator becomes explicit. + +### Negative + +- The delivered artifact is larger. +- Libraries and supporting components may be duplicated across containers. +- A container update typically replaces the container as a whole. +- Diagnosing and maintaining third-party containers is more difficult. +- The device integrator loses visibility and control over part of the delivered software. +- The container may become a black box whose internal composition is controlled by the supplier. +- The integrator may not know which library versions, build options, patches, tools, or auxiliary processes are present. +- Internal defects often cannot be corrected without supplier involvement. +- The container runtime becomes an additional part of the maintained platform. + +## Special Considerations + +### Independent Supplier + +Container-based delivery is most useful when a subsystem is supplied by a third party. + +It allows the supplier to distribute an almost complete software environment without adapting it to every customer's user-space platform. + +For the system integrator, this may simplify initial integration. It also reduces control over the subsystem's internal design and maintenance. + +Delivery convenience does not remove operational responsibility. The integrator must still supervise startup, resource usage, logging, health, updates, and interaction with the rest of the device. + +### Containers as Black Boxes + +Bundling a complete user-space environment transfers part of the control from the integrator to the supplier. + +Even when familiar libraries are included, the integrator may not be able to determine: + +- how they were built; +- which patches were applied; +- which optional features were enabled; +- which additional dependencies were included; +- which background processes are started; +- what changed between container releases. + +This complicates auditing, debugging, security review, and impact analysis. + +The less transparent the container contents are, the more the integrator depends on the supplier's release process, documentation, and long-term support. + +### Containerization Does Not Replace Architecture + +If the entire software stack is developed and maintained by one organization, the benefits of containerization are often limited. + +A well-designed package-based architecture can frequently provide similar lifecycle independence without introducing a separate user-space environment for each component. + +Containerization does not correct: + +- tightly coupled components; +- unstable interfaces; +- incorrect state management; +- poor service lifecycle design; +- inadequate observability; +- weak diagnostics. + +Wrapping a poorly designed component in a container does not make it independent. + +### Fault Isolation + +Containers are often presented as a fault-tolerance mechanism. + +In most embedded Linux systems, user-space processes are already isolated by the operating system. A correctly designed service can fail without terminating unrelated services and can be restarted by a supervisor, watchdog, or service manager. + +Restarting a container therefore does not necessarily provide stronger fault isolation than restarting a process, and may consume more time and resources. + +Containerization also does not protect against a shared kernel failure. A kernel panic remains fatal to both containerized and non-containerized user-space architectures. + +Systems that isolate complete operating systems under a hypervisor or a safety-certified RTOS use a different architectural model and are outside the scope of this ADR. + +### Different Library Versions + +Containers can be useful when independent subsystems require incompatible versions of the same libraries. + +However, this does not always require full containerization. + +In many embedded Linux systems, a component can ship with private libraries in its own directory and load them independently from the platform-wide versions. + +Different library requirements alone are therefore not sufficient justification for introducing containers. + +## Limitations + +Containerization does not eliminate software maintenance. + +It transfers part of the responsibility for the user-space environment from the device developer to the container supplier. + +If the supplier does not provide timely bug fixes, security updates, or new compatible releases, the integrator may have little practical ability to maintain the container internals independently. + +Container updates and rollbacks may also replace the entire bundled user space even when only one internal component changed. + +This approach therefore requires: + +- a high level of trust in the supplier; +- a transparent release process; +- documented container contents; +- long-term maintenance commitments; +- clear diagnostic and update procedures. + +## Applicability + +This approach is well suited when: + +- the subsystem is supplied and maintained by an independent organization; +- the supplier must minimize dependence on the customer's user-space platform; +- the application or subsystem is an independently maintained product; +- a clear responsibility boundary between supplier and integrator is required; +- additional storage, memory, and runtime overhead are acceptable; +- independent delivery is more valuable than full control over the implementation. + +Another approach should be considered when: + +- the complete software stack is developed by one organization; +- components can be delivered as independent packages; +- storage, memory, or OTA download size are critical; +- full control over all device software is required; +- simple component-level rollback is important; +- containers are used only as packaging for ordinary services; +- expected fault tolerance is already provided by Linux process isolation and supervisor mechanisms. + +## Alternatives Considered + +The following alternatives are described in separate ADRs: + +- full-system image updates; +- package-based updates; +- versioned filesystem trees; +- hybrid update strategies. + +## Summary + +Containerization primarily solves organizational problems related to the delivery and maintenance of independently owned software subsystems. + +When all software components are controlled by one engineering organization, a well-designed package-based architecture often provides the same practical benefits with significantly less system complexity.