I do use Nginx in docker for (personal hobby) dockerized applications... but I didn't fully understand some of your reasons:
* 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
* Docker containers can be modified at runtime, it is just more involved to do so. Hot-reloading inside Docker works best if you mount a host directory.
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?).
Just run it in LXC. Then the container is not immutable but the process will still be isolated with it's dependencies. And infrastructure as code, with Ansible etc, all possible.
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..
Oof, in his reasons to use docker (which it seems like he uses as a synonym for containerization), misses probably the most important one -
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.
olivierduval|1 year ago
* 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
ebenes|1 year ago
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.
smitty1e|1 year ago
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?).
[0] https://docs.aws.amazon.com/ecs/
bootloop|1 year ago
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..
ebenes|1 year ago
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.
unknown|1 year ago
[deleted]
JohnMakin|1 year ago
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.
SPascareli13|1 year ago
No one should use containers primarily for security ever.