Firstly, this is not to be confused with CLONE_NEWCGROUP which unit already supports and is related to namespaces. To re-cap, namespaces allow processes to have different views of various parts of the system such as filesystem mounts, networking, hostname etc. Whereas cgroup[0] is a Linux kernel facility for collecting a bunch of processes together to perform some task on the group as a whole, for example to implement resource limits. There are two parts to cgroup, the core part of organising processes into a hierarchy and the controllers which are responsible for enforcing resource limits etc. There are currently two versions of the cgroup sub-system, the original cgroup and a version 2[1] introduced in 3.16 (August 2014) and marked stable in 4.5 (March 2016). This commit supports the cgroup V2 API and implements the ability to place applications into their own cgroup on a per-application basis. You can put them each into their own cgroup or you can group some together. The ability to set resource limits can easily be added in future. The initial use case of this would be to aid in observability of unit applications which becomes much easier if you can just monitor them on a per cgroup basis. One thing to note about cgroup, is that unlike namespaces which are controlled via system calls such as clone(2) and unshare(2), cgroups are setup and controlled through the cgroupfs pseudo-filesystem. cgroup is Linux only and this support will only be enabled if configure finds the cgroup2 filesystem mount, e.g cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel,nsdelegate,memory_recursiveprot) The cgroups are removed on shutdown or as required on reconfiguration. This commit just adds the basic infrastructure for using cgroups within unit. Subsequent commits will wire up this support. It supports creating cgroups relative to the main cgroup root and also below the cgroup of the main unit process. [0]: <https://man7.org/linux/man-pages/man7/cgroups.7.html> [1]: <https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html> Cc: Alejandro Colomar <alx@nginx.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
NGINX Unit
Universal Web App Server
NGINX Unit is a lightweight and versatile open-source server that has three core capabilities:
- it is an HTTP reverse proxy,
- a web server for static media assets,
- and an application server that runs code in seven languages.
We are building a universal tool that compresses several layers of the modern application stack into a potent, coherent solution with a focus on performance, low latency, and scalability. It is intended as a building block for any web architecture regardless of its complexity, from enterprise-scale deployments to your pet's homepage.
Unit's native RESTful JSON API enables dynamic updates with zero interruptions and flexible configuration, while its out-of-the-box productivity reliably scales to production-grade workloads. We achieve that with a complex, asynchronous, multithreading architecture comprising multiple processes to ensure security and robustness while getting the most out of today's computing platforms.
Quick Installation
macOS
$ brew install nginx/unit/unit
For details and available language packages, see the docs.
Docker
$ docker pull docker.io/nginx/unit
For a description of image tags, see the docs.
Amazon Linux, Fedora, RedHat
$ curl -sL 'https://unit.nginx.org/_downloads/setup-unit.sh' | sudo -E bash
# yum install unit
For details and available language packages, see the docs.
Debian, Ubuntu
$ curl -sL 'https://unit.nginx.org/_downloads/setup-unit.sh' | sudo -E bash
# apt install unit
For details and available language packages, see the docs.
Running a Hello World App
Suppose you saved a PHP script as /www/helloworld/index.php:
<?php echo "Hello, PHP on Unit!"; ?>
To run it on Unit with the unit-php module installed, first set up an
application object. Let's store our first config snippet in a file called
config.json:
{
"helloworld": {
"type": "php",
"root": "/www/helloworld/"
}
}
Saving it as a file isn't necessary, but can come in handy with larger objects.
Now, PUT it into the /config/applications section of Unit's control API,
usually available by default via a Unix domain socket:
# curl -X PUT --data-binary @config.json --unix-socket \
/path/to/control.unit.sock http://localhost/config/applications
{
"success": "Reconfiguration done."
}
Next, reference the app from a listener object in the /config/listeners
section of the API. This time, we pass the config snippet straight from the
command line:
# curl -X PUT -d '{"127.0.0.1:8000": {"pass": "applications/helloworld"}}' \
--unix-socket /path/to/control.unit.sock http://localhost/config/listeners
{
"success": "Reconfiguration done."
}
Now Unit accepts requests at the specified IP and port, passing them to the application process. Your app works!
$ curl 127.0.0.1:8080
Hello, PHP on Unit!
Finally, query the entire /config section of the control API:
# curl --unix-socket /path/to/control.unit.sock http://localhost/config/
Unit's output should contain both snippets, neatly organized:
{
"listeners": {
"127.0.0.1:8080": {
"pass": "applications/helloworld"
}
},
"applications": {
"helloworld": {
"type": "php",
"root": "/www/helloworld/"
}
}
}
For full details of configuration management, see the docs.
Community
-
The go-to place to start asking questions and share your thoughts is our Slack channel.
-
Our GitHub issues page offers space for a more technical discussion at your own pace.
-
The project map on GitHub sheds some light on our current work and plans for the future.
-
Our official website may provide answers not easily found otherwise.
-
Get involved with the project by contributing! See the contributing guide for details.
-
To reach the team directly, subscribe to the mailing list.
-
For security issues, email us, mentioning NGINX Unit in the subject and following the CVSS v3.1 spec.