graceful restart できない daemon の再起動時のダウンタイムを HAProxy でリトライして救う - 酒日記 はてな支店
とあるネットワーク(Web)サーバがありまして。 graceful restart できない graceful stop はできる 処理中のものは全て処理し終わってから終了する 再起動は数秒で完了する という性質のものを、稼働中に再起動するとダウンタイムがでてしまうのをなんとか誤魔化したかったのです。 最初は nginx から proxy しているところで、繋がらなかったら何秒かおいて何回までリトライ、みたいな設定ができないか探したんですが見つからず、HAProxy を調べたら以下のような設定でできたのでメモ。 frontend absorber mode tcp default_backend upstream bind *:9999 backend upstream mode tcp server localhost localhost:8888 weight 1 retries 10
Nginxのパフォーマンスを極限にするための考察 - Qiita
ピクセルトラッキングを想定した設定で、Nginx on EC2(c3.large) という環境で、極限まで設定をして、どれぐらいさばけるのか運用中、パフォーマンステストしてる時は、別のところに問題があり、Nginx自体の性能限界までテストできなかったので、実際どこまでいけるのかは計測できてない。 秒間1万とか2万は行けてたと思う、ちなみに実際の運用では秒間9000以上とかを記録していて、サーバ自体にはかなり余裕があるので、記録はまだまだ伸びると思う。 ちなみに empty_gif は応答が短すぎて、Nginx の $request_time では記録できない... 全部 "0.000" だから、どれぐらい掛かってるのか分からん...。 nginx.confの設定 user nginx; worker_processes auto; error_log /var/log/nginx/erro
varnish + nginxでPROXY PROTOCOL - Qiita
webサーバ（バックエンド）をロードバランサ下に複数置いて負荷分散をするのは極めて一般的なことですが、 そのときの問題として、バックエンドからはアクセスがロードバランサーから来たものとして扱われてしまいます。 バックエンド側のアクセス元IPが変わってしまうので、アクセスログに元IPが載らなくなってしまいます。 また、アプリケーション側でIP制限をかけたい場合も、標準的な方法（PHPだと$_SERVER['REMOTE_ADDR']）で取得できるIPアドレスが変わってしまうのも困りものです。 この問題を解決するために、ロードバランサーからバックエンドへ元IPを伝えるためのPROXY protocolというプロトコルがあります。 今回はvarnish（ロードバランサ）とnginx（バックエンド）の組み合わせで、PROXY protocolを有効にして、バックエンド側に元IPを伝えてみます。 構
ps aux | grep serinuntius
表題の通りの事件に遭遇したので、一応記録として残しておきます。 環境 Flutter v1.5.4 Gradle 3.2.1 => 3.4.1 にあげようとした バージョンを上げようとした動機 Gradleのこととかよくわかってないのに、FirebaseでAndroid用の設定をしているときに、こんな画面が出た。 Recommendedか〜、なるほど〜〜〜という軽い気持ちでupdateを押したら、Gradleのタスクがコケるようになり涙目・・・。 解決方法 Android StudioとかをFlutterモードで使ってる場合はAndroidモードに１回しなくちゃ行けないっぽい？ Androidモードに入るにはprojectRoot/android/build.gradleとかを Android Studioで開くと右上に、 Open for Editing in Android Studi
Nginxのupstreamに安易にlocalhostと書くと嵌まる罠、またはドメイン名解決の挙動 - Qiita
Nginxで、アクセスしたらちゃんと返ってきているのにログを見ると connect() failed (111:Connection refused) が頻発に発生している謎を調査したら、 いままで知らなかったNginxの挙動にたどり着いたのでメモ。 （ただしよく見るとドキュメントにちゃんと書いてあったというオチ） 問題 [error] 11#11: *21735 connect() failed (111: Connection refused) while connecting to upstream, client: xx.xx.x.x, server: example.com, request: "GET /hogehoge HTTP/2.0", upstream: "http://[::1]:3000/hogehoge", host: "xx.xx.x.x", referrer:
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
手っ取り早くウェブアプリケーションにOAuth2認証を導入する - その手の平は尻もつかめるさ
bitly/oauth2_proxyを用いて，ウェブアプリケーションに手っ取り早くOAuth2認証を導入するという話です． oauth2_proxyは良い感じでOAuth2による認証を肩代わりしてくれる君で，何らかのリバースプロキシの認証機構と組み合わせて利用すると簡単にOAuth2ログインを実現することができます． 今回は例としてKibanaにGoogleのOAuth2ログインを導入してみたいと思います． 構成 Kibana bitly/oauth2_proxy nginx +------+ +-------+ +--------------+ +--------+ | | | | ----auth----> | | | | | user | --request--> | nginx | | oauth2_proxy | <--auth--> | Google | | | | | <--
oauth2_proxyとNginxのauth_requestを組み合わせると便利 - lamanotrama's diary
oauth2_proxy、便利でググると導入手順も結構出てくるのだけど、今回紹介するのは（環境によっては）さらに便利に使えるナウい方法です。 なにをするのかというとREAMDEに書いてあります。 Configuring for use with the Nginx auth_request directive The Nginx auth_request directive allows Nginx to authenticate requests via the oauth2_proxy's /auth endpoint, which only returns a 202 Accepted response or a 401 Unauthorized response without proxying the request through. For example: サンプル設定もある
Converting Static Modules to Dynamic Modules | NGINX
Analytics cookies are off for visitors from the UK or EEA unless they click Accept or submit a form on nginx.com. They’re on by default for everybody else. Follow the instructions here to deactivate analytics cookies. This deactivation will work even if you later click Accept or submit a form. Check this box so we and our advertising and social media partners can use cookies on nginx.com to better
nginxでもapacheでも使えるDoS的アクセスを検知して任意の制御をするWebサーバ拡張をmrubyで作った - 人間とウェブの未来
github.com 会社の運用メンバーと色々議論していた中で、「カジュアルにWebサーバへのDoSみたいなアクセスが来た時に検知して制御したいよねー」という話が上がったので、http-dos-detectorというnginxでもapacheでも使えるWebサーバ拡張をmrubyで書きました。 もちろんmrubyなので、mod_mrubyとngx_mrubyを使っています。ので、Rubyコードはそのまま同じコードをどちらのミドルウェアでも使えます。mod_mrubyとngx_mrubyを使えば、ちょっとしたWebサーバの拡張は両方で同じ実装に落とし込めるので便利ですね。 使い方 例の如く、GitHubのREADME通りにインストールして下さい。Rubyのコードはmod_mrubyでもngx_mrubyでも有効なので、そのコードを読み込む設定をそれぞれ以下のように記述するだけでよいです。 a
NGINX IMAGE SERVER
2015/02/18 画像変換Night にて ngx_small_light を使った動的画像変換の事例を発表した際の資料です。 http://connpass.com/event/11516/ 画像サーバは Docker イメージを用意しています。 https://github.com/wantedly/nginx-image-server An usecase of image processing server with Nginx and ngx_small_light. Image processing server is available as Docker images under the wantedly organization. https://github.com/wantedly/nginx-image-server
自己証明書を作成してnginxで使う その1 | Tangerina.jp
自己サーバ証明書(オレオレ証明書)を作成し、nginxでHTTPS通信ができるようにします。 サーバ証明書を作成するためには、 秘密キーの生成 秘密キーから証明書署名要求ファイルを作成 証明書署名要求ファイルからサーバ証明書を作成 のステップで行います。 秘密キーの作成 最初に秘密キーを作成しましょう。 シェルでopenssl genrsa -out server.key -aes128 1024と入力してください。 以下のようになります。 $ openssl genrsa -out server.key -aes128 1024 Generating RSA private key, 1024 bit long modulus ..........................++++++ ..............++++++ e is 65537 (0x10001) Enter
Nginxを使ったオレオレCDNの構築
CyberAgentのプライベートクラウド Cycloudの運用及びモニタリングについて #CODT2020 / Administration and M...
Battle ready Nginx - an optimization guide – Blogzor
A guide to optimizing Nginx for maximum performanceMost setup guides for Nginx tell you the basics - apt-get a package, modify a few lines here and there, and you’ve got a web server! And, in most cases, a vanilla nginx install will work just fine for serving your website. However, if you’re REALLY trying to squeeze performance out of nginx, you’ll have to go a few steps further. In this guide, I’
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
