Can a docker container kill itself willingly, from the inside, if it's what I need it to do?

Question

For testing purpose, I plan to test some REST servers written in various languages and technologies.

1. A docker container compiles and starts a C++ rest server, for example
2. Then a test suite runs to challenge it, writing its results on a volume.
3. And then the container must stop. Kill itself.
   • because there's not always an easy/known way to stop a rest server
   • and that the tests might have frozen it, and it won't respond anymore

If I manage to put in a docker image a script doing step 1, step 2,

Does a way exist to write in my Dockerfile my step 3 that will kill my docker container from its inside?

---

To explain more my goal, if it's needed : In my mind the global test process

• will start a bunch of Docker containers, each dedicated for one REST server language and technology,
• each container will be autonomous for testing the REST server it carries
• and each container will have the instruction of killing itself at the end
• then the global test process check results by the mean of existing files present in a volume, showing what each container succeeded or failed to complete before dying.

Answer 1

Sure!

Short excourse why that works: a running docker container is really just the fact that there's a process that runs in a Linux Namespace, for (among other things) Network, Filesystems, Users, and PIDs. What that means is that docker starts a process but gives it a different set ideas of existing network interfaces, mounts, users and processes than the "global" initial namespace. When "unsharing" the world view with the "mother of all processes" in that container, that "mother process" gets PID 1 (just as init usually has PID 1 in the global namespace), and to all other processes running in that container, it looks as if all processes were directly spawned from that process, or from a process spawned from it, or from a process spawned from a process spawned from a process from it… you get the idea.

Every process spawned from that "namespaced" process inherits the same view.

Your system will clean up all spawned processes after that mother process has quit. With all processes from that namespace dead, the namespace ceases to exist, and everything is over that made up the Docker container.

So, what you need to do is make sure this mother process, as specified as ENTRYPOINT in your Dockerfile, has the capability to shut itself down, and otherwise starts whatever you want to start in the container.

Any program, however, unless explicitly designed to continue running, such as your REST server.

So, really no big deal there: your ENTRYPOINT would be the test script anyways, and if the test script quits, your container gets deconstructed. Done! It might be a nice gesture to signal (e.g. via kill or via some specific REST command) to the REST server that it should gracefully shut down – but it's not something you have to do.

You can test that really easily. Say, you have a plain debian container (or whatever distro):

docker run -it --rm sh -c 'echo welcome; (sleep 60 &); echo done'

This will show

welcome
done

really quickly, and the container gets deleted. But wait, the sleep should exist for 60 more seconds?! It doesn't, because it gets killed when the entry point process (here, explicitly set to sh) finishes. You can check that the container exited instantly in docker ps.

So, you worry too much. Write a test script that forks of the REST server into the background, use it as ENTRYPOINT and when it's done – it's done, the container quits.