* AFAIK "docker exec NGINX_DOCKER nginx -s reload" works to 'hot reload' configurations
* You're right that "in place NGINX binary upgrade" won't work. The "bright side" of this problem is that the "NGINX container binary" is immutable and can be easily "rebooted" if any corruption occures (instead of having to reinstall everything). For hobby websites (including the condo mail server), the downtime is acceptable (not much traffic, not really 24/7, fast restart, few versions of NGINX every year...)
For me: having an isolated (dockerized) NGINX is easier to manage (like a dockerized mail server) because it limits the amount of processes "on bare linux with files everywhere" and make is easier to backup/replace/upgrade (just start a new docker with a new version). YMMV
It drives the container philosophy to an ad absurdum. When I serve paying customers then I refrain from what is possible. I try to stick to what appears to be the simplest thing.
* I haven't encountered a corrupted Nginx binary, so far. I think that it is very unlikely to happen. I consider my Nginx binary "almost immutable" even without Docker. Since I am the only one working on my VPS I also know who to blame if that's not the case :D
I see Docker as an amazing fit for isolating business applications. They tend to have many dependencies (often less stable than evergreen libraries like libc), get continuously update and deployed.
However, for a quick skim of the article, all of cited issues with Docker as such are in fact solved by services such as ECS[0].
Thus, the question of whether to manage nginx directly may be more of a business decision (am I dealing with a cloud provider?) than a technical one (are these requirements delivered by a service?).
Also the talk about docker being itself a dependency I can't really follow. I guess you would have many other dockers also running, otherwise being nxing the only thing within docker.. that doesn't make much sense..
It is about:
Everything that something depends on makes it a little more likely to introduce failures which I want to minimize if reasonably possible.
I corrected the section.
6. Provides an additional layer of security between the application and its host
As far as his availability concerns, I don't see why running or not running docker would help this problem. You can certainly build highly available nginx reverse proxies in docker, and can do in place upgrades with no downtime. This has been solved for a very long time.
No one should use containers primarily for security ever.
