3 ms·
I think that in the specific case of nginx plus php-fpm, separating things all the way out to one process per container is overkill, and it would be better to p
by mwcampbell 12y ago
I think that in the specific case of nginx plus php-fpm, separating things all the way out to one process per container is overkill, and it would be better to put the two in a single container, managed with something like runit or supervisord. Conceptually, the combination of nginx and php-fpm can be treated as a single service, and your operations team (or youu when wearing your ops hat) would probably prefer to think of it as such. There are two tricky parts though: getting both underlying processes to log to the container's stdout/stderr, and getting them both to shut down cleanly in response to a SIGTERM to the supervisor.
- opendais 12y agoIt is why I used it as an example. Nginx+php-fpm = web app role, easy to conceptualize as a single service, and in many workplaces might be the entire depth of a given service [except for the database]. > There are two tricky parts though: getting both underlying processes to log to the container's stdout/stderr, and getting them both to shut down cleanly in response to a SIGTERM to the supervisor. I was simplifying it for purposes of example. The reality is I'd have a log-shipper as well shipping logs. I don't need it to dump to the container's stdout/stderr because its all in [insert log management application here]. They shutdown as cleanly enough as-is without worrying about it too much as well.
- vidarh 12y agoI disagree. It's a perfect example where one of the components is likely to scale differently than the other, and where the components are reusable separately but less reusable together. As someone constantly wearing my "ops hat", I much prefer to see them treated separately for that reason.
- deleted 12y ago[deleted]