GitHub - denji/nginx-tuning: NGINX tuning for best performance
# you must set worker processes based on your CPU cores, nginx does not benefit from setting more than that worker_processes auto; #some last versions calculate it automatically # number of file descriptors used for nginx # the limit for the maximum FDs on the server is usually set by the OS. # if you don't set FD's then OS settings will be used which is by default 2000 worker_rlimit_nofile 100000
nginxでリクエスト開始時刻をログに出力する - Qiita
nginxがログに出力する時刻はリクエスト処理が終わった時点の時刻のため、障害対応時など、いつ開始したリクエストから問題が出たのかを調査するために開始時刻もログにだしたいことがあります。 nginx単体ではリクエスト開始時刻にアクセスする方法が見つけられなかったのですが lua-nginx-module を使うと以下のようにできました。 set_by_lua_block $start_time { return os.date("%Y-%m-%dT%T%z", ngx.req.start_time()); } ngx.req.start_time() でリクエスト開始時刻のunix timeが取れるので、それを os.date() でフォーマットして変数に設定し、ログでは $start_time 変数を出力する形です。
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への変更に伴うリバースプロキシのテストの改善 - クックパッド開発者ブログ
Nginxへの変更に伴うリバースプロキシのテストの改善 SREグループの菅原です。 クックパッドではブラウザ用Webサイトのリバースプロキシ用のWebサーバとして長らくApacheを使っていたのですが、最近、Nginxへと変更しました。 Nginxへの変更に当たって、構成管理の変更やテストの改善を行ったので、それらについて書きたいと思います。 リバースプロキシのリニューアルについて まず、ブラウザ用Webサイトの基本的なサーバ構成は以下のようになります。 リバースプロキシはELB経由でリクエストを受けて、静的ファイルの配信やキャッシュサーバ・Appサーバへの振り分けを行います。 リバースプロキシとして利用されているApacheは、長年の改修により設定が煩雑なものとなっており、設定の追加や変更にコストがかかる状態になっていました。 また、Apacheの設定ファイルはItamaeでは管理されて
Direct Data Transfer: NginxのX-Accel-Redirectを使って直接データを転送する — LS4 v1.0.0 documentation
目的¶ LS4の用途の一つにWebサービスの画像ストレージシステムがあります。このようなWebサイトでは、アプリケーションサーバの前面にHTTPリバースプロキシを設置しているでしょう。 もしHTTPリバースプロキシとして nginx を使っているなら、nginxの “X-Accel-Redirect” 機能を組み合わせる事で、アプリケーションサーバのCPU負荷とトラフィックを削減することができます。 このドキュメントでは、次のようなWebバックエンドシステムを想定しています： Internet | load balancer / reverse proxy (1) / (5) / App (3) (2) | ----------- GW / | +-------------+ (4)| | | | | | +-|--+ +----+ +----+ | MDS | | DS | | DS |
NGINXからアプリケーションサーバ「NGINX Unit」がオープンソースで登場。PHP、Go、Pythonに対応。Java、Node.jsにも対応予定
NGINXからアプリケーションサーバ「NGINX Unit」がオープンソースで登場。PHP、Go、Pythonに対応。Java、Node.jsにも対応予定 NGINX UnitはNginxの開発者であるIgor Sysoev氏が設計し、NGNIXのソフトウェア開発チームが実装したもので、同社としてはNginxと同等の開発プロセスと品質を実現しているとしています。 現時点でPHP、Go、Pythonに対応。Java、Ruby、Node.jsにも対応予定です。 NGINX Unitの最大の特徴として挙げられているのは、最初から動的制御が可能なように設計されており、アプリケーションの入れ替えやバージョンアップなどを再起動することなくシームレスに行えるところです。 RESTful APIやJSONによるコンフィグレーションの変更やリロードもリアルタイムかつ動的に反映されるとのこと。 また、同一サー
NGINX Microservices Reference Architectureの3モデルを紹介 - Evolutionary Architectures
Nginx, Inc.のMicroservices Reference Architecture(MRA)についてのドキュメントでProxyモデル、Router Meshモデル、Fabricモデルという3つのネットワーキングモデルが解説されている。 GoFのデザインパターン然り、名前が付いている、というのは重要なことだ。本項ではこの3モデルについて紹介する。 1. Proxyモデル Proxyモデルはマイクロサービスアプリケーションのフロント側にリバースプロキシクラスターを配置する。 出典元: MRA Part 2 – Proxy Model Proxyモデルは比較的単純であり、API Gateway、初期のマイクロサービス、もしくは、複雑なレガシーモノリシックアプリケーションを変換する際のターゲットとして適している。特に大規模なマイクロサービスやトラフィックについての負荷分散に適している
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のupstreamコンテキストで有償のresolveオプションを使わずに動的にDNS解決する - Qiita
TL;DR nginxからリバプロ先のバックエンドがELBの場合は、IPアドレスがキャッシュされないようにDNS名を動的に解決しないといけない。 serverコンテキストならset変数使うハックで回避可能だけど、この技はupstreamコンテキストで使えない。 nginxのupstreamコンテキストでresolveオプション使おうと思ったら有償版の商用機能だった罠。 upstreamコンテキストで必要な負荷分散しつつ、Unixドメインソケットを1段挟んで、serverコンテキストでset変数するハックと組み合わせると動的にDNS解決できた。 経緯 nginxをリバースプロキシとして使っていて、バックエンドにELBみたいな構成の場合、DNS名を起動時に名前解決してIPアドレスをキャッシュしてしまうので、IPアドレスが変わると繋がらなくなるというのはよくあるハマりポイントみたいです。 で、調
Nginxのリバースプロキシでバックエンドとhttp2通信する - ASnoKaze blog
以前書いたとおり、ApacheではリバースプロキシでバックエンドとHTTP2通信することができます。 asnokaze.hatenablog.com Nginxの場合は、開発者のメーリングリストでGoogleの人が書いてる「ngx_http_v2_upstream」パッチを利用することでバックエンド(upstream)とHTTP2通信することが出来るようになります。 パッチ [PATCH 01 of 14] Output chain: propagate last_buf flag to c->send_chain() [PATCH 02 of 14] Upstream keepalive: preserve c->data [PATCH 03 of 14] HTTP/2: add debug logging of control frames [PATCH 04 of 14] HTTP/
nginx の 308 Permanent Redirect サポート
今日(2017/04/20)時点ではまだリリースされていないが、nginx: be5cfa918bfcで、HTTP ステータスコード 308 Permanent Redirect1 がサポートされた。おそらく nginx 1.13.0 で利用可能になるだろう。 308 については、GIGAZINE の記事『新たなHTTPステータスコード「308」とは？』が分かりやすかった。301 Moved Permanently はリダイレクト時にリクエストメソッドをGETに変えてしまう可能性があり、例えばPOSTメソッドのリクエストボディが失われる懸念があった。それに対し、308 Permanent Redirect はリクエストメソッドの不変を保証する。 幅広い用途があるとは思えないが、以下のkazuhoさんのブコメにあるように、エンドポイントの変更などに対しては有用だろう。 新たなHTTPステータ
ngx_mrubyで最初のHTTPSアクセス時に自動で証明書を設定可能にするFastCertificateの提案とPoC - 人間とウェブの未来
Let’s EncryptやACMEプロトコルによるDV証明書取得の自動化に伴い、証明書の取得と設定が簡単になってきました。 一方で、ACMEをツール化したものが増えるに従って、ACMEってそもそもどういう動きになっているのか、とか、自分たちの用途でどういう使い方がありえるのかとかが余計にわかりにくくなってきており、どこまで自動化できるかもよくわからない場合が多いのではないでしょうか。 そこで、 ドメインとAレコードの紐付けさえしていれば、最初のアクセス時に自動で証明書をとってきて、HTTPS通信にできないか というような、いわゆる FastCertificate 的な動きを実現したいと考え、ACMEの通信の中で各種処理を別のスクリプトでhookできるdehydratedとngx_mrubyを応用して実現可否も含めてPoCを実装してみました。 ※ FastContainerという考え方につ
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 Dynamic Modules: How They Work – NGINX Community Blog
Introduction Maxim Dounin: My name is Maxim Dounin, and I am an NGINX developer. Today, I would like to talk about dynamic modules, which we introduced last winter. 0:17 The Basics First, let’s review some basics about modules in general, and dynamic modules in particular. As you probably know, modules in NGINX have existed since its inception. In fact, NGINX is actually a collection of modules. E
nginx はデフォルトで merge slash する - kurainの壺
久しぶり技術ネタを一つ。 問題 nginx を reverse proxy として使っていると original http://example.com/hoge/huga//path proxied http://example.com/hoge/huga/path みたいな感じに重なったslash を merge してから proxy される。path最後の '//path' が '/path' となって、状況によってはありがたい。これが default なのが良いかは分からないが。slash は 2 以上連続していると、1つになる。 さらに、 original http://example.com/entry/http%3A%2F%2Fwww.hatena.com%2F proxied http://example.com/entry/http%3A%2Fwww.hatena.com%
How to use a hyphen in cookie names for nginx?
I want to use the new cookie-prefixes, which are not yet standardized by the IETF. These are __Secure- and __Host-. So let's e.g. set this cookie (here the header returned by the server): Set-Cookie: "__Host-apple=yummy; Secure; HttpOnly; Path=/" I want to access this cookie now in nginx with the $cookie- variable. So for testing I use the echo module to show me the value of the cookie: location =
nginx で omniauth を利用してアクセス制御を行う - クックパッド開発者ブログ
インフラストラクチャー部 id:sora_h です。クックパッドでは、社内向けの Web アプリ (以降 “社内ツール”) を社外のネットワークから利用する際、アプリケーションレベルでのアクセス制御とは別に、リバースプロキシでもアクセス制御を実施しています。*1 これまで BASIC 認証あるいは VPN による社内ネットワークを経由した接続という形で許可していました。しかし、iOS の Safari などでは BASIC 認証時のパスワードを保存できない上、頻繁に入力を求められてしまいますし、VPN はリンクを開く前に接続をしておく必要があります。これにより、社内ツールを社外で開く時に手間がかかってしまう問題がありました。 これに対し、一部では typester/gate などを導入し Google Apps での認証を行なっていました。しかしいくつか問題があり、非アドホックな対応では
nginxによるTCPロードバランサー | メルカリエンジニアリング
SREチームの@cubicdaiyaです。今回はnginxによるTCPレイヤーでのロードバランスについて解説します。 ロードバランサーとしてのnginx nginxはHTTPやTCP、UDP等の複数のレイヤーでロードバランサーとして稼働させることができます。（TCPロードバランサーは1.9.0以降、UDPロードバランサーは1.9.13以降で利用可能です） また、ngx_http_ssl_module や ngx_stream_ssl_module を利用することでそれぞれのレイヤーでTLSを有効化することも可能です。 TCPロードバランサー用のモジュールを有効にする HTTPレイヤーでロードバランスするためのモジュールはデフォルトで組み込まれますが、TCP(とUDP)レイヤーでロードバランスするにはnginxのconfigureスクリプトに--with-stream(あるいは --with
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - yandex/gixy: Nginx configuration static analyzer
『CDN切り替え作業における、Web版メルカリの個人情報流出の原因につきまして - Mercari Engineering Blog』へのコメント
