Re:Docker can forkbomb the host system: `docker run busybox ...
by djb_hackernews on Monday January 25, 2016 @11:48AM
(#10968200)
That information is quite out of date as docker doesn't use lxc as it's execution driver by default. This explains how to control cgroups with docker https://docs.docker.com/engine/reference/run/
Re:Docker can forkbomb the host system: `docker run busybox ...
by eeZi on Friday January 22, 2016 @01:46PM
(#10954693)
This. Containers are not ready for production, except for fault-tolerant/distributed payloads. You can't even live migrate them to another host, and CRIU is nowhere near production ready (assuming it ever will be).
Everything else? VMs it is. The overhead is so low nowadays that it's totally irrelevant for the vast majority of use cases.
Re:Docker can forkbomb the host system: `docker run busybox ...
by toomuchtodo on Friday January 22, 2016 @04:05PM
(#10955620)
Sorry everyone's downvoted you, despite that you're correct.
I do Devops, and Docker provides very little benefit in production (unless you're an org with your own non-cloud computing resources, where you're going to orchestrate with something like Kubernetes; even then, there's dissent in the ranks between that project and Docker).
Re:Docker can forkbomb the host system: `docker run busybox ...
by djb_hackernews on Monday January 25, 2016 @11:39AM
(#10968132)
Not sure if I am missing something but this shouldn't be all that surprising. The process you execute in the container is being handled by the same kernel as the host. I think this is a common fundamental misunderstanding of what docker is. If it's a fork bomb on your host (and this is) it's a fork bomb with docker too.
Now the interesting thing about docker is you can control this in similar ways you'd do to control this via VMs and that is via kernel primitives (cgroups) to control resource allocation. In general if you are running docker containers in production you should be explicitly allocating resources via cgroups according to the needs of your applications. If you are writing and deploying software that fork bombs (why?) then you should mitigate the effects of the noisy neighbor via the kernel features. The benefit here is you don't need the (extremely, IMO) heavyweight overhead of running separate OSes in VMs.
See: http://stackoverflow.com/questions/16084741/how-do-i-set-res...
Everything else? VMs it is. The overhead is so low nowadays that it's totally irrelevant for the vast majority of use cases.
I do Devops, and Docker provides very little benefit in production (unless you're an org with your own non-cloud computing resources, where you're going to orchestrate with something like Kubernetes; even then, there's dissent in the ranks between that project and Docker).
Now the interesting thing about docker is you can control this in similar ways you'd do to control this via VMs and that is via kernel primitives (cgroups) to control resource allocation. In general if you are running docker containers in production you should be explicitly allocating resources via cgroups according to the needs of your applications. If you are writing and deploying software that fork bombs (why?) then you should mitigate the effects of the noisy neighbor via the kernel features. The benefit here is you don't need the (extremely, IMO) heavyweight overhead of running separate OSes in VMs.