4 ms·

I'm only a beginner, but the analogy that makes sense to me is that containers do for app deployment what npm does for Javascript development. That is, the magi

by fenomas 10y ago

I'm only a beginner, but the analogy that makes sense to me is that containers do for app deployment what npm does for Javascript development. That is, the magical part isn't that Docker simulates an operating system and so on - the magic is that it allows a chunk of logic to precisely declare its dependencies - including on other pieces of logic which declare their own dependencies - and then Docker knows how to (in theory anyway) run the logic in such a way that its dependencies are all satisfied. And of course the meta-magic is then that there's a public registry of (in theory) solved problems, which one can build on top of by declaring dependencies against them. I have a pet theory that this "declared dependencies + dependency wrangler + public registry" is a general formula which will keep cropping up as we find new places to apply it.

kpil 10y ago
Not really - Linux package management systems do exactly that. The magic - if there is any - is to combine it all together; separation, discovery, relatively easy packaging and dependencies.
- fenomas 10y ago
  Sure, at a different level. Package managers at the app level, docker at the deployment level, npm at the development level, or something vaguely along those lines. I wasn't suggesting this was unique to Docker - precisely the opposite, that it's a generally useful pattern, being applied here to deployment.
bpizzi 10y ago
To me it's more like a lightweight virtualization: processes inside containers have no clues that there are others processes running in others containers alongside its own, all of that without eating too much memory (at least well under the amount that virtual machines would use). Added benefits: - the 'host' os can be very light and tailored to run Docker and nothing more (cf CoreOS), - we can design orchestration software that handle containers operations across a herd of lightweight hosts (cf Kubernetes). The dependencies/recipes thing is more like a tool that enable those higher goals, but again that's just my point of view.
- majewsky 10y ago
  > processes inside containers have no clues that there are others processes running in others containers alongside its own Except, of course, if you're dealing with privileged containers. Docker [1] gives you detailed control over what to share between container and host, and what to isolate (with the default being more rather than less isolation). For example, I'm currently working on a container that mounts disks in the host's mount namespace. In that case (and many others), the selling point of Docker [1] is not the isolation, but the deployment story. [1] Or any other container runtime. I'm saying "Docker" because that's the one I'm familiar with.

by fenomas 10y ago

kpil 10y ago

Not really - Linux package management systems do exactly that. The magic - if there is any - is to combine it all together; separation, discovery, relatively easy packaging and dependencies.

fenomas 10y ago
Sure, at a different level. Package managers at the app level, docker at the deployment level, npm at the development level, or something vaguely along those lines. I wasn't suggesting this was unique to Docker - precisely the opposite, that it's a generally useful pattern, being applied here to deployment.

bpizzi 10y ago

To me it's more like a lightweight virtualization: processes inside containers have no clues that there are others processes running in others containers alongside its own, all of that without eating too much memory (at least well under the amount that virtual machines would use). Added benefits: - the 'host' os can be very light and tailored to run Docker and nothing more (cf CoreOS), - we can design orchestration software that handle containers operations across a herd of lightweight hosts (cf Kubernetes). The dependencies/recipes thing is more like a tool that enable those higher goals, but again that's just my point of view.

majewsky 10y ago
> processes inside containers have no clues that there are others processes running in others containers alongside its own Except, of course, if you're dealing with privileged containers. Docker [1] gives you detailed control over what to share between container and host, and what to isolate (with the default being more rather than less isolation). For example, I'm currently working on a container that mounts disks in the host's mount namespace. In that case (and many others), the selling point of Docker [1] is not the isolation, but the deployment story. [1] Or any other container runtime. I'm saying "Docker" because that's the one I'm familiar with.