Hacker News new | ask | show | jobs
by tomjakubowski 3215 days ago
I was relieved to see the article mention dumb-init in its conclusion. It's very likely what you want if you're not booting your containers with a full init system, and the README has a thorough explanation of why and how dumb-init works.

https://github.com/Yelp/dumb-init

2 comments

Does docker's newer --init flag not fully replace dumb-init's use? Or is dumb-init now just so you don't need to remember to --init whenever you use the container? I find it really weird that --init is a run-time option rather than something specified in the Dockerfile and baked into the image.
Some container engines don't support the --init flag, such as Amazon ECS[0], so there is still a place for dumb-init and tini for the time being.

[0] https://github.com/aws/amazon-ecs-agent/issues/852

Lately I've found myself using runit a lot in docker containers. In the happy path with a single process, you still gain because it does leave you a bunch of nice hooks when docker exec'ing to shutdown/restart your main process when your developing.

In the more common path, I rarely have containers which don't more easily share 1 or 2 tightly coupled support containers (and in general I prefer having `docker run` just work, rather then turn into an affair with docker compose).

>"In the happy path with a single process ..."

What is meant by "the happy path"? I've seen this reference a couple of time now but have not found a clear explanation.

The path where everything goes right/as expected. No error or special handling is needed.

https://en.wikipedia.org/wiki/Happy_path