[cypres]

As long as Dynamic Configuration is locked behind an nginx plus-only API, these are hollow words.

This is a must have feature for todays workloads (kubernetes or just very busy webservers) in production, and nginx will likely continue to lose market share to Envoy based alternatives where everything is configured through APIs, without needing to reload the server.

[kungfufrog]

This is definitely addressed in the article. The relevant bits talk about moving features from the commercial version to the open source version, as well as the introduction of an open source nginx agent that can do the "dynamic config" on your behalf (via API I presume).

I agree with your sentiment though! I hope they do follow through as nginx is generally an easy sell to others when trying to fill holes in your tech stack and otherwise pretty bulletproof.

[cypres]

Good catch! I hope this is applicable to the kubernetes ingress controller.

[throwaway892238]

Kubernetes will probably drop Ingress in favor of API Gateway in two years.

[harpratap]

That's just the API layer for configuration, you still need a proxy to route. Nginx will still stay relevant

[bithavoc]

yeah, hopefully it helps replace a bunch of lua code from ingress-nginx

[cypres]

Some additional context to what I'm referring, in this old blog post from 2015, nginx describe exactly why the dynamic configuration feature is important, and what's wrong with just reloading (draining the old process of connections). https://www.nginx.com/blog/using-nginx-plus-to-reduce-the-fr...

For rolling deployments, it can cause repeated configuration changes exacerbating the problem, some workloads more affected from this than others of course. The nginx ingress controller makes this clear

https://docs.nginx.com/nginx-ingress-controller/intro/nginx-...

> Every time the number of pods of services you expose via an Ingress resource changes, the Ingress Controller updates the configuration of the load balancer to reflect those changes. For NGINX, the configuration file must be changed and the configuration subsequently reloaded. For NGINX Plus, the dynamic reconfiguration is utilized, which allows NGINX Plus to be updated on-the-fly without reloading the configuration. This prevents increase of memory usage during reloads, especially with a high volume of client requests, as well as increased memory usage when load balancing applications with long-lived connections (WebSocket, applications with file uploading/downloading or streaming).

edit: formatting

[nocterro]

Just to make things interesting, there’s actually two Ingress controllers based on NGINX, one led by the NGINX company and one under Kubernetes organisation. The Kubernetes-led controller ‘ingress-nginx’ is substantially enhanced with OpenResty integration and doesn’t have the issue with reloads that the blog refers to.

[nwellinghoff]

You can use a switch to start the nginx process and tell it to stop accepting new connections on the old one without killing it. Forgot the switch but its in the docs. Don’t know if this is well known but this is how I made a poor mans dynamically configurable nginx like 7 years ago using the free version. It worked great

[remram]

I think this is known, and the Kubernetes Ingress Controller leverages this, however you are leaving that other process behind until connections drain. If you are changing configurations often enough, you might have many old processes lying around, consuming resources and using old settings. So it's not ideal.

[infensus]

Reload signal?

> Once the master process receives the signal to reload configuration, it checks the syntax validity of the new configuration file and tries to apply the configuration provided in it. If this is a success, the master process starts new worker processes and sends messages to old worker processes, requesting them to shut down. Otherwise, the master process rolls back the changes and continues to work with the old configuration. Old worker processes, receiving a command to shut down, stop accepting new connections and continue to service current requests until all such requests are serviced. After that, the old worker processes exit.

http://nginx.org/en/docs/beginners_guide.html#control

[preisschild]

OpenResty (nginx distribution with lua JIT plugin built in) can do this

[Grimburger]

> This is a must have feature for todays workloads (kubernetes or just very busy webservers) in production

So something you are making money from? How do you propose to keep it secure and maintained as FOSS? Someone else's donations?

If it is so critical, surely paying a few dollars won't break your business model.