Would you mind expanding on these two reasons ?
If I understand you well, the first is about using reload instead of
restart.
I guess it is useful for shorter downtimes, or even to avoid breaking
existing connections, right ?
This seems like a valid point to me. We could try to improve this.
But I do not understand your second concern.
Regards,
-- Layus.
On 09/08/16 19:06, Luca Bruno wrote:
So, there are few drawbacks with the read-only nginx config as it is.
Of course, you can at any time run the nginx with an /etc/nginx config
that you write imperatively, by creating a brand new systemd service
and disregarding the existing one. After all nginx is quite a simple
service to run.
Problems with the current approach:
1. Doesn't allow for nginx reload, because the file path changes hence
nginx needs to be restarted.
2. If you are auto-updating the nginx config and reloading it
automatically after e.g. Consul health checking you are in trouble.
With /etc/nginx you give up nix rollbacks, but you can do it manually
with git which is faster than a nixos-rebuild.
So if you are going to run production stuff and maximize availability,
I'd suggest to go for imperative /etc/nginx.
That applies to most of fully declarative services in nixos.
An alternative would be to still be kind of declarative by creating a
static /etc/nginx path which symlinks to the read-only config. It all
depends if nginx follows symlinks or not.
If it works, it's worth changing the nixos systemd definition of nginx
for all with this approach.
Still you will have troubles with 3rd orchestration software
auto-updating the nginx config file.
_______________________________________________
nix-dev mailing list
[email protected]
http://lists.science.uu.nl/mailman/listinfo/nix-dev
_______________________________________________
nix-dev mailing list
[email protected]
http://lists.science.uu.nl/mailman/listinfo/nix-dev
