At the Institute for Automotive Engineering at RWTH Aachen University, we have moved to a more and more containerized stack of ROS applications over the years. We use ROS containers for the development and deployment of our automated driving functions for connected intelligent transport systems.
We are happy to announce that we have open-sourced docker-run, a CLI tool for simplified interaction with Docker images.
Working with Docker images in the context of robotics, one usually wants to launch containers with additional configuration in order to, e.g., enable GUI forwarding or GPU access. From our own experience we know that many people resort to custom bash scripts for launching containers with custom configuration. While this works, it is often custom-tailored to specific needs and developers not only need to know Docker, but also how to operate the custom scripts.
This is where docker-run comes in. It works exactly the same way as the Docker’s official docker run CLI, but extends it with useful defaults. Note that docker-run is not limited to ROS-based containers or robotics in general, but can add value to any container-driven workflow.
Good news, thank you for our effort guys!
I am currently using the rocker, although docker-run has the greatest options, the same options also available for rocker.
So I want to ask you what is the advantage of docker-run? Why do i stop using rocker?
There are a couple of differences in how docker-run and rocker work.
docker-run can be used in exactly the same way as the official docker run command. You can easily launch a container with docker-run defaults such as GUI forwarding or GPU support enabled, but at the same time also pass other Docker-native options such as port exposition or volume mounting. Note that docker-run only sets runtime flags for launching a new container of an existing image.
rocker always builds a dedicated new Docker image based on a given base image. At the same time, it also sets the required runtime flags (similar to docker-run) for enabling things like GPU support. This definitely slows down the initial launch process a bit, since a new image is either built or read from image cache each time. On the other hand, this approach allows rocker to inject some installation steps into the base image.
We feel like docker-run covers most of rocker’s features, even though it is only setting runtime flags for starting the container. One noteworthy feature of rocker is that it sets up a new user with appropriate permissions in the image that is built, such that no permission conflicts between host user files and container files arise. While docker-run cannot solve this problem on its own through runtime flags, its docker-ros plugin also solves permission errors by setting up a new user on-the-fly during container launch. This works with compatible images such as our docker-ros-ml-images or the ones built by docker-ros.
One last highlight of docker-run is that in principle is doesn’t relate to ROS at all, but is useful for any kind of Docker container.