Hacker News Reader

Comment by yblu | Hacker News Reader

Can someone tell me what's the point of this? (I seriously love to know, not criticizing it.) Why would I need to have docker containers to install stuff on them instead of just installing stuff directly on host?

Let's say I develop a new web app, I would install NodeJS, PostgreSQL and such on my machine. Before I deploy the app for the first time, I'll install them in the necessary servers. Now, it looks like I would need to do the same, except adding the step of building Docker containers.

I think I must miss something important here because the number of GitHub stars for Docker is impressive and this is usually a good indication of the usefulness of the project.

View on HN

Docker containers let you isolate the entire environment for your app. Let's say your running an app on CoreOS in a container that needs python 1.2.3.

On your laptop you can build and test the new version of the app that needs python 1.2.4. Once you decide that's ready to go, you can push the new container onto the same CoreOS machine, so it's running both containers. Without the containers, running two versions of python on the same box isn't possible. If you had a chef script that updated to 1.2.4, you'd possibly break every other app on the box.

Containers also let you do some cool things like sign and verify a container before it's launched on the box. It should be bit for bit the same on your laptop as it is on the remote machine. Containers also boot within seconds, much faster than a VM. There have been a few tech demos running around that actually spin up a new container with a web server to service every web request, just to show how fast you can boot them. 300ms is pretty long for a web request, but it's the idea that counts.

Thanks, this is good info. For NodeJS and Rails, I use nvm and rvm, so didn't have any problem with multiple environments. But yeah, I see your point that Docker can help in such scenario or when there's no equivalent of nvm/rvm.

Have a dependency on conflicting libc is a favourite problem that can be difficult to solve without some form of container (vm, chroot or something "in between" like lxc/jails). Another is dependency on different kernel (either major version on same os, or dependency on a different kernel, like freebsd), which docker (by design) doesn't solve.

I don't use ruby much, but it doesn't strike me as very easy to work with/very reliable for production deployment. But that might be me. How well does it handle dependencies on conflicting modules with parts written in c?

Perhaps the most important point is that (when it makes sense) a docker setup might allow easier horizontal scale-out, and or redundancy.

All that said, keeping things simple is generally a good thing. But sometimes adding complexity in one area makes the overall system less complex.

Imagine you wanted to run two apps on the same host, and they depended on different versions of those components, and you wanted to be able to install the app and its dependencies on a new machine really quickly for scaling reasons, and you wanted an exploit on one of the apps to be difficult to escalate over to the other app from, and you'll start understanding some of the pain points Docker solves. :)

Thank you. Do you normally setup your dev environment inside a container? Or you do development as usual and then when coming to deployment, you deploy your app into the container?

Reply on news.ycombinator.com