GitHub - nginxinc/nginmesh: Istio compatible service mesh using NGINXYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
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
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 でトップページのみリダイレクト
nginx でサーブしているサイトのトップページのみリダイレクトしたいという場合、以下のようでいけるかなと思った。 location / { rewrite / https://example.com/foo permanent; } しかしこれはまったく動かなかった。 あれ、なんだっけ、こうかな？と頭をひねって以下のように書き換えてみた。 location / { rewrite ^$ https://example.com/foo permanent; } しかしこれもまったく動かなかった。 やべ、あわせてこうかな？というのも試してみた。 location / { rewrite ^/$ https://example.com/foo permanent; } とにかく、動かない orz で、実は location ディレクティブ で = が使えたので、以下のように書けば良いだけだった
Let's Encrypt で手軽に HTTPS サーバを設定する - Qiita
[追記] この記事にはかなり古い情報が掲載されています。 Certbot を使うことで更に手軽に設定することが出来ますので、お試しください。 https://certbot.eff.org/ 良い時代になりましたね。 ※コメントでのご指摘ありがとうございました。 昨日、 Let's Encrypt が Public Beta になり、申請不要で誰でも利用できるようになりました。 Entering Public Beta Let's Encrypt とは Let’s Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit. Let’s Encrypt is a service provided by the Internet Security Researc
NginxHttpCoreModule
Enables or disables the use of asynchronous file I/O (AIO) on FreeBSD and Linux: location /video/ { aio on; output_buffers 1 64k; } On FreeBSD, AIO can be used starting from FreeBSD 4.3. Prior to FreeBSD 11.0, AIO can either be linked statically into a kernel: options VFS_AIO or loaded dynamically as a kernel loadable module: kldload aio On Linux, AIO can be used starting from kernel version 2.6.2
Inside NGINX: How We Designed for Performance & Scale
NGINX leads the pack in web performance, and it’s all due to the way the software is designed. Whereas many web servers and application servers use a simple threaded or process‑based architecture, NGINX stands out with a sophisticated event‑driven architecture that enables it to scale to hundreds of thousands of concurrent connections on modern hardware. The Inside NGINX infographic drills down fr
nginx の拡張モジュールを書いて DoS 対策をした - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。インフラチームの野島です。 最近、cybozu.com はロードバランサを Apache から nginx に置き換えました。 (参考: cybozu.com のリバースプロキシを nginx にリプレイス) 置き換えの一環として、Apache に実装していた DoS 対策の仕組みを nginx の拡張モジュールにする形で移植しました。今回、この拡張モジュール nginx-maxconn-module を OSS として公開しましたので紹介します。 背景 DoS 対策 秒間リクエスト数 v.s. 瞬間同時リクエスト数 実装方針 nginx-maxconn-module 基本的な使い方 高度な使い方 インストール おわりに 背景 本題に入る前に、cybozu.com において、HTTP リクエストがどのように処理されているかを説明します。 cybozu.com では、負荷分散のた
日本Nginxユーザ会が発足。開発者Igor Sysoev氏が語る、Nginxが生まれ、商用化された理由
軽量で高速なオープンソースのWebサーバとして知られるNginx（エンジンエックス）のユーザー会「日本Nginxユーザ会」が18日発足し、都内で最初のユーザ会が行われました。 ユーザ会をバックアップしたのは、Nginxの商用版である「Nginx Plus」の国内販売パートナーとなったサイオステクノロジーと、コミュニティ活動の経験が豊富なハートビーツ。 来日中の、Nginx.incのCEO、Gus Robertson氏、CTOでNginxの開発者でもあるIgor Sysoev氏、ビジネス開発担当のAndrew Alexeev氏の3人がユーザー会に登壇し、日本でのコミュニティ活動に期待する発言が相次ぎました。 HTTPの世界は爆発的に成長している Nginx,Inc. CEO Gus Robertson氏。 Nginxは世界中で1億4000万ものサイトで使われています。もともとはIgorが一人
Nginxでproxy_passにホスト名を書いた時の名前解決のタイミング - （ひ）メモ
Nginx 1.4.2で試しました。 ネームサーバーは、ローカルのunboundをlocal-zone, local-dataを使って簡易コンテンツサーバーにして試しました。 local-zone: "oreno." static local-data: "api.oreno. 30 IN A 192.0.2.11" # local-data: "api.oreno. 30 IN A 192.0.2.12" proxy_passにホスト名を書くと→名前解決は一度だけ このように Nginx の設定を書いた場合、 location /api { proxy_pass http://api.oreno:9999; } 「api.oreno」の名前解決は、nginxの起動時に行われます 名前解決できない場合は、nginxは起動しません 名前解決できた場合は、ずっとそのIPアドレスにreverse
G-WANはなぜ速いのか？をnginxと比べながら検証してみた - blog.nomadscafe.jp
ツチノコブログのWEBサーバベンチマークツール比較の記事で紹介されていた。WebサーバのG-WAN。この記事によると凄く速いようです。 Intel Xeon E5-2640 (6コア/12スレッド 2.50GHz) を2つというサーバで gwan 334944 req/s nginx 111842 req/s と、速いと言われているnginxの3倍の速度を出しています。 このベンチマーク結果がとても気になったので、なぜG-WANが速いのか、自分でも検証してみました。 結論から言うと以下の2つ。 1) G-WANはデフォルトで物理CPUに合わせた数のスレッドを起動する 2) HTMLファイルも一度読み込んでキャッシュする という事です。 今回はAWSのcc2.8xlarge(E5-2670 8コア/16スレッド 2.60GHz *2)を使ってベンチマークを行いました。OSはAmazon L
lua-nginx-module の紹介 ならびに Nginx+Lua+Redisによる動的なリバースプロキシの実装案 - hibomaの日記
Nginxは非常に強力なhttpdですが、独自のモジュールを実装しようとするとこれまた非常に敷居が高い印象です。 追記 この記事よりも前に http://openresty.org/#DynamicRoutingBasedOnRedis でほとんど同じ内容のエントリが書かれていました。こちらも参照ください モジュールの開発はむずかしい まず開発用のドキュメントはほとんどありません。必然 既存のモジュールをお手本としますが、コメントも少ないのでソースだけが頼りです。 {ファイル,ネットワーク} I/O を伴う処理では、Nginxのノンブロッキング/イベントドリブンのアーキテクチャにのっとってコールバックを駆使したCで実装する必要があり、LLで育ったゆとり脳では太刀打ちできませんでした lua-nginx-module が代わりになるかも なんらかのNginxモジュールを開発しなければならない
How to defend SSL/TLS servers against BEAST, CRIME and BREACH attack for Nginx - （ひ）メモ
The information presented herein is without any guarantees and I’ll take no responsibility if any harm happens to you or your users. If you find any factual problems, please reach out to me([twitter:@hirose31]) immediately and I will fix it ASAP. http { server { listen 80; listen 443 ssl; server_name example.com; # BEAST: dont's use CBC ssl_protocols SSLv3 TLSv1; ssl_ciphers ECDHE-RSA-AES256-GCM-S
Module ngx_http_map_module
Creates a new variable whose value depends on values of one or more of the source variables specified in the first parameter. Before version 0.9.0 only a single variable could be specified in the first parameter. Since variables are evaluated only when they are used, the mere declaration even of a large number of “map” variables does not add any extra costs to request processing. Parameters inside
http://nginx.org/patches/spdy/README.txt
We are pleased to announce the first beta version of SPDY draft 2 module for nginx. This work has been sponsored by Automattic (http://automattic.com/). For more information about SPDY protocol specification please check http://www.chromium.org/spdy/spdy-protocol We will be working on improving SPDY support during the next few months with the goal of eventually integrating it fully into the main n
Syn の独り言 : mod_proxy_balancer と nginx の Load Balancer 機能の夜明けはちかいぜよ - livedoor Blog（ブログ）
June 21, 201223:29 カテゴリOS / Middlewareネットワーク mod_proxy_balancer と nginx の Load Balancer 機能の夜明けはちかいぜよ 以前、Apache の mod_proxy_balancer と nginx のLoad Balancer の機能比較を行ってから 2年がたってしまった。 その間、両者とも Load Balancer としての機能が追加されてしまったので再比較。 ってか、比較するまでもなく機能面だけでみると両方とも私が必要としている２個の機能を 実装してしまった。 まず、least connections アルゴリズムによる負荷分散。 これは現時点の接続数が最も少ないワーカー（通常は web サーバー） に処理を割り振るというもの。 代表的な負荷分散アルゴリズムの `round-robbin' と比較して、
FRiCKLE Labs / nginx / ngx_cache_purge
nginx / ngx_cache_purge (project fully funded by yo.se) Module adding ability to purge content from nginx's FastCGI, proxy, SCGI and uWSGI caches. View: README file, CHANGES file. Download: ngx_cache_purge-2.3 (SHA1: 69ed46a23435e8dfd5579422c0c3996cf9a44291) GitHub repository: http://github.com/FRiCKLE/ngx_cache_purge/ Example configuration: proxy_cache_path /tmp/cache keys_zone=tmpcache:10m; loca
nginxで 特定ページだけhttpsに振り分ける方法 | 変なヤバいもんログ
Posted on 2010年7月17日 Posted by ちゅう コメントする Posted in Development Tags: Linux, nginx ログインページや管理画面など、セキュアにしたいページにだけSSLをかける。というのを nginx でやる方法。 たとえば、/admin 以下、 /login 以下をSSLにして、それ意外のページは非SSLにしたい場合です。細かい設定は端折って、upstream appserver でバックエンドのサーバが設定されてるときです。 # HTTP setting server { listen 80; server_name localhost; location ~ ^/(admin|login) { rewrite ^(.*) https://$http_host$1; break; } location / { proxy_p
nginx連載5回目: nginxの設定、その3 - locationディレクティブ
locationディレクティブはパスの条件が評価されて選ばれたものが適応されます。この条件はパスの文字列の前方一致あるいは正規表現による評価です。この評価の順番は以下のようになります。 前方一致（"=", "^~", プレフィックスなし）の条件の評価を実施 最も一致する条件を選ぶ。 選ばれた条件が、完全一致で、プレフィックスが"="であれば、そこで評価を終了し、そのlocationディレクティブを適応する。 選ばれた条件のプレフィックスが"^~"であれば、そこで評価を終了して、そのlocationディレクティブを適応する。 正規表現（"~", "~*"）の条件の評価を実施 正規表現の条件を設定ファイルに定義した順番に評価する。一致したら、そこで評価を終了して、そのlocationディレクティブを適応する。 前方一致の評価で選ばれた条件のlocationディレクティブを適応する。 ここで注意
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Nginx で構築したリバースプロキシを ngx_mruby で細かい制御をする試み（1） - Qiita