まだcronで消耗してるの? ≒ Rundeckを試してみる

Pocket
LINEで送る

最近crontabによる管理が面倒なのでなんとかしたい
菊池です

弊社ではいわゆるバッチ処理をcrontabで管理しています
そろそろいろいろな面でツラミが出てきてどうにかしたいと思い始めています

  • 実行ログが取りづらい
  • ワークフローの構築が困難
  • 開始完了の時間計測などしづらい
  • 多重実行管理がめんどう
  • アドホックな実行が面倒
  • エトセトラ etc…

自前でいろいろ考慮・構築すれば解決はできますが、ここは
問題を解決してくれる勇者的ツールを試していきます

  1. ジョブ管理ソフトウェアの意義
  2. Rundeckの特徴
  3. localで試して動かしてみる
  4. ジョブを登録してみる
  5. できそうなことと展望
  6. まだ本導入できない・しない理由
  7. まとめ

 

1. ジョブ管理ソフトウェアの意義

カジュアルに定期実行させる場合、Windowsなら「タスクスケジューラ」/linuxなどは「cron」を用いるケースがほとんどだとは思いますが、両者ともに数多くのタスクを管理するためには機能が足りないです
(端的に言うと人に優しいものではない…)

また、cronでは複数のジョブを組み合わせて逐次実行させたり、エラーなら後発の処理を止める(or 止めずに続ける)ようなジョブフローを組むことは困難です

ジョブ管理ソフトウェアはそんな管理の問題を解決するためにある!と言っても過言ではないです
逐次実行はビジネスがスケールするに従ってセンシティブなものが増えていき、管理が複雑化しやすいので
導入を検討するというのは嬉しい悲鳴です

今回取り上げるRundeckをはじめ、JobStarSOS jobschedulerなどなど
探すと結構出てくるので、それだけ需要があると言えます

 

2. Rundeckの特徴

特徴と言っても他と比較をしたわけではないですが、先人の知恵を借りるならば
> 「SSHさえ疎通すれば、どんなマシンのどんなコマンドでもcron実行できる」という柔軟さ
が大きな特徴なのかなと思います

それ以外にOSSである点や、Webベースであることは昨今の事情にマッチしています
日本語での記事も多いことから導入に対しての情報を仕入れやすいこともメリットですね

 

3. localで試して動かしてみる

さっそく試して動かしていきましょう
今回はとりあえず試してRundeckに慣れていきたいのでdockerでうまく動かせるように以下の記事を参考にしていきます

RundeckをDockerで動かす(Rundeck+MariaDB+Nginx) – Qiita
#はじめに Rundeckをコンテナ化、更にNginxとMariaDBのコンテナも同時に作成する`Docker Compose`を公開します。 基本的に下記の手順で進めていけば、**単一ノード**上に3つのコンテナが作成され、Rund…


詳細は割愛しますが、上記の記事に従ってlocalで実行できるようにします
概ね記事の通りで動作しますが、以下は別途で対応しました

  • .envファイルのRUNDECK_HOST_NAMEをlocalhostにする
  • docker-compose.ymlのvolumesに記載してある「/etc/localtime」の書き換え(下記を記事参考)

参考:Mac OSのDockerで/etc/localtimeがマウントできなくなって困った話 – A1 Blog

localhost:4440 にアクセスすると以下のようなログインページが表示されます
Rundeck_-_Login
ID/PASSなんて登録してないよ!と思うかも知れませんがデフォルトでadmin/adminでログインできるので安心してください

ログインすると以下のような表示だけが出てきます
Rundeck
Rundeckは「Project」という単位で「Job」をまとめて管理しますので、まずはProjectを作る必要があります

[New Project +]から作成画面に行きますが、英語がぎっしりでちょっとたじろいでしまいますね…
Create_a_Project
ですが、今回はlocalでのみ動かしたいのでひとまず「Project Name」のみ入力してさっさと「Create」します

できたら次は「Job」の登録に行きましょう

 

4. ジョブを登録してみる

今回のメインストリームになるジョブ登録を行っていきます
[Job Actions]->[+ New Job..]からジョブ作成画面にいきます
Cursor_と_Rundeck_-_Create_New_Job
Job Nameにジョブ名、Descriptionに説明を入力します(ただし、日本語で入力するとdefaultでは文字化けするので英語で…)
Groupを設定するとなにかできそうですが今回は割愛します

Optionsを設定するとジョブの「引数」を付けることができます
Cursor_と_Rundeck_-_Create_New_Job-2
データの型からデフォルト値など細かい設定ができそうですね
とりあえず簡単に動かすので今回は割愛します

次に、ジョブ設定の肝になるWorkflowの設定です
Rundeck_-_Create_New_Job
「If a step fails」は読んで字のごとく後続処理の設定です

  • Stop at the failed step. : 失敗したstep以降を中止します
  • Run remaining steps before failing. : 失敗したstepのみスキップして後続のstepを続行します

「Strategy」は実行戦略の設定です
Rundeck公式の説明でも書いてありますが、「Step」とそれをまとめる「Node」という考え方により実行されます
まとめると以下の図のようになります
Rundeck_Strategy
参考:[Qiita] OSS ジョブスケジューラ(Rundeck)を自宅サーバに入れてみた Part2

実際に実行するものは「Command」「Script」を始め、プラグインで様々なものが定義できるようです
今回は「Command」のみで指定して実行するので詳細は割愛します

後は細かい設定をしていきます
Rundeck_-_Create_New_Job-3
リモートで実行するか、ローカルで実行するかを設定します
今回はローカルを選択します

Rundeck_-_Create_New_Job-4
細かい設定項目を雑にまとめてみます

  • 通知設定 : 「メール」or「Webhook」が設定できる
  • 繰返設定 : 「シンプル」or「Crontab」が設定できる
  • 実行設定 : スケジュール・実行の有効無効が設定できる
  • log設定 : 「Normal」or「Debug」が設定できる
  • 多重起動設定 : 多重起動の有効無効が設定できる
  • Timeout設定 : タイムアウト時間が設定できる
  • リトライ設定 : 失敗時の再実行が設定できる
  • log size設定 : log size(MAX)が設定できる
  • タブ表示設定 : Webでの初期表示タブが設定できる
  • UUID設定 : 実行JobにUUIDが設定できる

かなり細かい設定も多く使いこなすまで時間がかかりそうですが、多くのユースケースに対応できそうでいいですね

 

5. できそうなことと展望

Rundeckを入れるモチベーションとなるとやはりcrontabでの管理に限界を感じた場合は移行を検討するくらいの温度感でしょうか
単純なワークフローによるジョブ管理や通知・多重起動管理と言ったバッチ処理でありがちな処理をシンプルに実現するにはもってこいな気がします

プラグインを入れることでわざわざコーディングすることなくジョブを組み上げることも可能なので設定を駆使して実装工数を減らすこともできそうな予感がします…
また、実行状態をWebGUIで閲覧して、再実行を行うなどのアドホックな対応もWebで行えるのは本当に嬉しい限りですね
Jobs_-_test
今回は機能の確認のためにdockerにて簡単に動かすことにしましたが
EC2上にしっかりと構築してリモートでバッチ処理を回すようにすればスポットで時間が掛かる処理をしたい場合にだけ強いインスタンスを時間起動しておくと言った運用もカバーできそうでいいです

 

6. まだ本導入できない・しない理由

ここまでべた褒めしましたが、弊社ではまだ本導入に踏み切らずに一旦見送りました
なぜ?と思われるかもしれませんが、以下のような課題がありそうでした

  • Rundeckの設定に詳しい人が少ない
  • Rundeck環境自体の問題に対応する時間が取れない
  • バッチ処理のリプレイスでAWS内で完結する可能性が高い

やはりシステムを追加するとメンテナンスコストは付き物なので、気軽に導入するという判断は難しいです
有識者が少ない中で業務の重要なバッチフローを置き換えるのはリスクも大きく、慎重になる必要があります

また、弊社でバッチ処理系の再設計を行う際にAWS内で完結するような構成にする可能性も高く
Rundeckの恩恵を受けられる処理系が少なくなるのであればいらないかなー

という月並みな判断ですが、上記から本導入に関しては見送ることにしました

 

7. まとめ

タスクスケジューラ・crontabによるバッチ処理の管理はいずれ限界を感じる分野でありRundeckなどのシステムで解決する方法はシステム構築当初から検討する必要があるかもしれません

Webベースで気軽に扱えるOSSも多く、早い段階で慣れて設定項目の把握などできていると細かな導入に対して前向きに対応できるのでいろいろなシステムに触れている価値を感じますね

導入に関しては慎重になる必要はありますが、一度軌道に乗ってしまえば業務の流れを一変しうる強力なツールなので注視していきたいですね

Rundeckに関して、今回はver 2.11に触れましたがメジャーバージョン3系も出ているので改めて導入記事を書いて見ようと思います(プレッシャー)

Pocket
LINEで送る