Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Not only is it sharing the kernel, but to the original question, it's not booting an entire OS. It's running a single process; your application. There is no overhead of another init process (although some people use dumbinit or tini for basic process and signal management).

Now a container will have an entire copy of a basic OS it builds from (ubuntu, alpine, etc.), so its dependencies are self contained and it should run the same anywhere. However they're usually installed with apt-get or yum or apk commands in the Dockerfile, so if you don't do rebuilds and there's a security issue in a dependency, it can be difficult to detect.

Security problems are still isolated to that container, but that container shares a kernel. If someone can get root inside your container, and use a cgroup exploit, they could break out of the container. It's unlikely, and the layering does provide protection, but it's something to be aware of.

The process in the container runs at the same speed as a native process as if it were outside the container as well.



> Not only is it sharing the kernel, but to the original question, it's not booting an entire OS. It's running a single process; your application.

This is the first time I've been anywhere close to understanding the benefits of Docker (I've been watching and not understanding for years!). Thanks for your comment


When you’ve been in java version dependency hell then you try replicate the same install with Docker, and succeed in 5 minutes it all becomes very clear. I am very very far from being a Docker expert but love it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: