動的証明書読み込み ngx_mruby編 #hoscon / GMO HosCon 2016
"HosCon - GMO Hosting Conference - @渋谷" http://gmohoscon.connpass.com/event/41490/ の発表スライドです。10分 LT なのにだいぶ詰め込んでます。 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 【資料に登場したURLs】 SSL_CTX_set_cert_cb() の説明: https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_set_cert_cb.html ngx_mruby で動的証明書読み込みをサポートした旨のツイート: https://twitter.com/matsum
nginxのステータスコード444 · yuuki/yuuki
nginxのステータスコード444 nginx独自のステータスコード444は、レスポンスヘッダを返さずにコネクションを切断できる。レスポンスヘッダを返さないので、ステータスコード444をクライアントが受け取ることはない。 http://nginx.org/en/docs/http/ngx_http_rewrite_module.html#return The non-standard code 444 closes a connection without sending a response header. DoS攻撃など、特定条件のアクセスをBANするときに、なるべく計算機リソース消費を抑えたいときに使えるはず。 403を返すときなどと比べて、レスポンス送信のためのCPUコストを節約 403を返すときなどと比べて、レスポンスヘッダ分のネットワーク帯域を節約 HTTP Keepalive
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
ts_mruby + mruby-mrmagick で画像リサイズするリバースプロキシをサクッと実装してみた - ブログ・ア・ラ・クレーム
今日は夏コミのようですね！僕は今年は特に原稿を描いておらず用事も無いためコミケに縁のない夏を過ごしてしまいました。 ところで最近拙作の ATS(Apache Traffic Server) プラグインである ts_mruby にレスポンスボディをいじくるメソッドを追加し、ふと思い立って画像リサイズのロジックを mruby で書いてみました。 そのレスポンスボディ加工メソッドは ATS::Filter#transform! になります。 このメソッドではブロックまたは Proc オブジェクトを渡すとブロックパラメータに加工前のレスポンスボディが渡され、評価値でレスポンスボディを差し替えます。 f = ATS::Filter.new f.transform! do |body| # append text to the end of response body body + "rewritte
mruby + ngx_mrubyでアプリケーションを実装するという選択肢 - LIFULL Creators Blog
はじめまして、技術基盤部の相原(kaihar4)です！ 今回は、アプリケーションのクラウドサービスへの移行の一環で、 Amazon S3から取得した画像URLを含むファイルを元に、そのURLの外部画像を取得して返す機能 をmrubyで書き直してAWSに移行した話をしていきたいと思います。 この機能は元々モノリシックなアプリケーションの一機能として動いていたもので、これを切り出してAWSに移行するというのが今回私に与えられたミッションでした。 このアプリケーションは歴史が長く、その間ほとんどメンテナンスされていませんでした。 ディストリビューションは古くPHPのバージョンも4系、したがってそのまま持っていくという選択肢はなく、AWS上に新規にインスタンスを構築することになります。 弊社にはAPI部分をPHPからRubyに移行する方針があるということもあり、Amazon Linux上にRuby
nginxのリクエストを制限することができるngx_http_limit_req_moduleでハマった - Usual Software Engineer
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
Docker と infrataster で nginx の振る舞いをテストする
こんにちは。吉川 ( @rrreeeyyy ) です。今期オススメのアニメはリゼロです。 Nginx は設定ファイルの記述力も高い、大変便利な Web サーバです。 便利な反面、設定ファイルの複雑化や、設定に依っては意図しない挙動を引き起こしてしまうこともあります。 そこで本稿では docker 並びに infrataster を使用し、 Nginx の挙動をテストすることによって、安全に Nginx の設定を記述する方法について紹介します。 テスト対象の Nginx の仕様 今回は例として、次のような仕様の Nginx のテストについて考えます。 ネットワーク帯は 10.0.0.0/16 を使用している Nginx の前段として L7 ロードバランサが存在している L7 ロードバランサが https を終端している Nginx 自体は 80 番ポートと 8080 番ポートにて待ち受けてい
３つのnginxをうまく使い分けよう〜nginx、OpenResty、Tengine〜
OpenRestyはnginxのほかにngx_luaをはじめとするCで書かれた各種サードパーティモジュールとngx_luaのAPIを利用したrestyモジュール、そしてLua/LuaJITで構成されています。 OpenRestyに含まれているnginx自体は本家のnginxと基本同じなので、別にOpenRestyを利用しなくても自分でngx_luaを組み込んだり、サーバ上にrestyモジュールを配布することで似たような環境を構築することは可能ですが、OpenRestyであれば主要なモジュールやライブラリが./configure、make、make installの一連の流れですべてゴソッとインストールされますし、OpenRestyのconfigureスクリプトはnginxのconfigureスクリプトを継承したものなのでnginxのconfigureオプションをほぼそのまま利用することもで
cybozu.com のリバースプロキシを nginx にリプレイス - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。インフラチーム Hazama の深谷です。 デブサミ 2015 で、cybozu.com の自社製リバースプロキシを全面的に再実装した話をしてきました。 今回は、そちらの資料を紹介いたします。 cybozu.com ではお客様ごとに異なるサブドメイン（ex. demo.cybozu.com）を用意しています。サブドメイン方式には、お客様ごとに異なる IP アドレス制限をかけられるとか、Same-Origin-Policy のため安全に JavaScript でカスタマイズができるといった利点があります。 このサブドメインを実現しているのは、従来 Apache で実装されたリバースプロキシでした。しかし、この時の実装はサブドメインごとに異なる VirtualHost を定義する方式で、お客様サブドメインの数に比例して Apache の設定を変更する時間が伸びていくというものでした
秒間50kリクエストを捌くノウハウがこの1冊に！nginx実践入門 - pixiv inside [archive]
こんにちは、@harukasanです。ピクシブでは3年以上にわたってHTTPサーバにnginxを採用しています。これらのノウハウが詰まった「nginx実践入門」が1/16(土)、技術評論社から発売されることになりました。 この記事では本書からピクシブで良く使われているnginxのテクニックについてかいつまんで紹介します。 すべてのリクエストを受け止めるnginx ピクシブのたくさんあるサービス（pixiv、pixiv Spotlight、pixivコミック、ピクシブ百科事典……）のどこかにHTTPリクエストを投げると、複数台あるフロントサーバのどれかに届きます。実際にアプリケーションを処理するのはフロントサーバの裏側にいるアプリケーションサーバです。これらのサーバにはPHPだったり、Ruby on RailsだったりPlay/Scalaだったりいろんなアプリケーションがデプロイされています
![秒間50kリクエストを捌くノウハウがこの1冊に！nginx実践入門 - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/e3cbfd0838fff5d53ac2fa7e2c6499b71dfee893/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fh%2Fharukasan%2F20160115%2F20160115160510.jpg)
Unicornの2倍のパフォーマンスを実現したRackサーバ「Rhebok」をリリースしました - blog.nomadscafe.jp
“Hello World”なベンチマークでUnicornに比べ2倍高速に動作するRackサーバをリリースしました。 rubygems: http://rubygems.org/gems/rhebok github: https://github.com/kazeburo/rhebok PerlのGazelleをベースに作っています。Rackアプリケーションの運用経験がほぼないので、機能不足があると思います。issue等で教えて頂ければ幸いです。 なぜ高速に動作するアプリケーションサーバが必要なのか Unicornは高速に動作します。多くのアプリケーションにとっては十分でしょう。それでもRhebokでさらに上のパフォーマンスを出そうとしたのは、技術的なチャレンジの他に以下のようなアプリケーションで高速なアプリケーションサーバが必要とされると考えているからです。 ソーシャルゲーム、広告サーバ、
nginx で omniauth を利用してアクセス制御を行う - クックパッド開発者ブログ
インフラストラクチャー部 id:sora_h です。クックパッドでは、社内向けの Web アプリ (以降 “社内ツール”) を社外のネットワークから利用する際、アプリケーションレベルでのアクセス制御とは別に、リバースプロキシでもアクセス制御を実施しています。*1 これまで BASIC 認証あるいは VPN による社内ネットワークを経由した接続という形で許可していました。しかし、iOS の Safari などでは BASIC 認証時のパスワードを保存できない上、頻繁に入力を求められてしまいますし、VPN はリンクを開く前に接続をしておく必要があります。これにより、社内ツールを社外で開く時に手間がかかってしまう問題がありました。 これに対し、一部では typester/gate などを導入し Google Apps での認証を行なっていました。しかしいくつか問題があり、非アドホックな対応では
Nginxと名前解決の話 - Masteries
Nginxでは, serverコンテキストのlocationコンテキストにおいて, proxy_passディレクティブを利用することで任意のホストにアクセスを転送することができます. 例えば, serverコンテキストにおいて, location / { proxy_pass http://127.0.0.1:5000; } みたいに書いてあげれば, localhostの5000番ポートにアクセスを転送することが出来ます. Webサービスでは, こういう感じでNginxが443番(HTTPS)や80番ポート(HTTP)で受けたアクセスを5000番ポートなどで動いているWebアプリケーションに転送している訳です. で, このproxy_passディレクティブは, IPをそのまま書くのではなく, 次のようにドメインを書くこともできます. location / { proxy_pass http
[Nginx] www 付きの URL を www 無しにリダイレクトさせる設定方法 | CodeNote
カテゴリー アクセス解析 (2) Analysis (1) Android (7) Apache (6) API (2) Amazon Web Services (66) CloudSearch (1) EC2 (3) RDS (1) SES (1) Backbone.js (1) BigQuery (1) Blockchain (3) Blogger (1) Book (113) Bootstrap (4) Configuration Management (3) Cacti (1) Capistrano (2) CentOS (15) Chef (1) Chrome (9) ClamAV (1) CMS (2) CODA (1) CoffeeScript (1) CORESERVER (4) 仮想通貨 (1) CSS (22) Sass (6) CSV (1) DNS (1) 資料 (
![[Nginx] www 付きの URL を www 無しにリダイレクトさせる設定方法 | CodeNote](https://cdn-ak-scissors.b.st-hatena.com/image/square/2270508fec68a441c454e2085629dc62e7f46d11/height=288;version=1;width=512/http%3A%2F%2Fcodenote.net%2Fwp-content%2Fuploads%2FNginx.png)
google_auth_proxy + nginx で作る簡易認証システム - Qiita
お詫び nginx advent calendar ですが、nginxの濃い話ではないです。nginxと組み合わせて作成する簡易認証システムについて書きます。 はじめに 管理画面の認証、皆さんどうされていますか？ 一番ナイーブな方法だとBasic認証を使う、ということになると思いますが、ID/PWの管理が面倒なことや、漏洩した時のリスクを考えるとさすがに企業内ではBasic認証のみでの認証は採用がしづらいです。とはいえ、きちんとした管理システムを作成するのも、これはこれで手間です。多くのリソースを管理業務に割く事が難しい小さい組織であれば尚更、難題です。 多くの人がGoogleのアカウントを所持し、Google Appsを採用している企業も多い今、こういう認証部分はできることならGoogleさんに任せてしまいたいな、と思うところです。 とはいえ、googleのoauthを使用した認証システ
nginxのパラメータチューニングとh2o - Qiita
(追記:タイトルが少々煽り気味な気がしたので微妙に変更しました。) h2oとnginxの性能比較 nginxよりも速いとされるh2oですが、実際に自分でもローカルでベンチマークを取ってみました。環境は以下の通りです。 EC2のc4.8xlargeインスタンス gcc (GCC) 4.8.2 20140120 (Red Hat 4.8.2-16) Linux ip-172-31-13-40 3.14.35-28.38.amzn1.x86_64 #1 SMP Wed Mar 11 22:50:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux nginx-1.8.0 h2o-1.2.1-alpha1 wrk(ベンチマーク) ベンチマークコマンド 実行するベンチマークコマンドは以下になります。なお、オプションはできるだけRequest/secが大きくなるように調
NginxでHTTPS：ゼロから始めてSSLの評価をA+にするまで Part 2 – 設定、Ciphersuite、パフォーマンス | POSTD
NginxでHTTPS：ゼロから始めてSSLの評価をA+にするまで Part 2 – 設定、Ciphersuite、パフォーマンス 今日のインターネットの世界では、一般的な静的Webサイトも含め、 全てのWebサイト に、強固で安全なHTTPSのセットアップが必要となります。この記事は、Nginxセキュリティをどのようにセットアップするのかに関するシリーズのパート2です。 パート1 は、Webサーバに有効な署名証明書をセットアップする話で終了しました。しかしこれには、最適な設定とは言い難い、デフォルトのNginxの設定を使用していました。 この記事を読み終えれば、SSL Labsのレポートで、A+の評価を獲得できる安全なHTTPSの設定ができます。それだけでなく、追加でいくつかの微調整も行い、パフォーマンスそしてUXも向上させていきます。 ここに掲載した記述やコードの抜粋の他にも、すぐに使
nginxのリクエストボディのバッファリングに関する問題とその改善策 - Qiita
nginxのデフォルトの動作ではクライアントから受け取ったリクエストボディをメモリにバッファリングするようになっています。 このメモリバッファのサイズはclient_body_buffer_sizeで変更することができ、リクエストボディのサイズがこのバッファのサイズを越えた場合はclient_body_temp_pathにファイルとして書き出されます。 ログレベルがwarn以上の場合はエラーログにa client request body is buffered ...という警告が出ます。 2015/03/29 14:02:20 [warn] 6965#0: *1 a client request body is buffered to a temporary file /etc/nginx/client_body_temp/0000000001, client: x.x.x.x, ser
Nginx導入時やること - Qiita
HTTPレスポンスヘッダにサーバのバージョンの表示を消す なぜ必要？ 潜在攻撃者への情報提供になることも。 もし使用中バージョンの脆弱性が明らかになった時、恰好の標的になるとか。 対応 nginx.confのhttpディレクティブに server_tokens off; を追加。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
nginxによる実践的Webシステム / Practical nginx web system
