5 ms·

Yeah that's cool, but my main point is that images which make use of the stable debian package system and are actively maintained are a better approach than an

Yeah that's cool, but my main point is that images which make use of the stable debian package system and are actively maintained are a better approach than an image that makes use of more obscure technology that could be abandoned, or worse, maintaining your own container infrastructure. > No well, written software won't spawn zombie-processes - sorry. And yet it happens. > The ssh server... Containers are no vm's, if you have to log in on a container running in production - you're doing something wrong The SSH server is incredibly useful for diagnosing problems in production, so I for one applaud it (although it's not really necessary anymore with docker exec). > Cron - again - same thing: run in a separate container and give access to the exact things your cronjob needs. Or just run it in-container to keep your service clusters together. > That is for me the essential thing about containers: separate everything. It's a question of degree. Where you draw the line is almost always a personal, aesthetic choice.

krisdol 11y ago
>And yet it happens. I can understand that argument. It's an edge case, and building a sane Dockerfile on top of Alpine that runs applications through S6 (or runit), which developers use for their applications is the way to go for me. This is what phusion baked in? >The SSH server is incredibly useful [...] (although it's not really necessary anymore with docker exec). It's an additional attack vector and, by your own admission, it's useless. docker exec has been baked into docker for over a year. >Or just run [cron] in-container to keep your service clusters together. Per-container cron sounds painful. Then you have to deal with keeping every container's system time in sync with the host (yes, they can deviate). Not only that, if you have a periodic cron job that runs an app to update some database value, scaling becomes bottlenecked and race conditions (and data races) can get introduced. You are prevented from running multiple instances of one application to alleviate load because the container has the side-effect of running some scheduled job. Cron should be separate. One can also choose the degree to which they want to throw out good practices that prevent them from repeating others' mistakes.
- ffk 11y ago
  Have you ever seen a container's system time deviate from a host? This makes sense with boot2docker since it runs in a VM but I can't think of a reason this would happen in a container.
  - _yy 11y ago
    Yes, time keeping is up to the host kernel. The time can't deviate in the container.
koffiezet 11y ago
>> No well, written software won't spawn zombie-processes - sorry. > And yet it happens. Strange, I have been running software in docker for almost 2 years in production on 6 docker hosts running a ton of containers these days, and yes - a lot of this software spawns child-processes. In all this time I have never seen zombie processes with one major execption: Phusion Passenger to run our Redmine instance. If you run this under supervisord as 'init' process - you indeed notice the init process cleaning up "zombie processes" at startup like this: 2015-12-24 01:00:32,273 CRIT reaped unknown pid 600) 2015-12-24 01:00:34,774 CRIT reaped unknown pid 594) 2015-12-24 01:00:35,802 CRIT reaped unknown pid 610) So that case for me is the exception, and I do use an init process (supervisord) to run only apache with passenger. Note that using Apache with PHP or plain does not leak zombie processes.

krisdol 11y ago

>And yet it happens. I can understand that argument. It's an edge case, and building a sane Dockerfile on top of Alpine that runs applications through S6 (or runit), which developers use for their applications is the way to go for me. This is what phusion baked in? >The SSH server is incredibly useful [...] (although it's not really necessary anymore with docker exec). It's an additional attack vector and, by your own admission, it's useless. docker exec has been baked into docker for over a year. >Or just run [cron] in-container to keep your service clusters together. Per-container cron sounds painful. Then you have to deal with keeping every container's system time in sync with the host (yes, they can deviate). Not only that, if you have a periodic cron job that runs an app to update some database value, scaling becomes bottlenecked and race conditions (and data races) can get introduced. You are prevented from running multiple instances of one application to alleviate load because the container has the side-effect of running some scheduled job. Cron should be separate. One can also choose the degree to which they want to throw out good practices that prevent them from repeating others' mistakes.

ffk 11y ago
Have you ever seen a container's system time deviate from a host? This makes sense with boot2docker since it runs in a VM but I can't think of a reason this would happen in a container.
- _yy 11y ago
  Yes, time keeping is up to the host kernel. The time can't deviate in the container.

koffiezet 11y ago

>> No well, written software won't spawn zombie-processes - sorry. > And yet it happens. Strange, I have been running software in docker for almost 2 years in production on 6 docker hosts running a ton of containers these days, and yes - a lot of this software spawns child-processes. In all this time I have never seen zombie processes with one major execption: Phusion Passenger to run our Redmine instance. If you run this under supervisord as 'init' process - you indeed notice the init process cleaning up "zombie processes" at startup like this: 2015-12-24 01:00:32,273 CRIT reaped unknown pid 600) 2015-12-24 01:00:34,774 CRIT reaped unknown pid 594) 2015-12-24 01:00:35,802 CRIT reaped unknown pid 610) So that case for me is the exception, and I do use an init process (supervisord) to run only apache with passenger. Note that using Apache with PHP or plain does not leak zombie processes.