2013-10-18

Nginxのimage filter moduleをchefで

chef nginx

この記事の内容は2013年6月頃にメモしたものです
なんか中途半端な説明になってますがめんどいのでそのまま公開します

これ便利だわーってことで試してみることにした。

image filterの機能を追加するには、 --with-http_image_filter_module 付きでbuildする必要がある。

既存のcookbookでとりあえずソースビルドするように設定するには attributesで以下のように設定するだけでよい。

default[:nginx][:install_method] = 'source'

ただ、opscodeが提供しているcookbookには、 http_image_filter_moduleが含まれていないので、 forkして自分で追加した。

moqada/nginx

パッケージで既にインストール済みの環境にソースビルドで再度インストールを試みる。

nginxを起動しっぱなしでrecipeを実行してもうまくいかない。事前にnginxのプロセスをkillしておかないと、usermodコマンドを実行できないらしい。

事前に /etc/init.d/nginx stop を実行して、再度実行

2013-10-18

tmux上のvimで無駄にboldになったりするやつ

tmux vim

※ この記事の内容は2012年11月頃にメモしたものです。

Solarizedを入れてtmux上でvimを開くとなんかコメントとかが無駄にboldになっていて表示が壊れてしまった

welcome vimrc

素のzshだと何ともないのでtmuxの方の問題っぽいググったらここで議論されていた

https://github.com/altercation/solarized/issues/159

そんで最終的に以下のブログを参考にzshrcを変更した

http://rhnh.net/2011/08/20/vim-and-tmux-on-osx

.zshrc

alias tmux="TERM=xterm-256color tmux"

一旦、screen-256color-bceにしたけど環境によって terminfoに存在しなかったりしたので上記に変更

.tmux.confのほうは元々以下の設定にしてあって、今回ここは変更してない

set-option -g default-terminal xterm-256color

修正後はこんな感じ

すっきり！

2013-10-18

GitLabのsidekiqをプロセス監視して再起動する最低限の設定

gitlab

※ この記事の内容は2013年8月頃?にメモしたものです

GitLabを動かしていると、たまにsidekiqだけ落ちていて post_receive hookとかがちゃんと動かなくなるときが結構あったんで、監視することにした

muninにもプロセス監視用スクリプトはあるみたいだけど、監視方法が ps -C しかないらしく sidekiq だとうまくいかない

なんとなくmonitが簡単そうだったので、こちらを参考にプロセス監視して、落ちたら再起動するようにする

http://shanon-tech.blogspot.jp/2011/11/15monit.html

monitをインストール

yum install monit -y

設定

vim /etc/monit.conf

アラートメールの送信先とアラート送信に使うメールサーバを設定

メールサーバは複数用意した方が安全だけど今回はそんな重要でもないのでひとつ

# recipients for alerts
set alert moqada+monit.gitlab@example.com
# settings mailserver
set mailserver localhost
# settings management server
set httpd port 2812 and
     use address localhost  # only accept connection from localhost
     allow localhost        # allow localhost to connect to the server and

httpdの設定は必須。これを設定しておかないと、監視状態を変更したりするための monit コマンドが利用できなくなる

とりあえず、デフォルトの設定をほぼコピペして、 localhostからのアクセスのみ許可するようにする

sidekiqの監視設定

sidekiqの起動スクリプトを書く

cd .. みたいにディレクトリ移動して云々って書いたら動かなかったのでスクリプト化した uid/gid指定でも動かせるらしいけど、rootでinitに配置しておく

vim /etc/init.d/sidekiq

gitlabの起動スクリプトにも同じような記述があるけど sidekiqのみじゃなくてunicornとか色々まじってるので sidekiqんとこだけ取り出す

APP_ROOT="/home/git/gitlab"

start() {
        cd $APP_ROOT
        sudo -u git -H bash -l -c "bundle exec rake sidekiq:start RAILS_ENV=production"
}

stop() {
        cd $APP_ROOT
        sudo -u git -H bash -l -c "bundle exec rake sidekiq:stop RAILS_ENV=production"
}

case "$1" in
        start)
                start
                ;;
        stop)
                stop
                ;;
        *)
                echo "Usage: sidekiq {start|stop}" >&2
                exit 1
                ;;
esac
exit 0

monitの設定ファイルを書く

vim /etc/monit.d/sidekiq

check process sidekiq with pidfile /home/git/gitlab/tmp/pids/sidekiq.pid  # このpidfileのプロセスを監視
        every 2 cycle  # 60 x 2 秒毎に監視
        start program = "/etc/init.d/sidekiq start" with timeout 90 seconds  # 起動コマンド (90秒でtimeout)
        stop program = "/etc/init.d/sidekiq stop" with timeout 90 seconds    # 停止コマンド (90秒でtimeout)
        if 5 restarts within 5 cycles then unmonitor  # 5回再起動に失敗したら監視をやめる

5.0から with timeout XX seconds オプションが追加されたらしいこれを指定しておかないとデフォルト30秒でtimeoutになってしまうこれ知らなくて、何度やっても、start/stopが失敗してしまってハマった...

http://wiki.niwos.com/linux/applications/monit

※ やっぱ、timeout設定関係なく、stop/start失敗する…原因いったい何…

unmonitorになったserviceの扱い

いったんunimonitorになったサービスはほっとくと二度と監視してくれないらしいこれも知らんなくてハマった…

http://d.hatena.ne.jp/hogem/20090723/1248358467

とりあえずここにあるように定期的にcrontで monit monitor all を叩いておくことに

起動

/etc/init.d/monit start

chkconfig monit on

2013-10-18

Django x gunicorn x supervisor 環境で New Relic を利用する

django

※ この内容は2013年7月にメモしてほったらかしていたものです。なのでちょっと内容が古いかもしれません

AWSで利用している場合は Standard が無料で使えるらしいので、使ってみる。

ちゃんと Python アプリケーション用のライブラリも用意してあるし、ドキュメントの量も結構多いので、よさげな感はある。

New Relic アカウントを取得する

/aws/ とそうじゃないところがあるけど、違いがよくわからない。どっちでとっても同じなんじゃないかと思う。

Python ライブラリを設定する

https://newrelic.com/docs/python/python-agent-quick-start

ほぼここのとおり

pip install

pip install newrelic

iniファイルの生成

supervisor で管理しているプロセスは、 gunicorn と celery の2つなので、2つ分作成してみる

newrelic-admin generate-config LICENSE_KEY PROJECT_DIR/newrelic-celeryd.ini
newrelic-admin generate-config LICENSE_KEY PROJECT_DIR/newrelic-gunicon.ini

iniファイルを編集

app_nameを任意のものに変更する。「;」で区切るとグループとして扱える(？)らしいので、 celeryd と gunicorn で2つの app_name を設定してみることに

celery用

vim PROJECT_DIR/newrelic-celeryd.ini

...
app_name = Awesome App (Celeryd); Awesome App
...

gunicorn用

vim PROJECT_DIR/newrelic-gunicorn.ini

...
app_name = Awesome App (Django); Awesome App
...

テスト

いちおうやっておく

newrelic-admin validate-config PROJECT_DIR/newrelic-celeryd.ini
newrelic-admin validate-config PROJECT_DIR/newrelic-gunicorn.ini

supervisord.confを設定する

supervisorを利用しているので、設定ファイルをいじる

vim PROJECT_DIR/supervisord.conf

command にまんま起動コマンドを記述したら spawnerr: can't find command とかで怒られるので環境変数部分は environment で設定するようにする

newrelic-admin コマンドもフルパスじゃないとうまく起動できなかったので、環境変数に設定して environ 経由で渡すようにする

具体的には /etc/profile.d/<PROJECT_NAME>.sh を設置して、 NEW_RELIC_ADMIN_COMMAND 変数を設定するようにした

/etc/profile.d/<PROJECT_NAME>.sh

export NEW_RELIC_ADMIN_COMMAND=/home/

<PROJECT_DIR>/PROJECT_DIR/supervisord.conf

[program:gunicorn]
command={{ environ.NEW_RELIC_ADMIN_COMMAND }} run-program {{ PYTHON }} {{ PROJECT_DIR }}/manage.py run_gunicorn --bind='unix:{{PROJECT_DIR}}/PROJECT_DIR/tmp/sockets/gunicorn-PROJECT_NAME.sock' --pid={{PROJECT_DIR}}/PROJECT_DIR/tmp/pids/gunicorn-PROJECT_NAME.pid
autostart=true
autorestart=true
redirect_stderr=true
environment=NEW_RELIC_CONFIG_FILE={{PROJECT_DIR}}/PROJECT_NAME/newrelic.ini

[program:celeryd]
command={{ environ.NEW_RELIC_ADMIN_COMMAND }} run-program {{ PYTHON }} {{ PROJECT_DIR }}/manage.py celery worker --pid={{PROJECT_DIR}}/PROJECT_DIR/tmp/pids/celeryd-PROJECT_NAME.pid --logfile={{ PROJECT_DIR }}/PROJECT_DIR/logs/celeryd.log
autostart=true
autorestart=true
redirect_stderr=true
environment=NEW_RELIC_CONFIG_FILE={{PROJECT_DIR}}/PROJECT_DIR/newrelic.ini

[program:autoreload]
exclude=true

[supervisord]
logfile={{ PROJECT_DIR }}/PROJECT_DIR/logs/supervisord.log
pidfile={{PROJECT_DIR}}/PROJECT_DIR/tmp/pids/supervisord-PROJECT_NAME.pid

起動

python manage.py supervisor --config-file=PROJECT_DIR/supervisord.conf -d

その他

環境毎に設定を上書きする

https://newrelic.com/docs/python/python-agent-configuration#agent-configuration-file

素直に設定したままだとステージング環境とかのデータまで混入してしまう。

それを避けるために環境毎の section で上書き設定を定義して、環境変数 NEW_RELIC_ENVICONMENT をセットするようにするといろいろ捗る

例えば、ステージング環境だけ、別の app_name で記録したい場合、前述の newrelic-gunicorn.ini に以下のように追記する

[newrelic:staging]
app_name = Awesome App(Staging) (Django); Awesome App(Staging)

.bash_profile とかに以下を追記

export NEW_RELIC_ENVICONMENT=staging

これでステージング環境で実行される gunicorn プロセスは「Awesome App(Staging) (Django)」として記録されるようになる。

2013-09-04

Composer で依存ライブラリのバージョンがあわないとき

php

問題

依存ライブラリを追加しようと思って composer.json を編集して php composer.phar update を実行したらこんな感じのエラーが出た

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Conclusion: remove yiisoft/yii dev-master
    - yiiext/migrate-command dev-master requires yiisoft/yii 1.1.* -> satisfiable by yiisoft/yii[1.1.14, 1.1.14-rc].
    - yiiext/migrate-command dev-master requires yiisoft/yii 1.1.* -> satisfiable by yiisoft/yii[1.1.14, 1.1.14-rc].
    - Can only install one of: yiisoft/yii[dev-master, 1.1.14].
    - Can only install one of: yiisoft/yii[dev-master, 1.1.14-rc].
    - Installation request for yiisoft/yii dev-master -> satisfiable by yiisoft/yii[dev-master].
    - Installation request for yiiext/migrate-command dev-master -> satisfiable by yiiext/migrate-command[dev-master]

原因

yii-restful と yii-migrate-command ってのを両方使いたかったんだけどそれぞれ composer.json に書いてある yii のバージョン指定が違うらしい。

yii-restful: dev-master
yii-migrate-command: 1.1.*

そんでどっちつかずになってインストールできなくなる模様。

解決

alias を使うと大丈夫だった

Composer

dev-master で master ブランチを指定していた yiisoft/yii を

{
  "require": {
    "php": ">=5.5.0",
    "yiisoft/yii": "dev-master",
    "yiiext/migrate-command": "dev-master",
    "likai/yii-restful": "dev-master"
  }
}

↓ as で 1.1.x ブランチとして扱うように変更する

{
  "require": {
    "php": ">=5.5.0",
    "yiisoft/yii": "dev-master as 1.1.x-dev",
    "yiiext/migrate-command": "dev-master",
    "likai/yii-restful": "dev-master"
  }
}

これで dev-master と 1.1.* を両方満せるようになって解決。