Rundeck 代替

JVM も SQL データベースも GUI でのジョブ作成もなしで、Runbook を自動化する。

Dagu は、スケジュール実行、オンデマンドの Runbook、Web UI を 1 つの小さなバイナリで使いたい運用チーム向けの Rundeck 代替です。ジョブ定義はコンソールの中ではなく Git 上の YAML になり、状態は MySQL や Postgres ではなくファイルに保存され、既存サーバーへは SSH またはラベル付きワーカーで届きます。移行の進め方と、Rundeck のほうが強い領域もこのページに書いています。

Dagu をインストールプランを比較する比較一覧を見る
Runbook を YAML 1 ファイルで
# restart-app.yaml
params:
  - name: host
    default: app01.internal
 
ssh:
  user: ops
  host: ${params.host}
  key: ~/.ssh/ops_key
 
steps:
  - id: drain
    run: /opt/app/bin/drain --wait
 
  - id: restart
    run: sudo systemctl restart app
    depends: [drain]
 
  - id: health_check
    run: curl -fsS http://localhost:8080/healthz
    retry_policy:
      limit: 5
      interval_sec: 10
    depends: [restart]
 
handler_on:
  failure:
    run: ./scripts/notify-oncall.sh

実行順序

drainsshrestartsshhealth_check5 retries

状態をファイルに持つ単一バイナリ。JVM も SQL データベースも不要

ジョブはバージョン管理された YAML。ほかの変更と同じくレビューできる

SSH ステップとラベル付きワーカーで既存サーバーへ届く

SSO、RBAC、監査ログを公開価格のサーバー単位ライセンスで

一目で比較

運用自動化における Rundeck と Dagu

ランタイム
Dagu

状態をファイルに持つ単一バイナリ。キューとワーカーは任意。

Rundeck

Java サービスに加え、本番では MySQL または Postgres。

定義方法
Dagu

Git でレビューする宣言的 YAML。

Rundeck

Web コンソールが主で、YAML エクスポートと SCM 同期は補助的な経路。

リモート実行
Dagu

SSH ステップ、または mTLS 保護の gRPC で外向き接続するラベル付きワーカー。

Rundeck

リソースモデルのインベントリから SSH / WinRM でノードへディスパッチ。

権限委任
Dagu

システム全体に効くロール。ライセンス版で SSO と監査ログ。

Rundeck

プロジェクト単位・ジョブ単位のきめ細かい ACL ポリシー。

ライセンス
Dagu

サーバー数無制限で無料。有償版は Dagu サーバー単位でワーカーは無制限。

Rundeck

オープンソースのコアに加え、商用の Process Automation は見積もりベース。

可用性
Dagu

スケジューラーは単一インスタンス。可用性の設計は自社で組む。

Rundeck

商用版にクラスタ構成がある。

詳細

それぞれの強みと向き不向き

01

Runbook の考え方は残し、スタックだけ落とす

Rundeck は SQL データベースを背にした Java サービスとして動き、ジョブはプロジェクトごとに Web コンソールで定義します。Dagu は同じ運用の概念を、状態をファイルに持つ 1 プロセスの中に収めます。

  • ジョブは DAG ファイル、ジョブステップはステップ、エラーハンドラーは handler_on.failure に対応します
  • ジョブオプションは params に対応します。型とデフォルト値を持ち、実行時に UI、CLI、API から値を渡せます
  • サイズ設計やバックアップが要る MySQL / Postgres も、チューニングする JVM ヒープもありません。小さな VM で動きます
02

コンソール操作ではなく、コードとしてのジョブ

Rundeck も定義のエクスポートや SCM プラグインでの同期はできますが、主な作成手段はコンソールです。Dagu は逆で、リポジトリにある YAML ファイルそのものが定義です。

  • すべてのジョブが Git 上の YAML ファイルになり、変更はコンソール編集ではなくレビュー可能な diff で届きます
  • dagu validate で、生成した定義も手書きの定義も CI でスケジューラーに届く前に検査できます
  • Web UI は運用のために残ります。パラメーター付きで実行し、ログを見て、リトライし、スケジュールを停止できます
03

エージェントを入れずに既存サーバーへ届かせる

Rundeck はリソースモデルのインベントリからノードへコマンドをディスパッチします。Dagu は同じ領域を 2 つの仕組みでカバーします。エージェントレスなホストには SSH、常駐の実行基盤が向く場所にはワーカーです。

  • SSH ステップで既存の Linux / UNIX ホストを常駐エージェントなしに実行します
  • ローカル実行が必要なマシンでは dagu worker を起動し、worker_selector のラベルでステップを割り当てます
  • ワーカーは mTLS で保護された gRPC で外向きに接続するため、セグメント化されたネットワークでも受信ポートは不要です
04

ジョブを実行する人と定義を変更する人を分ける

Rundeck の典型的な使い方は、安全な操作だけを広いグループに委任することです。Dagu ではその分離を、ライセンス版セルフホストのロール、SSO、監査ログでカバーします。

  • operator ロールは実行と停止はできますが定義は変更できません。viewer は参照のみ、developer と manager はワークフローを変更できます
  • OIDC で既存の ID 基盤にログインを寄せられるため、利用者情報を二重管理せずに済みます
  • 監査ログに管理操作とセキュリティ上重要な操作が記録されます
05

営業への問い合わせではなく、公開された価格

Rundeck の商用版は PagerDuty Process Automation になり、価格は見積もりベースです。Dagu のコミュニティ版はサーバー数もワーカー数も無制限で無料、ライセンス版はサーバー単位の公開価格です。

  • コミュニティ版でオーケストレーション本体、Web UI、cron スケジュール、Docker と SSH と HTTP のステップまで使えます
  • ライセンス版のセルフホストはサーバーライセンス 3 つで年額 500 ドルから。SSO、RBAC、監査ログ、インシデント連携、メールサポートが付きます
  • どのプランでもワーカーは無制限です。実行ホストを増やしてもライセンス数は変わりません
06

Rundeck のほうが強い領域

良いところだけ並べた比較は検討の役に立ちません。Rundeck を使っている組織が追加の作業を見込むべき、あるいは移行しないほうがよい領域です。

  • ノードインベントリは Rundeck のほうが豊富です。リソースモデルソースとノードフィルターで 1 つのコマンドを数百台に展開できます。Dagu のステップの宛先は SSH ホストかラベル付きワーカーで、フリートのインベントリという概念はありません
  • Rundeck はプロジェクト単位・ジョブ単位の ACL で、特定の 1 ジョブだけをヘルプデスクのグループに渡せます。Dagu のロールはシステム全体に効き、ジョブ単位ではありません
  • 商用の Process Automation には高可用性のクラスタ構成があります。WinRM ノードエグゼキューターや通知プラグインなど、プラグインのエコシステムも大きいです

FAQ

Dagu を導入する前によくある質問

Dagu は Rundeck をそのまま置き換えられますか？

いいえ。概念の対応は素直です。ジョブは DAG ファイル、ジョブステップはステップ、オプションは params、エラーハンドラーは handler_on.failure になります。ただしインポーターはなく、Rundeck のノードフィルターに直接相当するものもありません。移行は各ジョブを YAML ファイルとして書き直す作業で、コマンドベースのジョブなら機械的に進みます。

UI からパラメーター付きでジョブを実行できますか？

はい。params で型とデフォルト値を持つ入力を宣言し、Web UI、CLI、API から実行時に値を渡せます。Dagu にないのは、特定の 1 ジョブだけをグループに公開する Rundeck のジョブ単位 ACL です。ロールはシステム全体に効きます。

多数のサーバーでコマンドを実行するには？

2 つの方法があります。SSH ステップはエージェントレスなホストで実行し、分散モードではマシン上のワーカーが worker_selector のラベルに一致するステップを取得します。リソースモデルのインベントリはないため、大きなフリートへの一斉展開は並列ステップかラッパースクリプトで表現します。

Rundeck のようにデータベースは必要ですか？

いいえ。実行履歴、ログ、キューの状態はディスク上のファイルです。これが閉域ネットワークでの動作を簡単にしている点でもあります。単一バイナリで、JVM も、到達すべき外部サービスもありません。

Rundeck のスケジュールや webhook は何で置き換えますか？

タイムゾーン対応の cron スケジュールを内蔵し、API または webhook で外部から実行を起動してペイロードをワークフローで参照できます。同時実行はデフォルトでワークフロー単位に制限され、共有の上限は名前付きキューで設定します。

関連ページ

分散実行ワークフローグラフは 1 つ。ワーカーはあらゆるプラットフォームに。読むcron ジョブのモダン化cron の手軽さを保ちつつ、本番運用に必要な制御を足す。読むJP1/AJS3 代替マネージャー専用サーバーも、ノードごとのエージェントも、ノード単位ライセンスもなしでジョブを回す。読む

次の一歩

まず 1 つのワークフローから。

Dagu をインストールし、不安定なスクリプトやエージェントタスクを 1 つ YAML に移して、実際の実行履歴を見て判断できます。

Dagu をインストール他の比較を見る