La version 2.0 d’evQueue est disponible

Posté par Thibault Kummer . Édité par Nÿco, Davy Defaud et palm123. Modéré par Nÿco. Licence CC by-sa
28
3
nov.
2017
Administration système

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

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.

  • # UFC que choisir? - site & doc en anglais -

    Posté par . Évalué à -10 (+1/-30).

    A quand la défense des consommateurs de langue française?

    Xubuntu 16.04

    • [^] # Re: UFC que choisir? - site & doc en anglais -

      Posté par . Évalué à 10 (+23/-2).

      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 (page perso) . Évalué à 3 (+1/-0). Dernière modification le 04/11/17 à 12:52.

    un système de files -> un système de fichiers ?
    Ou bien ce sont des files d'attentes ?

    • [^] # Re: Translation

      Posté par . Évalué à 1 (+0/-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 . Évalué à 4 (+4/-0).

        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 (page perso) . Évalué à 2 (+1/-0). Dernière modification le 05/11/17 à 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 sentis la différence.

        • [^] # Re: Translation

          Posté par . Évalué à 2 (+0/-0).

          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.

          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 (page perso) . Évalué à 2 (+1/-0).

            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 sentis la différence.

            • [^] # Re: Translation

              Posté par (page perso) . Évalué à 8 (+7/-1). Dernière modification le 05/11/17 à 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 . Évalué à 4 (+3/-0).

            Il s'agit bien ici de queues, donc de files d'attente, et pas de threads.

            Nicolas - UFC-Que Choisir

  • # Un concurrent ?

    Posté par . Évalué à 0 (+1/-1).

    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 (page perso) . Évalué à 3 (+1/-0).

    Est-ce que evQueue permets de gérer des contraintes de types au plus tôt / au plus tard ?

    http://devnewton.bci.im

    • [^] # Re: Contraintes temporelles?

      Posté par . Évalué à 3 (+2/-0).

      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 . Évalué à 3 (+1/-0).

        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 . Évalué à 2 (+1/-0).

          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 (page perso) . Évalué à 3 (+1/-0).

        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.

        http://devnewton.bci.im

        • [^] # Re: Contraintes temporelles?

          Posté par . Évalué à 1 (+0/-0).

          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 . Évalué à 2 (+0/-0).

    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 :

    • je n'ai pas vu de gestion d'utilisateurs, certains pourrait executer des workflows et d'autres les paramétrer
    • existe t il une gestion de ressource ex un lecteur de cartouche est occupé par un tache ce qui permet aux autres taches d'éviter de se mettre en erreur et d'attendre la libération de la ressource

    Et en plus je suis abonné à Que Choisir :)

    • [^] # Re: En cours de test ...

      Posté par . Évalué à 1 (+1/-0).

      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 :

      • le profil admin est essentiellement réservé aux développeurs (ou admins) qui vont créer les workflows.
      • le profil utilisateur a des droits par workflow, par exemple il ne peut que lancer un workflow donné.

      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 . Évalué à 2 (+0/-0).

        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 . Évalué à 1 (+1/-0).

          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 . Évalué à 1 (+1/-0).

    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 . Évalué à 1 (+1/-0).

      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 :

      • Système Open Source
      • Gestion native de la parallélisation
      • Gestion de ré-essai sur les tâches en erreur
      • Accès aisé via une API pour une intégration avec le serveur Web
      • Légèreté et de préférence gestion en interface Web

      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 . Évalué à 7 (+7/-0).

        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

Envoyer un commentaire

Suivre le flux des commentaires

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