nginxをdockerで動かす時のTips 3選
こんにちは。CTOの馬場です。 最近利用する機会が増えてきたdockerネタです。 nginxを動かすときのTipsを3つ紹介します。 foregroudで起動する dockerではコマンドをforegroundで動かさないとコンテナが停止してしまいます。 nginxはデフォルトはデーモンとして動くので、foregroundで動くように設定しましょう。 nginx.confで設定するならこうです。 daemon off; Dockerfileの起動コマンドで指定するならこうです。 CMD ["/usr/sbin/nginx", "-g", "daemon off;"] 動的な設定を外部化する イメージの中に設定値を入れちゃうのはダサいですよね。 コンテナ起動時に動的に設定したいものです。 dockerの場合は docker run 時に -e で環境変数を指定できるので使いましょう。 do
日本Nginxユーザ会 | nginx users group – japan
初来日のNginx開発者Igor Sysoev（イゴール・シソエフ）さんを囲む会 イゴールさんを囲んでビール、ピザスナックありのカジュアルな集まりの予定です nginx.com社公認のNginxユーザ会を立ちあげたいので、その第0回的な気持ちです Nginxユーザーコミュニティの立ち上げについて サイオステクノロジー 安藤浩二さん 日本のユーザーコミュニティの歓迎とNginx社としてのコミットについて Nginx社 CEO Gus Robertsonさん(通訳付き) Nginx アップデートNginx社CTO Igor Sysoevさん(通訳付き) 質疑応答(通訳付き) 懇親会 ※随時更新します！ ■概要 日時: 2014/6/18(水) 19:00～20:30 ※開場18:30 会場: サイオステクノロジー東京オフィス ９階オープンスペース (東京都港区南麻布2‐12‐3 サイオスビル)
PHP v5.4.28, v5.5.12以降で必要なPHP-FPMの設定
PHP v5.4.28 と v5.5.12での修正点PHP v5.4.28, v5.5.12 では、CVE-2014-0185 に対するパッチが当てられており、PHP-FPMで使用されるソケットファイルのデフォルトパーミッションが666から660に変更されています。ですので、運用環境によっては、WebサーバがPHP-FPMのソケットファイルにアクセスできなくなり、今まで問題なく動いていたWebサイトがエラーで見られなくなることになります。 必要になる設定対応策は簡単で、PHP-FPMの設定ファイル内にある listen.owner や listen.group に、Webサーバからアクセスできるような所有者・所有グループを設定するだけです(この設定が、ソケットファイルの所有者・所有グループになります)。その後で PHP-FPMを再起動して下さい。 設定例; ソケットファイルの所有者をセット
nginx最大パフォーマンスを出すための基本設定-オープンソーサー・日本
Nginxチューニング nginx最大限にスピードを出すために、設定パラメーターをチュニングしました。 nginx設定例 user www-data; pid /var/run/nginx.pid; worker_processes auto; worker_rlimit_nofile 100000; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; events { worker_connections 2048; multi_accept on; use epoll; } http { server_tokens off; sendfile on; tcp_nopush on; tcp_nodelay on; access_log o
Nginxで複数条件のIF文を書く方法がすごいｗ - Qiita
NginxでIf文を if ($host = 'www.example.com' && $request_uri ~ "/admin") という風には書けない。 入れ子にもできません。(ディレクティブなので？） そこで逃げ道は 文字列結合で判定。 if ($request_uri = /) { set $test A; } if ($host ~* teambox.com) { set $test "${test}B"; } if ($http_cookie !~* "auth_token") { set $test "${test}C"; } if ($test = ABC) { proxy_pass http://teambox-cms.heroku.com; break; }
Nginxのworker_processesとworker_cpu_affinity | 設定やツールねた
Nginxの設定項目にworker_processesというものがある。Nginx本体のプロセス数を設定するもので、Debianの標準パッケージだと4が設定されている。 /etc/nginx/nginx.conf worker_processes 4; とくに変更する必要はないが、Nginxがシングルスレッドで動作するため、コア数に合わせて設定しておくのが標準的な運用である。 # grep processor /proc/cpuinfo |wc 2 6 28 この場合、コア数は2なので、 worker_processes 2; として運用する。 とはいえ、コア数が2の場合でworker_processesを4にしてプロセス数が多くても特別問題ないので通常は変える必要はないだろう。 プロセス数が多いほうがいいのは、写真を多く扱っていたり、コンテンツが多い場合である。コンテンツにおけるページ数
そろそろApacheからNginxに移行したい人の、Nginx スターティング・ガイド
AV女優.com は7月1日に、 Apache から Nginx にウェブサーバを切り替えました。 理由は簡単で、少しでもパフォーマンスを上げるためです。 あまり収益も上がっていないので ( 先月の収益報告 ) 、サーバ費用を捻出出来ません。 今日は、私が ApacheからNginxにウェブサーバを移行するために、掻き集めた情報 をまとめていきます。 Nginxに移行すべき理由 Nginxはパフォーマンスが良い と言われています。 しかし、本当にパフォーマンス良いのか？ また、本当にApacheからNginxに切り替えて、問題がないのか？ blog@a2o.si で ApacheBenchを使ったベンチマーク が分かりやすくまとまっています。 Apache + mod_php compared to Nginx + php-fpm NginxでPHPを走らせる場合のバックエンドサーバとなる
#isucon 2013 予選をトップ通過してきた（はず）。 - 双六工場日誌
あとに回すと、ブログを書くハードルが上がってしまいそうなので、取り急ぎ。*1 さて、10月5日、6日と2日間の日程で開催された、isucon（いい感じにスピードアップコンテスト）の予選に参加して、なんと、総合トップで通過いたしました！！！！！ 今回は、まずは予選突破を目指して参加したのですが、いろいろな幸運が重なり、現時点で予選総合トップ！ 現時点では、運営の方のAMI審査で問題がなければ、という条件付きではありますが。 すでに、参加チームの幾つかからブログ報告が出ていますが、ほかのチームがかなりアプリ側のコードに手を入れているのとは、対照的にスコアの大半はインフラ側チューニングです。 特に、フロントにおいたnginxで以下にリクエストを捌くかがスコアアップの決め手になっています。 また、アプリの言語はPythonを選びました。Python 3.3が使われていたのにはちょっと戸惑いましたが
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モジュールを開発しなければならない
CloudFront+nginx+S3で動的にgzip圧縮したデータを転送する - おぎろぐはてブロ
前回の記事でCloudFront + S3でgzipで圧縮する方法について書きました。 CloudFrontでgzip圧縮したデータを転送する - おぎろぐはてブロ オリジンがS3の場合、CloudFrontで動的にgzipしたりgzip版を応答してくれたりはせず、ノーマルとgzip版両方をS3にアップして、リンクを張る側で、クライアントのヘッダみて、URLを切り替えろということで、微妙です。 たとえば、ユーザがデータをアップロードするような場合、両方をアップロードしてもらうわけにもいかないので、アップロードしたあとに、S3にgzip圧縮したデータを別途アップしないといけません。 ということで、その解決案として、CloudFrontとS3の間にgzip圧縮するサーバをはさむのを試してみました。 まずレスポンスの確認 S3においたファイルと、それをオリジンにしたCloudFrontディストリ
高速WebサーバのNginx、ミッションクリティカル対応の商用版「NGINX Plus」リリース
オープンソースのWebサーバとしてコンパクトで高性能なソフトウェアとして知られるnginx（エンジンエックス）の開発元Nginx.incは、ミッションクリティカルな用途に対応した商用版の「NGINX Plus」をリリースしました。 The High Performance Reverse Proxy, Load Balancer, Edge Cache, Origin Server | NGINX As business requirements continue to evolve rapidly, such as the shift to mobile and the explosion of dynamic content on the Web, CIO’s are continuously looking for opportunities to increase applicat
ガントチャート上でドラッグ＆ドロップでタスクの並び替えられるようにしてほしい – Customer Feedback for Backlog
ベトナムにおけるBacklog活用のリアル ベトナムにおけるBacklog活用のリアル backlog Backlog の Amazon EKS クラスターを Blue-Green アップデートするためにやっていること Backlog の Amazon EKS クラスターを Blue-Green アップデートするためにやっていること backlog 2023年最も素晴らしいプロジェクトを表彰！Good Project Awardを開催しました 2023年最も素晴らしいプロジェクトを表彰！Good Project Awardを開催しました backlog Backlog開発者が夫婦の不和をなくす家庭管理アプリを作ってみた話 Backlog開発者が夫婦の不和をなくす家庭管理アプリを作ってみた話 backlog 創業からもうすぐ80年の老舗企業！ミートボールでおなじみの石井食品様で、プロジェクト
Nginxの分散状態を確認するには - SERVER MEMO
Redisから少し離れてNginxの話。 Nginxでは、標準で入っているUpstreamモジュールを用いることで、ロードバランサーとして動作させる事が可能になっています。 ただし、LVSのように分散先に対して定期的にヘルスチェックは行なっておらず、リクエストが飛んでくる度に分散先のステータスを確認し、どのサーバに対してリクエストを投げるべきか決定しています。 もし、分散先の一部サーバがダウンしていたり、応答が遅い場合は一定期間チェック対象から除外する事も可能です。 また、障害を検知した場合はログに情報を出力する事もできるようになっているのですが、ブラウザやツール類からサクっと今のステータスを取れると色々と幸せになれる事も多いのかなと思います。 この手の情報を出力するモジュールは既にいくつか存在しており、 ・ngx_upstream_status ・nginx_upstream_check
nginxのlocation適用順 - NullPointer's
この記事の内容は不正確なので、別の記事をご覧ください リクエストURIが複数のlocation設定にマッチしても適用されるものは１つだけです。適用の優先順位は 完全一致（=） 前方一致（^~あり、複数マッチした時は一番パスが長いもの） 正規表現（~または*~ 複数マッチする場合は一番上のもの） 前方一致（^~なし、複数マッチした時は一番パスが長いもの） =や^~でマッチした場合はその時点でマッチング処理を終了するそうです。 わずかでも軽くしたいなら正規表現を避けるといいのかもしれません。たとえば画像ファイルを全て /img 以下に設置しているのであれば location ~* .(gif|jpg|png)$ { access_log off; }よりも前方一致マッチングを使って location ^~ /img/ { access_log off; }とした方が、わずかながら速くなるかもし
nginxで同じパスでPCとSPのページ出し分け（簡易版） - taiyoh's memorandum
今更ながら、nginxにmapという機能があることを知った。 → HttpMapModule ということで、以下のことを試してみた。serverブロックの外側に以下のような記述を追加してみる（中に書くと怒られる）。 map $http_user_agent $myindex { default /index.html; ~(iPhone|Android) /index_sp.html; } んで、serverブロックの中のlocationの指定で location / { root /path/to/document/root; index $myindex; } って感じでindexの値をmapで指定した値に変えておくと、UserAgentに「iPhone」とか「Android」って入ってればindex_sp.htmlをインデックスファイルに、そうでなければindex.htmlをインデッ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
nginx入門
nginx -V (plus)
http://pythonarticles.com/python_server_setup_part1.html
Using ngx_lua / lua-nginx-module in pixiv
