Tâches cron et workers en arrière-plan sans dyno séparé

Le cadre habituel d’une PaaS traite une tâche cron et un worker en arrière-plan comme des produits séparés de votre application web — un onglet différent du tableau de bord, parfois une ligne de prix différente. Ce ne sont pas vraiment des choses séparées. Ce sont des processus de la même application, ce qui mérite d’être pris au sérieux plutôt que traité comme un détail technique.

Ce que l’onglet Workers propose vraiment

Il ne montre que les gestionnaires de tâches qu’il peut vraiment trouver dans votre dépôt — pas une liste générique que vous configurez depuis zéro : des processus déclarés dans Procfile/Procfile.dev/app.json, ou des gestionnaires déjà dans vos dépendances (Sidekiq, Solid Queue, GoodJob, Resque, Celery, RQ, la queue de Laravel ou Horizon, un script npm run worker). Ajoutez-en un en un clic, ou pointez vers n’importe quelle commande longue durée vous-même si rien n’est détecté. Chaque worker fait tourner la propre image de l’application et se met à l’échelle indépendamment du processus web.

Ce dernier point compte plus qu’il n’y paraît : un worker n’est pas un déploiement plus petit et séparé qui dérive hors synchronisation avec le web — c’est le même build, la même release, le même retour en arrière, juste un type de processus différent qu’on met à l’échelle à part.

Des workers qui dorment aussi

Une application uniquement worker — aucun processus web, juste un consommateur de queue — peut quand même utiliser Sleep when idle sous Settings → General. Elle s’arrête une fois que son CPU rapporté a été inactif assez longtemps, et Railyard la réveille selon son propre horaire spécifiquement pour vider ce qui s’est accumulé dans la queue, puis la laisse se rendormir. Le motif qui se construit habituellement à la main (une tâche cron qui réveille un worker, une lambda qui vérifie une profondeur de queue) est juste une case à cocher ici.

Cron, séparément

Cron exécute une commande dans la propre image de l’application selon un horaire (0 3 * * *), avec un historique des exécutions conservé — aucun conteneur séparé, aucune image séparée à garder synchronisée avec le code réel de l’application, parce que c’est littéralement la même image que tout le reste fait tourner.

Pourquoi ça mérite d’être remarqué

L’alternative — une tâche cron définie quelque part en dehors du pipeline de déploiement de l’application, pointant vers une vieille image parce que personne ne l’a mise à jour au dernier déploiement — est un mode de défaillance spécifique et courant dans les plateformes qui traitent le travail planifié comme un citoyen de seconde classe. Faire tourner cron et les workers comme des types de processus d’une seule application veut dire qu’un déploiement qui corrige l’application corrige ses tâches planifiées et ses workers en même temps, par construction, pas en s’en souvenant.

Référence complète : Workers et tâches planifiées.