You 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. Dismiss alert
こんにちは。最近、ピストのチェーンを 和泉チエン TOUGH GUARD に替えて、ご機嫌な原口です。 ホスティング事業部の MRE(Messaging Reliability Engineering *ペパボの造語です)というチームで、 SRE ような取り組みを、DNS やメールなどのメッセージングサービスに対して実施しています。 今回は、弊社のホスティングサービスで提供しているメールシステムについてご紹介いたします。 メールシステム構成 弊社のホスティングサービスで提供しているメールシステムは、運用効率化やメールサーバー リプレイス時のダウンタイム削減のため、リバースプロキシを導入しています。 このリバースプロキシについては、過去、dovecot や Courier-IMAP などを利用していましたが、 現在は Nginx に変更しています。メールシステムで Nginx を利用している
Nginx configs. Not the most powerful, productive or the best one. Just useful configs, which I would like to see in default nginx packages out of the box 😆 Bonus: fail2ban, filebeat, dockerfile and docker-compose configs for nginx :) Motivation: I have been using nginx since 2015, and I configured it really for hundreds setups of 30+ companies and startups: sites, apps, websockets, proxies, load
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
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
CTO室SREの @kenzo0107 です。 2021年6月24日に「 kakari for Clinic ホームページ制作 」がリリースされました。 kakari for Clinic ホームページ制作 今回は上記サービスで採用した、 AWS + ngx_mruby で構築した SSL 証明書の動的読み込みシステムについてです。 SSL 証明書を動的に読み込みする理由 kakari for Clinic ホームページ制作の1機能で、制作したホームページに独自ドメインを設定する機能がある為です。*1 複数ドメインでアクセスできる =複数ドメインの SSL 証明書を読み込む を実現する必要があります。 動的に SSL 証明書を読み込むには? 以下いずれかのモジュールを組み込むことで SSL 証明書の動的読み込みが可能になります。 ngx_mruby lua-nginx-module 以下理
For this configuration you can use web server you like, I decided, because I work mostly with it to use nginx. Generally, properly configured nginx can handle up to 400K to 500K requests per second (clustered). Most what I saw is 50K to 80K (non-clustered) requests per second and 30% CPU load, of course, this was 2 x Intel Xeon with HyperThreading enabled, but it can work without problem on slower
nginx でリクエストを複製できるモジュール「ngx_http_mirror_module」を使うと,簡易的な「Shadow Proxy」を構築することができる.例えば,本番環境のリクエストの一部を開発環境に流せるようになる.この「ngx_http_mirror_module」は nginx 1.13.4 で実装された機能で,2017年8月リリースなので,最近のバージョンだとデフォルトで使えるようになっている.今回は「リクエストの複製」を試すため,Docker Compose を使って検証環境を構築した. nginx.org 検証環境 今回 Docker Compose を使って,nginx と Sinatra を起動する検証環境を構築した.コンテナは計3種類で,以下の構成図にまとめた.基本は Frontend と Backend でリクエストを処理し,今回は Mirror にもリクエス
2018-07-31 はじめに nginxとshibbolethでSAML2のシングルサインオンを試してみた では Service Provider – Shibboleth Consortium を使いましたが、汎用的な分、設定方法のドキュメント NativeSPConfiguration - Shibboleth 2 - Shibboleth Wiki を見ても圧倒される感がありました (なお、ページ上部の囲みを見ると Shibboleth SP は先日 3.x がリリースされて 2.x はEOLになったそうです)。 そこで、 nginx lua で SAML の Service Provider (以下 SP と略)を書いてみたところ、動くものが出来たので公開して説明を書いておきます。 hnakamur/nginx-lua-saml-service-provider ただし、この S
※静的・動的の数値は 1 リクエストあたりの平均値。 いずれも、トータルの所要時間は 60 秒(5 ドメイン並行時)強・90秒(9 ドメイン並行時)強でした。 リクエスト毎の記録は掲示しませんが、特に時間が順に延びていくこともなく、この程度の負荷では動的処理のオーバーヘッドはごくわずかであることが分かりました。 参考/テスト環境の構築について 今回は、以下の流れで環境を用意しました。 リバースプロキシ/Web サーバ側 EC2 インスタンスを用意 EC2 に割り当てる IAM Role を作成(AmazonRoute53FullAccessポリシー付き) CentOS 7 の AMI から EC2 インスタンスを作成(↑を割り当て) 要 awscli・httpd・openssl aws configureでデフォルトリージョンを指定(awsコマンドを使うユーザで) /etc/httpd/c
OpenRestyで動的生成されたコンフィグファイルをLuaで読み込んで云々、という処理を行っているのですが、 その際Nginx側で表題の「pread() read only xxxx of xxxx from xxxx」といったエラーが表示される事案がありました。 状況まとめ 特定の環境のみ表示 突然エラーが出始めた 同じロジックで、過去にエラー表示されたことはない しばらく(1分くらい)するとエラーでなくなる ググる 以下の2つのリンクが引っかかりました。 https://www.scalescale.com/tips/nginx/nginx-pread-read-only-of-from-errors/ forum.nginx.org 引用ですが Investigating my Nginx configuration I found this may be related to t
Google Chrome 68 による非 HTTPS サイトの Not secure(保護されていません)警告待ったなし!の今頃になってこの記事を出すのもどうかとは思うのですが、 nginx+ngx_lua を使って(実際には OpenResty を導入するのがお手軽) 静的な設定ではなく、動的に SSL/TLS 証明書を読み込む形の SSL/TLS ラッパー兼リバースプロキシを手軽に立ててみる ということを(今更ながら)やってみます。 なお、想定している環境・状況等は、 ドメイン名(FQDN)はそこそこたくさんある(数百~)が、万単位までは行かない アクセス数(PV)はそれほど多くない(リバースプロキシをたくさん立てないといけない状況ではない) Let's Encrypt などを使って証明書を自動更新している/したい 但し、証明書の発行はある程度人手でコントロールしたい(「初回アクセス
みなさんにも、さまざまな過去の経緯からくる微妙挙動を満載した外部ユーザ向けのHTTPサーバをリプレイスしたりするとき、実際にガツンとやっちまう前にちょっとリクエストを分岐して挙動と性能を確認したい、と思うことがあると思います。考えるだけでつらい気分になってくるやつ。でもやったほうが100倍マシなやつ。 どうしよっかなとちょっと考えたところ、少し前にこんな話があったのを思い出すはずですね*1。 asnokaze.hatenablog.com とはいえヨッシャ使うぞといきなりぶちこむこともできないので、まずいくつか試してみることにする。 準備 前提としては以下のように、元のアプリケーションと同じにホストにリバースプロキシが立っており、そこのnginxで http_mirror_module を使う、という想定*2。ミラー先はどこか適当なアプリケーションサーバ(あるいはロードバランサ)で、元アプ
lua-nginx-cheatsheet.md 逆引きlua-nginx-module (WIP) Table of Contents 検証環境 nginx lua-nginx-module luajit 基本編 hello, world! nginxログに出力する nginxの変数にアクセスする HTTPヘッダにアクセスする POSTデータを取得する 外部のluaモジュールを使用する オンメモリの共有tableを定義する luajitでnginx立ち上げ時にluaをコンパイルする 動的にluaスクリプトを更新する luaによるフックが行えるタイミング luaの実行時例外発生時に特定のページにリダイレクトする proxy編 http通信をフックする upstreamのレスポンスbodyを改竄する websocketをフックする https通信のペイロードを傍受する 任意のステータスコードで
オリジンサーバーはset server_tokens off; でhttp headerのserverを一致させます。 ハードウェア Intel(R) Xeon(R) CPU X5650 @ 2.67GHz(12 cores) RAM 32GB 1Gbps ethernet card ソフトウェア CentOS: 7.4.1708 (Core) wrk: 4.0.2-2-g91655b5 varnish: (varnish-4.1.8 revision d266ac5c6) nginx: nginx/1.12.2 nuster: nuster/1.7.9.1 システム設定 /etc/sysctl.conf fs.file-max = 9999999 fs.nr_open = 9999999 net.core.netdev_max_backlog = 4096 net.core.rmem_m
個人的に、Nginx で「これは危険だ」と思っている設定があって、Nginx でなにかあるたびにその設定をつい疑ってしまいます。その設定について他の人に話すたびに、いちいち資料を集めるのが面倒になってきたので、今回はその設定項目についての情報をまとめておきます。 まだ理解に自信がない部分があるので、新しい情報が入ってきたら、この記事を適宜修正します。 リバースプロクシ設定の基本 Nginx をリバースプロクシとして使う時には、ngx_http_upstream_module でサーバのグループを定義します。そして、サーバ名やロケーション(パス)に対して、送信先のグループを指定します。 以下はマニュアルにある例です。その Nginx サーバへのすべてのアクセスを、backend グループに指定されたいずれかのサーバに送信します。 upstream backend { server backe
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く