スピーカー
@morihaya55 さん
スライド
Slideshare
https://www.slideshare.net/ssuser1f3c12/cronrundeck
前提条件
CentOSを基本とした内容です。
cronの辛みと、辛み解消のRundeckの紹介
勉強会の目的
- ジョブ管理って大変
- 引き継いだシステムがcronしか利用していなくて、”crontab -l”の表示が1000行を超えるものだったらなおさら!
- そんな痛みを避ける手段の1つを覚えましょう
ジョブとは
- 何らかのひとまとまりの処理
- 実態はスクリプトファイルや、バッチファイルが多い
- 会話では「バックアップジョブ」とか「レポートジョブ」「集計ジョブ」とか、気軽に「XXジョブ」という言い方をする
ジョブ管理とは
- 必要に応じて、特定の日時に、特定のジョブが実行される状態を維持すること。以下みたいな感じ
- 毎日AM3:00にDBのバックアップを取得
- 月初(1日)の09:30に先月分の売り上げレポートを作成
- 5の付く日にキャンペーンを行うので、キャンペーン開始日の0:00にメール送信
Cronとは
- Linux標準のジョブスケジューラ
- Windowsでいうタスクスケジューラの機能
- 実行日時の書式は初見殺し
- でも慣れるとこれ以外にない気がしてくるほど便利
書式は以下の通り。1行=1ジョブ
分 時 日 月 曜日 実行コマンド
大抵のジョブはCronで十分。
Cronの設定例
- 毎日AM3:00に、DBのバックアップを取得
0 3 * * * /home/opt/bin/get_db_backup.sh
- 月初(1日)の09:30に先月分の売り上げレポートを作成
30 9 1 * * /home/opt/bin/create_monthly_report.sh
- 5の付く日にキャンペーンを行うので、キャンペーン開始日の0:00にメール送信
0 0 5,15,25 * * /home/opt/bin/send_mail_5dayevent.sh
※コンマで区切ることで複数指定可能
Cronを使うためには
- crontab -e コマンドで追記する
- /var/spool/cron/ユーザ名のファイルが生成される
- /etc/crontabに追記する
- /etc/cron.d/配下へ、書式で書いたファイルを配置する
- /etc/cron.dailyといったところへファイルを配置する。
- 各ディレクトリに配置されたファイルを/etc/anacronがランダムな時間を付与して実行してくれる。
Cronのここがすごい
- OS標準である
- 必ず使えるという安心感
- 設定が簡単
- 書式に慣れれば、さくさくジョブがかける
Cronのココが辛い
- ログが出ない
- エラーハンドリングが難しい
- サーバ単体で完結してしまう
Cronの辛み1 ログが出ない
- /var/log/cronへ、「cronで実行した」というログしか出ない。
(MAILTTO設定をすればメールで飛ばせるが、ディスクがいっぱいになるから基本やらない) - 実行されたジョブ自体が出力した標準出力、およびエラー出力は残らない
-> どのような処理が行われたかがわからない
対策1:cronのジョブ指定時にリダイレクト
0 3 * * * /home/opt/bin/get_db_backup.sh >> /var/log/job.log
対策2:実行されるスクリプトの中でログ出力を実装
#!/bin/bash # This is get_db_backup.sh log="/var/log/job.log" date >> ${log} echo "Start db dump" >> ${log}
-> 統一されたルールが無いと、両方のパターンが混ざってカオスになっていく
Cronの辛み2 エラーハンドリングが難しい
Cronでは、実行されたジョブがエラー終了しても気づけない。
/var/log/cronへ、「cronで実行した」というログしか出ない。
-> エラー検知の仕組みを別に実装する必要がある
Cronの辛み3 サーバ複数で連携してできない
サーバ単体で、"jobA"が終わり次第、"jobB"を実行というのは以下のように書ける。
0 22 * * * jobA.sh && jobB.sh
しかし、"サーバAのjobA"が終わり次第、"サーバBのjobB"を実行するような処理は書けない。
-> サーバBのCronで、サーバAのjobAがすでに終わっているはずの時間を指定して逃げるしかない
-> ある日のサーバAのjobAの処理時間が伸びる。サーバBのjobBで必要なデータが出来ずに…
-> 後続のジョブ全滅!!
そこでRundeck
-
OSSのジョブスケジューラ
-
Apache 2.0 License
-
WebのリッチなGUIが特徴
-
crontabからの移行に最適
-
細やかなアクセス制御
-
APIもあるよ
-
GitHub Star 2k超
他ツールとの比較
- Jenkins -> 多機能すぎてシンプルじゃない
- digdag -> GUIの機能(認証や設定変更)が不足
- ConcouceCI -> GUIから編集ができない
ここがすごいぜ!Rundeck
- 雰囲気で操作できるGUI
余分な装飾が無いUIでわかりやすい - 細かいアクセス制御
少し複雑だが、LDAPやADと連携して以下のようなことが細やかにできる。 - ジョブの実行を許可(編集はさせない)
- ジョブの結果参照を許可
- 特定のプロジェクトへのアクセス許可(ジョブの集まり)
- ログの保存(標準・エラー出力)
cronでは捨てられてしまう出力が残るので、これが非常にありがたい。
コマンド、スクリプトの実行
- 対象サーバ上でのコマンドを実行できる
- 対象サーバ上のスクリプトを実行できる
- rundeck上でスクリプトを書き、それを対象サーバ上で実行できる。
- optionという機能でジョブに変数を渡せる
- cron記法でのスケジューリングができる
->既存資産(スクリプト)をそのまま活かせる!!
ジョブワークフロー
- 登録したジョブはワークフローとして実行できる
某国産統合管理システムのジョブネットのような… - ジョブごとにどのサーバで実行するかも指定できる
プラグインによるansible連携
-
Jenkinsほどではないが、Rundeckも豊富なプラグインがあり、
その中でもansible pluginを使用すると以下が実現できる。 -
ansibleのインベントリを利用して、Rundeckへノードを自動登録できる
-
しかもインベントリのグループがRundeck上のTabとして登録される
-
ただし、定期的にgather_facts(各ノードのOSやスペック、ネットワーク情報などを収集する)をするため、
各サーバのシスログが汚れてしまう…
Rundeckを利用する上で気を付けること
- 集中化による負荷
同時に実行されるジョブ数、出力されるログ容量などのサイジングは必須 - 耐障害性
- HA機能は有償のため、pacemaker & corosyncで冗長化がおすすめ
- スケーリングについてはドキュメントも参照
Rundeck公式 : Scaling Rundeck
Studyチャット nice-rundeck 内の情報
- cronは、ubuntuだと標準出力を変なところに吐き出すことで事故ることがあるので注意。
- cronで標準出力にデータ吐き出す処理すると、OSの設定によってはhomeに吐き出されることがあるので、こちらも注意。
- Rundeskは、Jobの入れ子もできるよ!
質疑応答
- Rundeck自体の冗長化はどうやるの?
- オンプレだとpacemaker & corosyncでやってる
- AWSなら、DBをRDSにして、ファイルだけをlsyncdとかで同期すれば簡単にできると思われる
- 同じくOSSのJobSchedulerと、どれぐらい違う?
- JobSchedulerはほぼエージェント型
- RundeckはSSHでリモートサーバを操作できる。そのため、windowsには不向き