人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 なぜWebサーバソフトウェアであるApacheやNginx等にmrubyを組み込もうと思ったのかを整理しておきたいと思いました。 目的はWebサーバの開発支援 Webサーバの開発支援をしたい という壮大な目的が以前からありました。 それがどういうことかは後述するとして、ここでいうWebサーバの開発とは、Webサーバの内部機能拡張を指しています。それを行うにはどうしたら良いかをまず簡単に説明したいと思います。（スクラッチでWebサーバを1から実装するのもよいですが、ここではスコープ外とします） 例えば、Apacheを例にあげると、Webサーバの内部機能拡張はモジュール単位で組み込むという方法が取られています。ApacheやNginxはWebサー
Apache のバーチャルホストの設定方法の中で、ひとつの IP アドレスだけを使って複数の Web サーバを公開する名前ベースのバーチャルホストの設定方法について解説します。 NameVirtualHost ディレクティブ、および VirtualHost ディレクティブを使用します。 (Last modified: 2024-06-09) 名前ベースのバーチャルホストを設定する 名前ベースのバーチャルホストでは 1 つの IP アドレスで複数の Web サーバを公開することができます。 それでは設定を行っていきます。 httpd.conファイルの設定 Apache 2.4 系より前のバージョンを使用する場合は、下記の NameVirtualHost ディレクティブを使って設定を記述してください。 Apache 2.4 系以降は NameVirtualHost ディレクティブの設定は不要で
いままでリバースプロキシの設定がよくわかっていなくて、すでに動いているサーバの設定を見よう見まねで使い回してきた。ちゃんと理解しようと思って、マニュアルを読み直したらやっとわかった。設定の方法 (How) がわかったこと以上に、なぜそう書く必要があるかという理由 (Why) を理解できたのが嬉しい。久しぶりに「わかった！」と叫びたくなった。感動を忘れないうちに、思い出せるように、書いておく。 mod_proxy - Apache HTTP サーバ バージョン 2.2 が Apache のプロキシ関連のマニュアル。 mod_proxy を使うことになる。 大事なディレクティブは、 ProxyPass と ProxyPassReverse のふたつ。 ProxyPass これがリバースプロキシをする上でのほとんどすべてのことをやってくれる。実は見慣れた (コピペし慣れた) 設定ではこのディレク
みんなのIoT/みんなのPythonの著者。二子玉近く160平米の庭付き一戸建てに嫁/息子/娘/わんこと暮らしてます。月間1000万PV/150万UUのWebサービス運営中。 免責事項 プライバシーポリシー ずいぶん長いこと開発者が居なかったこともあり，mod_pythonが正式にCloseされるようです。 とはいえmod_pythonがすぐに使えなくなるわけではなく，Apache自体の変更に追従しなくなる，ということ。ディストリビューションなどでは引き続きパッケージが提供され続けるでしょうし，ソースをダウンロードして自分でビルドすることもできる。 しかし，将来のApacheでmod_pythonはそのままでは使えなくなってしまうし，Python 3.x用のmod_pythonがリリースされる可能性は限りなくゼロに近い。 現行のシステムでmod_pythonを使っている人は，とりあえずだま
まじめに調べた事がないと気づかされたので、ドキュメントを頼ってお勉強。 mod_proxy_balancer - Apache HTTP サーバ mod_proxy - Apache HTTP サーバ まず、mod_proxy_balancer では、２種類のアルゴリズムを選択できる。リクエスト回数ベースの Request Counting と、トラフィック量ベースの Weighted Traffic Counting の２種類。設定は、lbmethod で行う。 Request Counting Request Counting は、lbmethod=byrequests とすると有効になる。このスケジューリングアルゴリズムを左右するパラメータは、lbfactor と lbstatus の２つ。 設定パラメータ lbfactor は、ワーカーに割り当てる仕事量を意味する(クオータ)。lb
これまでの説明ではDocumentRootやディレクトリへの権限設定など、Apacheの基本的な説明をしてきました。しかし、今までの設定方法では1つのDocumentRootしか設定することができません。そのため複数のドメインを使用してサービスをできない設定となっています。 しかしながら実際は1台のサーバ、1つのApacheで複数のドメイン、複数のドキュメントルートでの＝サービスを行いたいケースは多くあるかと思います。今回は、そのような問題を解決することができるVirtualHostの説明をしていきたいと思います。 VirtualHostとは？ VirtualHostとは、複数のドメインをそれぞれのDocumentRootでサービスを行うことができるApacheの機能です。具体的に説明をしたいと思います。 たとえば、example.comとexample.netというドメインを複数運用して
mod_wsgi には embeded mode (Apache のプロセスと一心同体) とdaemon mode があるのですが、小さなWSGIスクリプト以外では daemon mode を使った方が応用が利きます。 そこで、mod_wsgi の daemon mode について調べてみました。 まず、 mod_wsgi の daemon mode (以降、WSGIDaemonProcess で表します) を図で表すと次のようになります(たぶん)。WSGIDaemonProcess と Apache は Proxy でゆるくつながっていて、設定ファイルでの WSGIDaemonProcess 宣言1つにつき複数の DaemonProcess が存在し、それぞれにまた複数のスレッドがぶら下がっています。 以下、 WSGIDaemonProcess の特徴です。 Apache のプロセスとは
http://mm.apache.or.jp/pipermail/apache-users/2003-November/003529.html からのスレッドをたどる http://mm.apache.or.jp/pipermail/apache-users/2003-November/003531.html が答え print "Content-Type: text/html\n"; print "Content-Length: 6\n\ntest.\n"; と、Content-Length を加えると、とりあえず表示されるぽい 前の日 / 次の日 / 最新 / 2004-04 2013 : 01 02 03 04 05 06 07 08 09 10 11 12 2012 : 01 02 03 04 05 06 07 08 09 10 11 12 2011 : 01 02 03 04 0
Content-Length ヘッダのほかに、 「子プロセスで STDOUT を close してはいけない」 ようだ。(親プロセスは close しても動作に違いはない) 場合によっては、下記の KeepAlive を無効にする必要もあり。
日頃より楽天のサービスをご利用いただきましてありがとうございます。 サービスをご利用いただいておりますところ大変申し訳ございませんが、現在、緊急メンテナンスを行わせていただいております。 お客様には、緊急のメンテナンスにより、ご迷惑をおかけしており、誠に申し訳ございません。 メンテナンスが終了次第、サービスを復旧いたしますので、 今しばらくお待ちいただけますよう、お願い申し上げます。
RailsでPageキャッシュをより広く活用する方法を考えてみました。以下、ちょっと長く前置きが続きます。 Rails遅杉 Railsは遅い。何が遅いって、Rubyが遅くてRoutingが遅くてRDBとRHTMLが遅い。RDBが遅いのは大抵のWebアプリケーションでは変わらない話、で、だからRailsなんかが評価される余地があるんだよね。RubyやRHTMLの遅さは柔軟性の代償として受け入れよう。なにしろRDBがもともと遅いんだから。ただ、Routingは無駄に高機能だったりして頭にくる。Rhino on RailsのSteve YeggeもRoutingは黒魔術だと言っていたし。私はActionPackの全てが黒魔術だと思うけど。 そういう訳で、RoutingをCで書き直すのはドリコムのみなさんがいつかやってくれると期待するとして(可能なら手伝いたいけどね)、当面の対応としてはキャッシュ
● 1. 一戸建てタイプ そのアプリ用に専用のマシンを準備できるケース。例えば、アクセス数が少ないβリリース時などは mongrel を直接80ポートで運用することもあるだろう。そして、負荷の増加、またはマルチコアを活かすという次の段階で、cluster 化した mongrel を扱う必要に迫られた場合、このタイプになる。この場合、フロントの仕事はバック(Rails)への割り振りだけだが、そのためにわざわざ Apache2 を持ち出すのは仰々しいと感じるかもしれない。そんな人にお奨めしたいのが Pound サーバだ。いきなり Apache から話が逸れてしまうが、このケースだとリアルでお奨めである。 Pound + mongrel Pound はリバースプロキシ用のWebサーバであり、特化しているだけあって、必要最低限かつ直感的で簡単な設定で済むため、敷居が低いのが魅力だ。それでいて、デジ
日夜アクセスと闘うWeb管理者のみなさんこんにちは. ログインしてる人にしか見せたくないコンテンツがあって,phpやperlやrubyとかで アクセス制御してたりしてなかったりするんだけど,それくらいapache側で対処 してくれよと日々悶え苦しむそんなアナタにapache Auth Cookie Fu module. これはなに? Cookieを使ってコンテンツのアクセスコントロールを行うモジュールです. Cookieの評価後,コンテンツの拒否は指定された方法(redirect, forbidden)で 処理されます.なおCookieの焼き込みは自前で用意する必要があります. module.jp小山さんのmod_auth_formとかなり似てますが, apache2対応 コンテンツ拒否の方法を指定できる などがウリです. ダウンロード http://scaleout.jp/open/mo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
