Today we are releasing the sixth beta version (0.6) of NGINX Unit, our new dynamic web and application server. In this blog post, we discuss the latest changes in detail.
Important: There are changes to the configuration API. Be sure to read Advanced Process Management in its entirety before upgrading your existing NGINX Unit installation.
NGINX Unit is under active development. It’s likely that at the time you read this blog post, even more recent releases will be available. Check https://unit.nginx.org/CHANGES.txt for details on the latest release.
Highlights of the changes since the release of NGINX Unit 0.3 are described in detail below:
With the addition of Perl support, we can now run applications like Bugzilla, a popular bug‑tracking system written in Perl.
In previous versions of NGINX Unit, the only way to limit the worker count was to include the workers
parameter of the application object. The workers
parameter has been removed and now you can manage your application more granularly with the new processes
{}
object, as described in the following sections.
max
ParameterWhen application load rises, NGINX Unit creates more application processes. However, it does not fork more application processes than the maximum defined by the max
parameter of the processes
{}
object. The default is 1
.
This example allows up to ten workers:
{ "listeners": {
"*:8090": {
"application": "myblog"
}
},
"applications": {
"myblog": {
"type": "php",
"root": "/srv/myblog",
"processes": {
"max": 10
}
}
}
}
Using the API, you can change the parameter’s value without reloading the rest of the configuration (here, the new value is 3
):
# curl -X PUT -d 3 --unix-socket /path/to/control.unit.sock http://localhost/applications/myblog/processes/max
When the application starts, Unit will create the number of workers specified in the spare
parameter of the processes {}
object. When the load is low, and the processes are idle, Unit will scale down to the number specified by the parameter. By default, this parameter is set to 0.
spare
ParameterWhen an application starts, NGINX Unit creates the number of workers specified by the spare
parameter of the processes
{}
object. When the load is low, and processes are idle, NGINX Unit scales down to the number specified by the parameter. The default is 0
.
The number of spare processes must be less than or equal to the maximum number of processes. Thus, you cannot set spare
to more than 1
unless you also set the max
parameter to a value higher than its default of 1
.
This example creates five application processes at startup, scales up to ten processes when the load increases, and scales back down to as few as five processes when the load is low:
{
"listeners": {
"*:8090": {
"application": "myblog"
}
},
"myblog": {
"crossplane": {
"type": "php",
"root": "/srv/myblog",
"processes": {
"max": 10,
"spare": 5
}
}
}
}
Using the API, you can change the parameter’s value without reloading the rest of the configuration (here, the new value is 3
):
# curl -X PUT -d 3 --unix-socket /path/to/control.unit.sock http://localhost/applications/myblog/processes/spare
idle_timeout
ParameterThe idle_timeout
parameter sets the number of seconds that NGINX Unit waits before terminating a worker that has become idle. The default is 15 seconds.
In the following example, NGINX Unit waits for a worker to be inactive for 20 seconds before terminating it.
{
"listeners": {
"*:8090": {
"application": "myblog"
}
},
"myblog": {
"crossplane": {
"type": "php",
"root": "/srv/myblog",
"processes": {
"max": 10,
"spare": 5,
"idle_timeout": 20
}
}
}
}
As with any other parameter, you can use the API to can change the value directly without reloading the confriguration. This example explicitly sets it to the default of 15 seconds:
# curl -X PUT -d 15 --unix-socket /path/to/control.unit.sock http://localhost/applications/myblog/processes/idle_timeout
If you want to use a simpler, static process model, you can set the processes
option to an integer value. In that case, NGINX Unit starts the specified number of application processes immediately, and keeps them active without scaling up or down.
An example for an application object:
{
"type": "php",
"root": "/srv/myblog",
"processes": 10
}
NGINX Unit now supports the Perl Server Gateway Interface (PSGI).
Notes:
The unit-perl binary package is available in our repository for all supported operating systems. See the complete installation instructions in the NGINX Unit documentation.
If you compile NGINX Unit from source, you need to install developer libraries for Perl before compiling the source:
libperl-dev
perl-devel
and perl-libs
See the complete source‑compilation instructions in the NGINX Unit documentation.
A Perl application object looks like this:
{ "type": "perl",
"user": "nobody",
"working_directory": "/my/bugtracker",
"script": "app.psgi"
}
This simple application collects environment variables and prints them out:
use Data::Dumper;
my $app = sub {
my $env = shift;
return [
'200',
[ 'Content-Type' => 'text/plain' ],
[ "Hello from Unit, Perl $^V, environment:nn", Dumper($env) ],
];
};
As with the other languages that Unit supports, you can use all listener, process management, and security features the same way with Perl applications as you do with any other app.
Docker containers for NGINX Unit are now available on Docker Hub. The Tags tab lists the containers available for various combinations of NGINX Unit version (represented in the list by unit) and application version:
The :latest tag (used by default) links to the -full container for the newest version of NGINX Unit (at the time of writing, 0.6-full).
In the simplest case, to run Unit in Docker pull and run nginx/unit, then use the API from within the container to configure NGINX Unit.
If you need to do more sophisticated configuration, you can mount the volumes and have the container socket accessible from the host or from another container, or have the control socket available via a TCP port.
Precompiled packages are now available for Amazon Linux. See the installation instructions in the NGINX Unit documentation.
With the 0.6 version, NGINX Unit is getting close to the functionality, language support, and reliability it will have when we reach general availability (GA) with Unit 1.0, which is described in our road map blog post and shown in the demo on YouTube. Please continue to experiment with NGINX Unit and submit your feedback on GitHub.
"This blog post may reference products that are no longer available and/or no longer supported. For the most current information about available F5 NGINX products and solutions, explore our NGINX product family. NGINX is now part of F5. All previous NGINX.com links will redirect to similar NGINX content on F5.com."