Quand votre travail est trop difficile pour cron

Les tâches Cron sont cool. Mais parfois, une tâche Cron ne suffit pas. Exécuter une tâche de temps en temps peut être une bonne chose pour certaines tâches, mais qu'en est-il si vous avez une tâche vraiment importante ? Une tâche qui a besoin de l'aide d'un processus de longue durée.

Pour les tâches importantes, une tâche Cron ne suffira pas.

Ce dont vous avez besoin, c'est d'une instance de worker dédiée ; des instances d'application de worker qu'Upsun fournit maintenant, bien sûr.

Qu'est-ce qui ne va pas avec Cron ?

Les tâches Cron sont parfaites pour ce qu'elles sont : Des tâches uniques relativement courtes qui s'exécutent à un moment ou à des moments spécifiques. Upsun supporte les tâches cron personnalisées depuis la nuit des temps. (Environ 3 ans en temps d'Internet.) Elles ont cependant un certain nombre de limitations :

• Les tâches Cron sur Upsun s'exécutent sur le même conteneur que votre instance d'application, ce qui signifie qu'elles sont en concurrence pour les ressources.
• Une tâche Cron réussit ou échoue entièrement, ce qui la rend peu adaptée à une tâche sur laquelle on veut travailler de manière incrémentale.
• Nous limitons les tâches cron à une exécution toutes les 5 minutes, ce qui signifie qu'une tâche qui doit être effectuée "maintenant, mais pas dans la requête web" peut se produire jusqu'à 5 minutes plus tard.
• Une tâche cron en cours d'exécution bloque le déploiement d'un nouveau code
• Si une tâche cron est toujours en cours d'exécution lors de son prochain déclenchement, elles peuvent se marcher sur les pieds et perturber l'état de l'application, à moins que vous ne fassiez très attention à la façon dont elles sont écrites.

En règle générale, les tâches Cron doivent être utilisées lorsque quelque chose doit se produire à un moment précis. Par exemple, si vous devez transférer un export CSV, tous les jours, après minuit.

Qu'est-ce qu'un worker ?

Les workers sont plus généraux et plus flexibles que les tâches Cron. Ils travaillent généralement de manière itérative sur des tâches fines, comme une queue, et parce qu'ils sont un processus persistant, ils peuvent travailler sur une tâche immédiatement après qu'elle ait été mise dans la queue.

Sur Upsun, un worker est une instance parallèle de votre application qui ne répond pas aux requêtes web. Au lieu de cela, il exécute un processus d'arrière-plan différent et persistant. Il s'agit exactement du même code, qui exécute simplement un processus autre que l'écoute des requêtes web entrantes.

Il est donc rapide d'implémenter votre application de manière traditionnelle et synchrone, puis, avec quelques changements, de transformer le gros du travail en asynchrone. C'est utile pour le traitement en masse, pour gérer de queues, pour les tâches de longue durée ou pour tout ce qui doit être fait "le plus rapidement possible, mais sans bloquer la requête web".

(Si vous avez besoin d'une application totalement distincte, éventuellement écrite dans un autre langage, consultez notre support multi-applications).

Il est également possible de combiner plusieurs applications. Par exemple, un envoi massif hebdomadaire peut être déclenché par une tâche Cron qui s'exécute une fois par semaine et met dans une queue une longue liste d'e-mails à contacter. Un employé commencerait alors immédiatement à parcourir cette file d'attente et à envoyer les courriels un par un. (L'envoi d'e-mails prend beaucoup plus de temps que la simple mise dans la queue des tâches à effectuer). Vous pouvez même créer plusieurs workers identiques pour traiter la queue encore plus rapidement.

L'utilisation de workers Upsun peut rendre votre application web plus rapide et plus réactive, tout en réduisant la latence de vos tâches d'arrière-plan et en rendant l'ensemble du système plus robuste et plus facile à gérer.

Bien, comment cela fonctionne-t-il ?

La mise en place d'un worker est assez simple. Pour le cas le plus basique, il suffit d'ajouter quelque chose comme ce qui suit à votre fichier ./.upsun/config.yaml:

applications:
    myapp:
        <snip> 
        workers:
            queue:
                commands:
                    start: |
                        php worker.php

Votre application sera ainsi déployée deux fois, dans deux conteneurs distincts : un pour gérer les requêtes web (exactement comme il le fait maintenant), et un second conteneur nommé "queue" avec exactement le même code qui exécutera worker.php au lieu d'un serveur web. Il n'est pas nécessaire que ce soit un script PHP, bien sûr. Il peut s'agir de n'importe quelle commande que votre conteneur d'application peut exécuter.

Par exemple, un site Drupal peut utiliser le module Drush Waiting Queue pour faire fonctionner sa queue comme une vraie queue, plutôt que de s'appuyer sur cron. Une application Ruby on Rails peut utiliser sidekiq avec une instance persistante de Valkey pour faire tourner une longue queue de tâches de fond. Les développeurs Symfony ou Laravel peuvent faire de même avec le portage PHP de Resqeue, tandis que les utilisateurs de Python peuvent opter pour Celery.

Les workers peuvent également être soutenus par un serveur de queues dédié qui offre des fonctionnalités plus fines, comme la RabbitMQ. C'est votre application, alors choisissez l'approche qui vous convient le mieux.

Les workers sont bien sûr beaucoup plus flexibles que les quelques lignes montrées ci-dessus, mais vous pouvez consulter la documentation pour savoir comment vous pouvez personnaliser une instance de worker en fonction de vos besoins, et même faire tourner plusieurs workers pour différentes tâches.

Pour les tâches les plus difficiles, mettez en place un véritable processus de worker.