nginx – blog.fukata.org

nginxからh2oに変えてみた

fukata — Tue, 20 Dec 2016 03:00:55 +0000

カンボジアで泊まったホテルに居た猫。可愛かったなぁ。
いつか試したかったh2o。ちょっと時間が作れたのでメモしておこう。

サイト構成

Digital Ocean 1GB (Singapore)
Ubuntu 16.04 LTS
PHP 7.0.14-1
nginx 1.10.11

こんな感じだろうか。今までDigital Oceanの2GBプランを使っていたけど調べてみるとほとんどメモリ使っていなかったので1GBプランに落とした。メモリも400MB程度しか使っていないので将来的に512MBのプランで運用しようかと思っている。

今回は、今までnginxで運用していたところをh2oに変えてみた。

h2oインストール

必要なパッケージをaptで入れて下記のコマンドをh2oの直下で行えば簡単にインストールすることが出来た。今回はmrubyも使いたいのでmrubyを有効にするオプションも忘れずに。
Install – H2O – the optimized HTTP/2 server

あとは、依存しているwebsocketのcライブラリであるwslayもソースからコンパイルして入れておく。インストール方法等は公式リポジトリから。
tatsuhiro-t/wslay: The WebSocket library in C

% cmake -DWITH_BUNDLED_SSL=on -DWITH_MRUBY=on .
% make
% sudo make install

WordPressのディレクトリ構造

このサイトはWordPressのマルチサイト機能を使っていて下記のようなディレクトリ構造になっている。

/var/www/fukata.org/index.php # WordPressのindex.php
/var/www/fukata.org/wordpress/ # WordPress本体

極力 wordpress という文字列をURLに含みたくなかったのでh2oの設定ファイルは下記のような感じになっている。多分もっとスマートに書く方法があるだろうから、追々編集するはず。

https://fukata.org/ ‘s h2o config

まとめ

意外とあっさりnginxからh2oに乗り換える事が出来たんだけど、もっと言えばnginxの時に使っていたレスポンス結果をディスクにキャッシュさせて任意のURLのキャッシュだけ削除したりなんて事が出来ると嬉しいかな。

現状どこまでmrubyを使ってh2oを拡張出来るのか把握していないので色々試したいところ。

[nginx]proxy_cacheでgzip済みコンテンツをキャッシュする

fukata — Thu, 25 Oct 2012 05:59:06 +0000

nginx + proxy_cacheの威力は凄まじく、ほとんどアプリケーションサーバまでアクセスが行かなくなることもあるので、proxy_cacheが使える状況なら非常に有効な手段だと思います。

今回は、proxy_cacheはしているけど、ページの容量が大きく転送量も減らしたいという場合のgzip圧縮の話です。

リクエスト毎にgzip圧縮の処理が行われてしまっており、リクエスト数が多大になってくるとcpuリソースを食ってしまう可能性があります。どうせgzip圧縮するんだったらそれごとproxy_cacheしちゃえばいいんじゃないかと思い、設定してみたところ正常に動作したので設定を書いておきたいと思います。

目指す構成

Internet -> [nginx(LB)] -> [nginx(RPX) -> app]

これの、RPXの部分でgzip処理を行い、LBの方ではその内容をproxy cacheして配信時に改めてgzipするのではなく、proxy cacheした内容を返す。

※[]はサーバの単位

nginx.lb.conf

nginx.rpx.conf

proxy_cache先にgzip後の容量で保存されているか確認。

ということで、とりあえず動いたのでメモでした。

自宅のgitoriousサーバをrvm + passenger(apache2) + daemontoolsからrbenv + bundler + passenger(standalone) + supervisordに移行した

fukata — Sat, 06 Oct 2012 17:50:01 +0000

当ブログで利用しているサーバ（さくらのVPS 4G）が色々同居させており、gitoriousのバッチがたまに負荷をかけ重くなってしまっていたので余っていたさくらのVPS 1Gに移しました。

どうせ移すんだったらと思い、今までrvm, passenger(apache2), daemontoolsだった構成をrbenv, passenger(standalone), supervisordに移行しました。

gitoriousの主な構成は下記の通り

OS: Ubuntu 12.04LTS
Ruby: 1.8.7-p370
実行ユーザ: git
リポジトリパス: /home/git/repos
Gitoriousルート: /var/www/gitorious

以前はapache2 + passengerで動作させていたのでwebの実行ユーザはwww-dataのままで、git-daemonなどの実行ユーザはgitという感じでしたが、今回はgitユーザに全て統一させました。

rbenv + ruby-buildへの移行

まず、rvmからrbenv, ruby-buildへ移行します。手順は下記のページで書かれている通りに実行すれば大丈夫です。

うぶ毛プリン: rvmからrbenvに移行した

実際に入れたRubyのバージョンは1.8.7-p370なので、コレを入れておきます。

rbenv install 1.8.7-p370

gemでモジュールをインストールした際にrehashする手間を省くため、rbenv-rehashを下記の通りにインストールします。

rbenv で gem を使った時に rbenv rehash しなくて良くする – sorry, unimplemented:

これで、gemを入れた段階で自動的にrehash作業も行なってくれます。

Gitoriousのインストール

cd /var/www
git clone git://gitorious.org/gitorious/mainline.git gitorious

gitoriousの細かな設定については下記のgistを参考にしました。

Gitorious installation on Ubuntu 12.04 — Gist

実際には移行だったのでまるまるインストールってわけではなく、/var/www/gitoriousディレクトリとmysqlのdumpを移行させた程度です。

Bundlerでモジュール管理

gem install bundler
cd /var/www/gitorious
bundle install --deployment

Passenger StandaloneでGitoriousを起動してみる

cd /var/www/gitrious
RAILS_ENV=production passenger start

Supervisord経由で起動する

最近はdaemontoolsではなくsupervisordで運用することが増えました。今回もsupervisordを使ってみます。設定は下記のようにしています。

なんか、調べているうちにGodというRuby製のプロセス監視ツール？があるらしいのでどっかで使ってみたいところ。

起動スクリプトはこんな感じ

pushしたらgitoriousコマンドが無いと言われる

.ssh/environmetに下記のように設定をする。

かなり端折ってて分かりにくいですが、rbenvに慣れていなくてsupervisordなどから実行させるのにはまりました。gitoriousはpassengerのstandalone版で動作させnginxをリバースプロキシとして置いて運用させています。とりあえず、今はこんな感じです。