インフラ勉強会用の発表資料です。cronで辛かった話から、rundeckがどれだけ素晴らしいかをご紹介。

1. ジョブ管理でcronは限界があったの
で”Rundeck”を使ってハッピーになりま
した
2018/2/9(金) 22:00 インフラ勉強会
もりはや

2. 免責事項
自己紹介はインフラ勉強会Wikiをご確認ください＞＜
発表内容は個人のものであり所属する組織にいかなる（略）
CentOSでの経験で話します

3. アジェンダ
ジョブとは
ジョブ管理とは
Cronのあれこれ
Rundeckご紹介
デモ（時間余れば）

4. ジョブとは
何らかのひとまとまりの処理。
実態としてはスクリプトファイルや、バッチファイルであること
が多い。
会話では「バックアップジョブ」とか「レポートジョブ」とか
「集計ジョブ」とか気軽に「XXジョブ」という使い方をする。
﴾異業種の友達と話すとポカンとされます）

5. ジョブ管理とは
必要に応じて特定の日時に、特定のジョブが実行される状態を維
持すること。
﴾例﴿
毎日AM3:00にDBのバックアップを取得
月初﴾1日﴿の09:30に先月分の売り上げレポートを作成
"5のつく日キャンペーン"のメールをキャンペーン開始日の
0:00に送信

6. Cronとは
Linux標準のジョブスケジューラ。Windowsでいうタスクスケジュ
ーラの機能。
実行日時の書式は初見殺しだけど、慣れるとこれ以外に無い気が
してくるほど便利。
書式は以下の通り。1行＝1ジョブ。
分 時 日 月 曜日 実行コマンド
大抵のジョブはCronで十分。

7. Cronの設定例
毎日AM3:00にDBのバックアップを取得
0 3 * * * /home/ope/bin/get_db_backup.sh
月初﴾1日﴿の09:30に先月分の売り上げレポートを作成
30 9 1 * * /home/ope/bin/create_monthly_report.sh
"5のつく日キャンペーン"のメールをキャンペーン開始日の
0:00に送信
0 0 5,15,25 * * /home/ope/bin/send_mail_5dayevent.sh

8. Cronを使うためには
crontab ‐e コマンドで追記する
"/var/spool/cron/ユーザ名"のファイルが生成される
/etc/crontabに追記する
/etc/cron.d/配下へファイルを配置する
/etc/cron.daily OR cron.weekly OR cron.monthlyへファイルを
配置する
各ディレクトリに配置されたファイルを/etc/anacronがラ
ンダムな時間を付与して実行する仕組み

9. Cronのココがすごい
OS標準である
必ず使えるという安心感
設定が簡単
書式に慣れればさくさくジョブがかける

10. Cronのココが辛い
ログが出ない
エラーハンドリングが難しい
サーバ単体で完結してしまう

11. Cronの辛み1 - ログが出ない
/var/log/cronへ実行したというログしか出ない。
﴾MAILTO設定をすればメールで飛ばせるが、基本やらない﴿
Feb 8 14:04:01 localhost CROND[3694]: (ope) CMD (date)
Feb 8 14:04:01 localhost CROND[3695]: (ope) CMD (/home/ope/bin/get_d
実行されたジョブが出力した標準出力、およびエラー出力は残ら
ない。
‐> どのような処理が行われたかわからない

12. Cronの辛み1 - ログが出ない
対策1 : cronのジョブ指定時にリダイレクト
0 3 * * * /home/ope/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}
...
‐> 統一されたルールが無いと両方のパターンが混ざってカオスに
なっていく

13. Cronの辛み2 - エラーハンドリングが難しい
Cronは実行されたジョブがエラー終了しても気づけない。
以下のようなコマンド間違いがあったとしても
* * * * * date
* * * * * data # コマンド間違っている
華麗にスルーして実行
Feb 8 14:19:01 localhost CROND[3991]: (ope) CMD (date)
Feb 8 14:19:01 localhost CROND[3992]: (ope) CMD (data)
Feb 8 14:20:01 localhost CROND[4003]: (ope) CMD (date)
Feb 8 14:20:01 localhost CROND[4004]: (ope) CMD (data)
‐> エラー検知の仕組みを別に実装する必要がある

14. Cronの辛み3 - サーバ単体で完結してしまう
”jobA"が終わり次第"jobB"を実行というのは以下のように書ける。
0 22 * * * jobA.sh && jobB.sh
"サーバAのjobA"が終わり次第"サーバBのjobB"を実行するような処
理は書けないため、後続のサーバで「すでに終わっているはずの
時間」でジョブを実行する。
#@サーバA
0 22 * * * jobA.sh
#@サーバB
#※jobAは多分1時間以内に終わるはずだから23時に実行
0 23 * * * jobB.sh

15. Cronアンチパターン(実話)
Cronを使っていて実際に経験したアンチパターンをお話します。

16. アンチパターン1 - crontabが育ちすぎてつらい
とある日「なんか11時のジョブおかしそうだから調査ヨロ ﾉｼ」と
言われて入ったサーバでcrontab ‐lを打ったところ
> crontab ‐l | wc ‐l
1012 ( Д ) ゜ ゜ < 1000行！？
コメントや空白行があるとはいえ、開いた時点でつらい。
その時はgrepして頑張った。
egrep "^[^ #]+ [*1]1* " /var/spool/cron/hoge

17. アンチパターン2 - 肌感によるピタゴラスイッチ
以下のようなジョブがすべて連携していた。
22:00 サーバAのジョブA
23:00 サーバBのジョブB
24:00 サーバCのジョブC
01:00 サーバDのジョブD
とある日の改修でサーバAのジョブAの処理時間が40分 ‐> 1時間30
分に伸びた
‐> 後続のジョブ全滅...!!
加えて、普段うまく稼働していても無駄な空白時間があって
ﾓｯﾀｲﾅｲ

18. アンチパターン2 - 肌感によるピタゴラスイッチ
さらにサーバごとの部門が異なっていて各担当者への調整が大変
だった。
22:00 経理部門のサーバAのジョブA
23:00 総務部門のサーバBのジョブB
24:00 営業部門のサーバCのジョブC
01:00 管理部門のサーバDのジョブD

19. そこでRundeck

20. Rundeckとは
https://github.com/rundeck/rundeck
OSSのジョブスケジューラ
WebのリッチなGUIが特徴
crontabからの移行に最適
細やかなアクセス制御
APIもあるよ
GitHub Star 2k超

21. Rundeckと他ツールとの比較
他にも魅力的なOSSはあるけど、cronからの移行だけならRundeck
がおすすめ
Jenkins ‐> 多機能すぎてシンプルじゃない
digdag ‐> GUIの機能（認証や設定変更）が不足
ConcouceCI ‐> GUIからの編集ができない

22. ここがすごいぜRundeck

23. 雰囲気で操作できるGUI

24. 細かいアクセス制御
少々複雑だが、LDAPやADと連携して以下のようなことが細やかに
できる。
ジョブを実行を許可（編集はさせない）
ジョブの結果参照を許可
特定のプロジェクトへのアクセス許可（ジョブの集まり）

25. 細かいアクセス制御
※最近﴾2017/10﴿GUIから編集ができるようになった。

26. ログの保存（標準・エラー出力）
個人的にはこれが一番ありがたい。

27. コマンド、スクリプトの実行
対象サーバ上でコマンドを実行できる
対象サーバ上のスクリプトを実行できる
rundeck上でスクリプトを書き、それを対象サーバ上で実行で
きる
optionという機能でジョブに変数をわたせる
cron記法でのスケジューリングができる
=> 既存資産(スクリプト)をそのまま活かせる！！

28. ジョブワークフロー
登録したジョブはワークフローとして実行できる
ジョブごとにどのサーバで実行するかも指定できる

29. （おまけ）プラグインによるansible連携
Jenkinsほどではないが、Rundeckも豊富なプラグインがあり、
その中でもansible pluginを使用すると以下が実現できる。
ansibleのインベントリを利用してRundeckへノードを自動登録
しかもインベントリのグループがRundeck上のTabとして
登録される
（ただし定期的にGather_factsをするため、各サーバのシスログは
汚れていきます...﴿

30. Rundeckを利用する上で気を付けること
集中化による負荷
﴾同時に実行されるジョブ数、出力されるログ容量など）
耐障害性
HA機能は有償のため、pacemaker & corosyncで冗長化
スケーリングについてはドキュメントも参照
http://rundeck.org/docs/administration/scaling‐
rundeck.html

31. デモ
時間があまったらデモします！！
ご清聴ありがとうございました
m( _ _ )m