3 ms·

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

by eganist 10y ago

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

chrisper 10y ago
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))
SFJulie 10y ago
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)
chrisfosterelli 10y ago
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.
markbnj 10y ago
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.
hippiefahrzeug 10y ago
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.
- julg 10y ago
  I prefer exec to installing an sshd inside the container. docker exec -it "id of running container" bash
  - hippiefahrzeug 10y ago
    great tip, thanks!
- JdeBP 10y ago
  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?

by eganist 10y ago

chrisper 10y ago

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

SFJulie 10y ago

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)

chrisfosterelli 10y ago

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.

markbnj 10y ago

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.

hippiefahrzeug 10y ago

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.

julg 10y ago
I prefer exec to installing an sshd inside the container. docker exec -it "id of running container" bash
- hippiefahrzeug 10y ago
  great tip, thanks!
JdeBP 10y ago
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?