@marguedas Answered your more specific questions. For the more generic final question.
Is it possible to create even smaller container sizes, though, than ros-core or ros-base, for the cases when someone just wants to use Docker to quickly run examples like talker/listener without having to download the big base images first? Or is ros-core already the bare minimum of what is needed? Thanks.
Overall I’m sure that it’s possible to make our containers smaller with general technical improvements. However that’s not likely to fundamentally change the tradeoff of grouping packages for general purpose installations. If you want a super stripped down image for just the talker
example it can be much smaller. But if you then also want to run ros2 topic pub
it could also be significantly stripped down to use a much smaller container, but it will be a different container than talker
‘s container because they have non-overlapping depedencies. If you have a generic target like ros-core
or ros-base
you get the benefit that if you pull that one image, you have the necessary dependencies for both of those tools as well as many other common tools. But clearly the size of that image is going to be larger than just the dependencies for a specific component.
For a given application there are tradeoffs to be made as to how many tools you’ll want versus how much space and bandwidth you have available. For the simplest case, if you only have a very limited amount of space for images, then you have to make a custom stripped down image. If you have an intermediate amount of space and bandwidth available you then have to make the tradeoff of do you want more small images or fewer more generic images to provide coverage of the different functions that you need in your system. And of course at the other end of the spectrum if you have unrestricted size and bandwidth you can just have one large bundle of everything that you want.
The public images that we host are focused on providing the more generic images that are useful for a larger number of people. With the large number of packages and combinatoric complexity of selecting specific ones and their dependencies we can’t feasibly provide the precisely optimized images for each specific use case. And in that case I’d recommend looking at making the specific docker image which selects the specific debian packages that you want in your image. You can do that by forking the 32nd line of a 39 line Dockerfile used to create all our standard images.
Originally posted by tfoote with karma: 58457 on 2020-04-24
This answer was NOT ACCEPTED on the original site
Post score: 1
Original comments
Comment by peterpolidoro on 2020-04-27:
Thanks! The container sizes seem very reasonable for the generic images you provide. On robots with lots of packages, it seems fine to have big base images storing most of the dependencies. Those base images do not need to be transferred very frequently since they are shared by so many packages.
I was mostly curious about the case when you might only want to quickly run one or a couple of packages on a device. Then it might be nice to have a Dockerfile or method to build a container with the absolutely bare minimum dependencies to make it as small as possible.
I recently gave a talk to some scientists who had never heard of ROS before. They were very curious to try it. They wanted to run talkers and listeners on a set of computers just to get a sense for how it works. Downloading multiple GB desktop images to every computer to run such simple tutorial examples might scare new users. Just ros-core and those packages and dependencies would be nice, even less would be nicer.
Comment by tfoote on 2020-04-27:
There’s a possibility of trying to reduce that specific use case. Though I see most of our desktop images coming in between 700 and 800 MB. eloquent for example
And certainly if you’re trying things out on a robot, something without the GUI dependencies included might make sense. That could save probably a few hundred MB. But for most tutorials and introduction having the GUI tools is actually a strong part of the demo to show off the introspection and debugging capabilities which is actually one of the strongest drivers of adoption for ROS. So I’d rather not try to explicitly exclude them from our tutorials.
Comment by peterpolidoro on 2020-04-28:
I did not realize desktop images were so small, sorry. Maybe they just seem large to me since I’m stuck in quarantine with a very poor internet connection. Their relatively small size might make my original question nonsense, but I will try to clarify it more. Tutorials were not a good example. Say I have a sensor node that just publishes to a single topic. If I am running that node on a computer with lots of other nodes, perhaps it is optimal to base it on a desktop image shared with all of the other nodes. Then if I change my mind and want to move that node to a standalone microcontroller, it might be nice to shrink that node’s image. I am wondering if it is better to just build a new image based on core or if there is a multistage Docker build trick to just extract the bare minimum from the desktop-based image. Out of curiosity I am wondering if the bare minimum even needs the full core and full ubuntu or if it possible to pare it down to just a few compiled binaries or something.
Comment by gvdhoorn on 2020-04-28:
@peterpolidoro: I would suggest to read the Discourse thread linked by @marguedas as it discusses many of the same things that are mentioned here in your comments, @marguedas’ answer and @tfoote’s answer and comments.
Comment by peterpolidoro on 2020-04-28:
Oh I missed that link when reading the answer, there is a lot of great information in that discussion, thanks! Sorry for naively assuming there was a simple answer to what seems like a very nontrivial problem. Thank you everyone.