Introducing dumb-init, an init system for Docker containers
engineeringblog.yelp.com
Introducing dumb-init, an init system for Docker containers
1–10 of 40 posts
Re: Introducing dumb-init, an init system for Docker containers
#2Very nice! I see this as the next evolution to the phusion's custom init system[0], which was created to solve largely the same problems.
I should be able to take Yelp's dumb-init and add it easily to any linux container I want -- including things such as Alpine[1]
[0] https://github.com/phusion/baseimage-docker/blob/master/imag... [1] https://github.com/gliderlabs/docker-alpine
Re: Introducing dumb-init, an init system for Docker containers
#3The 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.
Re: Introducing dumb-init, an init system for Docker containers
#4Is there any reason you wouldn't run normal "non-dumb" init for this using
CMD ["/sbin/init", "2"]
I feel like logrotate, cron, etc, are worth having inside container no?
Re: Introducing dumb-init, an init system for Docker containers
#5If 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?
Re: Introducing dumb-init, an init system for Docker containers
#6If 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 something like Kubernates or Marathon or Paasta, they're probably going to do the "right thing" and ensure the containers are actually stopped.
We also use containers a lot in development. For example, we might put a single tool into a container, and then when developers call that tool, they're actually spawning a container without realizing it. For this use case, it's really important that signals are handled properly so that Ctrl-C (and similar) continues working.
Re: Introducing dumb-init, an init system for Docker containers
#7Is there any reason you wouldn't run normal "non-dumb" init for this using CMD ["/sbin/init", "2"] and start your app using init.d scripts or supervidord as usual? I feel like logrotate, cron, etc, are worth having inside container no?
Generally accepted practice is no - they aren't worth having. Containers should only contain a single process. That process shouldn't be writing logs to disk (hence no logrotate) and timed tasks would generally be done outside the container rather than in it (though there are a lot of ways to skin that cat).
Single process containers generally don't need all the baggage of a full init system or other dependencies - hence this project.
Re: Introducing dumb-init, an init system for Docker containers
#8Is there any reason you wouldn't run normal "non-dumb" init for this using CMD ["/sbin/init", "2"] and start your app using init.d scripts or supervidord as usual? I feel like logrotate, cron, etc, are worth having inside container no?
Weight, right? All of those things take resources to run, and if you're running 1000s of them, it adds up.
Re: Introducing dumb-init, an init system for Docker containers
#9Is there any reason you wouldn't run normal "non-dumb" init for this using CMD ["/sbin/init", "2"] and start your app using init.d scripts or supervidord as usual? I feel like logrotate, cron, etc, are worth having inside container no?
Part of the potential gain with containers is that you don't have to treat them like full os environments, and don't have to worry about administering them as such.
I'd rather have a few tens of simple, single-process containers logging to a shared collector (or to their stdout, which is then collected) than deal with managing logrotate for them all and solve processing all those files for every host somehow.
Re: Introducing dumb-init, an init system for Docker containers
#10This looks to be an alternative https://github.com/krallin/tini