> However, in most cases they recommend against it because it usually means you're doing something wrong.

Docker-novice question for you:

What's the best practice for this? What assumptions are at play for said best practice? I can understand separating DB from App, but what about other cases where an app might naturally have to have multiple processes running?

•••

Edit: I hate calling this out, but if you're going to downvote questions asking for elucidation of the reasons surrounding best practices for a platform (something I'm frankly having a hard time finding in the case of Docker), keep in mind that doing so does nobody any favors and only discourages productive discourse. You've got over 500 karma enabling your capacity to downvote. Be responsible with the practice of doing so. Nothing in this comment (except perhaps this edit) warrants one.

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))

> it because it usually means you're doing something wrong.

You always want to have at least two processes running. Docker doesn't re-parent processes properly (unless something has changed in this regard) so you would at least want an init (often supervisord or something like) and then your application.

You will often find strange recommendations online, such as the single process one which is just plain wrong. It's a young technology and best practices change regularly (the onion mounts is perhaps the most prominent example), so you have to keep up and engage your brain.

> I'm not sure where the "vendor lock-in" comes in here.

Vendor lock-in may not be here yet, but it's real and it's the simplest thing that can keep Docker Inc.'s value afloat so my guess is that we'll see more of it in the future. Why would anyone buy services from Docker when/if it is one of many components bundled with Red Hat? Unless getting acquired is a reasonable exit strategy they need to avoid commodization, while still keeping file formats etc. in the open. It's not obvious how they'll manage. Most things Docker do would be better suited to have either in systemd or in a more generic orchestration tool anyway.

We've already seen lots of reimplementation in Swarm of things that Kubernetes already do better. The main reason to invest in Docker's toolset is if Docker gets ubiquitous, their tools are likely to be everywhere.

> Having used both VM's and Docker for deployment,

But that's very much an apples-to-orangest comparison. Docker is not a VM. You don't even use them to solve the same problems. The only reason to compare them is because VMware is a belivable story how to make a living while the underlying technology gets commoditized. Application distribution is a nut VMware never cracked. How often have you even distributed your applications as vmdk's? Better perhaps to compare Docker to Vagrant.

> I don't worry about dependencies anymore. If I want to try a new app, I `docker run` it. No dependencies. My apps themselves comes with all of their dependencies so I don't have to screw around with dependencies on a host provider. Sure, it doesn't completely solve dependency problems (you still need to write a Dockerfile) but it makes my life a whole lot easier compared to without Docker.

A problem I frequently run into is that while package/linking dependencies are usually fixed by Docker, I still have issues due to system dependencies. I can't just docker run grafana, I have to install Grafana, Graphite and from memory StatsD or something too. Dependency hell is still a thing, it's just moved up to a higher level now.

Lock in could mean you can only use Docker to run your images, but that is untrue. CoreOS rkt can run Docker images.

Also, UNIX domain sockets work in docker just fine with volume mounts.