Revision history [back]

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

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

@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_ros2_workspace 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_) 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_ 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.