ラベル Linux の投稿を表示しています。 すべての投稿を表示
ラベル Linux の投稿を表示しています。 すべての投稿を表示

2017年7月17日月曜日

1つのサーバに2つのrailsアプリを共存させる方法

個人で作成しているKindleセール本まとめサイトで、railsアプリを1サーバに共存させる必要が出てきたのでその方法。

概要

http://kinsume.infoにアクセスした時はrails5.0.1のアプリに飛ばして、http://kinsume.info/kinsume_blogにアクセスされた時は、rails4.2.7のアプリに飛ばしたい。
kinsume_blogで動くアプリはオープンソースのCMS refinery-cmsを使用したかったのだが、rails4.x系にしか対応していなかったので、苦肉の策ではある。

環境はUbuntu, Nginx, Unicorn。

手順

まず、すでに動いているrails5.x系, ruby 2.3.xの環境には影響を与えたくなかったので、ruby 2.2.7をインストールして、ruby周りの環境を整える。


cd ~/repos/kinsume_blog
rbenv local install 2.2.7
gem install bundler
bundle install

Unicornの設定ファイルを作成

新しく設定したいアプリの下で、vim config/unicorn.rbでファイルを新規作成。


app_path = File.expand_path(File.dirname(__FILE__) + '/..')$
$
# workerをいくつ立ち上げるか。ここではCMSであまりアクセスないことを$
# 想定していて、メモリの空きもないので1にしている。$
worker_processes 1$
$
# どのソケットで連携するかNginxの設定ファイルにも書くので覚えておく$
listen app_path + '/tmp/kinsume_blog.sock', backlog: 64$
timeout 300$
working_directory app_path$
$
# この辺もすでに動いているアプリと被らないようにする$
pid app_path + '/tmp/kinsume_blog.pid'$
stderr_path app_path + '/log/kinsume_blog.log'$
stdout_path app_path + '/log/kinsume_blog.log'$
$
preload_app true$
$
GC.respond_to?(:copy_on_write_friendly=) &&$
GC.copy_on_write_friendly = true$
$
before_fork do |server, worker|$
defined?(ActiveRecord::Base) &&$
ActiveRecord::Base.connection.disconnect!$
end$
$
after_fork do |server, worker|$
defined?(ActiveRecord::Base) &&$
ActiveRecord::Base.establish_connection$
end$

railsアプリのルートパスを変える。refinery-cmsのパスを変えるには下記ファイルを変更。

vim config/initializers/refinery/core.rb


  # Specify a different Refinery::Core::Engine mount path than the default of "/".$
  # Make sure you clear the `tmp/cache` directory after changing this setting.$
  config.mounted_path = "/kinsume_blog"$


わかりやすくなるように、静的ファイルのパスを元のアプリと変える。

vim config/environments/production.rb


  config.assets.prefix = '/static'$

Nginxの設定ファイルは以下


upstream tagosaku{$
    server unix:/home/ishioka/repos/tagosaku/tmp/tagosaku.sock fail_timeout=0;$
}$

# 先ほど作成したアプリのソケットファイルをここで指定
upstream kinsume_blog{$
    server unix:/home/ishioka/repos/kinsume_blog/tmp/kinsume_blog.sock fail_timeout=0;$
}$
$
server {$
  error_log /var/log/nginx/error.log debug;$
  listen 80;$
$
  root /home/ishioka/repos/tagosaku;$
  index index.html index.htm;$
$
  keepalive_timeout 300;$
  client_max_body_size 4G;$

 # kinsume_blogないで使っているgemから走るアクセスパスをどうしても変えられなかったので悲しみのrewriteで対応
  rewrite ^/wymiframe$ /kinsume_blog/wymiframe last;$
$
  # ここでもkinsume_blogないのgemから走るアクセスを変えられなかったので、いったんassetsを見てふぁいるがなければ/static/を見に行くように変更
  location ~ ^/assets/(.*) {$
    root /home/ishioka/repos/tagosaku/public/;$
    try_files $uri /static/$1 =404;$
  }$
$
 # staticへのアクセスはkinsume_blogの静的ファイルへのアクセスなのでロケーションを変更
  location /static/ {$
    root /home/ishioka/repos/kinsume_blog/public/;$
  }$

  location / {$
    # First attempt to serve request as file, then$
    # as directory, then fall back to displaying a 404.$
    #try_files $uri $uri/ =404;$
$
    # Uncomment to enable naxsi on this location$
    # include /etc/nginx/naxsi.rules$
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;$
    proxy_set_header Host $http_host;$
    proxy_set_header X-Forwarded_Proto $scheme;$
    proxy_redirect off;$
$
    # This passes requests to unicorn, as defined in /etc/nginx/nginx.conf$
    proxy_set_header Host $http_host;$
    proxy_pass http://tagosaku;$
    proxy_read_timeout 300s;$
    proxy_send_timeout 300s;$
  }$
$
  location /kinsume_blog {$
    # First attempt to serve request as file, then$
    # as directory, then fall back to displaying a 404.$
    #try_files $uri $uri/ =404;$
$
    # Uncomment to enable naxsi on this location$
    # include /etc/nginx/naxsi.rules$
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;$
    proxy_set_header Host $http_host;$
    proxy_set_header X-Forwarded_Proto $scheme;$
    proxy_redirect off;$
$
    # This passes requests to unicorn, as defined in /etc/nginx/nginx.conf$
    proxy_set_header Host $http_host;$
    proxy_pass http://kinsume_blog;$
    proxy_read_timeout 300s;$
    proxy_send_timeout 300s;$
  }$
$
  error_page 500 502 503 504 /500.html;$
$
  location = /500.html {$
    root /home/ishioka/repos/tagosaku/public;$
  }$
}


refinery-cmsのpluginからリクエストされる静的ファイルのパスを/から/kinsume_blogへ変更することができなかったので、nginxのrewriteを駆使して対応。 

あまりアクセスパスを変更されることを想定されてない作りっぽいので、PR出していきたい。





2017年4月10日月曜日

Ubuntuスクレイピングサーバの構築

なんかしらの価値ある情報サービスを提供するばあい、

  1. 自分でコンテンツを作成する
  2. コンテンツを集めて加工する
  3. ユーザがコンテンツを提供するフラットフォームを提供

のどれかの手段を取る必要があるが、今回作成したキンドルセール情報の検索サイトは「2」なので、スクレイピングして情報を集めることにした。

結構この手段を使うひとはいると思うので、構築手順を書いておく。

スクレイピングサーバ構築手順

node.js install
 sudo apt-get install nodejs
ruby install
apt install rbenv ruby-build
git clone https://github.com/sstephenson/rbenv.git ~/.rbenv
git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build
sudo apt-get install -y autoconf bison build-essential libssl-dev libyaml-dev libreadline6-dev zlib1g-dev libncurses5-dev libffi-dev libgdbm3 libgdbm-dev ruby-dev  libmysqlclient-dev
mkdir -p "$(rbenv root)/plugins"
git clone https://github.com/rkh/rbenv-update.git "$(rbenv root)/plugins/rbenv-update"
rbenv install 2.3.1 
ruby project deploy
git clone xxxxxxx
sudo apt install ruby-bundler
bundle install
ブラウザ動作環境を整える
chromium install
sudo apt-get install chromium-browser
sudo apt-get install xvfb
chrome-driver install
wget https://chromedriver.storage.googleapis.com/2.26/chromedriver_linux64.zip
unzip chromedriver_linux64.zip
cp chromedriver ~/.rbenv/versions/2.3.1/bin
~/.bash.rcに追加
# rbenv
export PATH="$HOME/.rbenv/bin:$PATH"
eval "$(rbenv init -)"
nohup Xvfb :99 -ac -screen 0 1024x768x8 &
export DISPLAY=":99" 

のちにAnsibleで書いて自動化する気持だけは強くもっている。




2013年11月3日日曜日

HipHop for PHP 調査

Facebook のエンジニアが開発したオープンソースソフトウェアである、「HipHop for PHP」について調査した。

情報源

Wikipedia
hhvm blog

Wikipediaの情報

  • PHPの実行エンジンで、速度を上げるために作られた。
  • サーバのリソース削減のために作られた。
  • Zend PHPとの高い互換性をめざしている。
  • HPHPcはPHPをC++に変換するコンパイラー
  • ピークではZend PHP x6のパフォーマンスがでた。
  • PHPでインタラクティブにデバッグできるHipHop debugerがある。
  • HPHPcは成功した、特にFacebookで。
  • しかし、Facebookは2013年に廃止予定だ。
  • 理由は、パフォーマンスの向上が頭打ちになったこと、完全な互換性がないことなど。
  • それらの問題を解決するために、PHP virtual machineの開発を決めた。HipHop Virtual Machine(HHVM)
  • PHPを高水準のバイトコードに変更する。
  • そのバイトコードは実行時にJITコンパイラーによって、x64機械語に翻訳される。
  • JavaのJVMみたいなもの。
  • ほとんどPHP5.4をサポートする。
  • パフォーマンスではHPHPcと同等の性能がでた。

hhvm blogの情報

  • 有名なDistoributionにはパッケージングされている
  • CakePHPのUnitテストは動かない。※Stringという名前のClassが許されない
  • CodeIgniterのテストは19%はfail
  • Drupalは2%fail, Facebook SDKは100%成功
  • どれが完全に動くかは明確
  • 6-12 monthの計画として、ドキュメントの充実、簡単なインストール等を目指している



2013年10月31日木曜日

Flashcache 調査

Facebookの作成したLinux cacheシステムであるFlashhcacheについて、調べているので調査結果を。

まずは英語で情報収集を行った。


  • 2010年に作成され、日々更新されている。
  • MySQLのカンファレンスで、DBサーバに対して使用していると発表。
  • 遅いメディアへの読み込み、書き込みをSSDなどの早いメディアにキャッシュするシステム。
  • MYSQLをスケールさせるために作った。
  • Linux Device Mapperを使っている。
  • NAND memory devicesにHDDの情報をキャッシュさせる。
  •  random IOのみをキャッシュさせ、sequential IOは無視する設定もできる。
  • version 3系では、パフォーマンスが上昇し、average hit rateが60%から80%、ディスクIOが半減した。



参考
Flashcache at Facebook: From 2010 to 2013 and beyond

2013年6月25日火曜日

Memcache のSlab Reassign, Slab Automoveについて

Memcache1.4.5を使用しているのだが、アプリケーションにとって不都合な点がでている・・・
具体的に言うと、メモリは余裕があるのに、Evictionが発生してしまっているのだ。
検索したところ、ちょいと記事が古いがMemcachedのメモリ使用方法について詳しいものを見つけた。

これらを見ると一度確保されたチャンクのページは、他のチャンクに割り振られることがないので、最初に容量を確保されてしまったら、開放されることがない模様。

しかし、 version 1.4.11からは「Slab Reassign」、「Slab Automove」と言う、使っていないチャンクのページを、頻繁に使っているチャンクに割り振り直す機能があるようなので、公式ページを見てみた。

以下要約

Slab Reassign

 

 長い間稼働しているmemcahedインスタンスは、すべての利用可能なメモリが特定のスラブクラスに割り当てられている問題に直面するかもしれない。
100バイトのリクエストがたくさんあり、その後200バイトのリクエストが、異なるチャンクに保存された。その場合Memcachedは100バイトのチャンクを使うことができず、200バイトのデータは少ししか保持できない。

 1.4.11はスラブページを再割り当てする機能をもつ。 この機能、コマンドはベータです。近々のリリースで変わるかもしれません。覚えておいてください。コマンドが確定したとき、リリースノートにかかれるでしょう。

Slab Reassignを有効にするには、スタート時に以下オプションをつける必要がある。
$memcached -o slab_reassign
一度すべてのメモリが割り当てられてしまった場合は、以下コマンドでリアサインできる。

$ echo "slabs reassign 1 4" | nc localhost 11211
それは成功を表すエラーコードを返す、または後でリトライするひつようがある。
成功はスラブが移動したことを意味してはない。しかし、 バックグラウンドスレッドがメモリ移動を試みることを意味している。


Slab Automove

slab reassignは手動実行の機能である。Slab Automoveは自動できに実行されるアルゴリズムだ。
$ memcached -o slab_reassign, slab_automove
 上記はスタートアップ時に有効にする。slab_automoveは slab_reassignが最初に有効になっていなければならない。

automoveは起動中にも変更可能
$ echo "slabs automove 0" | nc localhost 11211
 このアルゴリズムは遅くて、古くさい。10秒のあいだに3回Evictionが発生すると、30秒の間Evictionが発生していないスラブクラスからページを移動させる。このアルゴリズムは十分出ないです。コミュニティを助けてください!改修したらパッチを送ってください!

Slab Reassign Implementation

スラブページのリアサインはトレードオフがある。
  • 500kより大きなすべてのアイテムが、1MBのスペースをとる。
  • メモリをリアサインしたとき、 1MBのページにいたすべてのアイテムは追い出される。
  • スラブリアサインが有効な時、追加のバックグラウンドスレッドが使われる。 
1つめのものは、のちのバージョンで改修される。そして、 -o slab_reassignオプションをつけなければ回避されます。


ふむふむ。あまり洗練された機能ではなさそうだな。
先のバージョンで改修があるかもしれないので、見てみよう。
1.4.14 で機能に改修があるのを見つけた。以下要約。

slabs reassign -1 15と与えると、どこかのスラブから、クラス15に対してページが移動される。

slabs automoveはアグレッシブなページリアサインアルゴリズムになった。
追い出し発生後とに、移動ができるか試みる。あなたが何が起こっているか本当に理解していないと、決して動かすべきでない。ほとんどの人は、ヒットレートがさがる。
緊急時には使える。

警告します。


結論

緊急時意外使わない方がいいのでは。