search

sameersbn / docker-ubuntu

My Ubuntu boilerplate image that forms the base for my docker containers.
MIT License
33 stars 71 forks source link

Use runit-based image instead of (plain) Ubuntu image #4

Closed fbender closed 9 years ago

fbender commented 9 years ago

Hi there,

since the official Ubuntu image has some issues with running inside Docker, I'd like to see your superb Dockerfiles be based on phusion/baseimage-docker instead. They explain why this has benefits on the project page: http://phusion.github.io/baseimage-docker/

Thank you for your consideration!

sameersbn commented 9 years ago

since the official Ubuntu image has some issues with running inside Docker

Does it? What issues do you see? IMO the phusion baseimage does not offer any benefits that may be useful.

fbender commented 9 years ago

I am mostly concerned about the init system not behaving correctly within Containers, especially failure to clean up and shutdown correctly. =

sameersbn commented 9 years ago

@fbender I don't completely understand what you mean by "clean up and shutdown correctly". As far as I can tell right now supervisord (when configured correctly) does shutdown running processes gracefully. I don't understand what you mean by cleanup.

edit: Is there a way you can demonstrate the shortcomings of supervisord.

fbender commented 9 years ago

I wasn't aware of supervisord and am unfamiliar with it. After a quick glance at the docs and sameersbn/gitlab/Dockerfile I fail to see how this can work for that particular image (looking at CMD et al.) however I'm lacking the config files.

Either way, the issue is explained in the link I provided and I'm quoting the most "interesting" parts:

When your Docker container starts, only the CMD command is run. The only processes that will be running inside the container is the CMD command, and all processes that it spawns. That's why all kinds of important system services are not run automatically – you have to run them yourself. […] [Ubuntu's] init system, Upstart, assumes that it's running on either real hardware or virtualized hardware, but not inside a Docker container, which is a locked down environment with e.g. no direct access to many kernel resources. […] The system halts when [the init] processs halts. If you call CMD ["/my_app/start.sh"] in your Dockerfile, then start.sh is your init process. But the init process has an extra responsibility. It inherits all orphaned child processes. It is expected that the init process reaps them. Most likely, your init process is not doing that at all. As a result your container will become filled with zombie processes over time. Furthermore, docker stop sends SIGTERM to the init process, which is then supposed to stop all services. If your init process is your app, then it'll probably only shut down itself, not all the other processes in the container. The kernel will then forcefully kill those other processes, not giving them a chance to gracefully shut down, potentially resulting in file corruption, stale temporary files, etc.

These issues seem to be handled by supervisord, judging by the little I know about it. However, it does not act as an init system in that it runs and manages system daemons (like syslog, cron, or sshd) alongside the actual app you want to run (again, just judging by what little I know). runit is such a lightweight init system and many docker images use it.

I'm not married to baseimage-docker either, there also the very promising dockerbase-service which builds on dockerbase-runit and ultimately the official Ubuntu image.

Hope this clarifies.

sameersbn commented 9 years ago

@fbender closing.. too much work, too little benefits (it at all)