ROS2 Docker development practice (volume mounting)

edit

I can recommend using remote development in vscode using this template: https://github.com/athackst/vscode_ro...

This is only for development, but I think it can be easily converted to a deployable docker container. This dev environment will be mounting onto your work directories root folder and thereby the development is "local" while you are building inside the docker container.

The only issue I have encountered so far is having to bind hardware(USB ports, etc.) to the docker container before running the dev environment. But in general, it works pretty nicely.

This might not be a direct answer to 1. or 2. but I think it is a better way of developing as you do not have to rebuild your container every time you want to recompile.

We have a docker environment working well for us. As you suggested, we mount volumes from the host into docker with the -v option. Typically we have a workspace folder which has all our ros2 workspaces and we map a workspace folder from the host into the docker. The rosdep output is written to your home $HOME/.ros folder. So we create a .ros folder on the host and map it to $HOME/.ros folder. This way the rosdep output is not lost when we exit the docker. There are probably other approaches as well but this is what we do and it works for us. Hope this helps.

@ThomasL624 I have found it best to separate Dockerized development from Dockerized deployment. It is usually best to have a minimal image for deployment that contains just the install space (binaries, libraries, configuration, etc.) required to execute your application without any source code or git files.

I have used a customized version of https://github.com/athackst/vscode_ro... for Dockerized development with success, but the linked template does not include functionality for resolving workspace dependencies using rosdep. The solution I have used to address this limitation is to include resolving the rosdeps in the Dockerfile (used by devcontainer.json) as one of the last layers. The user is required to manually rebuild the vscode container periodically. If the commands utilized in the Dockerfile are efficient rebuilding the container will utilize Docker cache when there are no changes to the installed rosdep dependencies.

https://hub.docker.com/r/arm64v8/ros/ provides an example of using a muli-stage Docker build for caching the rosdeps, the key content is:

# copy manifests for caching
WORKDIR /opt
RUN mkdir -p /tmp/opt && \
find ./ -name "package.xml" | \
  xargs cp --parents -t /tmp/opt && \
find ./ -name "COLCON_IGNORE" | \
  xargs cp --parents -t /tmp/opt || true

That copies the just the non-ignored package.xml files (including the folder structure) in a temporary directory that can be copied by a different stage to run rosdep on. Then the dependencies are installed:

COPY --from=cacher /tmp/$OVERLAY_WS/src ./src
RUN . /opt/ros/$ROS_DISTRO/setup.sh && \
apt-get update && rosdep install -y \
  --from-paths \
    src/ros2/demos/demo_nodes_cpp \
    src/ros2/demos/demo_nodes_py \
  --ignore-src \
&& rm -rf /var/lib/apt/lists/*

Obviously, you should tailor the --from-paths argument to either specify your entire src folder or specific packages.

Once the developer rebuilds the container based on a specific branch of the workspace repository all the necessary dependencies will be installed.

The same link can be used as a template to create a separate Docker image that is just used for deployment.