Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing dumb-init, an init system for Docker containers

engineeringblog.yelp.com

Post reply on HN
Print view View original

31–40 of 40 posts

Re: Introducing dumb-init, an init system for Docker containers

#31

Post by vishvananda »

gnud wrote: post #3

The actual reason you really need a proper PID 1 is not explained in this post, but a couple of clicks away at [0]: >[...] the init process must also wait for child processes to terminate, >before terminating itself. >If the init process terminates prematurely then all children are terminated uncleanly by the kernel. 0: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zomb...

It also needs to reap orphan processes or they will become zombies. The dumb-init code does not appear to be doing that so I reported an issue[1].

In general docker is half-trying to be the init system, but most people using it are putting a whole child os with its own init system in their container. I think the approach that rkt uses where it uses systemd to run the process is safer. Now if people would just start using lightweight containers...

[1]: https://github.com/Yelp/dumb-init/issues/44

Re: Introducing dumb-init, an init system for Docker containers

#32

Post by sandGorgon »

ckuehl wrote: post #6
lox wrote: post #5

If it's such a straightforward fix, why isn't it part of the docker core? I'd love to hear from the docker team why it's not a concern for them. Presumably if it was they'd have addressed it by now. From my own experience with docker in production, I'm yet to see any of the described scenarios crop up. Has anyone else, or is this solving an extreme edge case?

> From my own experience with docker in production, I'm yet to see any of the described scenarios crop up. Has anyone else, or is this solving an extreme edge case? The biggest issue we see at Yelp is leaking containers in test (e.g. Jenkins aborting a job but leaving the containers it spawned still running). Depending on how you orchestrate containers, you might not encounter the issue in prod. If you're using somet…

Why did you not use something like supervisord? I run a few containers (obviously not at yelp scale) and supervisors has been spectacular at restarting, managing,reloading,etc. It handles nginx,gunicorn,puma,tomcat, etc pretty well. Yes its python - but was that the motivation?

Also,you guys should comment on https://github.com/docker/docker/pull/5773 which is work on unprivileged systemd in docker. I think you guys can influence the bug with your experience in this.

Re: Introducing dumb-init, an init system for Docker containers

#33

Post by anonbanker »

sandGorgon wrote: post #32
ckuehl wrote: post #6

Earlier quoted context omitted.

> From my own experience with docker in production, I'm yet to see any of the described scenarios crop up. Has anyone else, or is this solving an extreme edge case? The biggest issue we see at Yelp is leaking containers in test (e.g. Jenkins aborting a job but leaving the containers it spawned still running). Depending on how you orchestrate containers, you might not encounter the issue in prod. If you're using somet…

Why did you not use something like supervisord? I run a few containers (obviously not at yelp scale) and supervisors has been spectacular at restarting, managing,reloading,etc. It handles nginx,gunicorn,puma,tomcat, etc pretty well. Yes its python - but was that the motivation? Also,you guys should comment on https://github.com/docker/docker/pull/5773 which is work on unprivileged systemd in docker. I think you guys…

some of us don't want systemd and it's tag-alongs ruining our docker.

Re: Introducing dumb-init, an init system for Docker containers

#34

Post by [deleted] »

sandGorgon wrote: post #32
ckuehl wrote: post #6

Earlier quoted context omitted.

> From my own experience with docker in production, I'm yet to see any of the described scenarios crop up. Has anyone else, or is this solving an extreme edge case? The biggest issue we see at Yelp is leaking containers in test (e.g. Jenkins aborting a job but leaving the containers it spawned still running). Depending on how you orchestrate containers, you might not encounter the issue in prod. If you're using somet…

Why did you not use something like supervisord? I run a few containers (obviously not at yelp scale) and supervisors has been spectacular at restarting, managing,reloading,etc. It handles nginx,gunicorn,puma,tomcat, etc pretty well. Yes its python - but was that the motivation? Also,you guys should comment on https://github.com/docker/docker/pull/5773 which is work on unprivileged systemd in docker. I think you guys…

[deleted]

Re: Introducing dumb-init, an init system for Docker containers

#35

Post by [deleted] »

sandGorgon wrote: post #32
ckuehl wrote: post #6

Earlier quoted context omitted.

> From my own experience with docker in production, I'm yet to see any of the described scenarios crop up. Has anyone else, or is this solving an extreme edge case? The biggest issue we see at Yelp is leaking containers in test (e.g. Jenkins aborting a job but leaving the containers it spawned still running). Depending on how you orchestrate containers, you might not encounter the issue in prod. If you're using somet…

Why did you not use something like supervisord? I run a few containers (obviously not at yelp scale) and supervisors has been spectacular at restarting, managing,reloading,etc. It handles nginx,gunicorn,puma,tomcat, etc pretty well. Yes its python - but was that the motivation? Also,you guys should comment on https://github.com/docker/docker/pull/5773 which is work on unprivileged systemd in docker. I think you guys…

[deleted]

Re: Introducing dumb-init, an init system for Docker containers

#37

Post by XorNot »

yrro wrote: post #26
XorNot wrote: post #14

Earlier quoted context omitted.

Under a time crunch I've not found a way to use language-package managers and not wind up with gcc in the container. The problem is apt does a poor job of letting you setup something like build-essential and then remove it and leave just the runtime shared libraries you need for the other things you build to actually work.

If you installed build-essential, then removed it, then apt-get --purge autoremove should remove the packages that build-essential pulled in that were not already installed.

The problem is by default this will remove runtimes like libtool as well. Sure, I could figure out what these are and keep them around, but the problem is the time-crunch aspect - it takes time, and if the program changes then you still need to take the time.

Re: Introducing dumb-init, an init system for Docker containers

#39

Post by myhf »

XorNot wrote: post #14
rvense wrote: post #12

Earlier quoted context omitted.

At my current job, we're basically using Docker as a sort of package manager and deployment script runner. Our containers are very fat, things are installed with apt. One of them has GCC in it but I'm not sure why. One installs Node and runs a few js scripts during the build process, then never runs it again but keeps it around. It's obviously wrong, but I think it's just a new set of bad ideas that this software has…

Under a time crunch I've not found a way to use language-package managers and not wind up with gcc in the container. The problem is apt does a poor job of letting you setup something like build-essential and then remove it and leave just the runtime shared libraries you need for the other things you build to actually work.

You can use the "dockerception" method: build in a container with devtools, then import the resulting binaries into a container with no devtools. https://github.com/jamiemccrindle/dockerception

The resulting images can be very small: https://hub.docker.com/r/jjclark/nethack/tags/

It's currently a little difficult because of a bug with building from a tarball: https://github.com/docker/docker/issues/15785

Re: Introducing dumb-init, an init system for Docker containers

#40

Post by FooBarWidget »

dpedu wrote: post #29

This is cool, but you can solve the same problem with a single line of bash trap 'kill $(jobs -p)' EXIT

No you can't. It looks like it can, but there are various edge cases that aren't handled.

See https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zomb..., section "A simple init system".

Post reply on HN