CloudForecastをDaemontoolsの管理下におく
ようやくCloudForecastをDaemontoolsで管理する話です。
このへんからFedora15だとうまく行かないことが多くなってきたので、調べるよりもCentOSやScientific Linuxでやった方が良さそうなので、そちらに環境を移します。(本当はちゃんと調べたほうがいいんだろうけど)
ここからは、KVM上のCentOS 6 (x86_64) になります。
daemontools のインストール
ソースから入れてもそれほど苦にはならないが、パッケージ管理できていたほうが色々と都合が良いのでRPMからインストールします。
# wget http://www6.atomicorp.com/channels/atomic/centos/6/x86_64/RPMS/daemontools-0.76-1.el6.art.x86_64.rpm # rpm -ivh daemontools-0.76-1.el6.art.x86_64.rpm
前のエントリでも書いたが、CentOS6からはUpstartが採用されており、従来のinittabを利用したsvscanの管理ができなくなっている。そのため、以下のようにして、対応する。
- /etc/init/svscan.confを作成
start on runlevel [12345] respawn exec /command/svscanboot
- 作成したsvscan.confを読み込ませて、実行する。
# initctl reload-configuration # initctl start svscan
これで、daemontoolsの管理プロセスであるsvscanが起動する。
CloudForecastのradarプロセスとwebプロセスをdaemontoolsの管理下に置く
/servive 以下に配置するrunスクリプトなどの雛形を毎回手で作成するのは面倒なので、[twitter:@hansode] さんのaddsv.sh*1を利用させていただく。hansode++
# cd /service # ./addsv.sh cf_radar # ./addsv.sh cf_web # vi ./cf_radar/run # vi ./cf_web/run # mv .cf_radar cf_radar # mv .cf_web cf_web
以上でrunスクリプトに指定したコマンドが実行されて、無事CloudForecastのradarプロセスとwebプロセスが起動する。"-r"オプションをつけていてファイルが変更されるたびにプロセスが停止するのを、こいつが再起動してくれます。これで安心して運用できますね。
それぞれのrunスクリプトはこんな感じ。"sleep 3" はaddsv.shのひな形のままなのですが、特に検証してはいません。
- cf_radar/run
#!/bin/sh PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin export PATH CF_DIR=/opt/cloudforecast CF_CONF=${CF_DIR}/cloudforecast.yaml CF_SERVER_LIST=${CF_DIR}/server_list.yaml exec 2>&1 sleep 3 ${CF_DIR}/cloudforecast_radar -r -c ${CF_CONF} -l ${CF_SERVER_LIST}
- cf_web/run
#!/bin/sh PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin export PATH CF_DIR=/opt/cloudforecast CF_CONF=${CF_DIR}/cloudforecast.yaml CF_SERVER_LIST=${CF_DIR}/server_list.yaml CF_WEB_PORT=5000 exec 2>&1 sleep 3 ${CF_DIR}/cloudforecast_web -r -c ${CF_CONF} -l ${CF_SERVER_LIST} -p ${CF_WEB_PORT}
CentOS6でdaemontoolsを使う
以前の予告でCloudForecastをdaemontoolsの管理下において使う方法を書く！と言っておきながらだいぶあいてしまいました。理由は、CentOS6でdaemontoolsを動かすのに苦労して、ちょっと投げ出し気味になっていたからです。
そんな私にもようやく春が訪れ、無事に（？）daemontoolsを動かすことが出来ました！
CentOS6(というよりRHEL6)からはSysvinitからUpstartにかわっており、従来通りの /etc/inittab に管理プロセスの respawn 指定をしておくことができなくなりました。そこで、ここ（ CentOS6にdaemontoolsをインストールするとそのままでは自動起動しない。 | 技術系メモ
）を参考にさせてもらったのですが、なぜか起動してくれない。。。
インフラエンジニアのくせに全くログを見ようとしていなかった私、、、本当にダメですね。まずログを見よ。
という訳で、ログを見てみると
init: svscan main process (3573) terminated with status 126
exit code 126。。。ファイルが実行できませんという事らしい。（参照: シェルリファレンス）
なぜ？シェルから直接実行すれば問題ないのに、なぜ実行できないのか。daemontools の /comand 以下にあるコマンドはすべてシンボリックリンクになっている。これがなにか影響しているのではなかろうかと思って、リンク先のコマンドを直接指定するようにしたら、問題なく動作しました。
うーん、本当にこれでいいのか？（実はEnfoecingのままにしてあるSELinuxのせいだったるするのかな。）
という訳で、いまのところ /etc/init/svscan.conf に設定してあるのは、以下の通り。
start on runlevel [12345] respawn exec /usr/bin/svscanboot
※あとで、SELinuxをDisabledにした場合にシンボリックリンクでも動作するかも確認する
上記設定後、以下のコマンドを実行すればOSの再起動をせずとも起動できる。
# initctl reload-configuration # initctl start svscan
これにて無事にdaemontoolsを動かすことが出来ました。
次はようやく、CloudForecast を daemontools の管理下で動作させる方法です。
(即追記)
/command/svscanboot を指定した場合に、実行できないエラーが出ていたのはやはりSELinuxが起因していました。本当はちゃんと原因を調べて対応できるようにならないとダメなのですが、今回は目的から外れるのでDisabledにすることで対応しました。
その他、SELinuxが有効になっていると、multilogのあたりでもエラーが出て、サービスが起動しないといったことも発生するので、SELinuxを使いこなせるレベルではない私のような低レベルエンジニアは素直にDisabledにするのがいいでしょう。
gitweb + Nginx を使ってgitリポジトリをWEBで見られるようにする
今回参考にしたのは、こちらのサイト。
パッケージのインストール
CentOSでnginxをyumを使ってインストールする場合には、nginxのyumリポジトリを追加しておく必要がある。
vi /etc/yum.repos.d/nginx.repo [nginx] name=nginx repo baseurl=http://nginx.org/packages/centos/$releasever/$basearch/ gpgcheck=0 enabled=0
私は、デフォルト以外のリポジトリはenabled=0にしておく人なので、0にしているがnginxレポだけであれば、変更しなくてもいいと思う。
gitweb と nginx をインストールする。
# yum install gitweb nginx --enablrepo=nginx
gitweb の設定
/etc/gitweb.conf を編集する。
our $projectroot = "/home/git/repositories";
nginx と FastCGIを連携するための設定をする
# yum install spawn-fcgi perl-FCGI perl-FCGI-ProcManager --enablerepo=epel
nginx から fastcgi で動かしたgitweb にアクセスできるように/etc/nginx/conf.d/gitweb.conf に設定する。
server {
listen *:80;
root /var/www/git;
index gitweb.cgi;
server_name gitweb.example.net;
location ~ gitweb\.cgi$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index gitweb.cgi;
include fastcgi_params;
}
}
nginx を起動する。
# service nginx start
gitwebをFastCGIで動かす
gitweb.fcgi を 下記サイトから頂いてくる。
内容はこんな感じで、今回は /home/git/bin/gitweb.fcgi に配置してみた。
#!/usr/bin/perl -w use strict; use FCGI; use CGI; use Getopt::Long qw/:config gnu_getopt no_ignore_case auto_abbrev/; sub usage { print STDERR "$0 --fcgi-socket=(path|[host]:port) ", "--cgi-bin=path\n"; exit 1; } my ($fcgi_sock, $cgi_bin); GetOptions('fcgi-socket|s=s' => \$fcgi_sock, 'cgi-bin|c=s' => \$cgi_bin) or usage(); usage() unless ($fcgi_sock && $cgi_bin); die "FastCGI socket: $fcgi_sock already exists!\n" if (-S $fcgi_sock); die "CGI executable: $cgi_bin does not exist!\n" if (!-f $cgi_bin); # gitweb will exit, make it throw an exception instead: no warnings qw/once/; *CORE::GLOBAL::exit = sub { die 'gitweb_exit' }; use warnings; # FCGI will erase the current %ENV; so make sure we save this: my $gwcfg = $ENV{GITWEB_CONFIG}; my $fcgi_req = FCGI::Request(\*STDIN, \*STDOUT, \*STDERR, \%ENV, FCGI::OpenSocket($fcgi_sock, 128), FCGI::FAIL_ACCEPT_ON_INTR); while ($fcgi_req->Accept >= 0) { unless ($ENV{PATH_INFO}) { # nginx currently fails to set PATH_INFO, # so we'll do it ourselves my $pi = $ENV{SCRIPT_NAME}; $pi =~ s!^/\+!!; $ENV{PATH_INFO} = $pi; } # clear CGI query parameters set inside gitweb so we can reparse # the %ENV fed to us CGI::initialize_globals(); $ENV{GITWEB_CONFIG} = $gwcfg if defined $gwcfg; do $cgi_bin; delete $ENV{PATH_INFO}; } END { unlink $fcgi_sock if (defined $fcgi_sock && -S $fcgi_sock); }
/var/www/git/gitweb.cgi を編集する(該当箇所のみ)。
our $projectroot = "/home/git/repositories";
fastcgiでgitwebを動かす。
# sudo -u git /home/git/bin/gitweb.fcgi --fcgi-socket=127.0.0.1:9000 --cgi-bin=/var/www/git/gitweb.cgi &
これでブラウザからアクセスすれば、gitwebが確認できる。
ただ、参照したサイトにも書いてあるとおり、redifine のエラーが出る。これについては、後でちゃんと調べる。
gitのインストールと設定
毎度毎度ネタがバラバラなのは、その時の興味が移り変わり過ぎるから？ｗ
というわけで、今回はgitネタです。仕事でgitのリポジトリを公開する設定をしてみたはいいけど、いかんせん自分がgitを使ったことがなく、動作確認を他の人に頼らなくてはいけないということが発生して
非常に面倒だったのです。今後はそんなことがないようにも、インフラ周りの設定ファイルやらスクリプトやらをgitで管理できるように、ちゃんと使い方を覚えたいと思います。
今まではどうしていたかって？本番サーバとテストサーバにおいてあるだけ。いい時はファイルサーバにバックアップをおいてあるくらいという体たらくぶり。これはさすがにまずいので、重い腰を上げます。
gitのインストール〜設定まで
環境はいつもの通りノートPC上のFedora15といきたいところだが、実践で役立つようにKVM上のCentOS6にしておく。公開するために、gitolite *1 を使ってリポジトリを作成＆管理するようにします。CentOS5系の時はgitのインストールにrpmforgeやepelを使わなければインストールできなかったが、CentOS6はデフォルトのリポジトリからインストールできる。
- とりあえず git をインストール
# yum install git
-
- gitolite 自体が git で管理されているため
- gitolite 用ユーザの作成とPATHの設定
# useradd git # su - git $ vi .bashrc 以下を追記 PATH=$HOME/bin:$PATH $ source .bashrc
$ ssh-keygen -t rsa -f .ssh/id_rsa_git $ cp .ssh/id_rsa_git /tmp/git-admin.pub
-
- ここで作るのは、上で作った "gitolite用ユーザ ではなく、"gitolite 管理下ユーザ" の鍵となる(gitolite用ユーザのでもあるんだけど)。
- gitoliteのセットアップ時に指定をして適切なパスにコピーされるので、今の段階では /tmp コピーしておく。最初に作るのは管理者ユーザのものとする(UserName.pubとなるようにする)。
- gitolite のインストール〜管理者ユーザをアクセスできるようにするまで
$ git clone git://github.com/sitaramc/gitlite $ cd gitolite $ ./src/gl-system-install $ gl-setup /tmp/git-admin.pub|
-
- gl-setup実行直後に設定ファイルの編集ができるが、ひとまずそのままにしておく
- これだけで完了
- セットアップ完了後の gitolite用ユーザの .ssh.authorized_keys の中身
# gitolite start command="/home/git/bin/gl-auth-command git-admin",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa ... # gitolite end
-
- このようにして、OSのユーザとは別のユーザの認証を実現しているのですね
ユーザの追加とリポジトリの追加
ユーザの追加やリポジトリの追加、リポジトリの設定もすべて git 経由で行う。作成された gitolite-admin リポジトリをクライアントマシンから git-clone -> 変更 -> git-add -> git-commit -> git-push という手順を取れば変更が反映される。ステキ！
$ git clone git@git-server:gitolite-admin $ cd gitolite-admin $ vi conf/gitolite.conf ＞＞ 以下を追記することで、test-proj リポジトリの作成と、hoge ユーザの作成をする repo test-proj RW+ = git-admin RW = hoge ＜＜ $ cat pub_key_hoge > keydir/hoge.pub # hogeユーザの公開鍵を設定 $ git add . $ git commit $ git push
あとは追加したhogeユーザでtest-projへのアクセスが出来るかどうかを確認すればOK。すごく簡単ですね。
今後は、git-webやリポジトリをHTTP(S)で公開する方法も書きたいと思います。
*1:http://progit.org/book/ja/ch4-8.html gitのアクセス制御をより細やかにできるようにする
CloudForecastの続き
設定ファイルを変更してもちゃんと再起動しない
これは -r オプションをつけている場合に、本来であればSIGTERMを受け取って停止して、設定ファイルを読んで起動するはずなのだが、SIGTERMを受け取ったきり音沙汰がなくなる。
であれば、ちゃんと調べられるまでは -r オプションをやめてしまう。そうすれば、とりあえずは設定ファイルを変更したときに知らぬ間に監視が止まっているなんてこともなくなる。
こうなってくると、ますますinitスクリプトが欲しくなる。だが、どこにも落ちていなさそう。(ぉぃ
再起動してくれない原因とinitスクリプトのどっちを先にやろうかなっと、、、
再起動しないのはなぜ？
@kazeburoさんのYAPC::Asia::2010の資料をよく見てみると、 -r オプションは「停止」と書かれており、daemontoolsでプロセス管理をすると書かれている。
ん？
どういうこと？READMEでは「再起動オプション」と記されていますが、、、実は停止のみ？ソース上もシグナルを受け取って停止をする処理はあったけど、起動処理はなかったような。。。
下手に再起動してくれることを願って、-rオプションの挙動を探るよりは、素直に-rオプション+daemontoolsでプロセスが停止したら起動するようにしておくほうが利口そうですね。
手順までまとめようかと思ったが、眠気に襲われているので、今日はこのへんにして、また続きを書くことにします。
次回予告
- cloudforecatのプロセスをdaemontoolsで管理する
