サーバーがたくさんあって、各サーバーにcronがあって、
管理が面倒だなぁと思っていたので、rundeckを検討してみる
■やりたいこと
--------------------------------------
localからremotehostの処理を実行する。
psshの代替になるか？
サービス運営を考えた上の事も考える必要があるから
バックアップも考えないとね。
■現在の環境
--------------------------------------
local(ubuntu)->remotehost(sakura VPS)
■インストール
--------------------------------------
apt-get install openjdk-7-jdk
http://rundeck.org/downloads.html
から、DLしてきてインストール
dpkg -i rundeck-2.6.0-1-GA.deb
おそい。３０分位かかる
■ブラウザアクセス
--------------------------------------
sudo /etc/init.d/rundeckd start
http://localhost:4440
デーモンスタートして、この画面みられるまで１分位かかるね。
自分のPCが遅いんかいな
■rundeck全体の設定
--------------------------------------
/etc/rundeck配下にある
■プロジェクトの作成
--------------------------------------
プロジェクト作ると
/var/rundeck/projects/${project.name}
が作られて、ディレクトリ構造は下記の通り
.
├── acls
└── etc
├── ここに、readme.mdファイルを置くと、トップページにプロジェクトの説明が出るから採用しよう
├── project.properties
└── resources.xml＜= ここに、サーバーの設定を追加するみたい
■実行ユーザーってだれ？
--------------------------------------
idを表示するjobを登録して実行してみたら、
uid=125(rundeck) gid=139(rundeck) groups=139(rundeck)
rundeckユーザーってやつで実行しているんだね
■node（サーバー）の追加(resources.xmlにサーバーを追加)
--------------------------------------
/var/rundeck/projects/XXXXX/etc
＜node name="sakura" description="sakura server node" tags="sakura-www" hostname="hoge.vs.sakura.ne.jp" username="AAAA"/＞
■リモートサーバーを制御する前に鍵を作る
--------------------------------------
ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): id_rsa（ファイル名をid_rsaにする）
Enter passphrase (empty for no passphrase):「パスフレーズなし」
Enter same passphrase again: 「パスフレーズなし」
これで、鍵の作成はOK。
id_rsaとid_rsa.pubができているはずなので、
/var/lib/rundeck/.ssh/配下に２つのファイルを移動する
※パーミッションは変えてあげないとね
.ssh/
合計 16
-rw------- 1 rundeck rundeck 401 10月 17 12:05 id_rsa.pub
-rw------- 1 rundeck rundeck 1675 10月 17 12:05 id_rsa
■対象サーバー（リモートサーバーに公開鍵を置く）
--------------------------------------
先ほど作成したid_rsa.pubをリモートサーバーの.ssh/authorized_keysにおく
rundeckユーザーはリモートサーバーにいないし、rundeckユーザーを作るつもりもない。
対象サーバーには、AAAAユーザーが存在していて、そのユーザーが作成したスクリプトを実行したいわけだから、
対象サーバーのAAAAユーザーの、.ssh/authorized_keysにid_rsa.pubを追加する
というわけで、
localhost(rundeckユーザー）---＞sshで対象サーバーに入れるようになって、コマンドを実行できるようになった。
■resource.xmlの確認
--------------------------------------
sshで入るリモートホストのユーザー名が、resource.xmlのusernameと同じになっているか確認すること
■psshの代替になれるか確認
--------------------------------------
# dispatch -p sample-remote2 -F "tags:sakura-www" -- ls
上記コマンドを実行してみると、下記URLに実行結果が載っている。やばいなこれ、便利すぎる・・・
Succeeded queueing adhoc
Queued Execution ID: 22 ＜http://localhost:4440/execution/show/22＞
# dispatch -p sample-remote2 -F "tags:sakura-www" -f -- ls
上記コマンドを実行すると、画面上に実行結果が入ってくる
■sudoできるの？？
--------------------------------------
# dispatch -p sample-remote2 -F "tags:sakura-www" -f -- "sudo ls"
sorry, you must have a tty to run sudo
だってさ、
リモートホストの、/etc/sudoersの
Defaults requiretty
をコメントにする
再度実行したらできた
■rundeckデーモンが落ちたらどうなるの？？（キューイングされる前編）
--------------------------------------
rundeckは、jobとして、キューイングされて実行されるみたい。
まずは、キューイングされる前に落としてみる
サービス運営上デーモンが落ちる可能性があるので、シミュレーションしてみる
リモートのサーバーにシェルを用意
cat s.sh
#!/bin/bash
sleep 120
echo "success!"
じゃあ検証
sudo dispatch -p sample-remote2 -F "name:sakura" -f -- "./s.sh"
を実行して、もうひとつのターミナルで、
sudo /etc/init.d/rundeckd stop
sudo dispatch -p sample-remote2 -F "name:sakura" -f -- "./s.sh"
error: Error making server request to http://localhost:4440: 接続を拒否されました
ってでた。
sudo /etc/init.d/rundeckd startしてみる。そもそも、キューに登録されていない
■rundeckデーモンが落ちたらどうなるの？？（キューイングされた後編）
--------------------------------------
今度は、jobとして、キューイングされたあとに同じことやってみる
sudo dispatch -p sample-remote2 -F "name:sakura" -f -- "./s.sh"
Succeeded queueing adhoc
Queued Execution ID: 33 ＜http://localhost:4440/execution/show/33＞
error: Error making server request to http://localhost:4440: 接続を拒否されました
33番どうなったかな・・・
killedになってる。なるほどー、rundeck落ちたら、ダメなんだ。んーーー考えもんだ
■rundeckデーモンが落ちたらどうなるの？？（jobとして登録してみる編）
--------------------------------------
今度は、jobとして、キューイングされたあとに同じことやってみる
今までは、dispatchコマンドでやってみていたけど、今度は、jobとして、rundeckに登録して
スケジュールを組んでやってみる
さてさて・・・
だめだ、killedになって なる。そうかぁ・・・そりゃそうか。
結局、このrundeckサーバーが落ちるといろいろやばいというのがわかった
バックアップは課題だな
■job登録のオプションを調べてみる
--------------------------------------
なんか、いろいろできるんだね
optionname:message
allowed values:listを選択してopt1,opt2,opt3
とかにして、
ワークフローに
./test.sh ${option.message}
とかやると、オプションが渡せる。
選択式だから事故が少ない
■jobの登録とエラーハンドリング
--------------------------------------
phpがこけてもちゃんとstatas failになってくれるね
エラーをキャッチして、何かコマンドを実行するような想定で作ってみよう
Stop at the failed step.
Node-oriented
execute repomote command に、hoge.phpを入力(このphpはこける）
error handler に、エラーが発生したら作動スクリプトを書く。
これで、エラーを検知してログ出力とか、なんかできるね
※エラー発生時のメール配信は、Send Notificationを使えばできる
オプション使い回ししたいなー。できなそうだ
■ユーザー登録
--------------------------------------
このツールたくさん使う人がいることが想定されるので、
だれが設定したかを認識するために、ユーザーを追加する必要がある
#java -cp /var/lib/rundeck/bootstrap/jetty-all-7.6.0.v20120127.jar org.eclipse.jetty.util.security.Password ユーザー名 パスワード
OBF:xxxx
MD5:xxxxxxx
CRYPT:xxxxx
って出てきたから、
vi /etc/rundeck/realm.propertiesで
ユーザー名:MD5:XXXX,user,admin
で入れる
なんか、ユーザーをグルーピングしたら、アクセスコントロールとか設定が
できるみたい。
http://rundeck.org/docs/man5/aclpolicy.html
に書いてあるけど、ちょっと面倒になったのでスキップ。
adminユーザーがフルコントロールなのは、
/etc/rundeck/admin.aclpolicy
に定義があるため
とりあえず、誰が実行したかがわかるからこれでいいや
■バックアップと復元
--------------------------------------
サーバー飛ぶかもしれないし、別サーバーにすぐ同じ環境を再現しなくてはならない
なので、設定一式をどこかに格納する方法を確認しておく
右上のネジボタンのところから、
Setup SCM Plugin: Git Exportのところで、リモートリポジトリを指定してみる。
リポジトリをこれにする：
https://github.com/XXXXXXX/test.git
これでgitの環境下に設定が入るけど、ただし、jobだけ。
nodesの情報は入ってこない。
resource.xmlも対象にしたほうがいいよなぁ
jobを追加すると、自動で、
/var/rundeck/projects/${プロジェクト名}/scm
配下に置かれる
これを、rundeckのjobで定期的に、push origin masterでセットしておけば、githubのリモートリポジトリに格納される。
復元もここからやれば良いのか。なるほどね。これで行けそうな気がする
※コメント投稿者のブログIDはブログ作成者のみに通知されます