11 ms·

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

• kungfufrog 4y ago
  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 4y ago
    Good catch! I hope this is applicable to the kubernetes ingress controller.
    • bithavoc 4y ago
      yeah, hopefully it helps replace a bunch of lua code from ingress-nginx
    • throwaway892238 4y ago
      Kubernetes will probably drop Ingress in favor of API Gateway in two years.
      • harpratap 4y ago
        That's just the API layer for configuration, you still need a proxy to route. Nginx will still stay relevant
• deleted 4y ago
  [deleted]
• nwellinghoff 4y ago
  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 4y ago
    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 4y ago
    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 http://nginx.org/en/docs/beginners_guide.html#control
• cypres 4y ago
  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-frequency-of-configuration-reloads/ 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-plus#dynamic-reconfiguration 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 4y ago
    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.
• Grimburger 4y ago
  > 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.
• preisschild 4y ago
  OpenResty (nginx distribution with lua JIT plugin built in) can do this