6 ms·
My inability to personally audit systemd would be at the top of the list.
by acct1771 7y ago
My inability to personally audit systemd would be at the top of the list.
- zbentley 7y agoUbuntu Docker images do not run systemd by default or in most configurations. In many images it is removed entirely.
- silluk 7y agoI wouldn't be too concerned about that in a container since you're probably not running systemd in that context.
- Xylakant 7y agogiven that containers usually do not include any init system at all that’s not a good reason to pick a side.
- roywiggins 7y agoAs far as I can tell, the recommended way to run several processes in an Ubuntu container is under supervisord. The default Ubuntu containers don't even include an init system.
- sofaofthedamned 7y agoSuoervisord is an awful thing to do under a container tbf. Any oom event and it will kill a random process. Not good in a container environment.
- roywiggins 7y agoI've only ever done it when I needed to run exactly two processes- porting an older piece of software that was not originally designed to run inside containers, and orchestrating the separate processes to be able to communicate and run in separate containers didn't seem like worth the effort.
- mixmastamyk 7y agoAnd supervisord will restart it.
- outworlder 7y agoWhy would anyone run an init system inside a container? Just run the process. Let whatever is managing your container restart it if the process quits, be it docker or K8s.
- oliver_quartic 7y agoHere is one reason: https://news.ycombinator.com/item?id=10852055 https://news.ycombinator.com/item?id=10852055 (TL;DR - default signal behaviour is different for PID 1). [Edit - fix link]
- meddlepal 7y agoBecause sometimes it is easier to ship one thing to customers than 10 different images and several different run manifests. There's plenty of other reasons.