Dagu vs Argo Workflows
Argo Workflows は Kubernetes 上で動く。Dagu は普通のマシンで動く。
どちらも DAG を定義し、ステップを順に実行します。Argo Workflows は Kubernetes に組み込まれ、各ステップを pod としてスケジュールします。Dagu は既存のコマンドを呼ぶ 1 バイナリで、運用するクラスタはありません。
name: nightly-ops
schedule: "0 2 * * *"
steps:
- id: extract
run: python scripts/extract.py
- id: transform
run: ./bin/transform
retry_policy:
limit: 3
depends: [extract]
- id: notify
run: ./scripts/slack-success.sh
depends: [transform]自己完結した 1 バイナリ、Kubernetes クラスタ不要
既存コマンドを実行する宣言的 YAML
外部 database や message broker 不要
shell、Docker、HTTP、SSH、SQL、SubDAG、AI エージェント用の executor
下にクラスタを置かないオーケストレーション
Argo Workflows は稼働中の Kubernetes クラスタと、各ステップを pod に変える controller を前提とします。Dagu にその要件はありません。1 バイナリをサーバー、ノート PC、VM に置けば動きます。
- Kubernetes も controller も etcd もない通常のマシンで動く。
- 状態を別 database や broker ではなくローカルファイルに保持。
- ローカルで始め、負荷が増えたらキューや分散モードへ移行。
ステップはコンテナだけでなくコマンド
Argo Workflows では各ステップが pod 内で動くコンテナです。Dagu もコンテナを動かせますが、shell スクリプト、HTTP エンドポイント、SSH コマンド、SQL クエリ、SubDAG、AI エージェントステップを直接呼べます。
- 既存のスクリプトやバイナリを image 化せずそのまま使える。
- 同じワークフロー内で Docker ステップと shell、HTTP、SSH を混在できる。
- 実行、ログ、履歴を内蔵 Web UI で確認できる。
Argo Workflows を選ぶべきとき
すでに Kubernetes が基盤なら Argo Workflows が向いています。Kubernetes ネイティブで、各ステップを独立した pod としてスケジュールし、大量のコンテナ fan-out 向けに設計されています。Dagu はそれを行いません。
- Kubernetes 上で動き、ワークフローを他のマニフェストと並ぶ CRD として定義したい。
- 各タスクごとに pod スケジューリング、node selector、クラスタ autoscaling が必要。
- パイプラインが多数のノードへ一度に数千コンテナへ fan-out する。
Argo Workflows vs. Dagu の概要
FAQ
Dagu を導入する前によくある質問
Dagu は Argo Workflows を置き換えますか？
すべてのチームでではありません。Kubernetes に標準化し、各ステップを pod として動かしたいなら Argo Workflows が適切です。クラスタを動かさず通常のマシンでコマンドをオーケストレーションしたいなら Dagu が向いています。
Dagu は Kubernetes なしで動きますか？
はい。Dagu はサーバー、VM、ノート PC で動く自己完結した 1 バイナリです。Kubernetes クラスタ、外部 database、message broker のいずれも不要です。
Dagu でもコンテナを動かせますか？
はい。コンテナが必要なステップ向けに Docker executor があります。違いは、コンテナが唯一の実行単位ではなく、shell、HTTP、SSH、SQL、SubDAG のステップと並ぶ 1 つの選択肢である点です。
まず 1 つのワークフローから。
Dagu をインストールし、不安定なスクリプトやエージェントタスクを 1 つ YAML に移して、実際の実行履歴を見て判断できます。