Announcing gRPC Support in NGINX ということで、nginx 1.13.9 で gRPC サポートが入り、HTTP と同じように gRPC ストリームを扱えるようになるようです。めでたい！ grpc_pass ディレクティブが新規に実装され、grpc:// と grpcs:// なバックエンドに対してリバースプロキシを行えるようになるようです。これを使って、 TLS 終端を nginx にやってもらったり 複数のバックエンドを置いて柔軟にロードバランスしてもらったり 同一のエンドポイントに複数 gRPC service を設定して、nginx にルーティングしてもらったり などの設定をすることが可能になるようです。 まだ正式にリリースされているわけではないので、今回は HEAD を持ってきて、リリースに載っている例を試してみます。 下準備 今回は適当に EC2
http { : log_format json escape=json '{"time": "$time_iso8601",' '"host": "$remote_addr",' '"vhost": "$host",' '"user": "$remote_user",' '"status": "$status",' '"protocol": "$server_protocol",' '"method": "$request_method",' '"path": "$request_uri",' '"req": "$request",' '"size": "$body_bytes_sent",' '"reqtime": "$request_time",' '"apptime": "$upstream_response_time",' '"ua": "$http_user_agent",'
Today, we’re excited to share the first native support for gRPC traffic, released in NGINX Open Source 1.13.10. NGINX Plus Release 15 includes gRPC support as well as the support for HTTP/2 server push introduced in NGINX 1.13.9. NGINX can already proxy gRPC TCP connections. With this new capability, you can terminate, inspect, and route gRPC method calls. You can use it to: Publish a gRPC service
追記 [nginx-announce] nginx-1.13.9 http://mailman.nginx.org/pipermail/nginx-announce/2018/000207.html 1.13.9でサーバプッシュがサポートされました 先程、Nginxでサーバプッシュをサポートするコミットが入ったので試す。 HTTP/2: server push. http://hg.nginx.org/nginx/rev/641306096f5b ビルド $ git clone https://github.com/nginx/nginx.git $ cd ./nginx $ ./auto/configure --with-http_ssl_module --with-http_v2_module $ make $ sudo make install #一旦インストールしてしまう 設定 一
We all know that performance is critical to a website’s success. No one wants to use a slow website. Since its initial open source release in 2004, NGINX has been synonymous with high‑performance websites. More of the world’s websites use NGINX than any other web server, and more than [ngx_snippet id=’26097′] sites worldwide are now powered by NGINX. But how well does NGINX actually perform? What
[20170809追記] nginx-1.13.4に ngx_http_mirror_module は含まれました Nginxで、リクエストを複製するmirrorモジュールがコミットされ、何もせずとも使用できるようになりそうです(現状最新コミットをビルドする必要あり)。 例えば本番環境のproxyからリクエストを複製して開発環境に流すような事も出来ます。もちろん複製処理は本来のリクエスト処理をブロックしません。 例えば以下のように、mirrorに来たリクエストを複製してバックエンドサーバに投げるようにしてみます conf server { listen 80 ; server_name localhost; mirror_request_body on; log_subrequest on; location /mirror { mirror /proxy; #/proxy宛にリクエストを
NginxのL4レイヤのProxy機能である、streamモジュールのDTLS対応パッチが公開されていたので試す。 (まだ検証段階で、フィードバック募集中らしい) 簡単に言うと、以下のようににDTLS -> Plain UDPや、その逆にPlain UDP -> DTLSへのProxyが出来る。 DTLS -> Plain UDP Plain UDP -> DTLS Plain UDP -> DTLS -> Plain UDP 2つ組み合わせれば、中間だけDTLSで暗号化することも出来る ビルド 今回は、Ubuntu Trustyでビルドする sudo apt-get install libpcre3-dev wget http://nginx.org/download/nginx-1.13.0.tar.gz wget http://nginx.org/patches/dtls/nginx
$request_id Nginx 1.11.0 以降に限りますが、リクエスト毎に発番されるIDの変数として $request_id が追加されたようです。 http://nginx.org/en/docs/http/ngx_http_core_module.html#var_request_id この変数を利用することにより、Nginxコアだけでサービス間のトレースを簡単に行うことが可能になります。 シンプルな例 以下のように、$request_idをログに含めるだけでリクエスト毎のIDを記録できます。 http { log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "
nginxのリクエスト数を制限する、ngx_http_limit_req_moduleの動作を勝手に勘違いして勝手にハマったというお話です。 大したことではないのですがdockerでその動作を再現した例はこちらです。 github.com 何にハマったのかというと、”5r/sが5req per secではない”のです。 ”2r/sも2req per secではない”のです。でも”1r/sは1req per secです”。なぞなぞでしょうか。 ...dockerのコンテナを動かしてshellを実行すると次のようなエラーログとアクセスログが出力されます。 nginx_1 | 2016/06/13 15:35:35 [error] 8#8: *18 limiting requests, excess: 0.995 by zone "five", client: 192.168.99.1, ser
2年半ほど前にnginx vim syntaxを導入したのだが、nginxも日々進化しており、syntax highlightの効かない項目が増えてきた。使える機能に色がつかないと地味に気を取られるし、いつの間にか生産性を下げていたのかもしれない（そういう意味では、syntax highlightを使わない選択は合理的なのかも。） いつものようにnginx-develメーリスを眺めていたら、Vim用のパッチが送られており、Vimの設定ファイルがメンテされていることに気づいた1 2。そしてその設定ファイルこそが、元々使っていたevanmiller/nginx-vim-syntaxの移管先だった。nginx-vim-syntaxのREADMEをよく見ると、2013年12月に移管した旨が書かれている…ずっと気づいてなかった。公式が最強だった。 早速nginx-vim-syntaxを捨てて、以下の
For general purposes, nginx code uses two integer types, ngx_int_t and ngx_uint_t, which are typedefs for intptr_t and uintptr_t respectively. Most functions in nginx return the following codes: NGX_OK — Operation succeeded. NGX_ERROR — Operation failed. NGX_AGAIN — Operation incomplete; call the function again. NGX_DECLINED — Operation rejected, for example, because it is disabled in the configur
Nginx uses an event-driven architecture with a master process that manages worker processes. It handles requests non-blockingly and efficiently using techniques like memory pooling, buffer chaining, and an event-driven model. Key parts of the architecture include phases and handlers for HTTP requests, virtual servers, locations, and filters. Nginx also supports mail proxying and module development
Emiller’s Guide To Nginx Module Development By Evan Miller First published: April 28, 2007 (Last edit: August 11, 2017 – changes) Bruce Wayne: What’s that? Lucius Fox: The Tumbler? Oh… you wouldn’t be interested in that. To fully appreciate Nginx, the web server, it helps to understand Batman, the comic book character. Batman is fast. Nginx is fast. Batman fights crime. Nginx fights wasted CPU cyc
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く