ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
1

Minimizing ROS 2 Docker container size?

asked 2020-04-24 14:22:17 -0500

peterpolidoro gravatar image

updated 2020-04-28 10:29:24 -0500

Can colcon be used in a multi-stage Docker build to minimize the container size of ROS 2 images? Can colcon-bundle or something like it figure out the bare minimum dependencies so everything else can be excluded from the container image?

Perhaps it is just as good to just start with ros-core or ros-base and only add the necessary packages on top of them since most robots will already have those base images.

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.

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted
3

answered 2020-04-24 16:30:55 -0500

marguedas gravatar image

Can colcon be used in a multi-stage Docker build to minimize the container size of ROS 2 images?

Yes colcon can be used in multi-stage builds and it is expected (though I dont have numbers to compare) to yield you smaller images. Here you can find an example of a multi-stage build with colcon. An interesting work in progress is the ability to tell rosdep to install only specific dependency types (e.g. only runtime dependencies for your final image)

Is it possible to create even smaller container sizes, though, than ros-core or ros-base

This is something that would be great as when installing "metapackages" you always end up with some things you don't need. There has been a dicussion to provide a C++ only set of packages to be able to run a simple talker listener. This should yield much smaller images.

Or is ros-core already the bare minimum of what is needed?

Some work has been done recently to trim a bit the size of the ros_core images (ROS 1 or ROS2) https://github.com/osrf/docker_images... and https://discourse.ros.org/t/generatin.... That last discourse post emphasize the need for packages to declare as runtime dependencies only what they really need at runtime.

As far as ROS 2 images are concerned I believe there is still much size to be gained. One reason is that message packages debs are big in ROS 2 because they come with headers and libraries for each DDS implementation. By building these packages yourself with support for only 1 implementation you can reduce size significantly.

edit flag offensive delete link more
1

answered 2020-04-24 17:19:36 -0500

tfoote gravatar image

@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.

edit flag offensive delete link more

Comments

1

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 ...(more)

peterpolidoro gravatar image peterpolidoro  ( 2020-04-27 14:32:22 -0500 )edit

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.

tfoote gravatar image tfoote  ( 2020-04-27 16:24:24 -0500 )edit

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 ...(more)

peterpolidoro gravatar image peterpolidoro  ( 2020-04-28 09:48:12 -0500 )edit

@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.

gvdhoorn gravatar image gvdhoorn  ( 2020-04-28 09:52:54 -0500 )edit

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.

peterpolidoro gravatar image peterpolidoro  ( 2020-04-28 11:04:29 -0500 )edit

Question Tools

4 followers

Stats

Asked: 2020-04-24 14:22:17 -0500

Seen: 1,621 times

Last updated: Apr 28 '20