Découvrez un émulateur Tasks simple qui facilite le déploiement et le débogage.
Lorsque vous développez une application qui s'appuie sur Cloud Tasks (une application web, par exemple), vous avez besoin de visualiser le cycle de vie de vos Tasks : leur planification, leur livraison et leur traitement par un task handler. Pourtant, malgré une demande fréquemment exprimée, Google ne propose aucun émulateur pour développer avec Cloud Tasks, à l'image de ce qui existe pour Datastore ou PubSub.
Mon nouveau Cloud Tasks In-Process Emulator en Python répond à ce besoin. Si vous êtes pressé et souhaitez l'utiliser dès maintenant, rendez-vous directement à la section Démarrage rapide, ci-dessous.
Comment développer pour Cloud Tasks
Quatre options s'offrent à vous :
- Utiliser le service Cloud Tasks réel.
- Utiliser un émulateur sur localhost qui expose la même interface HTTP que Cloud Tasks.
- Faire l'impasse : ne pas se soucier du traitement des tasks. Vous pouvez laisser la création des tasks échouer en silence, ou déclencher des tasks sans handler défini.
- Utiliser un émulateur in-process. Vous l'injectez en développement, tandis qu'une implémentation reposant sur Cloud Tasks prend le relais dans les systèmes déployés.
Mes recommandations :
- Un émulateur in-process pour le développement
- Cloud Tasks réel pour les tests d'intégration dans le cloud
- Pas de Cloud Tasks dans les tests unitaires.
Voyons pourquoi.
Les avantages de l'in-process
Débogage
En développement, vous voulez savoir où se trouve chaque task et ce qu'elle contient. Avec un émulateur in-process, vous y parvenez directement depuis votre debugger, en mettant la file d'attente en pause et en inspectant les valeurs.
La simplicité, c'est précieux
Le code de cet émulateur reste volontairement très simple : il prend en charge uniquement la création et le traitement des tasks. C'est délibéré : une base de code épurée (ici, moins de 100 lignes) facilite grandement le débogage.
Par ailleurs, avec un produit en alpha — et tous les émulateurs Cloud Tasks, celui-ci compris, sont en alpha — mieux vaut garder l'intégralité du code sous contrôle direct, pour pouvoir le déboguer rapidement, voire le modifier.
Pour des fonctionnalités plus complètes et des tests plus réalistes, j'utiliserais le vrai Cloud Tasks dans une application déployée dans le cloud.
Facilité d'utilisation
D'autres émulateurs Cloud Tasks, comme gcloud-tasks-emulator de Potato London et cloud-tasks-emulator d'Aert van de Hulsbeek, s'exécutent sur localhost et présentent l'avantage d'exposer la même API que le service cloud ; il vous suffit de modifier l'endpoint. De plus, du code écrit dans n'importe quel langage peut les appeler, ce qui n'est pas possible avec l'émulateur in-process.
En contrepartie, ils ajoutent la contrainte d'un processus supplémentaire : il faut le lancer avant chaque session de développement et surveiller s'il a planté ou s'est figé. Et même si vous pouvez les déboguer en les lançant dans un debugger, cela sort généralement de votre flux de développement habituel.
Ne perdez pas vos Tasks
Vous pouvez choisir d'envoyer des tasks vers Cloud Tasks sans jamais les traiter, ou simplement de laisser leur création échouer en silence. Cela fonctionne bien si votre flux de développement principal n'inclut pas le traitement des tasks : par exemple, lorsqu'elles sont gérées dans un microservice distinct dont une autre équipe a la charge. Cette approche convient également aux tests unitaires, qui ne sont généralement pas destinés à tester des processus asynchrones distribués ; ce rôle revient aux tests d'intégration.
Mais si vous voulez voir ce qui se passe réellement avec vos tasks et comment le callback les traite, un émulateur d'une forme ou d'une autre s'impose.
Développer avec le cloud, ou sans
Pour un flux complet de bout en bout, vous pouvez aussi utiliser le vrai Cloud Tasks sur votre machine de développement, en bénéficiant de la même API et des mêmes fonctionnalités que sur le système déployé. Cette approche convient bien aux tests d'intégration exécutés dans le cloud.
Cependant, sur votre machine de développement, vous devrez disposer en permanence d'une connexion réseau ; et il vous faudra configurer un proxy comme ngrok pour permettre à Google Cloud Platform d'atteindre votre machine locale (comme décrit ici). L'API Cloud Tasks réelle nécessite aussi de vraies files d'attente, ce qui implique soit un projet Google Cloud personnel, soit une gestion des files telle que chaque développeur dispose des siennes.
Conséquence : déboguer ne serait-ce qu'un processus simple sur votre machine de développement vous renvoie vers la Cloud Console pour obtenir plus d'informations. Personnellement, je préfère m'éviter cette mise en place et garder le débogage au sein de mon propre processus.
Fonctionnalités et limites
Ce projet prend en charge les fonctionnalités que l'on utilise habituellement en développement : créer une task, puis la traiter dans un callback.
En revanche, par souci de simplicité (évoqué plus haut), il ne couvre pas d'autres fonctionnalités, telles que :
- La gestion des files d'attente, notamment la création, la suppression, le vidage, la mise en pause et la reprise. (Lorsque vous créez une task, la file est créée automatiquement si elle n'existe pas encore.)
- Les limites de débit et les nouvelles tentatives.
- La déduplication et la suppression des tasks.
Si vous souhaitez voir apparaître de nouvelles fonctionnalités (et si elles restent suffisamment simples pour justifier la complexité ajoutée), n'hésitez pas à soumettre des Pull Requests ou des Issues sur GitHub.
Démarrage rapide
Pour utiliser cet émulateur, copiez simplement emulator.py dans votre base de code — un copier-coller direct depuis GitHub suffit — et vous êtes prêt.
Créez un objet Emulator et passez-lui une fonction callback, qui recevra les payloads des tasks que vous créez. Ensuite, pour envoyer des tasks, appelez la méthode Emulator.create_task. Vous pouvez choisir le nom de la file d'attente ainsi que l'heure de livraison planifiée.
Exemple d'utilisation
Dans le projet, vous pouvez voir emulator.py à l'œuvre au sein d'une application web simple. Lancez-la en exécutant local_server.py. Rendez-vous ensuite sur http://127.0.0.1:8080 (ou cliquez simplement sur le lien qui apparaîtra dans la console) : une task sera alors créée. Elle sera traitée (affichée sur la sortie standard) trois secondes plus tard, comme prévu.
Si vous tenez à la propreté du code et souhaitez garder la base de code de production exempte de l'émulateur — en omettant emulator.py au déploiement —, cet exemple vous montre la marche à suivre. Dans local_server.py, utilisé en développement, nous injectons un Emulator. À l'inverse, sur un serveur déployé, où aucun Emulator n'est injecté, un nouveau CloudTasksAccessor est créé pour invoquer l'API Cloud Tasks réelle, ce qui maintient le code du serveur (main.py) libre de tout code d'émulateur.