主に参考にさせていただいたのは以下のサイトだ。
[Linux]10分で作る、Subversionレポジトリ (CentOS 版)
Subversion導入ツアー

ユーザーとレポジトリの作成
さくらのVPSで使われているCentOS6.2だとSVNそのものは最初から入っていたので、まずはSVNで使用するユーザー作成から行う。Subversion導入ツアーを参考に以下のようにした。

$ sudo useradd -M -r -s /sbin/nologin svnadmin

-Mはホームディレクトリ無し
-rはシステムアカウントを生成
-sはログインシェルの指定

次にレポジトリの作成をする。
ディレクトリは/var/svn以下にしておいた。
テストなのでtestrepoと名前を付けておき以下にSVNのお作法通りにtrunk,branches,tagsディレクトリを置いた。

$ sudo mkdir /var/svn
$ cd /var/svn
$ mkdir testrepo
$ sudo mkdir testrepo
$ sudo svnadmin create testrepo
$ sudo svn mkdir file:///var/svn/testrepo/{trunk,branches,tags} -m 'setup dir'

xinetdのインストールと設定
サーバーはsvnserveをxinetd経由で動かすことにする。
xinetdについてはコチラを参考にさせて頂いた。
さくらのVPS CentOSでサーバ構築 14 – xinetd
インストールと自動起動設定をする。

$ sudo yum install xinetd
$ /etc/init.d/xinetd start
xinetd を起動中: [  OK  ]
$ sudo chkconfig xinetd on
$ chkconfig --list xinetd
xinetd 	0:off	1:off	2:on	3:on	4:on	5:on	6:off

xinetd.dにsvnの設定をする。only_fromはあとで自宅のアドレスを調べて設定する。

$ sudo vi /etc/xinetd.d/svn
# default: off
# description: The svnserve server is a Subversion server.
service svn
{
        disable = no
        socket_type     = stream
        wait            = no
        user            = svnadmin
        server          = /usr/bin/svnserve
        server_args     = -i -r /var/svn
        log_on_failure  += USERID
        #only_from       = 192.168.24.0/24 127.0.0.1
}

ファイヤーウォールの設定
svnserveは3690を使うのでポートを空ける。

$ sudo vi /etc/sysconfig/iptables
#この行を追加する。
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 3690  -j ACCEPT

ファイヤーウォールを再起動し反映されているか確認する。

$ /etc/rc.d/init.d/iptables restart
$ iptables -L

svnserveの設定
checkoutやcommitできるメンバーを限定したいので、svnserve.confを書き換える。

$ sudo vi /var/svn/testrepo/conf/svnserve.conf
anon-access = none
auth-access = write
password-db = passwd

続いてpasswdを編集してログインできるユーザを限定する。

$ sudo vi /var/svn/testrepo/conf/passwd
  harry = harryssecret

次にレポジトリの所有者を変更する。これを変更しておかないとcommitの時に警告が出てくる。

$ sudo chown -R svnadmin /var/svn/testrepo

以上で、SVNクライアントから接続しCheckoutしたりCommitしたりできるようになる。

インタラクションデザインの定義をこの本より引っ張ってくると、このようになる。

　インタラクションデザインは、製品やサービスを介して人と人がインタラクション（対話）することを手助けするための技術である。そしてまた、範囲を限定していえば、何らかの「認識力」を持つ製品と人間とのインタラクションに関するものであるといえる。認識力を持つ製品とは、人間に対して何らかの判断を行い、反応を返すことができるマイクロプロセッサを伴う製品のことである。

なんとなくで認識をしていた部分について、改めてこのように定義された文章を読むのは頭の整理ができて良い。
更に前半に書かれていた「近接領域」と「4つのアプローチ」が参考になったので、少しメモをしておく。

近接領域
インタラクションデザインについての文献は少ない状態なので、今後調べたり学習したりするにあたって、近接領域として何が存在するのかをまとめてくれている部分は、とても役に立ちそうだ。
ざっとその関係を記述すると、

• UX（ユーザーエクスペリエンスデザイン）
  ユーザーと製品やサービスとの出会いを、ビジュアル・インタラクション・音声などのデザインから見て調和を図る。
  インタラクションデザインのほぼ全てを含みそれよりも広い領域を扱う。
  同じくUXに含まれインタラクションデザインと一部分の重なる分野に下記がある。
• IA(情報アーキテクチャ)
  ユーザーの欲しい情報が見つかるようなコンテンツの構造とラベル付など、コンテンツ構造そのもの。
• CD(コミュニケーションデザイン)、もしくはグラフィックデザイン
  フォント、色、レイアウトなどコンテンツを伝えるための視覚的な言語。
• UIE(ユーザインターフェース工学)
  デジタルカメラの画面など、デジタル機器の制御。
• HCI(ヒューマン・コンピュータ・インタラクション)
  インタラクションデザインよりも、もっと定量的な方法論に基づく。
  OSなど人間がいかにコンピューターと関係しているかについての分野。
• UE(ユーザビリティ工学)
  製品をユーザーにとって分かりやすいものにするためのテスティングに関する分野。
• HF(ヒューマンファクター)
  物が人間の身体的・心理的制約に従うようにする。

• ID(工業デザイン)
  形に関するもの。使用目的と機能に合わせて物の形を決める。

インタラクションデザインの文献だけで足りない時や深掘りしたい時は、これらの近接のどの領域あたりに検討をつけて探れば良いのかが見えやすくなった。

4つのアプローチ
インタラクションデザインは4つのアプローチとその組み合わせにより課題の解決を図るとしている。

• ユーザー中心デザイン(UCD:User-Centered Design)
  「ユーザーはなんでも知っている」と言うことをデザインの哲学とする。
  ユーザーがゴールを達成するためにデザイナーが関わる。
  デザインプロセスの全段階で、ユーザーが参加することが理想。

• アクティビティ中心デザイン(Activity-Centered Design)
  目的のために行われる行為や判断のかたまりをアクティビティと定義し焦点を当てる方法。
  アクティビティは行為と判断から成り立つタスクの連続。
  ユーザーゴールのためではなくユーザーのタスク完了のための解決策をデザインする。

• システムデザイン(System Design)
  規定のコンポーネントの組み合わせでデザインの解決策を作る。
  相互作用するコンポーネントであるシステムがデザインプロセスの中心。
  ゴール、センサ、比較器、差動装置といったコンポーネントがシステムに含まれ、このコンポーネントをデザインする。

• 才能に基づくデザイン(Genius Design)
  デザイナーの勘と経験に頼るアプローチ。
  Apple社のようにセキュリティ上の理由からユーザーを巻き込む調査を行わないような場合やユーザーを絡ませるような資金や時間のない場合にとられるアプローチ。
  デザイナー自身の感性が反映されやすい。

私の場合は、ほぼ「才能に基づくデザイン」がメインでアクティビティがほんの少しふりかけのように混じっているくらいのアプローチとなっている。
しかし今後は手持ち武器を増やすためにも他のアプローチを調べ、まずは個人開発の物から適用していってみたい。できればデザインリサーチも行なってみたいのだけど、その機会をどのようにしたら作れるか少し検討してみることにした。

この本ではさらにインタラクションデザインの基礎要素や法則などが説明されている。この辺りについてはスタディを書きつつ、ひとつひとつ深めていってみようかと考えている。
そうしたものや、スケッチ、ワイヤーなどのデザインドキュメント、インターフェイスあたりも説明されているが、中でも後半部分の、サービスデザインやウェアラブル・ユビキタスに触れている部分の未来に関する部分は、この本の中でも少し扱いが違い、インタラクションデザインが持つ可能性に楽しみを感じさせてくれた。

911ではじまったテロとの戦いが続いている近未来が舞台となる。その頃、アメリカの軍隊は、陸軍（アーミー）、空軍（エアフォース）、海軍（ネイビー）、海兵隊（マリーンズ）、情報軍（インフォメーションズ）から構成されており、主人公の”ぼく”グラウヴィス・シェパードは、情報軍・特殊検索軍i分遣隊で大尉として従軍している。この部隊はアメリカ5軍の中でも暗殺を請け負う唯一の部隊であり、主人公も世界各地の紛争地帯で暗殺を遂行している。
そして、その世界では、ここ数年後進国での虐殺が増えてきている。その虐殺地帯に現れ暗殺対象になり、幾度も失敗し続けているジョン・ポールという人物が居る。この物語は、ウヴィス・シェパードが、その目標であるジョン・ポールをプラハやインドなど世界各地で追いかけていく話であり、その過程で虐殺の動悸や方法が明らかになっていく構成となっている。

著者の伊藤計劃は2009年に満34歳で逝去している。彼が小説家として活躍したのは、その早すぎる人生の最後の三年間であり、この「虐殺器官」は初めて出版された近未来SF長編小説となる。

凄惨な虐殺の描写をするイントロダクションと共に、それを成り立たせていた虐殺の文法と、ジョン・ポールを捕らえところで終りとせずに、エピローグ配されたアメリカ-世界の反転に至る構成に心を奪われた。
話の中心部になる虐殺の文法を組み立てる深層言語とクレオール語や脳機能にまつわるエピソードが、グラウヴィス・シェパードが殺意でさえも自分のものではないと感じる様、そして民間軍事請負業者の戦争を普通の仕事と同じようにプレゼンする態度と現場で起きている穴だらけにされた死体や家族と離れ離れになった子供の存在する現実との乖離などと相まって、自分の存在はそんなに自分ではないのだろうという気分にさせられる。

この小説は、様々な世界の問題（貧困や対立、そしてテロ）とテクノロジーを繊細に組み立てることで世界観を作り上げている。そうした世界観を作り上げている小道具の中で、オルタナ（副現実）という名称で（たぶんARの進化した姿なのだろう）現実にレイヤードされて視覚に情報が映し出される描写が未来の都市や建築の姿を想像させられた。
このオルタナは、もちろん戦場でも使われているが、それよりもプラハにおける第二次世界大戦の爆撃を免れた古都の姿とレイヤーされる大量の情報という対比が気になった。オルタナのプラハは「リドリー・スコットの創造したロスアンゼルス」= たぶんブレードランナーの冒頭のようであったと書く。
また病院でオルタナを見るためのデバイスを忘れてきた描写があり、その場では床に現れるマーカーで誘導を行なっていた。病院は複雑すぎて迷路のようであり、マーカーがないと迷っていたであろうと書いている。
そうしたブレードランナーの未来がオルタナの中にやってきたプラハの姿や、複雑な病院などから示唆されて、未来の都市や建築というのは、サインや広告の多くが撤退し、建物や街自体が入り組んだ姿をしているのかもしれないと想像をしてみた。つまりそれは建築が遅いメディアとしてのスピードを発揮できるような世界であり、広告のような速いスピードのメディアを必要とするものに合わせる必要がなくなり、また空間の心地よさではなく経路のわかりやすさを目指した動線計画などからの脱却が起きた姿かもしれない。もしもこの妄想通りであれば、これからの都市や建物は伽藍のようになるかバザールのようになるか分からないが、より空間的な豊かさを目指すようになるだろうし、その豊かさはARの発展形（オルタナ的な）を空間の余白として組み込めるような形へと変化していくのだろう。こうなっていくと未来の都市/建築は、案外とそのメディアとしての遅さにみあったどっしりとした空間経験を与えてくれるものになってくれるかもしれない。

以上「虐殺器官」を読んだ感想とそこから発生した妄想を書いてみた。

こちらのサイトにもPHP-FPMの詳しい説明が書かれてありとても参考になった。
apache のかわりにnginxを使ってみる(2) php-fpmをインストールする

PHPそのものもインストールされていないので、そちらのインストールも説明していく。
PHPは5.3.3まではパッチを当てる必要がある。それ以降であればPHP-FPMが予め組み込まれておりパッチを当てる必要は無い。そのため、レポジトリ登録したら一度確認をしてからインストール作業に入る。

PHPとPHP-FPMのインストール

今回のインストールでは、こちらのサイトを基本として参考にさせて頂いた。
CentOSにNginx + php-fpmをInstall、設定してWordPressを動かす

ただし、上記サイトではCentOS 5.8 32bitであり、契約した環境はCentOS6.2 64bitなため下記が違う。
・remiのレポジトリはcentOS6版を入れる。5までとは違う。
・epelリポジトリはcentOS6ではインストール済みなので、入れる必要はない。

標準のリポジトリにはphp-fpmがないため、REMIレポジトリを追加する。

# wget http://rpms.famillecollet.com/enterprise/remi-release-6.rpm
# rpm -ivh remi-release-6.rpm

yumを確認するとphp-fpmも存在し、PHPは5.3.13なのでパッチを当てる必要はないようだ。

# yum list --enablerepo=remi | grep php
php.x86_64       5.3.13-1.el6.remi   remi  
・・・
php-fpm.x86_64   5.3.13-1.el6.remi   remi 
・・・

インストールするPHPと関連ライブラリは以下にしておいた。
php ;本体
php-fpm ;PHP FastCGI Process Manager FastCGIを動かすためのライブラリ
php-devel ;PHP拡張用のライブラリ
php-cli ;コマンドラインでPHPを使えるようにする
php-xml ;PHPでXMLを取り扱うライブラリ
php-mbstring ;マルチバイト言語を扱うためのライブラリ
php-gd ;PHP用グラフィックライブラリ

ライブラリ情報はyum infoで調べることができる。

# yum info php-xml  --enablerepo=remi

インストールする。

# yum install php php-fpm php-devel php-cli php-xml  php-mbstring php-gd --enablerepo=remi
・・・
Installed:
  php.x86_64 0:5.3.13-1.el6.remi            php-cli.x86_64 0:5.3.13-1.el6.remi        php-devel.x86_64 0:5.3.13-1.el6.remi          
  php-fpm.x86_64 0:5.3.13-1.el6.remi        php-gd.x86_64 0:5.3.13-1.el6.remi         php-mbstring.x86_64 0:5.3.13-1.el6.remi       
  php-xml.x86_64 0:5.3.13-1.el6.remi       

Dependency Installed:
  apr-util-ldap.x86_64 0:1.3.9-3.el6_0.1    httpd.x86_64 0:2.2.15-15.el6.centos.1    httpd-tools.x86_64 0:2.2.15-15.el6.centos.1   
  libXpm.x86_64 0:3.5.8-2.el6               libxslt.x86_64 0:1.1.26-2.el6            php-common.x86_64 0:5.3.13-1.el6.remi         
  t1lib.x86_64 0:5.1.2-6.el6_2.1           

Complete!

# php -v
PHP 5.3.13 (cli) (built: May  9 2012 16:43:49) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies

インストールして、ディレクトリチェックしていたら、なんか馴染んだものがvar/wwwに入ってしまってる。
ログを良く見ると、httpdがインストールされてしまっていた。
ということで、var/www/に入っていたnginx扱いのデータはvar/webdev/へと移動することにした。

php-fpmとnginxの設定

/etc/php-fpm.confはそのままで変更なし。

/etc/php-fpm.d/www.confでポートの確認(9000)をし、userとgroupをnginxへ変更する。

#vi /etc/php-fpm.d/www.conf
・・・・
; The address on which to accept FastCGI requests.
; Valid syntaxes are:
;   'ip.add.re.ss:port'    - to listen on a TCP socket to a specific address on
;                            a specific port;
;   'port'                 - to listen on a TCP socket to all addresses on a
;                            specific port;
;   '/path/to/unix/socket' - to listen on a unix socket.
; Note: This value is mandatory.
listen = 127.0.0.1:9000
・・・・
; Unix user/group of processes
; Note: The user is mandatory. If the group is not set, the default user's group
;       will be used.
; RPM: apache Choosed to be able to access some dir as httpd
user = nginx
; RPM: Keep a group allowed to write in log dir.
group = nginx

引き続き、nginx.confを変更しphpが使えるようにする。
大半はコメントアウトされていたのを消すことで大丈夫なようだ。

# 念の為にphpディレクトリを作成しbasic認証をかけテストゾーンにした。
location = /php/index.php {
    alias 		/var/webdev/php/;
    auth_basic    	"PHP test";
    auth_basic_user_file    "/var/webdev/php/.htpasswd";
    fastcgi_pass   	127.0.0.1:9000;
    fastcgi_index  	index.php;
    fastcgi_param  	SCRIPT_FILENAME /var/webdev/$fastcgi_script_name;
    include		fastcgi_params;

}

# rootはserverと同じなので設定せず。SCRIPT_FILENAMEのパス変更。
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
location ~ /*\.php$ {
#   root   		/var/webdev/index/html;
    fastcgi_pass   	127.0.0.1:9000;
    fastcgi_index  	index.php;
#   fastcgi_param       SCRIPT_FILENAME  /scripts$fastcgi_script_name;
    fastcgi_param  	SCRIPT_FILENAME  $document_root$fastcgi_script_name;
    include		fastcgi_params;
}

# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
location ~ /\.ht {
    deny  	all;
}

phpディレクトリを作成し、パスワードを暗号化して.htpasswdにいれる。

# mkdir /var/webdev/php
# cd /var/webdev/php
# vi .htpasswd

php-fpmを起動し、nginxを再起動する。

# /etc/rc.d/init.d/php-fpm start
# /etc/init.d/nginx restart

phpinfoを出力してみる。

# echo '<?php echo phpinfo(); ?>' > index.php

ブラウザで確認して大丈夫だったら、php-fpmの自動起動設定をする。

# chkconfig php-fpm on
# chkconfig --list php-fpm

これでphpがnginxでも使えるようになった。
もしもサブドメイン使用するアプリ作成した場合は、アプリにより設定が変わる可能性があるので、projectsディレクトリ以下にあるアプリごとのconfへphpの設定を書くことにした。

wordpressについては気が向いたらいつか行う事にして、ここまででとりあえずVPS設定は終わりとする。
また環境設定ができたため、これから作成するスタディにはできるだけリアルタイム処理を加え、様々なパターン検証を行うことにした。

リバースプロキシ
リバースプロキシ（英: Reverse proxy）または逆プロキシは、特定のサーバへの要求を必ず経由するように設置されたプロキシサーバ。一般的なプロキシとは異なり不特定多数のサーバを対象としない。リバースプロキシは、不特定多数のクライアントから寄せられる要求に対して、応答を肩代わりすることにより特定のサーバの負担を軽減したり、アクセスを制限することにより特定のサーバのセキュリティを高めたりする目的に用いられる。

node.jsでアプリを作成しforeverで永続化した場合、xxx.xxx.xx:3000などと最後にポート番号がついてしまう、これがとても気になっており、nginxでリバースプロクシを入れてアプリごとサブドメイン運用をしようとしたきっかけとなった。もちろんサブディレクトリの方にも入れることができるので簡単な実験とかはそちらの方がいいのかもしれない。
またnodeには動的な物を任せ、静的な部分についてはnginxで取り扱う形のほうがパフォーマンスから見ても良いようだ。
それとリバースプロクシはwebsocketを通さないのでnginx_tcp_proxy_moduleを使用して動かす方法も書いておく。

使用しているのは、以前作ったタッチ共有アプリだ。これをさくらのVPSサーバーへ持ってきて諸処の作業を行った。

nginx_tcp_proxy_moduleでnode.jsのsocket.ioをリバースプロクシさせる

nginx_tcp_proxy_moduleのインストールは以前のエントリの通りだ。そして設定方法は次のブログ記事を参考にさせて頂いた。

nginxでsocket.ioのリバースプロキシ設定
nginx_tcp_proxy_module を入れてnode.jsのsocket.ioを動かすnginxの設定

モジュール設定はtcpブロックで行うがhttpブロックとたいして変わりがない。
そして/usr/local/nginx/conf/tcps以下にtcp設定を置きnginx.confからincludeする形にした。

user nginx;
worker_processes  2;
・・・・
events {
    worker_connections  1024;
}
# Load config files from th/usr/local/nginx/conf/tcps/ directory
include tcps/*.conf;

http {
　・・・・
}

includeしたtcp_cotouch.confはこのような内容であり、3000ポートでnodeアプリを動かし、サイトに3001で接続するとちゃんと動くのを確認できた。

tcp {
  upstream coTouchApp {
    server 127.0.0.1:3000;
    check interval=3000 rise=2 fall=5 timeout=1000;
  }

  server {
    listen 3001;
    server_name cotouch.omusuhi.info;

    proxy_read_timeout 200000;
    proxy_send_timeout 200000;
    proxy_pass coTouchApp;
  }
}

ところで、ソケット通信は、こちらの説明でも書いてある通り、IPアドレスとPort番号を一組とした通信手段となる。
ソケット【socket】　

「ソケット」というのはIPアドレスとPort番号を一組にしたものに結び付けられた仮想メモリ空間なのです。 相手にデータを送るときは、このメモリ空間に通信するためのデータを書き込むことによって 「Socket」ライブラリの中の「socket」プログラムが相手アプリケーションとデータの通信を行ってくれるのです。

なので、[[Portが一つ占有されることになる]]はずだと思いながら、tcpとhttpで同じポート番号を指定すると、動いてしまった。しかしながら、別々のポートを指定していた時とは違い引っかかりがある。どういうことなのだろうと思いnginxを停めてinit.dで再起動しようとするとポートが使われていて動かせないと出てくる。

sudo /etc/init.d/nginx restart

前の時は、設定ファイルのリロードだったのを思い出し、nginx.confでtcpとhttpのポート指定を書き換えた上でnginxを機動、tcpとhttpのポート指定を同じにした上で下記のコマンドで設定リロードする。

sudo nginx -s reload

そうすると同じポートで動いてしまった。ここで、エラーログを確認しようとした。

sudo vi /usr/local/nginx/logs/error.log

すると重くて開くのにとんでもなく時間が掛かる。
やはり、ソケットとhttpの接続とで混乱が起きていた模様で大量のエラーが発生していた。これで同じポート指定はやはり出来ないことが分かった。
そして念の為にtcpブロックで同じポート指定で2つ動かそうとしてみたら、先に書かれていたものが優先され、default_serverの指定が後のサーバにあった場合、既に使われているというエラーが出る。
このため、やはりtcpのserverブロックは1ポート専有というのを再確認することができた。

nodeアプリをhttpブロックでリバースプロキシ

soket.ioでの接続は現段階ではリバースプロキシしてもあまり意味が無いので、これまでのようにポート指定で行うことにして、ソケットとは関係のないnodeアプリ本体の部分にリバースプロキシを使いURLにポート番号が出ないようにすることにした。
soket.ioと本体のポート番号を変えるのは下記の記事を参考にさせていただいている。
Socket.io Chat on Dreamhost: Hiding the URL

nodeアプリでは、このように本体を3001、ソケットを3002として指定しなおしている。

var sys = require('util'),
		express = require('express'),
		app = express.createServer();

app.configure(function(){
	app.use(express.static(__dirname+'/views'));
});
app.listen(3001);
//var io = require('socket.io').listen(app);appではなくポート番号指定と変えている。
var io = require('socket.io').listen(3002);

io.sockets.on('connection', function(socket){
・・・・

html部分だと、index.htmlでsocket.io.jsを指定する部分をポート番号付きに変更する。

<!--<script src="/socket.io/socket.io.js"></script> -->
<script src="http://www.omusuhi.info:3002/socket.io/socket.io.js"></script>

socketを使うクライアント側jsファイルの方でもsocket.io側のポート指定へと変える。

function initSocket(){
  var socket = io.connect('http://www.omusuhi.info:3002/');
  socket.on('message', function(t){
    console.log('mes; '+t);
  });
・・・・
}

Nodeアプリの変更点は以上となる。次にnginxでリバースプロキシの設定を行った。
参考にさせていただいたのは、主にこちらのサイトだ。
Virtualmin, Apache, and Nginx Reverse Proxy
さくらVPS を設定してみる:Nginx + リバースプロキシで WordPress を動かしてみた♪
apache のかわりにnginxを使ってみる(10) nginx をリバースプロキシとして使ってみた
nginxでリバースプロキシ。

プロキシ共有設定ファイルを上記サイトを見つつ、このような感じで書き、
projects/proxy.confへと保存した。

proxy_cache_path        /var/cache/nginx/ levels=1:2 keys_zone=czone:10m max_size=100m inactive=120m;
proxy_temp_path         /var/cache/nginx;
proxy_redirect          off;
proxy_set_header        Host            $host;
proxy_set_header        X-Real-IP       $remote_addr;
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size    10m;
client_body_buffer_size 128k;
proxy_connect_timeout   90;
proxy_send_timeout      90;
proxy_read_timeout      90;
proxy_buffers           32 4k;
proxy_cache_valid       200 302 10m;
proxy_cache_valid       301 1h;                                                           
proxy_cache_valid       any 1m;

また、今回のアプリのプロキシ設定を下記のように書き、
projects/cotouch.confへと保存してある。

upstream cotouch {
    ip_hash;
    server 127.0.0.1:3001;
}

server {
    listen   80;
    server_name cotouch.omusuhi.info;
    location / {
        proxy_pass http://cotouch/;
    }
}

前回のエントリで、projectsディレクトリにあるものは読みこむようにしてあったので、proxy.confもcotouch.confもnginx起動時に自動的に読み込まれることになる。

・・・・
http {
・・・・
 # Load config files from th/usr/local/nginx/conf/projects/ directory
 include /usr/local/nginx/conf/projects/*.conf;
}

ここまで変更してから、nginxの再起動を行う。

sudo /etc/init.d/nginx restart

すると、ちゃんとサブドメインでアプリが動き、さらに2枚同時に立ち上げると同期しているのも確認できた。
cotouch.omusuhi.info

これで、複数のNodeアプリがあってもnginx側で管理できるようになった。
次はphp-fpmでphpを動かしてみたい。
余裕ができたらwordpressもnginxでどれだけパフォーマンスが良くなるのか試してみたいと考えている。

ディレクトリ・グループ構成の検討

グループ構成

group;nginx
member;nginx

group;node
member;node
*nodeアカウントについては、必要になってから作成、今は保留する。

group;dev
member;foo dev nginx (node root)
*node、rootアカウントについては、必要になってから設定する。

/usr/local/nginx/
owner;nginx
group;nginx
*問題が出るかもしれないので一通りの設定が落ち着くまで保留する。

/var/tmp/nginx/
owner;nginx
group;nginx
*問題が出るかもしれないので一通りの設定が落ち着くまで保留する。

webアプリ公開用ディレクトリ。
/var/webdev/
owner;dev
group;dev
permission;775
パーミッションはとりあえずwebdevを775にしてdevグループの物は動くようにしておいた。

hogeプロジェクト
/var/webdev/hoge/
hogeプロジェクトの静的部分をhtmlディレクトリ、nodeアプリ等の動的部分をappディレクトリの形にする。
owner・groupはアプリに合わせて決めるが基本は以下の通りとしておく。

/var/webdev/hoge/html/
owner;nginx
group;nginx
permission;644

/var/webdev/hoge/app/
owner;foo
group;foo
permission;755

/var/webdev/html/hoge/
/var/webdev/app/hoge/
とすると、htmlディレクトリ以下、appディレクトリ以下でowner・groupをまとめれるのが良さそうだが、開発時にローカルマシンでプロジェクトを一箇所にまとめて管理しておきたかった事及びappがnodeのみでは無さそうなので、今回は採用しなかった。

ディレクトリ・グループ設定

devユーザーを作成する。アプリ名はとりあえずでindexにしておいた。

$ sudo useradd -s /sbin/nologin dev

補助グループに今まで入っていたグループも指定しておかないと、 補助グループから外されてしまう。
これで一度失敗した。
なのでまず補助グループを確認してから、それを含める形で再度指定する。

$ groups foo
foo : foo
$ sudo usermod -G dev,foo foo
$ groups foo
foo : foo dev

$ groups nginx
nginx : nginx
$ sudo usermod -G dev,nginx nginx
$ groups nginx
nginx : nginx dev

ユーザー確認する。

$ cat /etc/passwd

グループ確認する。

$ cat /etc/group

とりあえずindexのディレクトリを作成する。

$ sudo mkdir -p /var/webdev/index/{html,app}
$ cd /var/
$ sudo chown -R dev webdev
$ sudo chgrp -R dev webdev
$ sudo chmod 775 webdev
$ ls -l webdev
合計 4
drwxr-xr-x 4 dev dev 4096  5月 16 09:43 2012 index

各プロジェクトのアクセス権限については、また後で設定する。

confファイルの調整

プロジェクト毎に設定ファイルを置けるようにprojectsディレクトリを作成する。

$ sudo mkdir /usr/local/nginx/conf/projects/

ディレクトリ構成に合わせて設定ファイルの調整をする。

$ sudo nano /usr/local/nginx/conf/nginx.conf

ユーザーはnginxへ変更する。

user nginx;

worker_processesを決めるためにサイトをみると契約したさくらVPS1Gプランは仮想 2コアだった。

worker_processes  2;

デフォルトのroot指定をvar/webdev/index/へ変更する。
プロジェクト毎に設定を読み込めるようにprojects/*.confをincludeする。

http {
 ・・・
 server {
  ・・・
      location / {
         root   /var/webdev/index/html;
         index  index.html index.htm;
      }
  ・・・
  }
  ・・・
 # Load config files from the /usr/local/nginx/conf/projects/ directory
 include /usr/local/nginx/conf/projects/*.conf;
}

これで契約したVPSをみてみる。
http://www.omusuhi.info/
/var/webdev/index/html/にアップロードしてあった「おむすびコロン。」が表示されている。
試しに適当なのを指定すると、
http://www.omusuhi.info/a
ちゃんと「404 Not Found」がでている。
次回はnginxを導入した理由でもあるリバースプロクシの設定を行う。

追記・/var/www/としていたのをhttpdが使用するディレクトリと被るので/var/webdev/に変更した。

mongoDBのインストールまでは、今までと一緒で、nginxのインストールから変更となる。
ソースインストールで、しかも再インストールがありそうなnginxはpacoで管理するのがよさそうだ。

“make install”したソフトウェアを管理できる超便利ツール「Paco」
「Paco」で「make uninstall」できないソフトを削除する
yum,rpmで扱えないアプリケーションを管理するソフトpaco

pacoのインストール
インストールのために最新版を確認する。
paco – a source code pacKAGE oRGANIZER for Unix/Linux
2.0.9が最新版のバージョンなので、それをwgetし展開、configureする。

$ sudo mkdir /usr/local/src/paco
$ sudo wget http://downloads.sourceforge.net/paco/paco-2.0.9.tar.gz
$ sudo tar zxfv paco-2.0.9.tar.gz
$ cd paco-2.0.9
$ ./configure
・・
No package 'gtkmm-2.4' found

gtkmm-2.4がない模様だ。調べてみると、GUIインタフェース用らしいので要らないらしい。
pacoを導入
というわけで、–disableにして再度configureしインストールする。

$ sudo ./configure --disable-gpaco
$ sudo make
$ sudo make install

logmeコマンドでPaco自身もアンインストールできるようにする。
sudoで行おうとするとエラーが出る。

$ sudo make logme
make: *** [logme] エラー 2

suにチェンジしてlogmeするとうまくいった。

$ su
# make logme
# paco --version
paco-2.0.9  (28 June 2010)
Copyright (C) David Rosal <davidrr@sourceforge.net>
Protected by the GNU General Public License

pacoでnginxをインストール。
nginxをpacoでインストールする手順を、こちらで確認させて頂いた。
さくらVPSサーバにnginx-1.1.15をソースからビルドしてインストールしたときのメモ

アプリが使用するnginxアカウントを作成する。

$ sudo useradd -s /sbin/nologin -d /usr/local/nginx -M nginx

nginxのビルドに必要なパッケージのインストールをする。重要ではないがIPアドレスから地理情報を取得できるGeoIPも、使えそうなので入れてみる。

$ sudo yum install gcc openssl-devel pcre-devel zlib-devel GeoIP*

前と同じくnginx_tcp_proxy_moduleをダウンロードしパッチを当てる。

$ sudo mkdir /usr/local/src/nginx
$ cd /usr/local/src/nginx
$ sudo wget http://nginx.org/download/nginx-1.2.0.tar.gz
$ sudo git clone https://github.com/yaoweibin/nginx_tcp_proxy_module.git
$ sudo tar zxvf nginx-1.2.0.tar.gz
$ cd nginx-1.2.0

前回とは違い今回はユーザ名指定し幾つかのオプションとnginx_tcp_proxy_moduleを加えてconfigureする。
パス関連のオプション指定はコチラにまとまっていたので参考にさせて頂いた。
REMEMBER TO SPECIFY NGINX’S TEMP DIRECTORY PATH

$ sudo ./configure \
--user=nginx \
--group=nginx \
--with-http_ssl_module \
--with-http_realip_module \
--with-http_geoip_module \
--with-http_flv_module \
--with-http_stub_status_module \
--http-log-path=/var/log/nginx/access.log \
--http-client-body-temp-path=/var/tmp/nginx/client/ \
--http-proxy-temp-path=/var/tmp/nginx/proxy/ \
--http-fastcgi-temp-path=/var/tmp/nginx/fcgi/ \
--http-uwsgi-temp-path=/var/tmp/nginx/uwsgi/ \
--http-scgi-temp-path=/var/tmp/nginx/scgi/ \
--add-module=../nginx_tcp_proxy_module/
・・・・
Configuration summary
  + using system PCRE library
  + using system OpenSSL library
  + md5: using OpenSSL library
  + sha1: using OpenSSL library
  + using system zlib library

  nginx path prefix: "/usr/local/nginx"
  nginx binary file: "/usr/local/nginx/sbin/nginx"
  nginx configuration prefix: "/usr/local/nginx/conf"
  nginx configuration file: "/usr/local/nginx/conf/nginx.conf"
  nginx pid file: "/usr/local/nginx/logs/nginx.pid"
  nginx error log file: "/usr/local/nginx/logs/error.log"
  nginx http access log file: "/var/log/nginx/access.log"
  nginx http client request body temporary files: "/var/tmp/nginx/client/"
  nginx http proxy temporary files: "/var/tmp/nginx/proxy/"
  nginx http fastcgi temporary files: "/var/tmp/nginx/fcgi/"
  nginx http uwsgi temporary files: "/var/tmp/nginx/uwsgi/"
  nginx http scgi temporary files: "/var/tmp/nginx/scgi/"

一時ファイルの場所も変更された模様だ。
必要なフォルダを作成しインストールを行う。

$ sudo mkdir -p /var/tmp/nginx/{proxy,client,fcgi,uwsgi,scgi}
$ sudo make
$ sudo paco -D make install

エラーが出てくる。sudoではダメの模様なのでsuにチェンジしてインストールを試みるとうまくいった。

$ su
# paco -D make install
# paco -a
nginx-1.2.0  paco-2.0.9

paco -aするとnginxがpaco管理として入っているのが確認できた。

シンボリックリンクを張り起動してみる。

$ sudo ln -s /usr/local/nginx/sbin/nginx /sbin/nginx
$ sudo nginx
$ nginx -v
nginx version: nginx/1.2.0

「Welcome to nginx!」をブラウザで確認できたので停めておく。

$ sudo nginx -s quit

自動起動設定は前回の「Nginx自動起動スクリプトの作成」と同じなので割愛する。
次回はnginxとnode併用でのディレクトリやグループ構成を行う。

nginx [えんじんえっくす] は Igor Sysoev によって作られた HTTP とリバースプロキシのサーバで、メールプロキシサーバでもあります。Rambler (RamblerMedia.com) を含むロシアの多くの高負荷サイトで５年以上も動いています。Netcraft によると、nginx は 2010 年 4 月時点で 4.70% の人気サイトでサーバーとして、もしくはプロキシとして利用されています。成功例としては FastMail.FM や WordPress.com があります。

node.jsと同じくイベント駆動型アーキテクチャである。
nginxを表に置きリバースプロキシと静的ファイルの取り扱いを行い、裏に動的ファイルを扱う形でNode.jsを置く方法でVPSサーバーを構築していこうと考えている。
またwebsockeでリアルタイム通信を行う場合、そのままではリバースプロキシできないのでnginx_tcp_proxy_moduleというモジュールを使用する。この説明も加えておく。
まず今回はモジュールを組み込んだnginxのインストールと自動起動の設定までを行う。
<追記>いろいろと見直しをし再インストールした。

モジュールの組み込みとnginxのインストール

nginxではsocket.ioのプロキシがうまく行かないようで、yaoweibinさんという方がモジュールを書いてくれている。このnginx_tcp_proxy_moduleを使用してリバースプロキシでもリアルタイム通信が出来るようにする。
nginx_tcp_proxy_module

nginxのインストールは、nginx連載2回目: nginxのインストールでも書かれているようにいくつかありyumコマンドでもインストールできるのだけど、モジュールの組み込みがインストール時にしかできないため、ソースをダウンロードしてパッチを当てる方法を取ることとした。

wgetする前に最新版の確認をする。
http://nginx.org/download/
現時点ではnginx-1.2.0.tar.gzが最新版だった。
ということで、ソース及びnginx_tcp_proxy_moduleをダウンロードしパッチを当てる。

$ mkdir nginx
$ cd nginx/
$ wget http://nginx.org/download/nginx-1.2.0.tar.gz
$ git clone https://github.com/yaoweibin/nginx_tcp_proxy_module.git
$ tar zxvf nginx-1.2.0.tar.gz
$ cd nginx-1.2.0
$ patch -p1 < ../nginx_tcp_proxy_module/tcp.patch

nginx_tcp_proxy_moduleをオプションとしてconfigureしてみる。

$ ./configure --add-module=../nginx_tcp_proxy_module/
./configure: error: the HTTP rewrite module requires the PCRE library.
You can either disable the module by using --without-http_rewrite_module
option, or install the PCRE library into the system, or build the PCRE library
statically from the source with nginx by using --with-pcre=<path> option.

PCREライブラリというのがないらしいのでググってみると同じ症状の方がいてた。
CentOS5.5へのNginxのインストール
pcre-develを入れれば良いみたいなので、yumでインストールし再度configureする。

$ sudo yum -y install pcre-devel
$ ./configure --add-module=../nginx_tcp_proxy_module/
Configuration summary
  + using system PCRE library
  + OpenSSL library is not used
  + md5: using system crypto library
  + sha1: using system crypto library
  + using system zlib library

  nginx path prefix: "/usr/local/nginx"
  nginx binary file: "/usr/local/nginx/sbin/nginx"
  nginx configuration prefix: "/usr/local/nginx/conf"
  nginx configuration file: "/usr/local/nginx/conf/nginx.conf"
  nginx pid file: "/usr/local/nginx/logs/nginx.pid"
  nginx error log file: "/usr/local/nginx/logs/error.log"
  nginx http access log file: "/usr/local/nginx/logs/access.log"
  nginx http client request body temporary files: "client_body_temp"
  nginx http proxy temporary files: "proxy_temp"
  nginx http fastcgi temporary files: "fastcgi_temp"
  nginx http uwsgi temporary files: "uwsgi_temp"
  nginx http scgi temporary files: "scgi_temp"

大丈夫なようだ。configパスなどは上記を参考にしていけば良いのだろうと検討を付けておきながらインストールをする。

$ sudo make
$ sudo make install

入門！ nginxを参考にして、シンボリックリンクを張り機動してみる。

$ sudo ln -s /usr/local/nginx/sbin/nginx /sbin/nginx
$ sudo nginx

サイトで「Welcome to nginx!」の表示を確認できたので起動停止しておく。

$ sudo nginx -s quit

Nginx自動起動スクリプトの作成

サーバーを起動したらnginxも自動起動するように設定ファイルを作成する。
nginxをソースからインストール（＋基本設定）を参考にしてRed Hat Nginx Init Scriptのファイルをベースに機動パスと設定ファイルのパスを変更した。

$ sudo nano /etc/init.d/nginx

Red Hat Nginx Init Scriptをコピー＆ペーストする。

機動パス変更

# NGINX_CONF_FILE="/etc/nginx/nginx.conf"
NGINX_CONF_FILE="/usr/local/nginx/conf/nginx.conf"

設定ファイルのパス変更

# nginx="/usr/sbin/nginx"
nginx="/usr/local/nginx/sbin/nginx"

そして、コチラを参考に起動時設定スクリプトとして登録する。
CentOS用 Nginx起動スクリプト

実行権限を付与する。

$ sudo chmod a+x /etc/init.d/nginx

起動時に実行するスクリプトとして登録する。
ランレベル3と5の時に起動スクリプトを実行する。

$ sudo /sbin/chkconfig --add nginx
$ sudo /sbin/chkconfig --list | grep nginx
nginx          	0:off	1:off	2:off	3:off	4:off	5:off	6:off
$ sudo /sbin/chkconfig --level 35 nginx on
$ sudo /sbin/chkconfig --list | grep nginx
nginx          	0:off	1:off	2:off	3:on	4:off	5:on	6:off

VPSのコントロールパネルで再起動して、サイトで確認すると、「Welcome to nginx!」の表示になっており無事に自動機動の確認できた。

今回はここまで。リバースプロクシとNode.jsアプリの移動は次回行う予定にしている。
./configureオプションでできることあたりの把握がまだできていないので、必要になったときに再インストールしつつ調べようかなと考えている。

32bitか64bitか確認
32bitの場合「i686 i686 i386 」と表示され、64bitの場合はX86_64やamd64となる。

$ uname -a
Linux VPSホスト名 2.6.32-220.7.1.el6.x86_64 #1 
SMP Wed Mar 7 00:52:02 GMT 2012 
x86_64 x86_64 x86_64 GNU/Linux

x86_64なので64bitだった。なので64bit版でリポジトリ登録を行う。

$ sudo nano /etc/yum.repos.d/10gen.repo
[sudo] password for foo: 

[10gen]
name=10gen Repository
baseurl=http://downloads-distro.mongodb.org/repo/redhat/os/x86_64
gpgcheck=0
enabled=1

一度yumでローカルパッケージデータベースをアップデートした後にmongoDBパッケージをインストールする。インストール時に何か聞かれるのでyを押す。

$ sudo yum update
$ sudo yum install mongo-10gen mongo-10gen-server
・・
Total download size: 34 M
Installed size: 82 M
Is this ok [y/N]: y
Downloading Packages:
・・
Installed:  mongo-10gen.x86_64 0:2.0.4-mongodb_1   
            mongo-10gen-server.x86_64 0:2.0.4-mongodb_1                        
Complete!

インストールされたので起動してみる。

$ sudo service mongod start
Starting mongod: forked process: 11763
all output going to: /var/log/mongo/mongod.log
[  OK  ]

ストップして別方法で起動してみる。

$ sudo service mongod stop
Stopping mongod:[  OK  ]
$ sudo /etc/init.d/mongod start
Starting mongod: forked process: 11798
[  OK  ]
all output going to: /var/log/mongo/mongod.log

バージョン確認

$ mongod --version
db version v2.0.4, pdfile version 4.5
Sat May  5 12:44:35 git version: 329f3c47fe8136c03392c8f0e548506cb21f8ebf

chkconfigで起動時に開始するように設定する。

$ sudo chkconfig --add mongod

これもNode.jsに続き慣れた作業だったので楽だった。

nvm (Node Version Manager)
複数バージョンを切り替え

npm (Node Package Manager)
アプリごとの使用パッケージを管理。

基本は以前のエントリと同じだ。
VPS作業メモ[6]-node.js
こちらも、確認のために見ていた。
Node.jsの管理はnvmで
CentOS5.5 に node.js をインストールする

まずはビルドに必要なOpenSSLの開発用パッケージをインストールする。

$ sudo  yum -y install openssl-devel

githubにあるnvmのリポジトリをクローンする。

$ git clone git://github.com/creationix/nvm.git ~/.node
Initialized empty Git repository in /home/sib/.node/.git/
remote: Counting objects: 323, done.
remote: Compressing objects: 100% (182/182), done.
remote: Total 323 (delta 172), reused 273 (delta 133)
Receiving objects: 100% (323/323), 44.90 KiB, done.
Resolving deltas: 100% (172/172), done.

.でシェルスクリプトを実行しインストールする。

$ . ~/.node/nvm.sh

nodeのサイトで最近版のバージョン確認をする。
http://nodejs.org/
今はv0.6.17のようだ。

nvmでnode.jsの最新版をインストールする。

$ nvm install v0.6.17
・・・
Now using node v0.6.17
~/.node/v0.6.17/bin/npm

node、npmそれぞれを確認する。

$ node -v
v0.6.17
$ npm -v
1.1.21

.bashrcにnvmの設定を書いておきいちいち起動しなくても済むようにする。

$ nano ~/.bashrc
. ~/.node/nvm.sh
nvm use v0.6.17

一度離脱して確認

$ exit
$ ssh -p 10022 foo@VPSのIPアドレス
SAKURA Internet [Virtual Private Server SERVICE]
Now using node v0.6.17

大丈夫。

開発系ツールのグローバルインストールをしておく。

$ npm install node-dev -g
$ npm install node-inspector -g

出来上がったアプリを永続化するためにforeverもいれる。
sudoだとエラーが出たのでsuにチェンジしてからインストールした。

$ su
# npm install forever -g

このままだとsudoしたときにnpmが効かなくなるのでvisudoでetc/sudoersを編集して実行ユーザから環境変数を引き継ぐようにする。
新しくなった さくらVPS + nginx + Sinatra でプライベート Gyazo サーバを構築しよう

$ su
# visudo

Defaults    env_reset
Defaults    env_keep =  "COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS"
・・・・
Defaults    env_keep += "PATH"
# 最後にこの一行を追加
・・・・
# Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin
# この一行をコメントアウト

以上でNode.jsのインストールは終りだ。