NginxでリバースプロクシをしているサイトでWebSocket使ったら、なんか変な感じになった
バックエンドで起動しているMojolicious製アプリにNginxのリバースプロクシ経由でアクセスしたら、WebSocketが即切れるようになった。 考えてみたら当たり前だけど、そりゃ実行している場所とアクセス受けてる場所が違ったら、そうなる気がする。
解決方法は、単純にNginxの設定に
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
を書くだけ。serverディレクティブの下に書いていいのか、それともlocationで縛っておいたほうがいいのかはよくわからない。 nginx websocket reverse proxy configuration
仕組み的には、今のセッションを別のプロトコルに変更するヘッダがhttp1.1にあって、それを追加しているらしい。なので、http_versionのディレクティブは必須。これを書き忘れて、しばらく悩んでいた。 Nginxの最新安定版がWebSocketのリバースプロキシに対応したそうなので試してみた
あと、Nginxのバーションも1.4以上である必要がある。（開発版だったら1.3でも行けるらしいけど、いまさら1.3を使う理由は特にないと思う） CentOSだったので、yumにリポジトリ追加してインストール
rpm -ivh http://nginx.org/packages/centos/6/noarch/RPMS/nginx-release-centos-6-0.el6.ngx.noarch.rpm
yum update -y nginx
こんな感じで思いっきりばーんとアップデートかけたら、設定ファイルが飛んだ。ワロス。
実際には飛んだわけではなく、.rpmnewという拡張子がついてバックアップされていたが、それにしばらく気づかず、ブログのトップ画面が “ Welcome to Nginx! “ になって焦りまくっていた。二年前に勢いで作ったVPSとリバプロ構成だったので、全然設定覚えてなかったから助かった……マジでちゃんと構成管理やろう。
ともあれ、こんな感じで無事Nginxのアップデートと、WebSocketのリバースプロクシ対応ができたので、この間作ったWebSocketのサンプルをVPSで動かすことができた。 https://github.com/YasuhiroKinoshita/learn_websocket
今日は勉強会という名のもくもく会に出て、ひたすらWebSocketを使ったWebアプリをコーディングしていた（上のGithubのやつとは別）ので、VPS上で動かせてよかった。
ブロガー探偵になりたい
正確に言うと、ブロガーの助手がいる探偵になりたい
X61をアップグレードするかどうか、さくらクラウドで実験してみた（続報）
改めてdstatで同条件で計測してみたところ、どうやらメモリだけじゃなくてSSDのスピードも相当やばいことがわかった。 なんだこの結果
usr sys idl wai hiq siq| read writ| recv send| in out | int csw
5 1 94 0 0 0| 0 32k| 11k 443k| 0 0 | 420 83
2 1 77 20 0 0| 33M 0 |1356B 37k| 0 0 |1189 2150
7 2 56 35 0 0| 58M 0 |3380B 132k| 0 0 |2143 3771
2 1 86 12 0 0| 18M 0 |3378B 89k| 0 0 | 757 1261
3 1 78 18 0 0| 26M 0 |4077B 131k| 0 0 |1032 1722
5 2 62 31 0 0| 51M 0 |3612B 83k| 0 0 |1855 3315
6 3 54 38 0 0| 61M 0 |3148B 77k| 0 0 |2235 3997
5 2 59 34 0 0| 57M 0 |3247B 103k| 0 0 |2071 3714
5 1 63 32 0 0| 47M 0 |1963B 47k| 0 0 |1708 3057
3 1 90 7 0 0| 10M 0 |5131B 134k| 0 0 | 535 740
7 1 83 9 1 1| 12M 0 |9693B 402k| 0 0 | 803 862
3 1 78 18 0 0| 28M 0 |2745B 50k| 0 0 |1085 1892
7 1 74 18 0 0| 28M 0 |8038B 336k| 0 0 |1282 1846
4 1 81 14 0 0| 21M 0 |3696B 120k| 0 0 | 883 1411
4 1 82 14 0 0| 25M 0 |5269B 167k| 0 0 |1049 1683
4 2 74 21 0 0| 33M 0 |6067B 206k| 0 0 |1300 2149
10 2 50 38 0 0| 64M 0 |6456B 261k| 0 0 |2523 4182
10 1 73 16 0 0| 25M 144k| 12k 515k| 0 0 |1381 1677
X61をアップグレードするかどうか、さくらクラウドで実験してみた
さくらクラウドで、2コア6GのSSDマシンでインスタンス作ってみたところ、同等のDBでほぼクエリが一瞬で流れることが判明。むしろ、受け取ったデータを処理するほうがボトルネックになってた。 やっぱり、メモリの量が問題みたいだ。どうしたもんか。
X61にCentOS6.4を入れてDBサーバーにした
大学生の時に愛用していたX61に、最近とんと触っていなくて寂しくなった。
ので、CentOS6.4を入れて、前々からちょっとずつクラウドで作ってたDBを移植した。しかし、結局SSHで操作するから、あまり触らないことには変わりがなかったが……
ChinachuがTwitterでつぶやいた
Chinachuは、番組の録画が始まると自動でTwitterでつぶやいてくれる機能が有るらしい。
が、開発途中なのかわからないけど、リポジトリのWikiのところでは、まだ項目ができていなかった。 しかし、せっかくその機能があるならば使いたいと思ったので、直接ソースを見て確認してみたところ、上手くつぶやけたのでメモ。
結論だけ言うと、こういう記述をconfig.json内に書けばいいみたいだ。
Chinachuがなんだか変だ
たしかにアニメの方のChinachuも変だったけど、録画サーバーの方のChinachuも少し変だ。
現象としては、昨日の夜のアニメが全部録画できていなかった。 ファイルは作られていたのだが、全部のファイルサイズがアッカリ～ン状態で、 つまり何も録れていなかった。
これはいかんともしがたいので、とりあえずログを見てみると、どうやらチューナーがロックされたままになっていて、解除されること無く録画の時間に到達し、何も出来ないまま終了していたようである。 で、一体どこでロックされたままになったのかというと、同じログをたどっているうちにこんなのが出てきた。
DebianとChinachuで、録画サーバーを再構築した話
家の録画サーバーが不安定になった。
というか、そもそもが専用の録画サーバーというものが存在せず、メインマシンが片手間でやっていたのだが、色々となんかもう限界が訪れていた。 せっかく始まったばかりの2014年冬アニメをしょっぱなからいろいろ見れなかった後悔は大きく、これはもう専用の録画サーバーを作れというお告げだと受け取ることにした。
Chinachu
丁度、冬コミで素晴らしい物を見つけていた。 Chinachuである。Linuxで動く録画サーバーで、しかもオープンソース。 実際にC85のサークルスペースでは、NUCとPT3を使った実機のお手本みたいなものまで置いてあり、既にこの時点で自分の頭のなかには、「専用録画サーバーを作らなきゃ」という意識があった。多分、正月前後で録画マシンが急に不安定になったのは、そんな自分の頭のなかを読まれたのだと思う。
我が家にLEAP MOTIONがやってきた！
実際のところ、お前らはどれだけ草を生やしてるのか調べてみた。
ニコニコ動画のメタデータが公開された。
研究用にニコニコ動画のコメント約300GBを公開
中にはコメントのデータも含まれているので、こいつは格好の遊び……コーパスとして非常に優秀だろうと思って、形態素解析に突っ込む準備をしていた。
その過程で、どこのまとめブログだったか忘れたけど、こんな意見があったのを見た。
どうせ300Gのうちほとんどは「ｗ」とかなんだろうな。
確かに。分からんでも無いくらいお前らは草を生やしている。だが、実際のところはどうなんだろうかと思ったので、実際に数えてみた。