NGINX Unitが正式リリース。PHP、Go、Pythonなどに対応した軽量アプリケーションサーバ
NGINX Unitが正式リリース。PHP、Go、Pythonなどに対応した軽量アプリケーションサーバ オープンソースで開発されている軽量なアプリケーションサーバ「NGINX Unit」の正式版がリリースされました（「Announcing NGINX Unit 1.0 | NGINX」）。 NGINX Unitは、軽量なWebサーバとして知られるNGINXの開発者であるIgor Sysoevが設計し、NGNIXのソフトウェア開発チームが実装を担当したもの。昨年の9月にパブリックプレビュー版が登場しており、今回それがバージョン1.0に到達しました。 参考： 日本Nginxユーザ会が発足。開発者Igor Sysoev氏が語る、Nginxが生まれ、商用化された理由 － Publickey NGINX Unitの主な特長は、動的制御が可能なためコンフィグレーションやアプリケーションの入れ替え、バー
Nginx 1.13 の http_mirror_module を試す - たごもりすメモ
みなさんにも、さまざまな過去の経緯からくる微妙挙動を満載した外部ユーザ向けのHTTPサーバをリプレイスしたりするとき、実際にガツンとやっちまう前にちょっとリクエストを分岐して挙動と性能を確認したい、と思うことがあると思います。考えるだけでつらい気分になってくるやつ。でもやったほうが100倍マシなやつ。 どうしよっかなとちょっと考えたところ、少し前にこんな話があったのを思い出すはずですね*1。 asnokaze.hatenablog.com とはいえヨッシャ使うぞといきなりぶちこむこともできないので、まずいくつか試してみることにする。 準備 前提としては以下のように、元のアプリケーションと同じにホストにリバースプロキシが立っており、そこのnginxで http_mirror_module を使う、という想定*2。ミラー先はどこか適当なアプリケーションサーバ(あるいはロードバランサ)で、元アプ
nginx に実装された gRPC サポートを試してみる - Qiita
Announcing gRPC Support in NGINX ということで、nginx 1.13.9 で gRPC サポートが入り、HTTP と同じように gRPC ストリームを扱えるようになるようです。めでたい！ grpc_pass ディレクティブが新規に実装され、grpc:// と grpcs:// なバックエンドに対してリバースプロキシを行えるようになるようです。これを使って、 TLS 終端を nginx にやってもらったり 複数のバックエンドを置いて柔軟にロードバランスしてもらったり 同一のエンドポイントに複数 gRPC service を設定して、nginx にルーティングしてもらったり などの設定をすることが可能になるようです。 まだ正式にリリースされているわけではないので、今回は HEAD を持ってきて、リリースに載っている例を試してみます。 下準備 今回は適当に EC2
Introducing gRPC Support with NGINX 1.13.10 – NGINX Community Blog
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
Configuring HTTPS servers
To configure an HTTPS server, the ssl parameter must be enabled on listening sockets in the server block, and the locations of the server certificate and private key files should be specified: server { listen 443 ssl; server_name www.example.com; ssl_certificate www.example.com.crt; ssl_certificate_key www.example.com.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5;
Nginxで、リクエストを複製するmirrorモジュールが標準搭載された - ASnoKaze blog
[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でWebサーバ間をトレースするrequest_id - Qiita
$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の動的モジュールの最新状況（2017年2月版）
StreamモジュールとMailモジュールについては、nginxバイナリに静的にビルドされて組み込まれています。 なお、nginxバイナリと動的モジュールの両方とも、後述するconfigure時のオプション「--with-compat」付きでビルドされています。 nginxバイナリとモジュールのsignatureが異なると動作しない 動的モジュールが実装された当初から「nginxバイナリとモジュールのsignatureが異なると動作しない」という制約があります。 このことについては昨年の記事「nginx-1.9.11で動的モジュールをサポート」において次のように説明しました。 nginxバイナリと異なる環境でビルドされた動的モジュールを組み合わせて動かすことはできません。 これにより困ることの例としては、公式サイトやディストリビューションからnginxのRPMパッケージをインストールした環
Nginx + Rails (Puma) on ECS のいくつかの (本番環境にむけた) 構成例 - Qiita
コンテナの分離レベル, サービスの分離レベルに応じた 3 つの構成例を紹介します. 本投稿は以下を前提とします. ECS Cluster は構築済み VPC / Security Group / Application Load Balancer / RDS の構築ができる 要件 以下の要件は全構成例で達成すべきものとします. フロントエンドは Nginx, バックエンドは Rails5 (Puma) Rails の静的コンテンツ (public/ 配下) は Nginx が処理する また, 可能な限り Nginx-Puma 間は socket 通信を利用するものとします. 1. 単一コンテナ × 単一サービス 単一イメージに Nginx, Rails をまとめた, 最もシンプルなパターンです. 詳細の解説は省略します. 2. 個別コンテナ (Nginx, Rails) × 単一サービス
Nginx balancer_by_luaの話とupstream名前解決の話 - Qiita
balancer_by_lua_xxxxx いつの間にやら1 lua-nginx-module に balancer_by_lua_xxx という新しいディレクティブが増えていました。 以下ドキュメントより抜粋。 http { upstream backend { server 0.0.0.1; # just an invalid address as a place holder balancer_by_lua_block { local balancer = require "ngx.balancer" local host = "127.0.0.2" local port = 8080 local ok, err = balancer.set_current_peer(host, port) if not ok then ngx.log(ngx.ERR, "failed to set
Converting rewrite rules
People who during their shared hosting life used to configure everything using only Apache’s .htaccess files, usually translate the following rules: RewriteCond %{HTTP_HOST} example.org RewriteRule (.*) http://www.example.org$1 to something like this: server { listen 80; server_name www.example.org example.org; if ($http_host = example.org) { rewrite (.*) http://www.example.org$1; } ... } This is
mod_rewriteをnginxに移植するコツはifを使わないコト！
こんにちは。CTOの馬場です。 このエントリはnginxアドベントカレンダーの4日目です。 みんな大好き mod_rewrite をnginxに移植するコツをさらっと紹介します。 結論 まず server とか location を使おうとする try_files など他の方法がないか考える どうしてもどうしてもダメなら map と if を使う 以上！ コツは「とにかく if を使わない」ことです。 手続き的な書き方から宣言的な書き方に頭を切り替えるとうまく馴染めると思います。 例: wwwありでアクセスがきたらwwwなしに転送する server { listen 80; listen 443; server_name www.example.com; return 301 $scheme://example.com$request_uri; } rewrite 要りません。 例: サブ
100行あったmod_rewirteを ngx_mrubyで書き換えた話
第5回ペパボテックカンファレンス〜インフラエンジニア大特集〜 で発表した資料です http://pepabo.connpass.com/event/30348/
Let’s EncryptとNginx : セキュアなWebデプロイメントの現状 | POSTD
最近まで、SSL暗号化通信は「あると好ましい機能」という程度にしか考えられていませんでした。そのため、安全なのはアプリのログインページだけというサービスが数多く存在していました。 しかし、状況は良い方向へと変化しています。現在では暗号化は必須と考えられ、ほとんどの開発者が導入を義務付けています。また、巨大検索エンジンGoogleでは、SSLの導入が検索結果の順位を決定する要因にさえなっています。 しかし、SSLが広範に普及しているにも関わらず、セキュアなWebサービスを構築することは、未だに面倒で、時間がかかり、エラーの原因になりやすいと考えられています。 最近この分野では、 Let’s Encrypt が、SSL証明書をより広く普及させ、Webサイトのセキュリティ維持に係るワークフローを大幅に簡略化しようと取り組んでいます。 強力なWebサーバNginxや、他のハードニング方法と組み合わ
nginx Tech Talks で発表してきた - HsbtDiary(2016-02-08)
発表は書籍の9-10章で解説されている ngx_lua のコードをひたすら ngx_mruby に置き換えたらこんな風になったというのを話してきました。ngx_lua よく出来ていて、これは便利だな〜という発見が結構あったので ngx_mruby に積極的にフィードバックしていった。以下は例。 プロセス間をまたいでデータ共有する時の Cache クラスに渡すキーは String のみ、Symbol 入れると SEGV するというのを見つけて直してもらった ngx_lua にある Hash と Request クラスの args のやりとりを行うメソッド群が便利だったので ngx_mruby にパクった nodoc な handler が結構あるので ngx_mruby の隠し挙動を結構発見した 他の言語を触ると色々発見があって良いですね。アレコレパッチとか投げていたら ngx_mruby
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
nginxのコントロール 日本語訳
nginxについてまとめ(設定編)
TechCrunch | Startup and Technology News
Allowing NGINX to use a Puma/Unicorn UNIX socket with SELinux
NGINX Documentation
