5 ms·

Oh boy, as someone who's been using Docker for a while there seems like a lot of misinformation here. > strict restrictions like single process per container

Oh boy, as someone who's been using Docker for a while there seems like a lot of misinformation here. > strict restrictions like single process per container This isn't a real restriction, you can run as many processes as you want under a container. However, in most cases they recommend against it because it usually means you're doing something wrong. > Software developers forced to vendor lock-in their software I've made Dockerfile's for quite a few different apps now, and I have never once had to actually change the application. The applications still work completely independent of Docker, so I'm not sure where the "vendor lock-in" comes in here. > Docker won't be able to run even Postfix (or FTP daemons) https://github.com/tomav/docker-mailserver https://github.com/tomav/docker-mailserver https://github.com/atmoz/sftp https://github.com/atmoz/sftp > Docker is designed with cloud computing providers in mind exclusively I would disagree, although this is a matter of opinion I suppose. Having used both VM's and Docker for deployment, Docker is ridiculously more developer-friendly than a standard VM architecture. > No way to escape dependency hell 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. Docker isn't the right fit for everything, and there's a lot of ways that I can think of where it can be improved. It strikes me like this was written by a frustrated sysadmin who hasn't spent the time to learn the tools (which is understandable, the learning curve is high and most things are different from traditional sysadmin tools). In fact, in alot of cases Docker is needlessly complex and overkill. However, spreading FUD doesn't do anything to address these concerns and might scare away a lot of developers who could benefit from Docker.

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.
extrapickles 10y ago
Lock in could mean you can only use Docker to run your images, but that is untrue. CoreOS rkt can run Docker images.
bpicolo 10y ago
Also, UNIX domain sockets work in docker just fine with volume mounts.
deleted 10y ago
[deleted]
xorcist 10y ago
> 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.
Veratyr 10y ago
> 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.

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.

extrapickles 10y ago

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

bpicolo 10y ago

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

deleted 10y ago

[deleted]

xorcist 10y ago

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

Veratyr 10y ago

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