Last week we announced NGINX Controller 2.0. NGINX Controller has a modular architecture. In addition to the brand‑new API Management Module, we have also made significant improvements to the original Load Balancing Module and to the underlying platform. This blog post outlines those new capabilities.
Configuration-First Management
We have added a completely new way to approach configuration management, a configuration‑first approach that saves time, helps you scale, and ensures consistency across your NGINX Plus environment. You can now set policy, decide which NGINX Plus load‑balancing instances to apply it to, and then apply that policy across that set of instances with the push of a button.
As an example, here is a screenshot of a user who has decided that the Least Connections load‑balancing algorithm is best for his application and also wants to enable session persistence using the cookie method:
You can then see whether instances are in sync with the policy as you expect (and use that information to ensure compliance):
You can also check the version history for a policy to see who made what changes when, comparing any two versions with a modern‑style differencing tool. Those changes, if so desired, can also be rolled back with a single click to revert to a known‑good version.
We plan to continue adding policy areas to this configuration‑first approach in the future, to give you the same powers for other aspects of the product.
If you want to operate with instance‑centric workflows as in NGINX Controller 1.0, we have also added the ability to copy a configuration from one load‑balancing instance to any set of tags or instances. This allows you to make configurations once and send them out across your environment, instead of having to make changes on every instance. This is a huge time‑saver for large deployments.
Configuration pushes can now be deferred, and we have added indicators to remind the user that there are pending changes that need to be pushed.
Integration with ServiceNow
We have also added the first of many planned alerting integrations with the ability to send alarms to ServiceNow. Once configured, alarms from NGINX Controller trigger incidents to be created in the default ServiceNow incidents table, as shown in the following screenshot:
Control over Logging
We have also added the ability to enable the error_log
and access_log
directives from within NGINX Controller, and to either easily adopt the recommended log format for NGINX Controller (which ensures that all potential metrics are populated with data) or paste in any arbitrary format you desire.
Offline Installation
We have also added many small improvements, along with an offline installation method for both the NGINX Controller software and the agent software on hosts where NGINX Plus instances are running in environments without Internet connectivity.
Summary
In summary, in NGINX Controller 2.0 we have vastly improved the configuration management aspect of our Load Balancing Module, added ServiceNow integration for alarms, improved usability, and added an offline installation method.
Request a free trial of NGINX Controller today!