It sounds like you have the right intuition. A lot of the time when beginners are starting out they will try and put their entire application stack (say Postgres/Elasticsearch/their app/etc) all on the same container. This is not great because it is impossible to scale these services independently when configured like this.

I think advocating "process-per-container" was a poor choice, when really "role-per-container" was what the intention was (imo). You may have a separate container for Postgres, Elasticsearch, and then your app. But if every now and then your app needs to spawn a child process to do some sub-task related to the app, that's fine too.

It really depends on what the multiple processes are, so you should ask yourself "is this a logically separate job that I would want to scale and manage the lifecycle of independently from the main app?" and that'll help you make the best decision.

Postfix/qmail are cases where you have more than one process doing only one task and good. Like for instance you may want to deliver some mails locally, plug your own delivery system, or pass your mail through an anti spam/virus proxy from a 3rd party. You may even have process some to make custom authentications, routing ...

For this you may prefer to use unix domain socket, or even (if you use maildir) just the give the name of the file to a local process and avoid the extra fat of network communications.

And for scaling postfix prefers a multiprocessing approach to a multithreading approach. Sometimes you can communicate better as distinct processes than as distinct threads especially when you use the normal unix convention of using SIGHUP for reloading. (HINT, kill and threads are no friends)

There really isn't such a restriction.

I sometimes need containers with several services, and that's perfectly fine if it makes the setup simpler. Services can be dynamically enabled/disabled for instance with daemontools. As a matter of fact, docker brought new life to djb's daemontools for me. This makes it possible to conditionally add even an sshd to my containers (just by mixing in a directory with the run configuration), so I can go into them and check what's going wrong.

And when things need to be hardened up, just drop the corresponding service directory.

I prefer exec to installing an sshd inside the container.

  docker exec -it "id of running container" bash

great tip, thanks!

If you could improve your daemontools life inside a Docker container (presumably you are running svscan as the primary container process) what would that improvement be?

To the other responses I'll add that very often the right model is to compose containers within a system, not processes within a container. Most of the OP's concerns in this area stem from the basic misconception that containers are sort of like VMs, and so it's sort of wasteful to only run a single process in one. Containers are very lightweight jails to run a process in, and all the containers running on a system can communicate with each other over the docker bridge with one hop.

For VM like experience, you should probably be using LXD. It's basically like a VM running in a container (with a few differences obviously). I always thought of it like this:

Docker: One App per container

LXD: One system per container (I do not want to say one OS per container, since technically they all share the same OS (kernel))