perform_later et deliver_later fonctionnent comme avant.
Ce que ce tutoriel couvre
- Ajouter Solid Queue et ses tables à une application existante.
- Faire pointer Active Job vers Solid Queue, un environnement à la fois.
- Exécuter Solid Queue avec sa propre commande ou avec le plugin Puma.
- Lire les tables qu’il crée, et contrôler l’ordre dans lequel les jobs s’exécutent.
Prérequis
Rails 8 génère les nouvelles applications avec Solid Queue déjà configuré. Si vous avez exécuté
rails new sur Rails 8, l’étape d’installation ci-dessous est déjà faite, et vous pouvez passer directement à l’exécution du worker.Installer Solid Queue
Ajoutez le gem, installez ses migrations, et migrez :Faire pointer Active Job vers Solid Queue
Définissez l’adaptateur de queue par environnement, dansconfig/environments/development.rb puis à nouveau dans config/environments/production.rb :
config/environments/test.rb sur l’adaptateur :test, sauf si vous avez une raison de faire autrement. Les tests qui vérifient des jobs mis en file d’attente sont plus simples à écrire avec l’adaptateur de test.
Définir l’adaptateur fait seulement écrire les jobs par Rails dans la base de données. Rien ne les exécute avant que le processus worker ne soit lancé, donc mettre un job en file d’attente sans qu’il se passe rien est normal à ce stade, et non une erreur de configuration.
Exécuter le worker
Comme processus séparé
Procfile et gérez plusieurs processus.
À l’intérieur de Puma
Si vous préférez ne pas gérer un second processus, Solid Queue fournit un plugin Puma. Ajoutez-le àconfig/puma.rb :
bin/rails server vous donne les deux. Par défaut, Solid Queue crée des processus worker et dispatcher séparés par fork. L’intégration Puma d’AppSignal rapporte la capacité du serveur web plutôt que celle des jobs. Utilisez l’intégration Active Job pour surveiller les performances des jobs.
Ce que Solid Queue stocke
Chaque partie de l’état de Solid Queue est une table Active Record, si bien que vous pouvez l’interroger depuis la console Rails plutôt que d’interroger un service séparé.
Pouvoir lire et corriger la ligne d’un job est une réelle différence par rapport aux queues basées sur Redis, où modifier un job en place est déconseillé. Utilisez cette possibilité pour réparer une erreur, pas comme une pratique courante lors de l’exécution des jobs.
Ordre des queues et priorité
Deux mécanismes décident de ce qui s’exécute ensuite, et ils se combinent. Ordre des queues. Un worker configuré avec une liste de queues les vide dans l’ordre indiqué. Un worker qui écoutereal_time puis background vide toujours real_time en premier.
Priorité. Les jobs portent également une priorité entière. La valeur la plus basse gagne, et le compte commence à zéro, si bien qu’une priorité de 0 prime sur une priorité de 1.
Surveiller Solid Queue avec AppSignal
AppSignal instrumente Solid Queue via son intégration Solid Queue et, pour tout ce qui est mis en file d’attente via Active Job, via son intégration Active Job. Les jobs sont rapportés dans le namespacebackground, séparé des requêtes web, si bien qu’un job lent ne fausse pas vos percentiles de requêtes.
Deux choses valent la peine d’être mises en place une fois que Solid Queue fonctionne :
- Les erreurs des jobs échoués. Une ligne dans
solid_queue_failed_executionsvous indique qu’un job a levé une exception. Le suivi des erreurs d’AppSignal vous indique ce qu’il a levé, à quelle fréquence, et avec quels arguments. - La durée des jobs et le queue time. Chaque job obtient une trace de performance, décomposée en événements qu’il a exécutés. L’intégration Active Job rapporte combien de temps les jobs attendent avant de s’exécuter. Un queue time qui augmente peut signifier que les jobs arrivent plus vite que les workers ne peuvent les traiter.
Transcription
Transcrit à partir de la vidéo et légèrement édité : les sous-titres automatiques ont mal compris plusieurs noms de produits et d’API, et ceux-ci ont été corrigés.Lire la transcription
Lire la transcription
0:02 Salut à tous, dans cette leçon, nous allons parler de la façon d’utiliser Solid Queue dans vos applications Rails. Si vous venez d’un autre backend Active Job, comme peut-être Sidekiq : Sidekiq nécessite Redis pour l’envoi des jobs. Votre application Rails envoie donc un message à Redis, Redis est surveillé par Sidekiq, qui déclenche les jobs. Good Job est un autre outil similaire, mais il utilise votre base de données Postgres, et Solid Queue lui est très similaire, puisqu’il va utiliser la base de données de votre application Rails. Vous exécutez donc une migration, ajoutez quelques tables, et un processus va s’exécuter et surveiller votre base de données pour détecter les jobs.0:41 Ce qui est intéressant ici, c’est que vous n’avez pas besoin d’un service supplémentaire comme Redis. Si vous ne l’utilisiez pour rien d’autre, vous auriez dû ajouter Redis pour utiliser Sidekiq, et ceci est une façon d’utiliser simplement la base de données existante que vous avez déjà. Mettons donc en place un exemple. Je vais démarrer une toute nouvelle application Rails, et je vous montre, pour référence, que nous sommes sur Rails 7.1. Nous exécutons
rails new, et nous appellerons notre application Solid Queue Example. Nous revenons dans un instant une fois que c’est créé, et nous ajouterons Solid Queue, et mettrons en file d’attente quelques jobs. Bien, allons dans notre Solid Queue Example, et faisons bundle add solid_queue pour l’ajouter à notre Gemfile.1:30 L’étape suivante consiste à installer les migrations, puis à faire db:migrate. Cela pourrait changer à l’avenir, il y aura probablement un script d’installation qui fera cela directement, car une autre chose actuellement nécessaire est un fichier de configuration. Nous exécutons donc ceci pour installer les migrations, puis nous pouvons faire rails db:migrate pour l’ajouter à notre base de données. J’utilise SQLite dans cet exemple, mais vous pouvez utiliser Postgres ou MySQL, et la prise en charge de MS SQL et d’autres bases arrivera probablement bientôt, avec d’autres améliorations à venir. Mais ici, vous voyez que cela crée un, deux, trois, quatre, cinq, six, sept, huit, neuf tables pour gérer votre job.2:14 Vous pourrez donc consulter ces tables plus tard pour voir ce qu’elles font au fur et à mesure que nous mettons des jobs en file d’attente, mais testons d’abord la commande. Je vais vous montrer qu’elle va planter et dire qu’aucun fichier de configuration n’a été trouvé. Nous pouvons donc créer config/solid_queue.yml, et maintenant notre processus Solid Queue peut s’exécuter. Cela va fonctionner sans problème. Par défaut, cela démarre un dispatcher et un worker qui écoutent toutes les queues.2:50 Le dispatcher est essentiellement le superviseur qui maintient tous les workers et suit les processus et tout le reste. Les workers effectuent le traitement réel du job. Par défaut, cela écoute donc toutes les queues, avec un pool de threads de taille cinq, et met en place un processus pour cela avec la configuration par défaut. Vous pouvez toujours ajuster cela pour votre cas d’usage et dire que vous avez besoin de 10 processus qui doivent gérer différentes queues et tout ça, mais nous allons garder ces valeurs par défaut pour l’instant. Nous pouvons maintenant exécuter une application Rails et créer quelques jobs.3:26 Nous pouvons donc soit générer un mailer, disons un mailer, nous avons un mailer utilisateur et nous voulons le notifier, par exemple, d’un reçu de paiement. Nous pourrions aussi simplement créer un job, comme un job d’import qui a quelque chose à faire. Ensuite, nous pourrons ouvrir la console Rails. Mais d’abord, allons dans nos config environments. Nous ferons cela juste après.3:57 Nous allons dans config/environments, et vous y définissez une ligne de config : config.active_job.queue_adapter = :solid_queue. C’est la ligne qui fait la magie de relier Active Job à Solid Queue, et elle commencera à envoyer les jobs vers la base de données. Ensuite, nous avons besoin de ce processus séparé pour réellement exécuter les workers de jobs et le dispatcher afin que le travail soit effectué. Car si nous en restons là, Rails va mettre les jobs en file d’attente et rien ne les écoutera à moins que nous ne démarrions cet autre processus. Vous pouvez aller dans votre environnement de test pour ajouter cela ici, et l’ajouter en production.4:43 Peut-être que pour votre environnement de test, vous voulez garder l’adaptateur de test, ce qui est tout à fait normal et facile à utiliser. Mais en production, vous ferez cela aussi. Bon, laissons test avec l’adaptateur de test pour l’instant, et configurons Solid Queue en development. Bien, maintenant nous pouvons aller regarder notre application Rails. Nous ouvrons donc la console Rails et exécutons UserMailer.receipt.deliver_later, ce qui met le job en file d’attente.5:18 Vous verrez qu’il indique que cela a été pris en charge par Solid Queue, qui a mis un job en file d’attente. La queue par défaut a un identifiant Active Job et toutes les autres informations d’Action Mailer, puis le job d’envoi de mail a été mis en file d’attente et nous a été retourné, en disant, voilà. Nous pouvons aussi configurer ce job d’import et appeler perform_later sur celui-ci. Nous ne faisons encore rien avec ces jobs, mais ils vont être mis en file d’attente, et nous pouvons regarder dans notre base de données pour voir ce qu’il y a dedans. Comme nous utilisons SQLite, nous aurons notre base de données development.sqlite dans le dossier storage.6:00 C’est donc ce que nous voulons ouvrir dans un outil comme TablePlus, pour pouvoir explorer et voir ce qui se passe ici. La première table que nous avons est blocked_executions. Laissez-moi redimensionner cela. Table blocked_executions, claimed_executions, failed_executions, et solid_queue_jobs est l’endroit où nous voyons nos deux jobs que nous venons d’ajouter. Rien n’est encore traité, donc les jobs sont simplement là, en attente.6:29 Ils ont les arguments qui leur ont été donnés, des priorités que vous pouvez utiliser pour dire que ce job est plus prioritaire qu’un autre, puis il y a aussi l’identifiant Active Job, le moment où il a été planifié, et le moment où il a été créé et mis à jour, et cela garde aussi une trace du moment où il s’est terminé. Ce sont donc toutes les informations du job. Nous avons solid_queue_pauses, il semble donc que nous pourrons mettre un job en pause et interrompre son exécution en plein milieu. Nous avons nos processus, donc si nous démarrons nos workers Solid Queue, cela apparaîtra ici. Nous verrons le dernier heartbeat, et cela garde une trace de tout ça.7:10 Nous avons aussi ready_executions et scheduled_executions. Nous pouvons donc avoir des jobs et ces executions, et lorsque nous créons ces jobs, une execution est automatiquement mise en place pour nous. Nous pourrions donc créer un job puis le planifier pour plus tard. Il pourrait aussi être récurrent. Tout ceci est conçu pour gérer une grande partie de tout ça pour nous.7:30 Nous n’avons pas besoin de savoir grand-chose sur son fonctionnement interne, mais nous voulons connaître ces priorités et ces queues, car les queues peuvent aussi dicter la façon dont les jobs sont traités. Et je sais que c’est aussi mentionné ici. Euh, euh, euh… Voilà, ordre des queues et priorités. Donc si vous spécifiez une liste de queues pour un worker, elles seront traitées dans l’ordre donné, par exemple si vous choisissez real_time puis background, les jobs de real_time auront toujours priorité sur les autres.8:03 Mais vous pouvez aussi donner des priorités entières au job. Vous pouvez donc dire qu’il y a une priorité de zéro ou une priorité de un. La priorité zéro sera toujours plus importante, et elles commencent à zéro, un peu comme un tableau. Zéro est donc le premier élément, un le suivant, et ainsi de suite.8:26 Voilà pour cela, et c’est là que nous voyons cette priorité ici dans nos executions. Maintenant, nous pouvons exécuter notre commande pour démarrer Solid Queue. Nous aurions donc Rails qui s’exécute dans un serveur, dans un processus différent, et nous mettrions des jobs en file d’attente, ce qui pourrait venir de tâches rake ou de n’importe où ailleurs, tout comme vous utiliseriez Active Job par ailleurs. Et nous verrons qu’il exécute ces deux jobs et qu’ils se sont terminés. Le job numéro deux a été plus rapide que le job numéro un, qui était l’email, et il a pris en charge ces deux jobs et affiche simplement la sortie habituelle que vous verriez normalement, comme dans vos logs Sidekiq également.9:10 C’est donc à peu près tout. Il n’y a pas énormément de choses intéressantes à explorer. Nous voyons que ces processus sont maintenant visibles ici, si bien que nous pouvons interroger notre base de données. Si nous voulons voir dans un dashboard combien de workers nous avons et ce qu’ils font, nous pouvons simplement interroger la base de données au lieu d’avoir à communiquer avec, vous savez, un autre processus sous Linux ou autre. Nous avons toutes ces informations directement disponibles dans des modèles Rails, ce qui est vraiment génial.9:44 Aussi, une des choses déconseillées avec Sidekiq, c’est par exemple d’essayer de supprimer un job ou quelque chose comme ça. Ici, nous aurons un accès facile à la base de données. Donc pour les jobs, vous ne voulez probablement pas trop bricoler avec, mais si vous avez déjà fait une erreur et devez modifier les arguments d’un job ou changer la priorité ou quelque chose comme ça, vous avez accès à cela dans votre base de données, et vous pourriez le faire si nécessaire. C’est donc un outil assez sympa. Ce qui est génial, c’est que nous n’avons pas besoin d’un autre service en cours d’exécution ou quoi que ce soit de ce genre.10:20 C’est juste là, pour nous, dans notre base de données, et cela ne nécessite pas, vous savez, Redis ou autre chose. Une autre chose sympa que je voulais souligner, c’est qu’il y a un plugin pour Puma. Donc dans vos applications Rails, si vous ne voulez pas exécuter cela comme un processus séparé, c’est une fonctionnalité sympa que nous pouvons utiliser. Beaucoup d’entre nous ont maintenant des Procfiles et utilisent le bundling CSS et JS ou autre, ce qui nous amène à devoir exécuter plusieurs processus.10:48 Si nous allons dans VS Code, nous pouvons ouvrir config/puma.rb, et ici, en bas, à côté de plugin :tmp_restart, qui écoute la modification du fichier tmp restart pour redémarrer Rails, nous pouvons aussi ajouter ce plugin. Quand Puma démarre, il exécute aussi Solid Queue, et quand Puma s’arrête, il arrête aussi Solid Queue. Vous voyez donc ici que lorsque nous démarrons notre application Rails avec rails server, nous obtenons beaucoup de logs des processus Solid Queue qui surveillent la base de données. Par défaut, cela vérifie environ toutes les 100 millisecondes, soit environ 0,1 seconde.11:30 Je pense que c’était la valeur par défaut que j’avais vue dans le code plus tôt. Cela fait donc beaucoup de requêtes à votre base de données, mais pas si souvent, car vos bases de données sont très performantes, et cela ne fait que les surveiller. Donc quand vous mettez un job en file d’attente, cela devrait prendre environ un dixième de seconde avant qu’il commence à s’exécuter et soit détecté. Cela sera donc très rapide et performant, et fonctionnera simplement en parallèle de tout le reste. Et nous pouvons faire Ctrl+C, Puma va arrêter Solid Queue et arrêtera aussi l’application Rails, tout ça dans un seul processus, ce que je trouve vraiment très pratique comme fonctionnalité si vous n’utilisez pas de Procfile et ne gérez pas déjà des processus séparés.12:15 C’est agréable, et intégré. C’était toujours quelque chose où, si vous déployez Sidekiq, vous voulez vraiment qu’il soit exécuté et surveillé par autre chose, et maintenant c’est une bonne façon de le faire. Et je pense que peut-être même Sidekiq peut faire cela aussi de nos jours. Mais voilà une introduction rapide à Solid Queue. Il n’y a pas beaucoup de fonctionnalités, car c’est essentiellement transparent en arrière-plan.12:39 Vous devez exécuter un processus, ajouter quelques tables à votre base de données, et c’est tout. C’est à peu près ça. Il utilise déjà le backend, ou l’interface, Active Job auquel vous êtes déjà habitué. Il n’y a donc vraiment rien à faire pour vous. Je recommande vivement d’essayer ça.12:57 Je sais que ça va devenir un gros sujet à l’avenir. Ce sera probablement intégré dans beaucoup d’applications, car c’est simple et facile d’utiliser le service de base de données que vous avez déjà. Voilà donc pour cet épisode. J’espère qu’il vous a plu. Si vous avez des questions sur Solid Queue ou quoi que ce soit du genre, dites-le-nous dans les commentaires ci-dessous.13:14 Nous y jetterons un œil et essaierons d’y répondre.