5 ms·

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

by derFunk 11y ago

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.

azylman 11y ago
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.
- derFunk 11y ago
  > 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.
  - fatherlinnux 11y ago
    I think they mean this: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/ https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zomb...
- yo-code-sucks 11y ago
  this, only this. some people dont get it though.
omni 11y ago
> 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-policies-restart https://docs.docker.com/engine/reference/run/#restart-polici...

by derFunk 11y ago

azylman 11y ago

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.

derFunk 11y ago
> 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.
- fatherlinnux 11y ago
  I think they mean this: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/ https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zomb...
yo-code-sucks 11y ago
this, only this. some people dont get it though.

omni 11y ago

> 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-policies-restart https://docs.docker.com/engine/reference/run/#restart-polici...