4 ms·

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 ... superviso

by derFunk 11y ago

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).

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...
eikenberry 11y ago
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...
- fatherlinnux 11y ago
  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...
itajaja 11y ago
We use dumb-init[1] to handle containers with multiple processes when it's necessary. [1] https://github.com/Yelp/dumb-init https://github.com/Yelp/dumb-init
fatherlinnux 11y ago
Or systemd /me ducks and runs :-)
- lisivka 11y ago
  Can you review my implementation of container with centos7/systemd in unprivileged mode, please? https://github.com/vlisivka/docker-centos7-systemd-unpriv https://github.com/vlisivka/docker-centos7-systemd-unpriv
  - fatherlinnux 11y ago
    @ilsivka: check out: https://github.com/projectatomic/oci-register-machine https://github.com/projectatomic/oci-register-machine and https://github.com/projectatomic/oci-systemd-hook 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.
    - lisivka 11y ago
      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.
- gtrevorjay 11y ago
  Some of us just can't face going back to writing start-up scripts.
  - fatherlinnux 11y ago
    I feel you

by derFunk 11y ago

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...

eikenberry 11y ago

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...

fatherlinnux 11y ago
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...

itajaja 11y ago

We use dumb-init[1] to handle containers with multiple processes when it's necessary. [1] https://github.com/Yelp/dumb-init https://github.com/Yelp/dumb-init

fatherlinnux 11y ago

Or systemd /me ducks and runs :-)

lisivka 11y ago
Can you review my implementation of container with centos7/systemd in unprivileged mode, please? https://github.com/vlisivka/docker-centos7-systemd-unpriv https://github.com/vlisivka/docker-centos7-systemd-unpriv
- fatherlinnux 11y ago
  @ilsivka: check out: https://github.com/projectatomic/oci-register-machine https://github.com/projectatomic/oci-register-machine and https://github.com/projectatomic/oci-systemd-hook 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.
  - lisivka 11y ago
    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.
gtrevorjay 11y ago
Some of us just can't face going back to writing start-up scripts.
- fatherlinnux 11y ago
  I feel you