Hacker News Reader

Comment by derFunk | Hacker News Reader

All is quite valid, yet I disagree with "7) Don’t run more than one process in a single container". This is perfectly doable with supervisors like ... supervisord, which ensure that the multiple processes you want to run stay alive. In some environments it's just virtually impossible to only let one process run (eg webserver/proxy, log forwarder, fastcgi etc).

View on HN

I think they picked the wrong term and meant something closer to service than process. If your service is say postfix, it consists of a half dozen or so processes that make up one service. I don't think 'they' would say that you should run each of the processes in a separate docker. So sometimes a single service is more than one process, and sometimes they are not as tightly coupled as postfix...

Agreed, I was trying to help a friend implement the Actor model inside a container, and if you want to put every process in a different container, you basically have to talk tot he Kubernetes Daemon to do it (not fun).

I am fine with services. I am also fine with larger applications under duress. I think the format still makes operations lives easier. Containerize everything, is better than some things...

Oh, I want to add why supervisord makes so much sense: If your "main process" (PID 1) dies, your container would stop. Even if you only have a single process to run, using supervisord makes sense to monitor that single process, because restarting a stopped container can be a pain because it mostly involves some manual work. Supervisord itself is written in python and is very stable (because simple) itself.

Most container orchestration systems (Kubernetes, Mesos, ECS, etc.) handle restarting failed containers - that's generally something you want to be outside of your container, not inside.

If you don't use one of those, you can still have supervisor run outside of your containers, and manage a set of "docker run" commands.

> Most container orchestration systems (Kubernetes, Mesos, ECS, etc.) handle restarting failed containers - that's generally something you want to be outside of your container, not inside.

Not sure if I understand correctly. I'm using ECS. How would you provision the Host with supervisord (automatedly)? ECS and the other systems are taking care of restarting the containers anyway, but they don't necessarily have any logic attached (like restart it 5 times, then stop and notifify if the container doesn't come up again).

From my POV it's definitely better to directly have it deployed within the container. Maybe it's depending on the use case.

The problem is that it often happens that the container cannot restart because the main process (invoked by ENTRYPOINT or CMD) cannot start up anymore, e.g. because of corrupted (config) data which has to be loaded on startup or other suddenly unsatisfied dependencies.

I think they mean this: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zomb...

> restarting a stopped container can be a pain because it mostly involves some manual work

Restart policies are a thing since 1.2 https://docs.docker.com/engine/reference/run/#restart-polici...

Or systemd /me ducks and runs :-)

Can you review my implementation of container with centos7/systemd in unprivileged mode, please?

https://github.com/vlisivka/docker-centos7-systemd-unpriv

@ilsivka: check out:

https://github.com/projectatomic/oci-register-machine

and

https://github.com/projectatomic/oci-systemd-hook

Also, ping Dan Walsh as he is leading work on our (Red Hat) end to get this working.

Integration with host systemd/machinectl is nice, but it requires modification of host setup, while my solution can be run on unmodified docker, i.e. it is universal. I will manage my containers using Kubernetes, so integration with host systemd is useless for me.

I sent email to Dan.

Some of us just can't face going back to writing start-up scripts.

I feel you

We use dumb-init[1] to handle containers with multiple processes when it's necessary.

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

Reply on news.ycombinator.com