Relevant ROS Discourse discussions: Generating ‘dev’ and runtime artefacts from ROS packages and [RFC] Restricting the size of ROS docker images.

Thank you for these readings, I have to admit that I did not understood 100% but that was very interresting.
My understanding is that OSRF official images weight is mainly due to ros "runtime" deps that are allready optimized.
That will make me think twice about multicontainer docker-composed app :(

My understanding is that OSRF official images weight is mainly due to ros "runtime" deps that are allready optimized.

I'm not sure what you are writing here.

My understanding is that it's mostly due to how Debian packages work: even if you need only a tiny part of a dependency, you'll still have to install the complete Debian package. That's normal and accepted: packages cannot consist of only single files, so they (logically) group things together, leading to larger sizes (but less packages).

Follow this reasoning over a couple 'layers' of dependencies, and it quickly leads to MBs of 'wasted' space, because transitively, many dependencies will depend on only small parts of their dependencies, and so on.

That will make me think twice about multicontainer docker-composed app

why exactly? AFAIK and IIRC, Docker is capable of caching and deduplication per layer, so if you have multiple images starting FROM the same image, there should be no duplication. Or at least not up to the point where your changes start.

That will make me think twice about multicontainer docker-composed app because I am using balena fleet management system which, if I rellay want to eg. split my ROS app into multiple containers, lead to N services in docker-compose, which leads to N * 730MB services running on my final device.

EDIT: regarding you first comment about "my understanding", that is what I thought, explaining it too simply, thank you again for your clarifications.

In conclusion, I can split my ROS app into multiple docker services on a balena device only if I am okay with that 730MB duplication, so I will have to analyse pros and cons !

thank you again

In conclusion, I can split my ROS app into multiple docker services on a balena device only if I am okay with that 730MB duplication

I'm repeating myself, but: IIUC, that wouldn't necessarily be the case.

See my earlier comment about layer caching and deduplication in Docker. I'd suggest to try it with a small experiment and verify.

That what I did earlier this morning. I can confirm that each of my service weight 730MB. that's probably due to how balena "modified" docker engin works... I will investigate that later if times allow it.

On a regular Docker system/install you could run docker system df -v to see how big each Docker image "really" is. Especially with only a couple of images, the relationship between what they share and their size should be relatively easy to figure out.

I don't know what Balena did, so I can't comment there. If they're using/providing a stand-alone/isolated environment per image, then it's possible they can't share with other images.