La version 3.0 d’evQueue est disponible

20
18
août
2020
Administration système

evQueue est un ordonnanceur de tâches événementiel léger. Il permet la planification de tâches (remplacement de cron), mais également la gestion d’enchaînements complexes intégrant des boucles et des conditions. Le moteur permet d’utiliser la sortie (XML) d’une tâche pour instancier dynamiquement de nouvelles branches d’exécution.

Il dispose également d’une API complète lui permettant d’être interfacé avec n’importe quel système externe (comme un site Web) afin de lui déléguer l’exécution des traitements lourds.

La parallélisation intégrée des tâches via un système de fils d’exécution permet l’accélération des traitements intensifs en temps processeur, mais également le contrôle des ressources.

Cette nouvelle version propose une interface en ReactJS basée sur des WebSockets côté serveur. L’interface est donc elle aussi totalement événementielle (l’ancienne version étant basée sur de l’AJAX. Les traitements apparaissent immédiatement sur l’interface de suivi ! Cette approche nous permet également de proposer l’interface sous forme d’extensions Firefox ou Chrome. Un serveur Web n’est donc plus nécessaire. De plus, vous pourrez bénéficier des mises à jour automatiques via votre navigateur.

Outre la refonte complète de l’interface, de nouvelles fonctionnalités sont proposées :

  • scriptage « en ligne » directement dans l’éditeur de workflows, le workflow est donc totalement autonome ;
  • un workflow peut exporter des « custom properties » qui sont utilisables pour filtrer les instances (utile pour retrouver quelle instance a effectué quelle action) ;
  • possibilité d’étiqueter les instances ;
  • possibilités de se connecter à plusieurs environnements (développement, production…) ;
  • Docker Compose peut maintenant être utilisé pour monter encore plus facilement un environnement.

Et toujours en standard :

  • une interface de création de workflow en glisser‑déposer ;
  • haute disponibilité ;
  • prise en charge de Git pour versionner les traitements et les publier sur différents environnements ;
  • réexécution automatique des traitements en échec ;
  • greffons de notification (courriel, XMPP, clavardage…) ;
  • parallélisation des traitements grâce aux fils d’exécution ;
  • code publié sous licence GPL.

Aller plus loin

  • # Airflow

    Posté par  . Évalué à 7.

    Si je comprends bien, c'est similaire au projet airflow d'Apache https://airflow.apache.org/

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Airflow

      Posté par  (Mastodon) . Évalué à 4. Dernière modification le 20 août 2020 à 06:50.

      Airflow semble avoir besoin d'une base de données pour son fonctionnement interne (sqlite par défaut), ce qui ne semble pas être le cas de evQueue. Airflow semble proposer tout un tas de visualisation statistiques et de générations de rapports, ainsi qu'une interface de type 'cartes mentales', alors qu'evQueue se concentre sur la création et l'exécution des flux de tâches. evQueue met clairement en avant les connexions ssh (bien qu'optionnelles), tandisqu'après 4mn de lecture de Airflow je n'ai pas lu cela : il semble plutôt proposer des greffons de types de connexions (ssh est comme l'intégration à aws ou à hashicorp et autres slack)
      Ces premiers éléments me font penser que "Airflow est un monstre, je vais essayer evQueue" :-)
      Des retours d'usages récents ?

  • # Questions

    Posté par  . Évalué à 3.

    Un serveur Web n’est donc plus nécessaire. De plus, vous pourrez bénéficier des mises à jour automatiques via votre navigateur.

    Il en faut bien un pour l'autre coté de la websocket, non ?

    Quand tu parle d'instance tu fais référence à quoi ? Tu peux avoir une grappe de serveur et balancer une tâche sur la grappe sans te soucier de qui la lance ?

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Questions

      Posté par  (site web personnel) . Évalué à 2.

      Je pense que c'est plus le fait que le serveur de webSocket est déjà intégré à la solution, et on a plus à passer pas un server apache ou autre pour l'ajax et l'execution de script back :)

      Essaie pour vivre sans brider les utilisateurs https://www.indiegogo.com/projects/iwinote

      • [^] # Re: Questions

        Posté par  . Évalué à 3.

        Oui dans la solution initiale il fallait le serveur evQueue et un serveur web avec PHP pour faire le pont. Maintenant le javascript se connecte directement au serveur websockets intégré à evqueue.

        • [^] # Re: Questions

          Posté par  . Évalué à 2. Dernière modification le 01 septembre 2020 à 11:57.

          Bonjour,

          Bravo pour le travail et merci pour l'information !

          Je (re-)découvre EvQueue, cherchant à le comparer (à tord ?) à Rundeck, que j'avais retenu comme solution gestionnaire de workflow en 2013, en alternative à $U et BMC Control-M.

          Je comprends donc là qu'il n'y a plus besoin de serveur web avec le module php,
          mais par contre, je ne comprends pas quand je lis sur le site officiel en page d'accueil :
          "evQueue is an open source job scheduler and queueing engine. It features an event-driven C++ engine and a PHP / MySQL web control interface which provides tasks monitoring and creation.".

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.