Après plus de deux ans d’évolutions, l’équipe de développement est fière de vous présenter la version 2.0 d’evQueue, l’ordonnanceur de tâches événementiel libre (GPL v3).
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 d’une tâche pour instancier dynamiquement de nouvelles branches d’exécution.
L’objectif est d’extraire le flux de contrôle du code afin de donner une meilleure visibilité aux administrateurs système et aux développeurs. De plus, ce mode de fonctionnement assure la réutilisabilité du code avec le développement de briques élémentaires. 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.
Le projet propose deux orientations :
- un planificateur de tâches, qui peut être utilisé de façon autonome ;
- une API réseau qui permet la manipulation du moteur à distance et particulièrement depuis des pages Web. Ceci permet de rendre asynchrones les traitements intensifs ou longs : redimensionnement d’images, calculs, exportations SQL, envoi vers des FTP… Un suivi asynchrone pourra alors être proposé en AJAX, ce qui améliore l’expérience utilisateur et supprime les limitations de temps d’exécution du serveur Web.
La version 2.0 propose une interface de création de workflow en glisser‐déposer complètement refondue, ainsi que le gestion de la haute disponibilité. Il est ainsi possible d’utiliser evQueue en mode grappe de serveurs (cluster) (tous les nœuds étant actifs) afin de garantir une fiabilité accrue.
Un prise en charge de GIT a également été ajoutée, afin de faciliter la gestion d’environnements multiples (développement, production…).
evQueue est développé et maintenu par l’équipe informatique de l’UFC-Que choisir. Il est totalement intégré à notre système d’information depuis 2013. Environ 5 000 traitements sont exécutés chaque jour.
Aller plus loin
- Site officiel d’evQueue (1483 clics)
# UFC que choisir? - site & doc en anglais -
Posté par Gub . Évalué à -10.
A quand la défense des consommateurs de langue française?
Debian Stretch
[^] # Re: UFC que choisir? - site & doc en anglais -
Posté par elle . Évalué à 10.
Comme vous le savez peut-être Gub, la communauté informatique échange principalement en anglais, mais au lieu de critiquer une partie non primordiale de l'outil, je vous propose d'entrer en contact avec l'équipe et de proposer plutôt votre aide pour mettre au point une version française du site et de la documentation.
# Translation
Posté par NumOpen . Évalué à 3. Dernière modification le 04 novembre 2017 à 12:52.
un système de files -> un système de fichiers ?
Ou bien ce sont des files d'attentes ?
[^] # Re: Translation
Posté par Davy Defaud . Évalué à 1.
Comme il s’agit de parallélisation, je penche plutôt pour fils d’exécution. J’ai pris le risque d’effectuer une correction dans ce sens…
[^] # Re: Translation
Posté par coldsource . Évalué à 4.
Bonjour,
Il s'agit de files d'execution (de l'anglais queue). Ce système permet de gérer la parallélisation et de limiter le nombre maximum de tâches parallèles via la concurrence de ces mêmes files.
[^] # Re: Translation
Posté par Nibel . Évalué à 2. Dernière modification le 05 novembre 2017 à 13:39.
C'est bien files d'exécution (une file d'exécution) cependant et non pas fils (électriques).
Il n'y avait pas besoin de correction.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Translation
Posté par Davy Defaud . Évalué à 2.
Pourtant, lorsque l’on parle de tâches exécutées en parallèle, le terme consacré est bien fil d’exécution.
https://fr.wikipedia.org/wiki/Thread_(informatique)
[^] # Re: Translation
Posté par Nibel . Évalué à 2.
Exact, au temps pour moi.
Effectivement, pour moi nous parlions de queue et non de thread…
Je prendrai le temps de lire correctement la prochaine fois, promis.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Translation
Posté par NumOpen . Évalué à 8. Dernière modification le 05 novembre 2017 à 16:49.
Au fil de cette lecture, tout en faisant fi des fautes, je m'aperçois que la conversation s'effiloche. Je ne suis pas là pour enfiler des perles, je file avant le défilé de réflexions affligeantes des fils à papa.
[^] # Re: Translation
Posté par nicooo . Évalué à 4.
Il s'agit bien ici de queues, donc de files d'attente, et pas de threads.
Nicolas - UFC-Que Choisir
# Un concurrent ?
Posté par stephane74 . Évalué à 0.
Allez, pour ceux que ça intéressent je me permet de balancer un concurrent fort sympathique : www.sos-berlin.com
Ca tourne sous java, c'est assez bien fait et vraiment complet.
# Contraintes temporelles?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Est-ce que evQueue permets de gérer des contraintes de types au plus tôt / au plus tard ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Contraintes temporelles?
Posté par nicooo . Évalué à 3.
Bonjour devnewton,
Si je comprends bien, une contrainte au plus tôt consiste à dire « exécuter cette deuxième tâche dès qu'une première est terminée ». Ceci est le fonctionnement de base d'evQueue : un workflow est un enchaînement de tâches qui s'exécutent l'une après l'autre, dans l'ordre.
Sur cette capture d'écran, extraite de l'exemple d'un workflow qui fait l'équivalent de ls | wc -l, la deuxième tâche wc -l doit attendre que la première ls soit terminée avant de démarrer. Ça tombe bien car elle prend en entrée le résultat du ls.
Note qu'il est possible de mettre plusieurs tâches au même niveau (dans un même job) ; ces tâches s'exécuteront en parallèle, et quand toutes seront terminées, la ou les tâche(s) du job suivant pourra(ont) commencer à s'exécuter. C'est une implémentation du concept de barrière de synchronisation.
Pour revenir à la contrainte au plus tôt, il existe également une fonctionnalité avancée (evQueueWait) qui permet de formuler une condition très précise qu'une tâche devra attendre avant d'être lancée. Cependant, la combinaison de tâches à exécuter en parallèle et/ou de manière séquentielle suffit à répondre à la majeure partie des besoins.
Je ne vois pas trop ce qui pourrait coller à une exécution au plus tard dans evQueue. La date ou l'heure de fin d'un workflow n'étant pas connue à l'avance, on ne peut pas commencer « X temps avant ça ». Ai-je mal saisi la question ?
Nicolas - UFC-Que Choisir
[^] # Re: Contraintes temporelles?
Posté par Christophe B. (site web personnel) . Évalué à 3.
Au plus tard :
On ne connait pas la fin d'un workflow mais on ne veut pas qu'il démarre APRES une heure donnée
ou qu'il se coupe normalement a partir de l'heure donnée
Ex: je synchronise mon nas avec un claoude et de 2h du matin a 6h du matin
même si c'est pas fini je veu que la tache soit tuée à 6h du matin et cela reprendra le lendemain
[^] # Re: Contraintes temporelles?
Posté par nicooo . Évalué à 2.
Pour le démarrage du workflow, il semble que le planifier quotidiennement à 2h00 réponde à ce cas d'utilisation.
Pour le couper à une certaine heure, il n'existe pas encore d'option dans evQueue. Après discussion avec l'équipe, nous opterions pour une « durée maximale de workflow » (ici 4 heures).
Cependant, comment tuer le workflow ? Violemment à coup de kill -9 ?
En attendant, il est possible de planifier un deuxième workflow à exécuter tous les jours à 6h00, qui s'occuperait de terminer la tâche de synchronisation (quelle que soit la manière choisie).
[^] # Re: Contraintes temporelles?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Exemple: je dois récupérer des données mise à disposition sur un FTP entre 1h et 2h du matin, les traiter puis les uploader entre 5h et 6h sur un autre serveur.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Contraintes temporelles?
Posté par nicooo . Évalué à 1.
Pour cet exemple, deux workflows semblent appropriés.
Le premier est à planifier à 1h du matin, et va récupérer les données sur le FTP. La tâche pourra utiliser les retry schedules pour réessayer jusqu'à ce que les données soient disponibles.
Le deuxième workflow est à planifier à 5h du matin, il fera les traitements sur les données récupérées et les enverra sur un autre serveur.
Il pourra attendre que les données soient disponibles via les retry schedules.
Autre possibilité, en définissant une même file d'attente de concurrence 1 pour les deux tâches dans les deux workflows, on est sûr que le traitement des données ne débutera pas avant qu'elles aient été récupérées.
# En cours de test ...
Posté par Christophe B. (site web personnel) . Évalué à 2.
Bonjour,
je suis en train d'installer une debian8 pour voir un peu ce que votre outil a dans le ventre
idéalement il pourrait nous servir pour permettre a des nons informaticiens de lancer des opérations complexes
ex: dupliquer une arborescence d'un serveur a un autre
Mettre a jour une environnement de TEST par rapport a un environnement de DEV etc …
d’où mes questions :
Et en plus je suis abonné à Que Choisir :)
[^] # Re: En cours de test ...
Posté par coldsource . Évalué à 1.
Bonjour Christophe,
Oui c'est une utilisation que nous avons, des utilisateurs peuvent déclencher des traitements depuis l'interface directement ou depuis une interface ad-hoc qui utilise alors l'API evQueue pour déclencher le traitement.
Nous avons une gestion des utilisateurs :
La gestion des ressources est gérée nativement par le système de files qui est global à toutes les tâches. Si vous créez une file 'lecteur de cartouche' avec une concurrence de 1, il vous suffira ensuite d'assigner toutes les tâches qui utilisent le dit lecteur à cette file. Ceci vous garantit une utilisation exclusive de la ressource.
Vous avez un exemple ici
[^] # Re: En cours de test ...
Posté par Christophe B. (site web personnel) . Évalué à 2.
Merci pour vos réponses
C'est plus que prometteur comme outil, installation rapide …
Configuration simple (des que l'on a trouvé /etc/evqueue.conf ;) )
Comme pour les taches en // l'espace pour placer la tache sur les cotés est pas toujours facile a cibler.
=> comment fait on pour enlever une tache que l'on a posée sur le workflow ?
=> un bug / truc génant : parfois dans le paramétrage d'un workflow si l'on appui sur la touche ENTER … on ne peut plus rien faire … à part repartir dans la page précédente et perdre les modifs que l'on a fait
=> j'avais un gag avec les utilisateurs mais en retestant je ne reproduit pas le problème : je voyais bien les workflows mais impossible de les lancer (pas de droits)
voila pour les méchancetés …
Merci pour l'explication des files je n'avais pas compris a quoi cela pouvait servir …
L'expression des conditions n'est pas super intuitive et j'ai un peu de mal a voir quand il faut taper dans le shell scripts quand il faut utiliser l'interface Web pour faire de beau Workflow mais je n'ai que quelques heures de pratique …
En conclusion Bravo … un bien bel outil avec un approche pragmatique ( CLI / API / Web interface ) qui me plaît beaucoup
[^] # Re: En cours de test ...
Posté par coldsource . Évalué à 1.
Bonjour et merci de ce retour !
Quelques réponses aux points soulevés :
Pour supprimer une tâche il faut faire un clic droit dessus. Effectivement ce n'est pas dans la documentation je vais la mettre à jour.
Concernant la touche ENTER je n'ai pas été confronté à ce problème mais je vais faire des tests.
Si vous travaillez pas mal avec le moteur, vous verrez que la parallélisation est très pratique pour accélérer les traitements. Par ailleurs avec les files dynamiques, il est possible d'avoir une parallélisation par marchine (si les tâches s'exécutent en distant).
Les conditions font partie d'une utilisation qui est déjà un peu avancée. Elles fonctionnent en XPath donc si vous ne connaissez pas ce langage c'est un peu plus délicat au début. Ceci étant, nous sommes preneurs de vos retour pour améliorer la documentation : lorsqu'on a développé un outil, c'est parfois difficile de se mettre à la place d'un utilisateur débutant !
N'hésitez donc pas si avez d'autres retour, l'adresse email de contact est sur le site.
Bonne soirée,
# Impatient de tester
Posté par Binou . Évalué à 1.
Bonjour,
Connaisseur de BMC Control-M et utilisateur quotidien de la solution IBM TWS, Je testerai dans les prochains jours votre ordonnanceur et je vous ferai un retour si cela vous intéresse.
Par simple curiosité, quelles ont été vos motivations pour avoir décidé de se faire son propre ordonnanceur et ne pas choisir une solution d’ordonnancement existante ? Car il est vrai que c'est pas si simple que ça quand même …
Merci d'avance pour votre réponse.
Binou
[^] # Re: Impatient de tester
Posté par coldsource . Évalué à 1.
Bonjour,
Nous recevrons votre retour avec grand plaisir, et particulièrement si vous êtes connaisseur d'autres solutions du marché.
Concernant nos motivations, nous avions fait à l'époque un état des lieux et nos contraintes étaient les suivantes :
Nous n'avions pas trouvé de solution satisfaisante sur l'ensemble de ces critères. Nous avons donc commencé à développer une solution relativement simple. Avec le temps nous avons ajouté pas mal de nouvelles fonctionnalités et travaillé l'interface graphique… et sommes parvenus à la version actuelle !
[^] # Re: Impatient de tester
Posté par Binou . Évalué à 8.
Bonjour,
J'ai testé votre solution et je dois vous avouer que je suis très partagé par cette première utilisation. Veuillez garder en tête que ce qui suit sera très subjectif et comparé à ce que je connais. Avant toutes choses, je dois dire que le travail accompli est déja remarquable et je suis certains que pour une utilisation simple et restreinte, cette solution est tout à fait envisageable.
L'installation s'est correctement passé et il vrai que la simplicité est de rigueur. Je suis donc tombé sur une interface claire qui va à l'essentiel. Certainement un peu trop car je constate tout de suite que le développement du produit est clairement tourné pour avoir un résultat fonctionnel/efficace mais pas très pratique.
Je vous avoue également que mon premier réflexe n'était pas de lire la documentation utilisateur et j'ai eu tord car sans elle, le logiciel n'est clairement pas utilisable et c'est un vrai problème.
Sur la création d'un Workflow, lorsque je vois un icone de poubelle, ma première réaction est de sélectionner le Job et cliquer sur la poubelle et pas forcement glisser/déplacer l'objet sur la poubelle.
Toujours sur le Workflow, L'icone de sauvegarde ne sert à rien en l'état. Car lorsque je quitte la fenêtre, on m'oblige à sauvegarder.
Enfin, quand on supprime le dernier job d'un Workflow, on ne peut plus en rajouter et j'étais obligé de quitter la page. Vous allez me dire que c'est du détail mais on se sent vite frustré et en toute sincérité, si vous souhaitez que les gens utilisent votre produit, rendez le plus accessible en ajoutant beaucoup plus d'aide et en accompagnant l'utilisateur en commençant par avoir une vrai gestion des erreurs et pas simplement une petite fenêtre qui indique une erreur incompréhensible.
Pour l'aspect fonctionnel, j'ai eu du mal à comprendre qu'un tache n'est juste que la déclaration du binaire à utiliser pour réaliser l'action. Pourquoi je ne peux pas définir une tache avec !/bin/echo 'Première tache' ? Obliger de passer par un argument au niveau du Job qui se trouve dans le Workflow.
A mon sens, le niveau de 'tache' n'a pas lieu d’être et n'apporte aucun avantage vis à vis du job. Cet objet doit être fusionné avec le Job.
Le Job est la définition de l'action à réaliser avec ou sans ses différents paramètres/arguments (input/output, Condition OK/KO, connexion distante, etc ..). Le job doit pouvoir être mutualisé sur plusieurs Workflow. (1 seule définition, plusieurs manière de l'utiliser)
La tache rajoute de la complexité au processus et certainement beaucoup de dépendance.
Enfin, les deux solutions que je connais (Control-M et TWS) utilisent deux paradigmes que j'ai du mal à retrouver dans evQueue.
- La définition unique des objets en base : Elle représente l'ordonnancement attendu
- La gestion de l'ordonnancement par plan d’exécution : Elle représente l’exécution de l'ordonnancement attendu entre deux dates définit. (7J, 24H, …)
Que ce passe-t-il sur evQueue si je supprime une tache qui est en cours d’exécution ou qui peut prendre du temps à s’exécuter, ou qui est prévu de s’exécuter ? : Task execution : Unknown object name.
J'ai l'impression que la définition c'est le Workflow et le plan d’exécution c'est une fusion entre la Queue et le Scheduled Workflow.
Peux être que ces deux règles sont à remettre en cause mais s'ils ont fait ça, je suppose qu'il y a de multitude de bonne raison.
Par ailleurs, si vous suivez ces deux règles, la gestion de la concurrence prend tous son sens au chargement du plan. Ce n'est pas un objet de la Queue, c'est une ressource liée au Job.
Si aujourd'hui vous avez plus de 5000 jobs qui sont ordonnancés par evQueue, c'est que votre modèle fonctionne assez bien. Cependant, je peux vous dire qu'il ne ressemble pas au deux que je connais.
Pour finir, je peux également vous proposer des idées d'améliorations si çe stade de la lecture vous ne me detestez pas encore.
- Calendrier d’exécution (Inclusion/Exclusion de jour, Jour fériés ?)
- Utilisateurs partagés (1 objets user/mdp qui peut être utilisé dans plusieurs Jobs)
- Améliorer la gestion des conditions (Laisser libre : Cela peut être le statut du Job précédant mais aussi une simple chaîne de caractère attaché au Job précédant de type FIRSTJOB_FORCEOK)
- Modèle de Job (Job de transfert, Job de Webservice, Job de type Script: Objectif, faciliter la définition en ne saisissant que des paramètres tout en gardant la possibilité d'avoir un niveau avancé laissant libre la définition du Job)
- Sauvegarde / Restauration des objets
- …
J’espère que mes remarques ne seront pas mal interprétées et/ou mal perçues, je ne donnais qu'un premier avis. Actuellement, j'ai beaucoup de mal à utiliser votre solution mais peut être que je suis trop formaté à ce que je connais.
Je surveillerai les futures mises à jour avec beaucoup d'attention.
Merci de m'avoir lu.
Binou
[^] # Re: Impatient de tester
Posté par coldsource . Évalué à 1. Dernière modification le 22 novembre 2017 à 14:18.
Bonjour et merci pour votre retour.
Je vais tenter de répondre à vos diverses remarques.
Tout d'abord, concernant l'ergonomie de l'éditeur de workflows, il est vrai qu'elle peut être améliorée. Nous prendrons en compte vos remarques, même si en l'état passé 2H de travail, vous verrez que vous ne rencontrerez plus de problèmes.
Le produit étant maintenant assez complexe, je pense qu'il faut effectivement lire la documentation, tout du moins les différents concepts, si vous souhaitez utiliser pleinement les enchaînements de tâches et pas simplement exécuter une commande. La plupart de vos remarques viennent à mon avis d'une mauvaise compréhension des concepts.
Lorsque vous déclarez une tâche, il est tout à fait possible de passer directement des arguments comme vous le souhaitez si ces arguments sont statiques. L'ajout d'argument via l'édition permet d'ajouter des arguments dynamiques qui proviennent par exemple de sorties de tâches précédentes (très utile avec les boucles).
La notion de tâche et de job est elle aussi expliquée dans la documentation. Ces deux entités servent à la gestion de la parallélisation et au contrôle de flux. Un job peut contenir plusieurs tâches. Il se termine quand l'ensemble des tâches est terminé. Il assure donc un rôle de barrière de synchronisation. Par ailleurs, vous pouvez également mettre une condition sur un job, ce qui va permettre de ne pas exécuter l'ensemble des tâches qu'il contient au lieu de dupliquer la condition autant de fois que le job contient de tâches. Il en va de même pour les boucles qui peuvent être positionnées sur les jobs ou les tâches. Une boucle sur un job va dupliquer l'ensemble de ses tâches.
Supprimer une tâche utilisée dans un workflow est une erreur de développement. Les tâches n'ont pas vocation à être supprimées si elles sont utilisées. Il est vrai par contre que nous pourrions ajouter un avertissement pour éviter des erreurs de manipulation. La définition des tâches permet avant tout de contrôler les paramètres d'entrée sortie (mode XML ou texte par exemple).
evQueue ne fonctionne pas par plan d'exécution. Un workflow n'est pas un plan, c'est un enchainement de tâches simples qui a vocation à effectuer un traitement. Par exemple, récupérer un fichier sur un serveur FTP, puis traiter ses données et enfin les insérer en base. Ceci peut être réalisé par 3 tâches. L'intérêt est d'apporter de la visibilité aux administrateurs et développeurs en cas de problème (au lieu d'avoir un grand code monolithique). Autre exemple : redimentionner des images. C'est un cas très fréquent sur le web et très consommateur de ressources. C'est ici que les boucles et la parallélisation prennent tout leur sens. C'est bien pour cette raison que les files sont globales : si 100 personnes uploadent des photos sur notre site, nous ne souhaitons pas que tous les traitement démarrent en même temps. C'est donc evQueue qui va gérer la cadence en fonction du paramétrage des files pour ne pas surcharger la machine qui effectue les traitements.
Les sauvegardes sont déjà possibles via Git au niveau des workflows et des tâches.
Les conditions sont libres, elles utilisent le langage XPath.
La gestion des jours fériés est effectivement une bonne idée, de même que l'inclusion ou exclusion de jours.
Enfin, et de manière générale, notre solution propose une approche différente des solutions du marché. Ce n'est donc pas très étonnant que vous trouviez cela déroutant. L'orientation est résolument tournée Web avec des déclenchements dynamiques, via des actions des utilisateurs par exemple (upload d'un contenu, prise d'une commande etc). Le but est de clarifier les traitements en les subdivisant en sous parties visibles pour un non développeur tout en assurrant une gestion des ressources de la (des) mâchine(s) hôte(s).
Cordialement,
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.