Docker volume vs subsystem for Software Payload

Here I read that one of the use cases for Subsystems is

  • Software Payload: images, configuration files, and license files
    But I think that the same Software Payload could be handled inside a docker volume, which is pre-populated by a container, as described here.
    Am I right?
    Which is the best approach for this needs?
    Are there pros, cons?

Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


Hello,

Choosing between Docker volumes and Subsystem Updates for managing software payloads on Torizon depends on the specific requirements of your application and the nature of the payloads you’re dealing with.

Docker Volumes:

  • Pros:
    • Ideal for applications that are containerized and require persistent or shared data.
    • Easy to manage with Docker commands or docker-compose, providing a straightforward way to handle data persistence across container restarts or updates.
    • Good isolation, as data can be managed separately from containers, allowing for clean application updates without affecting the stored data.
  • Cons:
    • Primarily designed for use with Docker containers. If your application or payload doesn’t neatly fit into a containerized architecture, this might not be the best approach.
    • Limited to the scope of Docker’s ecosystem. If your software payload needs to interact closely with the host system or requires specific system-level integrations, Docker volumes might not offer the flexibility you need.

Subsystem Updates:

  • Pros:
    • Offers a broader scope for updates beyond just containerized applications. This includes firmware for hardware components, applications for Cortex-M cores, or real-time units, which might not be suitable for Docker volumes.
    • Provides a framework for complex update scenarios, including conditional and scheduled updates, custom rollback triggers, and multi-step installation processes.
    • Designed with embedded systems in mind, allowing for a more integrated approach to managing software payloads that interact with the hardware or require specific system-level functionality.
  • Cons:
    • Potentially more complex to set up and manage compared to Docker volumes, especially if your use case is straightforward and fits well within a containerized model.
    • Requires a deeper understanding of the Torizon platform and its update mechanisms.

Which is the best approach?
The best approach depends on your specific needs:

  • If your software payload is closely tied to a containerized application and doesn’t require deep integration with the host system or specialized hardware, Docker volumes are a simple and effective solution.
  • If your payload includes elements that go beyond what’s practical or possible to manage within containers, such as firmware updates for custom hardware or applications for real-time processing units, Subsystem Updates provide a more comprehensive and flexible framework.

In summary, for purely containerized applications or when dealing with data persistence for such applications, Docker volumes are likely the easier path. For more complex scenarios involving hardware, system-level components, or when you need advanced update control features, Subsystem Updates are the better choice.

Best regards,

Please, also check if these links can help you solve your problem:

High performance, low power Embedded Computing Systems | Toradex Developer Center.

Hello @vix,

The @ToradexAI response is pretty much on point here.

I would also recommend that you have a look at the Subsystem Updates Overview page on the developer website, as it contains more information about subsystem updates and our motivation for making them available.

Best Regards,
Bruno

@vix,

We could maybe give more specific guidance if you had a specific use-case in mind here. Otherwise as Bruno and the AI have said, it depends on your exact use-case/requirements.

Best Regards,
Jeremias

@jeremias.tx and @bruno.tx
thanks.
My use case is quite simple:

  • branding assets (i.e., images, logos, …)
  • configuration files (i.e., files that enable some specific features)
  • Cortex-M firmware

I see. Well you could deliver those “sub-components” via Docker as you said. Though knowing your use-case now here are some things to consider.

Every time you do a docker-compose update your application will have some downtime due to needing to stop the old containers and bring up the new ones. Though perhaps this is fine for you.

Another thing to consider is the version management of all these things. By using docker-compose updates for everything you only have a single version to manage at a time, the version of the docker-compose package. This may get confusing in some cases where say for example you’re trying to deliver new Cortex-M firmware. Imagine you have docker-compose package version 1 with Contex-M firmware A and then docker-compose package version 2 with firmware B. The only difference is the firmware otherwise everything else in the docker-compose package is identical, say for example it has version 1 of your application code. You would need to somehow keep track of the version of multiple things in a single package. Not impossible, but possibly prone to error.

One final thing to consider that I’m thinking of is the rollback behavior here, which could be messy. A failure would cause the entire compose package to rollback to the previous version, but maybe you don’t want to rollback a sub-component like the firmware in that case. On the other hand maybe the compose update succeeds, but the sub-component like the Cortex-M firmware fails. The compose update wouldn’t pick up on the failure of something you delivered via a Docker volume making recovery of a bad update difficult in this case. At least with subsystems each component would have their own defined rollback behavior separate from one another.

Now all that said, these are just my thoughts on the matter. At the end of the day you know your system better than us. Choose what makes sense for you and your system.

Best Regards,
Jeremias

Hi @jeremias.tx
one new question just came to my mind.
How should I include the subsystems in tcbuild.yaml so that a full Torizon OS is built as a TEZI image?

How should I include the subsystems in tcbuild.yaml so that a full Torizon OS is built as a TEZI image?

Well enabling and configuring a new Subsystem component is just a matter of creating a series of new configuration files and an action handler script. You should be able to capture and deploy these filesystem customization same as you would any other filesystem customization using TorizonCore Builder: TorizonCore Builder Tool “build” command | Toradex Developer Center

This example is assuming all new files related to the new Subsystem component are located in /etc.

Best Regards,
Jeremias