Ubuntu Linux for Robotics · Lesson 30 of 96

Deploying containers on Linux

Dockerfiles, compose, restart policies, updates and keeping robot images small.

Estimated time · 60–90 min

Learning goals

What you will understand

Explain deploying containers on linux in your own words
Use it in a small workstation example
Verify the result instead of assuming it worked

Understand the idea first

The mental model

A Dockerfile describes how to build your robot image: start FROM a ROS 2 base image, install dependencies with rosdep, copy your source, build with colcon and set a command. docker build creates the image; docker compose describes several containers (driver, navigation, perception) and how they start together.

For deployment give containers a restart policy (restart: unless-stopped), mount device files (--device /dev/ttyUSB0) instead of using --privileged, and use versioned image tags so you can roll back. Keep images small by using multi-stage builds and removing apt caches. Test the exact image you deploy.

Guided lesson

Work through these steps

1.
Open a terminal and record the current state before changing anything.
2.
Read the deploying containers on linux commands and predict what each one does.
3.
Run the commands one at a time and compare each output with your prediction.
4.
Write the commands that worked in a setup note you can repeat later.

Worked example

Read it before you run it

FROM osrf/ros:lyrical-ros-base
# Start from the official ROS 2 base image.
COPY src /ws/src
# Copy the source into the image.
RUN . /opt/ros/lyrical/setup.sh && cd /ws && rosdep install --from-paths src --ignore-src -y && colcon build
# Install dependencies and build inside the image.
CMD ["bash", "-c", "source /ws/install/setup.bash && ros2 launch robot_bringup bringup.launch.py"]
# Start the robot when the container runs.
docker build -t robot:1.0 .
# Build and tag the image.
docker run -d --restart unless-stopped --network host --device /dev/ttyUSB0 robot:1.0
# Run it in the background, restart automatically, with only one device passed in.

What the example is doing

1.Lines without sudo only inspect or change files you own; sudo authorizes a system-wide change.
2.Read command output before moving to the next line. Stop if names, versions, disks, or paths differ from the lesson.
3.Comments beginning with # explain safety checks and are not executed by the shell.

Watch it run · The robot's computer

See what this code does

The terminal types this lesson's practice solution and runs it. The scene shows the kind of robot behaviour that code drives. It plays by itself and loops.

Practice code

Now type it yourself

Open a terminal, run the starter line by line (or save it as practice.sh and run bash practice.sh), and replace every TODO with your own command.

# TODO: build the image from the current folder and tag it robot:1.0
docker run -d --restart unless-stopped --network host robot:1.0
docker ps

Expected output

The container robot:1.0 is running

Stuck? Show the full solution (try it yourself first)

docker build -t robot:1.0 .
docker run -d --restart unless-stopped --network host robot:1.0
docker ps

Expected result

How you know it worked

Each command completes without an unexplained error.
Your notes contain the command, the important output, and what it proves.

Practical exercise

Apply the lesson

Write a Dockerfile for a ROS 2 package, build and tag it, run it with a restart policy, kill the container's main process to see it restart, and change the tag to roll back to a previous image.

Before you continue

You recorded the starting state
Every command and output is understood
The change can be repeated from your notes

If something goes wrong

A command says permission denied.

Check ownership and permissions first. Do not add sudo unless the command changes a documented system location.

A command or package is not found.

Check spelling, Ubuntu version, enabled repositories, and whether the previous installation command succeeded.