Dagu vs Argo Workflows

Argo Workflows vit sur Kubernetes. Dagu tourne sur une machine ordinaire.

Les deux définissent des DAG et exécutent les étapes dans l'ordre. Argo Workflows est intégré à Kubernetes et planifie chaque étape comme un pod. Dagu est un binaire unique qui appelle les commandes que vous avez déjà, sans cluster à opérer.

Un workflow exécutable sur un seul hôte
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]

Un binaire unique autonome, sans cluster Kubernetes

Du YAML déclaratif qui exécute des commandes existantes

Sans base de données externe ni message broker

Des executors pour shell, Docker, HTTP, SSH, SQL, sous-workflows et agents IA

De l'orchestration sans cluster en dessous

Argo Workflows suppose un cluster Kubernetes en marche et un controller qui transforme chaque étape en pod. Dagu n'a pas cette exigence. Vous posez un binaire sur un serveur, un portable ou une VM, et il tourne.

  • Tourne sur une machine ordinaire, sans Kubernetes, sans controller, sans etcd.
  • Garde l'état dans des fichiers locaux plutôt qu'une base de données ou un broker séparé.
  • Démarrez en local, puis passez au mode queue ou distribué quand la charge augmente.

Les étapes sont des commandes, pas seulement des conteneurs

Dans Argo Workflows, chaque étape est un conteneur qui tourne dans un pod. Dagu peut aussi lancer un conteneur, mais il appelle aussi directement un script shell, un endpoint HTTP, une commande SSH, une requête SQL, un sous-workflow ou une étape d'agent IA.

  • Réutilisez vos scripts et binaires sans packager chacun en image.
  • Mélangez des étapes Docker avec du shell, du HTTP et du SSH dans le même workflow.
  • Consultez exécutions, logs et historique dans une Web UI intégrée.

Quand choisir Argo Workflows plutôt

Argo Workflows convient mieux quand Kubernetes est déjà votre plateforme. Il est Kubernetes-native, planifie chaque étape comme un pod dédié et vise le container fan-out lourd. Dagu ne fait rien de tout cela.

  • Vous tournez sur Kubernetes et voulez des workflows définis comme CRD à côté de vos autres manifestes.
  • Vous avez besoin de pod scheduling, de node selectors et d'autoscaling de cluster par tâche.
  • Vos pipelines déploient des milliers de conteneurs sur plusieurs nœuds à la fois.

Argo Workflows vs. Dagu en un coup d'œil

Dimension
Dagu
Typical alternative
Runtime
Un binaire unique sur une machine ordinaire, appuyé sur des fichiers locaux.
Un cluster Kubernetes avec un workflow controller.
Ce qu'est une étape
Une commande : shell, Docker, HTTP, SSH, SQL, sous-workflow ou agent IA.
Un conteneur qui tourne comme un pod sur le cluster.
Cas idéal
Jobs ops, scripts et pipelines mixtes sur des hôtes que vous gérez déjà.
Pipelines Kubernetes-native, lourds en conteneurs ou de ML à grande échelle.

FAQ

Practical questions before adopting Dagu

Dagu remplace-t-il Argo Workflows ?

Pas pour toutes les équipes. Si vous êtes standardisés sur Kubernetes et voulez que chaque étape tourne comme un pod, Argo Workflows est le bon outil. Dagu convient mieux pour orchestrer des commandes sur une machine ordinaire sans cluster.

Dagu peut-il fonctionner sans Kubernetes ?

Oui. Dagu est un binaire unique autonome qui tourne sur un serveur, une VM ou un portable. Il n'a besoin ni de cluster Kubernetes, ni de base de données externe, ni de message broker.

Dagu peut-il quand même exécuter des conteneurs ?

Oui. Dagu dispose d'un executor Docker pour les étapes qui ont besoin d'un conteneur. La différence est que le conteneur est une option parmi les étapes shell, HTTP, SSH, SQL et sous-workflow, pas la seule unité d'exécution.

Start with one workflow.

Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.

Install Dagu