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:
- Advanced process management and prefork model
- Support for Perl/PSGI
- Official Docker containers (featured on Docker Hub)
- Packages for an additional operating system, Amazon Linux
With the addition of Perl support, we can now run applications like Bugzilla, a popular bug‑tracking system written in Perl.
Advanced Process Management
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.
Setting the Maximum Number of Workers with the max Parameter
When 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/maxWhen 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.
Prefork and Scaling Down Unused Workers with the spare Parameter
When 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/spareThe idle_timeout Parameter
The 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_timeoutBasic Process Management
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
}Support for Perl/PSGI
NGINX Unit now supports the Perl Server Gateway Interface (PSGI).
Notes:
- PSGI applications are different from Perl CGI applications, which NGINX Unit does not support.
- We have tested NGINX Unit with various versions of Perl, the earliest being 5.12. It may work with older versions as well, but you need to verify that.
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:
- For Debian and Ubuntu:
libperl-dev - For CentOS/RHEL:
perl-develandperl-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.
Official Docker Containers
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:
- unit-full (for example, 0.6-full) includes the modules for all supported languages and also runs precompiled Go apps. If you are unsure which languages you will want to use, use this container.
- unit-minimal does not include modules and interpreters for any languages, but can run precompiled Go apps.
- unit-phpPHP_version (for example, 0.6-php7.0) can run PHP scripts and precompiled Go apps.
- unit-pythonPython_version can run Python scripts and precompiled Go apps.
- unit-go1.7-dev and unit-go1.8-dev can compile Go apps with the appropriate NGINX and NGINX Unit packages for the specified version of Go, as well as run precompiled Go apps.
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.
Support for Amazon Linux
Precompiled packages are now available for Amazon Linux. See the installation instructions in the NGINX Unit documentation.
Conclusion
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.