おそらくはそれさえも平凡な日々

そんな中、近年ではcronの代替としてjenkinsを使うという斜め上の発想が蔓延りつつあるが、 そんなことをすると「cronに500Mもメモリ使ってられるかー」と椅子が飛ぶこと請け合いなので非常に難儀するものである。

斯くの如く問題意識を抱えていたものの、やはり惰性でcronを使い続けていたのだが、 昨日、代替cronのネーミングとして “xaicron” という非常に格好良い名前を思いついてしまったので、 この際代替cronについて考えてみることにする。

懸念事項としては、将来RPMパッケージ化などされた時に、実行ユーザーとしてxaicronが作られてしまって、 万が一xaicronというユーザー名を使っている人がいた場合に困るというのがあげられる。 (世界中のjenkinsさんは困ってないんでしょうか)

または、そのネーミングだと午前中は仕事してくれなさそうだという意見も頂いております。

ネーミング駆動でまだ全然イメージ湧いてないのですが、とりあえず、cronのpros/consを思いつくままに書いてみます。

cronの良い点

• 枯れている
• crondが落ちて阿鼻叫喚みたいなことはあんま考えなくて良い
• Unix系なら大体どこにでも入っていてすぐ使える
• 記法は大体みんな知っている(謎記法だけど)
• 一つのエントリが一行に収まっているので綺麗に書けば一覧性はある(かも知れない)
• 実行権限がユーザーごと別れてたりとか最低限の環境変数しか設定されてないとかセキュリティに配慮されてる
• unixという考え方に則りsetlockとかsoftlimitとかcronlogとかtimeoutとかそういう細かいツールを組み合わせれば色々できる

cronのイケてない点もしくはcronができないこと

• 記法が謎で初学者にやさしくない。間違えて毎分設定にして泣く人続出
• setlockとかcronlogとかtimeoutとかsoftlimitとか覚えないといけないので敷居が高い
• $PATHがちゃんと設定されていなくて動かないとかでハマりがち
• crontabで環境変数の展開とかしてくれないの大分ダルい
• 設定の横幅が長くなりがちだったり、ちゃんとスペース調整しなかったりすると読めなくなる
• ちゃんと実行されるかどうかの確認に3分くらい待たないといけない
• 後続の処理とかこの処理が失敗したらこの処理は走らせたくないとかそういう処理の親子関係みたいなのが設定できない
• 標準の通知先がメールなので、いちいち全部のエントリーに| loggerとか書くのがだいぶダルい。結果としてログを捨てる人続出
• 時間単位でしか設定できないし秒単位の設定ができない
• 通知を受けてジョブを走らせるみたいなことができない
• 設定を動的に変更するとかそういうことがやりづらいしやらないほうが身のため
• Webインターフェースがない
• 並列/排他処理とかは自分で頑張るしかない
• 複数サーバーをまたいだジョブ管理とかができない
• リトライとかタイムアウトとかできない
• VCSとの連携(チェックアウトして実行とか)
• 可視化ツールとの連携
• プラグイン機構が無い

上記を踏まえていまぼんやりと考えているのは以下のような感じ。

• 分かりやすいジョブ設定・環境変数設定
• ジョブ管理デーモンがいて、うまいことクライアントと連携する
• トリガによるイベント駆動的なジョブ実行(定時実行もそのうちの一つに過ぎない)
• プラグイン機構
  • ジョブ実行前・実行後のフック機構
  • ログや通知機構の充実
  • 可視化
• Webインターフェースは敷居を下げるためには必要

クライアント側に関してはUkigumo::Clientがだいぶイケてるので、そのへんからパクってくればいいかなーと思っている。 Ukigumo::Clientをもうちょっと抽象化したやつを切り出して、Ukigumo::Clientはそっちに依存する形でも良いのかなーとか思っている。

デーモン側はno plan。

こういう時参考実装とかをサクッとかけたりすればカッコいいんですけどねー。