In this challenge, you will need to start a container using the default containerd CLI -
Knowing how to use it may come in handy when you need to debug lower-level container issues
(e.g., troubleshoot Kubernetes CRI on a containerd-powered cluster node).
You can use any container image you like,
but we recommend choosing a long-running container (e.g.,
because to complete this challenge you will also need to inspect the running container and answer a few questions about it.
Hint 1 💡
ctr is similar (although more low-level) to the docker CLI.
If you're familiar with Docker, following the
ctr --help and
ctr run error messages should be enough to complete this challenge.
And if you're not, try solving this Docker 101 challenge first.
Hint 2 💡
ctr requires you to pull the image explicitly before running it.
ctr image pull --help for more.
Hint 3 💡
Getting the mysterious
ctr: failed to resolve reference "<IMAGE>": object required error?
Make sure you specify the image name fully!
nginx and even
nginx:latest aren't good enough.
The fully qualified Nginx image name is actually
Hint 4 💡
Much like with explicit image pulling,
ctr requires you to explicitly specify the container ID before running it.
If you see the
ctr: container id must be provided error, try adding one more argument to the
ctr run command.
Now, when you have a running container, let's try to understand what it actually is.
Did you know that containers are regular Linux processes? Can you locate the main container's process? What is its PID?
Hint 5 💡
If containers are regular Linux processes, will they show up in
top output? 🤔
Hint 6 💡
Entered a PID of a process that definitely belongs to the container, but the solution checker doesn't accept it? One of the key Docker (hence, containerd) design principles is to run one service per container. However, it doesn't mean that every container will have only one process inside. Actually, more often than not, you'll find a whole process tree inside a container. Try identifying the root process of that tree. That's what the checker expects.
Approximating containers to regular Linux processes is helpful, but it's not very accurate. Thinking of containers as of boxes for processes might be even more helpful at times.
From inside the box, it may look like the containerized app is running on its own machine. In particular, such a virtualized environment will have its own set of network devices. This network virtualization is done using Linux network namespaces. Can you find the ID (inode number) of the network namespace the just started container is running in?
Hint 7 💡
lsns is a very handy command for listing all network namespaces in the system.
Spotting the container
netns in the
lsns output shouldn't be too hard.
Now that you know the container
netns ID, can you find the container IP address?
Hint 8 💡
There might be no easy way to get this info with
But since you know the container
netns already, you can enter it and run any command you like.
ip addr show.
Hint 9 💡
Don't be surprised if you see nothing but the
The bare minimum configuration that
containerd performs when starting a container is creating a new network namespace.
Adding network interfaces and configuring them is usually delegated to various CNI plugins or a higher-level container runtime (e.g., Docker).