Waiting for 15 years. Nginx Application Server
Since the appearance of Nginx in 2004, we all wondered: when will nginx be able to run applications? We ran PHP in php-fpm and apache, we launched Python via uWSGI, sometimes we lived with Apache, and if we needed different versions of PHP, we lived with a zoo from FPMs.
Just at the NginxConf conference in Portland Nginx, Inc. announced the launch of the Nginx Application Platform. ITSumma tested one of its components, the Application Server itself, called the Nginx Unit, from the closed version. In this post we will talk about how the Nginx Unit looks and how to launch applications on it.
Nginx Unit is a web application server that allows you to run web applications written in various programming languages ​​(php, python, go). This tool is quite easy and allows you to reconfigure the settings and the number of applications as needed during development on the fly.
')
→ Main project site
Currently supported platforms:
- Python 2.6, 2.7, 3
- PHP 5, 7
- Go 1.6 or later
An important and cool opportunity for people with zoo platforms: different versions of the same platform can be launched within one config, one appserver - goodbye, PHP-FPM zoo.
→ The source code of the project is loaded on GitHab .
What is cool and interesting: the guys have downloaded the code from the first commit to GitHab and promise to accept pull-requests in the classic GitHab style. Among other things, you can see the history, logic and style of development - very interesting.
Important: The current version is still beta, with a huge amount of debugging code that adds its overhead. In the next versions promise significant optimization, which should surpass the current app servers for performance.
Packages are now available for CentOS 7.0 and Ubuntu 16.04 LTS
Installation for CentOS 7
1. Create the file /etc/yum.repos.d/unit.repo with the following contents:
2. Run the package installation:
Installation for Ubuntu 16.04
1. Download the NGINX , Inc. PGP key .
2. Add the key to the apt keychain. After that, there should be no alerts about the missing PGP key during the installation of Unit.
3. Add the following lines to the end of the /etc/apt/sources.list file:
4. Download Unit:
Nginx Unit consists of several service processes (master / controller / router) and the application processes themselves. Configuration is done through REST API, through Unix socket unit.control.sock.
Getting the current config
Download new
The configuration consists of a set of applications (application) and workers (listener).
Consider the launch of the application on the example of the launch of "1C-Bitrix" and Laravel:
The front end is the classic nginx, and the back end is the Nginx Unit. Now every Nginx Unit “application” for PHP implies one entry point. In the case of Bitrix there may be two - urlrewrite.php and index.php, respectively, in beta - you need to either merge this logic into one file in the code, or run two applications. In the next versions of the Nginx Unit, the guys promise to do the routing to avoid this problem.
Configuration for Laravel:
Configuration for 1C-Bitrix:
To replace the configuration run
(By default, the socket, you can proxy from the socket to the TCP port using nginx.)
At the moment, the configuration must be loaded when the app server is started; in future versions, the Unit will save the loaded configuration upon restart.
First we list the applications, and for each application we indicate the version of the interpreter. As an entry point, you can specify the index parameter (and then the script will be taken from the query string), or, in the case of the entry point, the script - and then the queries will go to a specific script. Again, note that two applications are running for 1C-Bitrix:
Config:
Then the ups are hung on the ports:
We have all been waiting for this for a long time, but let's still consider the cases where the Unit will bring a serious advantage:
While the Application Platform is still beta, you can already try and prepare your configurations for production. We are waiting for further news!
Just at the NginxConf conference in Portland Nginx, Inc. announced the launch of the Nginx Application Platform. ITSumma tested one of its components, the Application Server itself, called the Nginx Unit, from the closed version. In this post we will talk about how the Nginx Unit looks and how to launch applications on it.
Nginx Unit is a web application server that allows you to run web applications written in various programming languages ​​(php, python, go). This tool is quite easy and allows you to reconfigure the settings and the number of applications as needed during development on the fly.
')
→ Main project site
Currently supported platforms:
- Python 2.6, 2.7, 3
- PHP 5, 7
- Go 1.6 or later
An important and cool opportunity for people with zoo platforms: different versions of the same platform can be launched within one config, one appserver - goodbye, PHP-FPM zoo.
→ The source code of the project is loaded on GitHab .
What is cool and interesting: the guys have downloaded the code from the first commit to GitHab and promise to accept pull-requests in the classic GitHab style. Among other things, you can see the history, logic and style of development - very interesting.
Installation
Important: The current version is still beta, with a huge amount of debugging code that adds its overhead. In the next versions promise significant optimization, which should surpass the current app servers for performance.
Packages are now available for CentOS 7.0 and Ubuntu 16.04 LTS
Installation for CentOS 7
1. Create the file /etc/yum.repos.d/unit.repo with the following contents:
[unit] name=unit repo baseurl=http://nginx.org/packages/mainline/centos/7/$basearch/ gpgcheck=0 enabled=1 2. Run the package installation:
# yum install unit Installation for Ubuntu 16.04
1. Download the NGINX , Inc. PGP key .
2. Add the key to the apt keychain. After that, there should be no alerts about the missing PGP key during the installation of Unit.
# sudo apt-key add nginx_signing.key 3. Add the following lines to the end of the /etc/apt/sources.list file:
deb http://nginx.org/packages/mainline/ubuntu/ xenial nginx deb-src http://nginx.org/packages/mainline/ubuntu/ xenial nginx 4. Download Unit:
# apt-get update # apt-get install unit Nginx Unit consists of several service processes (master / controller / router) and the application processes themselves. Configuration is done through REST API, through Unix socket unit.control.sock.
Getting the current config
curl --unix-socket ./control.unit.sock http://localhost/ Download new
curl -X PUT -d @/path/to/start.json --unix-socket ./control.unit.sock http://localhost/ The configuration consists of a set of applications (application) and workers (listener).
Application launch
Consider the launch of the application on the example of the launch of "1C-Bitrix" and Laravel:
The front end is the classic nginx, and the back end is the Nginx Unit. Now every Nginx Unit “application” for PHP implies one entry point. In the case of Bitrix there may be two - urlrewrite.php and index.php, respectively, in beta - you need to either merge this logic into one file in the code, or run two applications. In the next versions of the Nginx Unit, the guys promise to do the routing to avoid this problem.
Configuration for Laravel:
location / { proxy_pass http://127.0.0.1:8300; proxy_redirect http://127.0.0.1:8300/ /; proxy_read_timeout 60s; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location ~ \.php$ { proxy_pass http://127.0.0.1:8300; proxy_redirect http://127.0.0.1:8300/ /; proxy_read_timeout 60s; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } Configuration for 1C-Bitrix:
location = / { proxy_pass http://127.0.0.1:8601; proxy_redirect http://127.0.0.1:8601/ /; proxy_read_timeout 60s; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; break; } location / { try_files $uri /bitrix/urlrewrite.php =404; proxy_pass http://127.0.0.1:8600; proxy_redirect http://127.0.0.1:8600/ /; proxy_read_timeout 60s; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } To replace the configuration run
curl -X PUT -d @/path/to/start.json --unix-socket ./control.unit.sock http://localhost/ (By default, the socket, you can proxy from the socket to the TCP port using nginx.)
At the moment, the configuration must be loaded when the app server is started; in future versions, the Unit will save the loaded configuration upon restart.
First we list the applications, and for each application we indicate the version of the interpreter. As an entry point, you can specify the index parameter (and then the script will be taken from the query string), or, in the case of the entry point, the script - and then the queries will go to a specific script. Again, note that two applications are running for 1C-Bitrix:
Config:
{ "applications": { "laravel": { "type": "php 7.0", "user": "nobody", "group": "nobody", "workers": 2, "root": "/var/www/vhosts/laravel/public", "script": "index.php", }, "plain": { "type": "php 7.0", "user": "nobody", "group": "nobody", "workers": 2, "root": "/var/www/vhosts/test", "index": "index.php" }, "bitrix": { "type": "php 5.6", "user": "nobody", "group": "nobody", "workers": 2, "root": "/var/www/vhosts/bitrix", "script": "/bitrix/urlrewrite.php" }, "bitrix_index": { "type": "php 5.6", "user": "nobody", "group": "nobody", "workers": 2, "root": "/var/www/vhosts/bitrix", "script": "index.php" } }, Then the ups are hung on the ports:
"listeners": { "*:8300": { "application": "laravel" }, "*:8500": { "application": "plain" }, "*:8600": { "application": "bitrix" }, "*:8601": { "application": "bitirx_index" } } } We have all been waiting for this for a long time, but let's still consider the cases where the Unit will bring a serious advantage:
- heterogeneous application infrastructure. Now, within the same app-server, you can keep different versions of PHP, run Python and Go. NodeJS, Java and possibly Ruby are expected by the end of the year. All this in one config, the same app-server. Applications are no longer written in the same language, and this will really make life easier for all of us.
- Zoo versions on one system . Tired of the many configurations and builds of fpm with different versions? Now it can be run within the same application. It is clear that this is not a “clean” situation, but it often occurs and, again, a serious relief of life.
- if we feel points 1 and 2 on ourselves, then the third one, about which Nginx speaks, is yet to be tried. Unified and simple configuration management microservice architecture. A single configuration management system through the REST API, a single product as a whole.
While the Application Platform is still beta, you can already try and prepare your configurations for production. We are waiting for further news!
Source: https://habr.com/ru/post/337346/
All Articles