2004年のNginxの登場以来、私たちは皆疑問に思っていました。いつnginxでアプリケーションを実行できるのでしょうか？ 私たちはphp-fpmとApacheでPHPを実行し、uWSGIを介してPythonを実行し、Apacheと一緒に住んでいることもありました。異なるバージョンのPHPが必要な場合は、FPMの動物園で暮らしました。
Nginx、Inc.のポートランドで開催されたNginxConfカンファレンスで Nginx Application Platformの発表を発表しました。 ITSummaは、コンポーネントの1つであるApplication Server自体をテストしました。これは、Nginxユニットと呼ばれ、閉じたバージョンです。 この投稿では、Nginxユニットの外観と、その上でアプリケーションを実行する方法について説明します。
Nginx Unitは、さまざまなプログラミング言語（php、python、go）で記述されたWebアプリケーションを実行できるWebアプリケーションサーバーです。 このツールは非常に軽量で、開発中に必要に応じて設定とアプリケーションの数をオンザフライで再構成できます。
→
プロジェクトのメインサイト現在サポートされているプラットフォーム：
-Python 2.6、2.7、3
-PHP 5、7
-Go 1.6以降
プラットフォームの動物園を持つ人々のための重要でクールな機能：同じプラットフォームの異なるバージョンは、1つのアプリサーバーである同じ構成内で起動できます-さようなら、PHP-FPM動物園。
→プロジェクトのソースコードが
Githubにアップロードされます。
クールで面白いのは、最初のコミットからコードをgithubにアップロードし、githubのクラシックスタイルでプルリクエストを受け入れることを約束することです。 とりわけ、開発の歴史、論理、スタイルを見ることができます-非常に興味深いです。
設置
重要：現在のバージョンはまだベータ版であり、オーバーヘッドを追加する多くのデバッグコードがあります。 将来のバージョンでは、大幅な最適化が約束されており、パフォーマンスの点で現在のアプリサーバーを上回るはずです。
CentOS 7.0およびUbuntu 16.04 LTSで利用可能なパッケージ
CentOS 7のインストール1.次の内容で/etc/yum.repos.d/unit.repoファイルを作成します。
[unit] name=unit repo baseurl=http://nginx.org/packages/mainline/centos/7/$basearch/ gpgcheck=0 enabled=1
2.パッケージのインストールを実行します。
Ubuntu 16.04のインストール1.
NGINX 、Incの
PGPドングルをダウンロードします。
2.キーをaptキーチェーンに追加します。 その後、ユニットのインストール中にPGPキーが見つからないという警告は表示されません。
3. /etc/apt/sources.listファイルの最後に次の行を追加します。
deb http://nginx.org/packages/mainline/ubuntu/ xenial nginx deb-src http://nginx.org/packages/mainline/ubuntu/ xenial nginx
4.ダウンロードユニット：
Nginxユニットは、いくつかのサービスプロセス（マスター/コントローラー/ルーター）とアプリケーションプロセス自体で構成されています。 設定は、REST API、Unixソケットunit.control.sockを介して行われます。
現在の設定を取得する
curl --unix-socket ./control.unit.sock http:
新しいダウンロード
curl -X PUT -d @/path/to/start.json --unix-socket ./control.unit.sock http://localhost/
構成は、一連のアプリケーション（アプリケーション）とワーカー（リスナー）で構成されます。
アプリケーションの起動
「1C-Bitrix」およびLaravelの起動の例でアプリケーションの起動を検討してください。
フロントエンドは古典的なnginxであり、バックエンドはNginxユニットです。 現在、PHPのすべてのNginxユニット「アプリケーション」には1つのエントリポイントがあります。 Bitrixの場合、それらの2つがあります-urlrewrite.phpとindex.php、それぞれベータ版-このロジックをコード内の1つのファイルに結合するか、2つのアプリケーションを実行する必要があります。 Nginxユニットの今後のバージョンでは、この問題を回避するためにルーティングを行うことを約束します。
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; }
「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; }
構成を置き換えるには、次を実行します
curl -X PUT -d @/path/to/start.json --unix-socket ./control.unit.sock http://localhost/
（デフォルト-ソケット、nginxを使用してソケットからTCPポートにプロキシできます。）
現時点では、アプリサーバーの起動時に構成をロードする必要があります。将来のバージョンでは、ユニットは再起動時にロードされた構成を保存します。
まず、アプリケーションをリストしますが、アプリケーションごとにインタープリターのバージョンを示します。 インデックスパラメータをエントリポイントとして指定することができます（そして、スクリプトはクエリ文字列から取得されます）、またはエントリポイントの場合はスクリプト-そして、リクエストは特定のスクリプトに送られます。 繰り返しになりますが、「1C-Bitrix」の場合、2つのアプリケーションが起動します。
構成：
{ "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" } },
次に、ポートでupsがハングアップします。
"listeners": { "*:8300": { "application": "laravel" }, "*:8500": { "application": "plain" }, "*:8600": { "application": "bitrix" }, "*:8601": { "application": "bitirx_index" } } }
かなり長い間これを待っていましたが、Unitが深刻な利点をもたらすケースを引き続き見てみましょう。
- 異種アプリケーションインフラストラクチャ。 これで、同じアプリサーバー内で、異なるバージョンのPHPを保持し、PythonとGoを実行できます。 年末までに、NodeJS、Java、およびおそらくRubyが期待されています。 これらはすべて、同じアプリサーバーの1つの構成で実現されます。 アプリケーションは1つの言語で作成する必要がなくなり、私たちの生活が本当に楽になります。
- 1つのシステム上のZooバージョン 。 さまざまなバージョンの多数のfpm構成とビルドにうんざりしていませんか？ これで、同じアプリケーション内で実行できます。 これは「クリーン」な状況ではないことは明らかですが、しばしば遭遇し、再び深刻な生命の救済になります。
- ポイント1と2を自分で感じる場合、Nginxが話す3番目の点はまだ試されています。 マイクロサービスアーキテクチャによる統合された簡単な構成管理。 全体として単一の製品であるREST APIを介した統合構成管理システム。
Application Platformはまだベータ版ですが、既に本番用の構成を試して準備することができます。 さらなるニュースを楽しみにしています！