In this challenge, you will need to start a container using the default containerd CLI - ctr
.
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., nginx
)
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 π‘
Unlike Docker, ctr
requires you to pull the image explicitly before running it.
See 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!
No, nginx
and even nginx:latest
aren't good enough.
The fully qualified Nginx image name is actually docker.io/library/nginx:latest
.
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 ps
or 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 ctr
.
But since you know the container netns
already, you can enter it and run any command you like.
Including ip addr show
.
Hint 9 π‘
Don't be surprised if you see nothing but the lo
interface.
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).
Level up your Server Side game β Join 8,200 engineers who receive insightful learning materials straight to their inbox