以前書いた Rundeck のメモです。死蔵しておいてももったいないので Qiita で公開します。
内容は多少古くなっているので注意しください。
Rundeckとは
複数のサーバーを対象に、コマンドを分散実行するためのジョブコントローラーのひとつ。
ユーザマニュアルより引用
コマンドの分散実行
拡張可能な実行システム（デフォルトでは SSH）
マルチステップワークフロー
ジョブの定義と実行（即時 or スケジュール)
コマンドとジョブを実行するための GUI
ロールベースの ACL（LDAP/ActiveDirectory 連携可能）
履歴とログ監査
外部のホスト管理ツールとの統合(open integration)
CUI インタフェース
Web API
Rundeckはエージェントレスのシステム。
実行したコマンドの出力も含め履歴が残るので、ターミナルからコマンドを実行するよりも、こういったツールを利用した方がよい。
CLIコマンドもあり、構成とジョブの実行のために必要となる最低限のコマンドは網羅されているようだ。Web APIを使えば全ての機能が利用できるようなので、他のシステムとの連携にも困らないだろう。
ユーザマニュアルは邦訳されていたが、もとの版がかなり古いようで、あまり当てにしない方がよいだろう。
JobScheduler との比較
JobSchedulerだと、エージェントレスでジョブを実行することもできるけれど、扱えるのは1行コマンドのみとなるため、シェルスクリプトをJobSchedulerへ登録するような使い
方をするならエージェントを使う必要がある。
JobSchedulerが、ジョブネットのような連携したジョブのコントロールを目的とするシステムなのに対して、Rundeck はもう少し軽いところ、デプロイや構成管理ツールのコマンドやジョブを実行するのを主目的としている、というところか。
Rundeckではジョブのステップの出力を次のステップに渡したり、前に実行したステップ
の出力を参照するような仕組みはなさそうである。このあたりも、JobSchedulerと違うところである。
実行結果
実行結果は履歴として後から参照できる。結果には、実行時のワークフローの定義も一緒に記録されている。つまり、過去の実行履歴をみると、その時、どのような定義のワークフローで実行したかもわかるようになっている。これは、ワークフローを後から変更したときでも、過去の実行履歴は独立した記録になっていて、影響を受けないということであり、大変重要なことである。
クイックツアー
- Rundeck
インストール編 - Rundeck
プロジェクトの作成 - Rundeck
ジョブの作成と実行 - Rundeck
コマンド実行のされ方を見る