RabbitMQ Cluster Management - Météo France
language: FR
WEBVTT Il y a des gens qui ont déjà installé et qui n'arrivent juste pas à se connecter à l'interface d'admin. Pourtant le port est par défaut le bon, un 5, 6, 7, 2. Et la première suspicion qu'on a c'est est-ce que ce n'est pas un truc de firewall, est-ce que les ports sont bien ouverts, etc. Alors je vais vous mettre tout de suite sur la bonne voie. Ce n'est pas ça. C'est que cette interface de management, c'est un plugin aussi. C'est-à-dire que là pour l'instant vous avez installé RabbitMQ avec quelques plugins de base, mais les plugins ça s'active et ça se désactive. Donc je vous laisse farfouiller dans la documentation sur comment vous pouvez administrer la liste des plugins.
on 2024-03-13
language: NN
WEBVTT 噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi je vais aller regarder par là Philippe est d'accord bien sûr c'est pour plus jeune je reste que vous avez des questions est-ce que tout le monde a pu envoyer un message vers une QO et faire un binding au moins ? 噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi 噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi 噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi 噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi 噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi 噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi 噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi 噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi 噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi 噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi 噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi 噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi 噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi 噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi 噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi
on 2024-03-13
language: FR
WEBVTT Est-ce que tout le monde a pu envoyer un message vers une Qo et faire un binding ? Allez allez, encourageux, quelqu'un vient nous montrer. Vous voulez que je commence ? Sur mon écran partagé, je vais mettre ce que je vois. C'est une très bonne question à poser dont on n'a pas du tout discuté. Est-ce qu'on veut aussi spliter les messages ? Qu'est-ce que tu as mis sur ton exchange ? Je voyais aussi que sur tes QoS, tu avais mis le single active consumer. Les petits tags bleus qu'on voit, le SAC, c'est l'option au moment de créer la QoS de single active consumer qui a mis un trou. Il ne peut y avoir qu'un seul client connecté à la fois. Cela permet d'éviter des soucis de charge trop importantes. Tu limites puisque l'utilisation choisie chaque voiture va avoir sa propre Qo. Autant mettre des restrictions pour ne pas être emmerdé au niveau réseau. S'il y a des bugs, c'est le système qui nous empêchera de faire des bêtises. Le SAC sert à ça. Plutôt comme un garde-fou. C'est cool. Quelqu'un d'autre a fait différent et veut nous montrer ? Vas-y. Ouais. Typiquement, il faut que tu recrées un exchange. Oui. C'est un des trucs qui fait râler les gens régulièrement dans les forums. Les gens disent comment ça, je ne peux pas modifier les autres. Après, une fois que c'est en place, c'est en place. Ta seule solution, c'est de le détruire et recréer. Si tu as fait un lien... Je vais exprès répondre à ta question en disant que ça dépend. Si tu as un lien vachement fort entre les QoS et les exchanges, dès que tu touches un truc côté exchange, tu es emmerdé au niveau Q et potentiellement tu vas devoir refaire une nouvelle Q et bouger les messages. C'est possible aussi que tu aies un truc relativement découplé au niveau de la logique et que redéfinir l'exchange, le détruire et le recréer, ne t'oblige pas à changer quoi que ce soit au niveau des Q et des messages existants. Ça dépendra un peu du cas. Mais oui, s'il y a besoin potentiellement de bouger une Q... La réponse est la même si c'est une Q que tu veux modifier. Modifier les options. Là, il faut que tu fasses quelque chose des messages qui sont dedans. On verra des exemples demain de manipulations concrètes de merde, on a trois messages, il faut qu'on utilise une nouvelle Q maintenant. Qu'est-ce qu'on fait de ces trois messages ? On va avoir des solutions pratiques. Pourquoi on ne peut pas modifier ? La réponse sort un peu du cadre de la formation. Je pense que c'est un peu comme toutes ces technologies où les objets que tu crées, les exchanges, les Q, tout ça, ils ont un fonctionnement au bas niveau qui est vachement dépendant des options que tu as mises. Si tu veux changer une option, c'est pas du tout un truc au niveau virtuel que maintenant il va fonctionner plutôt comme ci que comme ça. Quand tu as mis l'option à la création, il a choisi une structure particulière pour fonctionner. Ce qui fait que si tu veux changer, tu dois recréer un qui va potentiellement avoir une forme différente. C'est ça, tout à fait. Modifier des options de configuration, c'est potentiellement un chantier de migration et non pas juste un flag qu'on active ou pas en lançant une commande. Non, tu ne peux pas. Maintenant, encore une fois, la réponse est non. Encore une fois, sur un exemple comme celui que vient de nous montrer Mathieu, où on choisit pour notre implémentation que c'est le client qui a besoin de consommer des messages qui définit la queue au moment où il se connecte. Il dit que si elle existe, tant mieux, mais si elle n'existe pas, crée-la. On s'attend à ce que ce soit toujours le deuxième cas. C'est-à-dire qu'on va faire en sorte que la queue disparaisse si le client se déconnecte. Tu vois, un truc dans le style. Du coup, cette question du renommage de la queue pose moins de soucis, puisque la responsabilité de la nommer, même de la créer, elle est au dernier moment et la responsabilité est côté client. Par exemple, la question est moins emmerdante que dans d'autres cas. Mais oui, effectivement, tu as tout à fait raison de dire qu'il faut se poser des questions avant d'aller en prod. Si tu configures quelque chose et que tu pars en prod sans avoir fait des tests de scénarios différents, est-ce que tous mes scénarios sont couverts et que j'ai de la flexibilité et de la performance dans un deuxième temps ? Oui, tu vas avoir des soucis. Est-ce que quelqu'un d'autre veut montrer ce qu'il a fait spécialement ? J'ai fait quelque chose d'assez proche de Mathieu. J'ai fait un exchange que j'ai appelé Traffic Update. Moi, j'ai mis deux types Topic, mais il se trouve que pour l'instant, je n'ai même pas mis de binding encore. Vous allez voir. Il est bindé à rien du tout. Donc je n'ai même pas fini le boulot. Par contre, j'ai fait même Philosophie. J'ai décidé que j'avais une queue par client et que je leur mette des noms comme ça, comme Mathieu, des noms variables. Je vais appeler ça. J'ai mis des points. Update.car.inidentifiant. Qu'est-ce que j'ai mis ? Je n'ai pas choisi le timeToLive comme tu nous as montré. J'ai fait l'autre méthode dont on a parlé dans la discussion. C'était de dire que je vais faire en sorte, je vais en ouvrir une des deux, elles ont la même config, les deux qui s'appellent Car. Update.car. Et puis ça, ce serait la partie variable entre guillemets de mes noms de queue. Alors, je leur ai mis une longueur maximum de 3. C'est-à-dire... Ah non, je dis une bêtise. Il y en a une C3, l'autre C5. Donc, déjà, elles n'ont pas la même. Donc, trois messages maximum ou cinq. Ce qui veut dire que je ne vais pas m'embêter à garder plus de messages que ça. Et tout va se faire automatiquement. Même si les messages arrivent plus lentement que ce à quoi je m'attends, comme je n'ai pas mis de time to leave, ils vont rester jusqu'à ce qu'ils disparaissent. Et le overflow ici, la propriété overflow, c'est pour le fonctionnement attendu quand il y a trop de messages, quand le quatrième message ici va se présenter. Donc, drophead, c'est celui qui est le plus en avant dans la file, va être dégagé pour que tous puissent s'empiler plus loin. Voilà. Le plus ancien disparaît. Singer Active Consumer, Mathieu l'avait mis aussi, puisque comme on a dit, c'est un bon garde-fou si c'est le mode d'utilisation attendu. Et puis, qu'est-ce que j'ai mis d'autre ? Ah oui, j'en avais fait une au début. Alors, je vais vous remontrer dans cette interface-là. J'en avais fait une, comme ça, qui s'appelait updates.car. Je ne sais pas, on va mettre un identifiant quelconque. Et je l'avais mis alors, max length, donc voilà, 5 messages, on va dire, overflow behavior drophead, très bien. Single Active Consumer, allez, comme ça, on s'évite des problèmes. Et puis, j'avais mis auto-expire. Auto-expire, ça fait quoi ? Je vous le rappelle, ça fait que s'il n'y a pas de client qui se connecte à cette queue, elle disparaît au bout d'un moment. Ce serait pas mal, ça, en fait, comme option dans notre système, parce qu'on va se retrouver dans la recette de queue, là, avec une queue par client. Imaginez, il y a 1000 voitures qui se connectent, on va avoir 10 000 queues, qui ont chacune très peu de messages. On aimerait bien que non seulement les messages disparaissent automatiquement, je pourrais même combiner les deux, je pourrais même mettre max length et message TTL, si je voulais être agressif sur mon effacement de messages, pourquoi pas. Le max length, dans ce cas-là, il éviterait que trop de messages s'empilent, et que mes queues deviennent trop longues. Et le TTL ferait en sorte qu'il n'y ait pas trop de données persistées qui servent à rien, parce qu'au bout de 2 heures, on peut considérer que je m'en fous, en fait. Je pourrais combiner les deux. Mais en plus de ça, je ne veux même pas garder les queues, s'il n'y a personne qui les lit. Et là, dans ce cas-là, ce serait tout à fait justifié de mettre un auto-expire. Et on peut considérer que c'est une queue par client. Peut-être qu'il va se déconnecter parce qu'il passe dans un tunnel, je ne sais quoi. On va lui laisser quelques minutes, peut-être, pour se reconnecter, éventuellement. Et au moment où il se reconnecte, il va dire, j'aimerais lire sur cette queue et créer là si elle n'existe pas. Sauf qu'il s'est reconnecté et elle existe encore, elle n'a pas expiré. Donc là, on voudrait peut-être lui laisser un temps, une chance, je ne sais pas, on peut mettre 10 secondes ou 30 minutes mais là, c'est un peu au choix. On va mettre une heure. 3600 x 1000. Si après une heure, il ne s'est toujours pas reconnecté, on dégage la queue pour ne pas nous encombrer. Donc notre système va se nettoyer tout seul. Et puis voilà ce que je disais. Je ne l'avais pas fait mais je peux aussi mettre un TTL. Par exemple, 10 minutes. 10 minutes, ça va faire 60 000, c'est ça ? 60 000, c'est ça ? Non, 600, je vais trop de mal. 1 minute 60, 600 000. Voilà, donc tu vois, avec un système comme ça, tu es tranquille parce que ça va se nettoyer tout seul. Tu ne vas pas voir grand chose mais rien n'empêcherait deux clients. Tu ne verrais pas de différence sauf que ça permettrait à deux clients de se connecter sur cette même queue. Concrètement, toi, pour ton système, ça ne changera pas grand chose. Ça peut être emmerdant sur un autre scénario où il y a un risque qu'il y ait des milliers de clients qui se connectent sur la même queue et que ça fasse un engorgement à ce niveau. Là, on pourrait imaginer une situation comme ça. D'ailleurs, ce sera l'exercice suivant. Là, on pourrait être embêté. Mais dans le cas ici, concrètement, si je ne le mets pas, si je mets d'ailleurs, regarde, on va mettre à false, tu vas voir, il ne va même pas mettre si flag dans les features. Il ajoute. Tu vois, ma carte ici, celle que je viens de créer, elle a TTL, elle expire, elle a donc aussi limit et overflow, mais elle n'a pas SAC, puisque j'ai mis false suite à ta question. Sauf que là, maintenant, cette queue qui n'a pas de clients, expire, donc là, j'ai mis une heure, donc on ne va pas voir, mais tout à l'heure, quand je l'ai fait, j'ai mis une minute. Et après une minute, elle a disparu, la queue, puisqu'aucun client ne s'est jamais connecté. Et donc, la queue, vu les règles que j'ai mis ici, elle a appliqué la règle, qui est « ça fait le temps que tu m'as dit que je n'ai pas de connexion, je m'effrace ». Ok ? Donc avec un système comme ça, tu peux faire du nettoyage. Et bien sûr, vous avez compris, il faut discuter avec les devs, notamment tous ces délais, par exemple. Je vais vous montrer autre chose. Et puis je n'ai même pas fait les bindings encore. Alors j'en ai fait une quatrième ici, que j'ai appelée « Update app » Android, etc. C'est juste pour discuter, c'est très abstrait encore, mais ce serait l'idée que, maintenant que mon système fonctionne, pourquoi ne pas permettre aussi de faire une application mobile qui recevrait des notifs aussi. Sauf que là, par exemple, ça m'intéresserait de pouvoir voir l'évolution du trafic en remontant un petit peu en arrière, donc de devoir faire une sorte de truc de replay pour voir si ça a changé. Et donc ce que j'ai fait ici, c'est que j'ai dit que celle-là pouvait avoir jusqu'à 20 messages. Et puis j'ai mis un TTL sur les messages, je ne sais même pas pourquoi. Mais l'idée, c'est que ici, par rapport aux autres, j'avais besoin que du dernier message sur un GPS de voiture. Le dernier message, c'est tout, ça suffit. Donc j'ai mis 3, 5, comme le maximum. Là, je mets 20 parce que peut-être sur l'application, je veux faire une espèce de replay avec les 20 derniers messages. Ici, il y en a 20. Et puis, j'ai fait ça un peu vite, j'ai même pas mis de overflow behavior ici. Donc on ne sait pas ce qui se passe quand il y a trop de messages. Alors justement, ça c'est une bonne question. On va tout de suite aller voir dans la doc. Il y a les modes de fonctionnement, c'est soit, quand la queue est pleine, quand tu mets maxlink, un nouveau message qui se présente va pousser tout, et donc le plus vieux, le premier dans l'air. Et puis, ça c'est drophead. Et l'autre mode de fonctionnement, c'est que le nouveau message qui se présente ne peut pas rentrer parce que la queue est pleine. Et puis là, t'as encore deux options. C'est-à-dire que ce nouveau message qui ne peut pas rentrer, il va soit être dropé, tout simplement, il ne va pas rentrer dans sa queue. Alors attention, c'est juste par ce binding. Peut-être que le message, avec d'autres bindings, il va quand même arriver au bout, par ce binding-là, sur cette queue, il ne rentre pas et il est dropé. Deuxième option, il n'arrive pas à rentrer, et il part dans les fameux dead letters, c'est-à-dire les messages qui n'ont pas réussi à être routés, ils vont dans un exchange spécial. Ouais. Ouais, c'est ça. C'est ça. Voilà, c'est ça. Et, un autre truc que je voulais vous montrer aussi sur les queues, est-ce qu'on va le voir ici ? Tu me remontes trop. On va le voir, il n'a peut-être pas. C'est bizarre, j'ai fait sur Fac. Je pensais que j'en avais fait autrement. Donc, pour continuer la discussion toujours sur cet exemple-là, on peut imaginer de faire updates car identifiant, ou puis de déclarer la queue comme transient. Alors, qu'est-ce que c'est, ça ? Vous vous souvenez, c'est, est-ce que ça survit au restart ? Posons-nous la question. Imaginons, on a 500 bagnoles connectées à notre système, chacune regarde sa queue, et puis, le serveur crasse. Bon, bah, a priori, côté GPS, il va dire « Ah, j'ai perdu la connexion ». Donc, au moment où ça va restarter ici, enfin, côté broca, est-ce que c'est vraiment pertinent de restaurer ces queues qui correspondent factuellement à une queue qui correspond à une connexion active d'un client qui a atterri sur ce node-là, quoi, auquel il a demandé de créer la queue pour lire les messages. Donc, si à un moment donné la connexion est érompue, a priori, on peut établir comme principe dans notre contrat avec les développeurs que le GPS, oui, il va essayer de se reconnecter, bien sûr. Mais du coup, il va potentiellement se reconnecter à un autre node dans le cluster, et donc recréer une queue là-bas. Ce qui veut dire que quand notre node qui a craché va restarter, on peut se débarrasser de toutes les queues sans problème, puisqu'elles correspondent à une connexion active. Et que même si par hasard, le GPS se reconnecte à nous, on peut tolérer de devoir recréer la queue et mettre des nominates, etc. Donc c'est une discussion, à voir si on peut se permettre de perdre toutes les queues. Plutôt oui, comme ça. Après, on peut imaginer un système où il n'y a pas de cluster, il n'y a que ce serveur-là. Et du coup, s'il y a une connexion qui pète entre la voiture et le node, on pourrait dire, ouais, ok, allez, on va restaurer les queues comme ça, les messages sont encore dedans, et puis celui qui se connecte, il retrouve ses messages, et bon, ça sera un cas particulier. J'irais que dans... si je devais faire une architecture comme ça, et qu'on se mettait en cluster, et que le GPS, la voiture, il se connecte à n'importe quel node disponible à tout moment, j'ai envie de dire, autant faire du ménage, et donc on met toutes les queues en transient. Il n'y a pas besoin de survivants en Vista. Vous voyez, c'est des trucs super bas niveau, des petites configs qui changent le fonctionnement à un niveau presque hardware, en tout cas, système. Mais en fait, c'est des questions métiers à se poser. Moi, c'est pour ça que je trouve très très intéressant cette technologie de broker de messages. Mais c'est... il faut que les devs et les amis communiquent bien. Alors, Leader Locator, j'en ai toujours pas parlé, on verra demain, c'est un truc lié au cluster. Est-ce que, sur toutes les options qui étaient disponibles pour les queues, vous avez eu des questions, expérimenté des trucs qui n'ont pas marché. On verra les deadletters très très bientôt dans la formation. Mais là, on a utilisé pour l'instant, vous voyez, auto-expire, message-ttl, overflow-behaviour, max-length, single-active-consumer, et puis max-length bytes, on l'a pas encore utilisé. C'est l'équivalent de max-length, mais plutôt pour une taille en fait. La place que prennent, le code de message. Je crois que c'est tout. Alors, je vous avais dit j'ai pas encore fait les... j'ai pas encore fait les bindings. Un téléphone qui s'est fait... Donc là, bon, je pourrais m'amuser, mais je pense que vous avez compris. Si j'ai bien compris tout, on va réussir à faire passer un message. Donc là, vers mon topic, je pourrais maintenant faire... Donc toi, t'as fait des directs ? Moi, je pourrais mettre, par exemple, ici, avec mon topic. Allez, je vais le faire. Est-ce que je peux faire ça ? New tab. Oui. Est-ce que je peux faire ça ? Ça va marcher, là ? Pas trop. Non, c'est pas mal. Allez, ça ira très bien. Donc, ce que je voudrais maintenant, c'est faire un seul binding. Pardon, une seule clé de routage. Tu vois, je vais dire que j'envoie ça updates.car. Il faut que je copie le nom ici. Je trouvais qu'ils auraient pu faire un petit effort et nous mettre des listes déroulantes. UGCVU, par exemple. Mais comme moi, j'ai pris un topic, je peux faire un truc de style traffic.cars. Donc, c'est une update de type traffic. Tu vois, ma clé de routage, elle peut être... Ça n'a pas forcément grand-chose à voir avec le nom de l'exchange ou le nom de la queue. Je ne vais pas mettre traffic, en fait. Je vais mettre... Info route.car. On va mettre en français. Info route.car. Et je vais mettre ici, par exemple, ce qui veut dire que maintenant, je peux... Alors attends, je ne dis pas de bêtises. Info route.car. On va faire comme ça. On va faire... On va faire 3. J'aimais bien la question qui a été posée sur la question de la position géographique. Donc, par cette queue, on va mettre info route.car. Point... sud-ouest. Et puis, par exemple, info route. On va mettre même... Regarde. Étoile.car.sud-ouest. Alors, c'est quoi, ça ? Donc, maintenant, là, ce que j'ai fait, c'est que je reçois toutes les mises à jour qui concernent les voitures. Mais tu vois, j'ai pas mis ici de... de dièse. Parce que je ne veux pas recevoir toutes les news de toutes les régions. Moi, je viens de m'abonner à la région sud-ouest. Donc, c'est le client, potentiellement, de cette voiture-là et qui a dit créer cette queue, d'accord ? Et puis, c'est probablement le client qui a créé ces bindings-là. Parce que lui, il sait qu'il est dans la région sud-ouest. Et donc, il a dit, ben voilà, je m'abonne, entre guillemets, aux news du sud-ouest. Donc, comment je fais ça ? Je fais un binding entre l'exchange traffic update et puis ma queue. Et donc, je vais l'appeler inforoute.carz.sud-ouest. Comme ça, toutes les infos qui concernent le sud-ouest, je vais les recevoir. Ensuite, peut-être que je vais avoir des messages qui vont concerner toutes les voitures de toutes les régions de nos pays. Et à ce moment-là, la clé de routage de ces messages, ça va être inforoute.carz. C'est-à-dire, je veux prévenir toutes les voitures. Par exemple, ça va être la vie de tempête sur la France, faites attention, risque de verglage, on ne sait rien, quelle que soit la région. Et tu veux l'envoyer à tout le monde, tout le monde. Donc, je m'abonne aussi à ça. Par contre, s'il y a un message qui est routé avec inforoute.carz.régionparisienne, ben là, je vais pas le recevoir, du coup. Tu as l'idée ? Et puis, la clé de routage du haut, là, c'est quoi ? C'est étoile.carz.sud-ouest. C'est tout ce qui va être des informations qui sont à destination des automobilistes dans le sud-ouest, mais qui ne sont pas, qui ne concernent pas le trafic, qui peuvent être, par exemple, je ne sais pas, des pubs, d'autres infos. Potentiellement, je vais pouvoir en fait aussi les recevoir. Je ne sais pas quelle va être leur nature. C'est au moment de recevoir le message que je verrai la clé de routage et que je déciderai si oui ou non, c'est pertinent pour moi. Mais en faisant un binding comme ça, maintenant, le système, il a la possibilité de m'envoyer des choses qui sont d'autres news, tu vois, qu'infos.route. Vous voyez, on peut créer de la complexité, en fait. Là, on ne gratte que la surface de ce qui est possible. Et puis, bien sûr, on peut aussi s'amuser à faire un exchange. Alors, tu vois, il y avait une autre stratégie, par exemple. Là, j'ai mis « Traffic Update ». On pourrait imaginer un truc compliqué. On essaiera de le faire demain. On va avoir un premier exchange qui est « Traffic Update ». Et puis, en fonction de paramètres qui sont dans le message qui va rediriger vers certains exchanges, par exemple Sud-Ouest, région parisienne, etc. Donc, des exchanges, voilà, comme ça. « Traffic Update », Sud-Ouest, par exemple. Et qui, lui, serait de type « Fan-out ». C'est-à-dire qu'on ne va même pas s'embêter avec du routage. Et moi, ma voiture, elle vient, elle se connecte, elle dit « Je veux cette queue-là et je voudrais m'abonner à « Traffic Update » Sud-Ouest. Et je n'ai pas besoin de mettre une clé de routage. Je vais recevoir tout ce qui arrive dans ce exchange-là. Et puis, je veux aussi m'abonner, peut-être, à « Traffic Update » pour d'autres trucs. Tu vois, tu peux t'abonner, depuis une queue, tu peux t'abonner à plusieurs exchanges ou bien plusieurs bains. Voilà, l'exemple, on pourrait en faire, on pourrait faire deux jours juste là-dessus. On va s'arrêter là. Est-ce que... Donc, on reviendra, on réutilisera cet exemple-là pour faire des trucs plus complexes. Mais est-ce que vous avez des questions ? Sinon, on va passer à l'autre. On va essayer d'aller en... Oui, vas-y, vas-y, non, non. Tu vois, on essaie quand même, c'est vrai, depuis le début, de définir des scénarios qui seraient plausibles et tout. Après, par exemple, en prod, ce serait assez rare que... Donc, tout dépend. Dans un système comme ça, en général, des mises à jour d'infotrafics, elles vont être fournies par... un fournisseur qui nous donne ses infos. C'est vraiment comme une agence de news qui nous envoie les dates. Et maintenant, il faut qu'on définisse, en fait, ici, qui nous sommes là-dedans. Est-ce que nous, on est, par exemple, le fabricant du GPS ? Auquel cas, nous, on cause directement avec les voitures, avec les machines qui sont embarquées chez nos clients. Si on est TomTom, tu vois, ou je ne sais quoi, là. Si c'est nous, nos clients, effectivement, c'est directement les voitures. Si on est plutôt côté diffusion de cette information, type une agence du style API qui fournit des data payantes à d'autres prestataires informatiques qui, derrière, en font quelque chose pour le client final, nous, effectivement, ceux qui vont venir se connecter chez nous, ce n'est pas les voitures directement, il va y avoir potentiellement quelqu'un, une autre entreprise d'informatique, justement TomTom, qui va se connecter chez nous, récupérer un max d'infos et puis les pousser vers ses clients. Selon qu'on est TomTom, ou qu'on est celui qui fournit les data à des TomTom et ses concurrents, on ne va pas se poser du tout les mêmes questions, parce que dans un cas, par exemple, TomTom, ça peut être pertinent de dire « ouais, pas de problème, on va créer une queue par voiture et puis on va gérer ce qu'on vient de faire, là, en fait. On va gérer vraiment au niveau de notre logique un dispatching des messages dans RabbitMQ, qui va avoir pour préoccupation combien de temps restent connectés les clients, les déconnexions possibles, c'est grosso modo ce qu'on vient de faire, on a duré des messages, tout ça, tout ça, tout ça. Si on se place dans la position de nous, on est broker d'informations, broker au sens agence, quoi, on diffuse ces informations-là pour TomTom, pour Google Maps, on fournit les infos à d'autres, nos préoccupations sont plus du tout les mêmes, parce que là on a beaucoup moins de connexions potentielles. On a par contre, peut-être, des gens qui veulent conserver une copie des données chez eux, en cache, assez longtemps, parce que voilà, on est découplé et ils veulent, eux, avoir l'historique au cas où, tu vois. Donc, on va peut-être leur mettre à disposition les choses beaucoup plus longtemps, mais les autoriser à rester connectés, peut-être qu'on va faire des queues qui ont des noms préétablis et c'est nous qui allons maintenir ces queues, c'est pas eux qui vont les créer au moment où ils se connectent, on va se mettre d'accord avec eux, ils nous payent un million à l'année et nous, on maintient les queues pour eux, quoi, tu vois. Pareil, on verra les questions de clusterisation demain. Donc, la clusterisation, en gros, c'est la répartition de charges de ce qu'on trouve en aval, c'est-à-dire les queues et les messages, et il y a une virtualisation dans le cluster de ce qu'il y a en amont, les exchanges, en fait, tu vas les retrouver dans tous les noms et c'est après le cluster qui va savoir où acheminer le message, concrètement. Mais, voilà, pareil, selon le scénario 1 ou 2, tu vas avoir, quand il y a un besoin plus ou moins fort de répartir des data. Donc, ouais, tout dépend, mais si on était sur le scénario, voilà, nous, on est top top, je pense que ce qu'on a fait, c'est pas trop mal, en fait, et c'est réaliste, une queue par TGPS, là. Un truc intermédiaire, ce serait, tu as un serveur par région, alors, région, c'est pas obligé d'être tout le sud-ouest, ça peut être plus petit, peu importe. On va dire les quatre gants de région française, plus la région parisienne. Dans ces cinq serveurs, signes eux reçoivent des messages et là, tu vas faire du routing en fonction de si le message est pertinent ou pas. Et puis, toutes les voitures vont s'abonner à ce serveur-là et à la même queue qui va être les objets. C'est possible aussi. Et donc là, tu partirais sur une architecture complètement différente. C'est dur de dire s'il y en a une qui est mieux qu'une autre, il faudrait vraiment aller plus loin encore dans la précision du problème pour faire des tests et puis se dire en fait, ça, ça va pas. Mon exemple, tu vois, on ne citait que un, mon exemple de, tiens, si la voiture va dans un tunnel, et puis, il n'a plus de connexion, est-ce que c'est important que quand elle se reconnecte, enfin, déjà, comment elle va se reconnecter ? Est-ce qu'elle va forcément tomber sur la même instance ou pas ? Et puis, quelle est la durée que je peux tolérer ? D'avoir une queue qui n'a pas de client ? Tu vois, avec ça, c'est tout un, tout un truc que je ne sais pas parce que ce n'est pas du tout mon métier, en fait. Alors, il est quelle heure ? 15h47 ? Est-ce que vous avez besoin d'une pause ? Criez, si c'est le cas. Ça va ? Vous pouvez faire une pause maintenant jusqu'à 16h, si vous le souhaitez. Ou bien, je vous montre encore des trucs et puis on fait une pause vers 16h, 16h40, un truc comme ça. Attends, on va utiliser des features de notes, ça marche ce truc ? Ouais, non, ça, c'est ma main. Comment je fais un vote ? Bon, je ne vais pas faire un vote dans le chat. C'est pas grave. On peut faire ça dans le team ? Ok, c'est pas grave. Ok, je vous propose un truc. Je vous montre le problème suivant. On ne va pas passer autant de temps sur les quatre. Une fois qu'on a fait un, je pense qu'on a compris un peu les principes. Je vais vous montrer qu'on peut se poser d'autres questions. Donc, on va parler des trois suivants. Et puis on prend un petit break. Donc, le deuxième scénario news type AFP par sujet, c'est on est une agence de presse qui diffuse des brevres avec liens, etc. C'est des objets riches. Il y a potentiellement peut-être même des liens vers des photos. Il diffuse des brevres avec liens, images, etc. Pour des professionnels. Donc, accès immédiat sans limitation de volume, etc. On a compris que c'est des accès payants. Mais aussi le grand public selon des termes différents. Voilà. Donc, et là, l'idée, c'est de dire les news sont les news sont réparties selon des thématiques dont la liste fixe et connue avance. Des tags, si vous préférez. On peut dire que des tags, peu importe. Et pour ajouter un peu, une news peut être tagguée dans plusieurs thématiques. Pourquoi pas. Voilà. Vous voyez, problème complètement différent puisque maintenant, est-ce que ici, par exemple, c'est plus important que dans l'exemple précédent avec l'infotrafic. Ici, c'est un peu plus de conséquences de perdre un message. C'est pas la fin du monde. On n'est pas sur du truc de centrales nucléaires ou d'informations historiques de transactions financières où là, c'est catastrophique. Mais c'est emmerdant quand même de perdre un message. Comparé à l'autre, on a la foi si on en perd un, c'est pas grave, il y en a un qui arrive juste après et ce qui compte, c'est le dernier. Donc, voilà. Vous voyez, c'est pas noir ou blanc. C'est pas catastrophique, mais c'est emmerdant. Et puis voilà, les réponses aux questions sont différentes. Est-il important de garder les messages longtemps ? Plutôt oui parce que c'est pareil, c'est pas mon métier. Je vais un peu bosser d'ailleurs avec la FP il y a très longtemps, mais c'est pas mon métier. Et c'est vrai qu'ici, ça peut être pertinent de pouvoir remonter dans le temps de même plusieurs semaines pour voir quelles étaient les news sur un sujet la semaine passée, il y a un mois, etc. Alors peut-être que justement, c'est une question à poser aux développeurs ou aux chefs de projet on peut marquer certaines news comme importantes doivent rester consultables longtemps et d'autres comme plus volatiles disparaissent au bout d'un moment. Vous voyez, on peut même avoir des messages qui vont pas avoir le même valeur entre guillemets et on va les persister on va les laisser disponibles plus longtemps dans certains cas. Pareil, la question est-ce qu'un client qui consomme un message doit le laisser dispo pour les autres ? Alors là, oui, plutôt. Bien sûr, on peut partir sur une architecture comme avec nos voitures, là, où chacun va créer sa petite queue, etc. Mais comme ça intuitivement on a envie de se dire que ça ne paraît pas optimal dans la mesure où on va vachement copier de l'information potentiellement sur un grand volume si on est sur le grand public. Alors, si on rentre vraiment dans les détails en vrai, le grand public ce serait certainement un site web que nous on est à disposition et qui s'alimente sur notre système via une queue par thématique. Je spoil un peu la solution qui serait de mettre une queue par thématique. Donc c'est pas le grand public qui va venir sur les queues directement, parce qu'il y aura certainement un site web qui va les afficher. Bon, on est... C'est pas forcément la multiplication des nombre de queues qui est inquiétant ici. C'est plutôt le fait que si un client consomme un message et ça disparaît ça nous oblige à faire ce système où chaque client doit avoir sa queue, etc. Peut-être que ce serait plus pertinent, dans ce cas là de faire une queue où tout le monde peut venir se servir. Et on peut même imaginer un système hybride où on aurait... oublions pour l'instant le portail client une seconde et puis on va juste regarder nos contacts B2B les professionnels. On pourrait même imaginer que selon le plan qui paye, s'il paye le plan bas de gamme ou le plan haut de gamme au niveau de tarification on va leur donner une queue dédiée dans le cas où il paye cher ou bien ils vont se servir là où tout le monde vient dans le cas où il paye pas cher. Et du coup là c'est un petit peu la foire d'empoigne parce que s'ils sont trop à se connecter potentiellement ils ont des soucis, etc. C'est pas aussi performant que si on leur met leur queue pour eux à disposition. Et tout ça, ça peut être dans le même cluster avec des configs différentes. Et en fait c'est exactement les mêmes messages qu'on va balancer dans toutes ces queues à la fin qui vont être dupliquées. Et vous voyez on peut imaginer des trucs complexes. Et donc voilà, j'ai un peu spoilé l'idée qui serait de dire là on va plutôt séparer les queues par sujets. Alors pourquoi ? C'est un choix comme un autre. On pourrait mettre toutes les braises à la suite et laisser les gens trier. Mais il y a des chances que vu le métier certains des clients de browse en fait ne récupèrent des messages que dans certaines thématiques qui les intéressent. Imaginons on a une chaîne de sport dans nos clients et puis on a une chaîne politique et puis on a une chaîne je sais pas d'autres thématiques. Ils vont pas consommer les mêmes infos et donc ça va de facto nous faciliter vachement le travail d'optimisation pour les performances de tout ça de répartir par thématique au niveau de nos queues. Parce qu'on va tout de suite pouvoir voir plus clair en gros les problèmes seront plus facilement identifiables. On peut très dire ça. Si on a 40 chaînes de sport comme clients et qu'ils sont sur une queue tous et qu'on a régulièrement des problèmes sur cette queue là bon on peut tout à fait imaginer si on a pas de problème sur les queues politiques on va se dire ok ils sont trop nombreux et il va falloir que on fasse plus de queues qu'on répartisse qu'on fasse en sorte qu'ils tapent sur 3 nodes ou 5 ou 7 ou 8 Qu'est-ce que je vais encore dire ? Cet exemple, non, Monsieur Jopama Ah oui, il y a l'histoire des messages volatiles ça peut même s'implémenter avec les options de base c'est à dire que, bien sûr on peut construire des architectures plus complexes on va avoir des archivives qui sont consultables ailleurs mais nous, au niveau de si on fait des queues par exemple, qui peuvent contenir beaucoup de messages, je ne sais pas un millier par exemple ça peut aller à plusieurs millions sans problème, mais imaginons on va garder 1000, 2000 messages et on va quand même mettre une limite on va pouvoir mettre à chacun de ces messages une durée de vie différente directement dans le message en fait cette fonctionnalité ici là elle est implémentable on peut dire au développeur, il n'y a rien à faire tu utilises une option de RabbitMQ de base et tu as cette feature déjà disponible les messages vont s'empiler et puis régulièrement il y en a qui vont en fait disparaître tout seul et ça va tout va se réordonner au fur et à mesure donc on va avoir les vieux messages qui doivent rester, qui sont toujours là et puis il y a des messages qui sont les plus récents qui s'accumulent, mais certains disparaissent, certains restent on va pas le faire concrètement comme manique, on s'arrête à la discussion est-ce que vous voulez parler encore un peu plus de celui-là ? alors réception de commandes e-commerce alors là c'est un exemple où on va dire on est qui ? la centrale qui contient tous les articles à expédier un entrepôt en fait tout dépend de comment il est organisé l'entreprise, mais un entrepôt c'est du dropshipping un site partenaire envoie une commande de son client donc il y a trois parties moi, le site son client ici la centrale qui contient tous les articles à expédier c'est il n'y a que deux parties moi, le client et où est-ce qu'on est ? le bureau il n'y a toujours que deux parties c'est moi et le client qui envoie des ordres de livraison vers le bon entrepôt rien que sur cette question là il faudrait préciser dans quel scénario on est soit ce sont des exemples réels soit ce sont des exemples réels il y a des e-commerce où c'est assez simple l'entreprise c'est aussi l'entrepôt et puis le site les articles disponibles sur le site c'est tout ce qu'il y a dans l'entrepôt c'est un business spécialisé j'en ai vu des gens qui ne vendent pas des cosmétiques naturelles ils ont leurs propres matériels articles pardon leurs propres stocks il y a des matelas aussi l'entreprise elle fait que l'e-commerce elle reçoit les commandes du site elle doit les traiter et derrière elle va dispatcher vers un entrepôt peut-être qu'il y a des entrepôts qu'elle gère elle-même et peut-être qu'il y a des entrepôts partenaires qui ne sont pas à partir de l'entreprise mais qui peuvent livrer l'article ça c'est le mode hybride le troisième mode le dropshipping pure c'est à dire que moi en tant qu'entreprise je n'ai aucun entrepôt je ne fais que alors pardon je suis encore sur le bureau je reçois les commandes c'est mon site mais moi je n'ai aucun entrepôt je ne contacte que des entrepôts tiers et puis le troisième c'est le point de vue de l'entrepôt lui-même en fait il n'a pas de site il ne reçoit que des commandes à envoyer quelque part c'est ce qu'on appelle le dropshipping il y a un gars quelque part qui a fait un site il reçoit des commandes dessus il les envoie vers l'entrepôt et l'entrepôt envoie donc ça fait un triangle donc là on pourrait en parler longtemps de tous ces scénarios mais les questions intéressantes c'est toujours une même est-ce que c'est grave de perdre un message ici ? c'est vraiment problématique de perdre un message parce que, alors il n'y aura peut-être pas Mordome c'est toujours pas la centrale du éclair mais il y a potentiellement un client qui a payé et qui ne reçoit pas son article donc c'est forcément des emmerdes donc ici, perdre un message c'est embêtant ici c'est très problématique exemple, le client a déjà payé qu'est-ce qu'on a d'autre ? est-ce que c'est important ici de garder les messages longtemps ? en fait la question ici elle se pose pas tellement parce qu'on n'est pas sur de la diffusion d'informations on est sur un processus métier donc là ici notre broker il ne sert pas à pousser de l'info que les gens vont consommer quand ils ont envie c'est totalement différent ici chaque message est en fait une étape critique d'un processus métier bien défini et donc la question de garder les messages longtemps ou pas quelque part elle est presque pas pertinente il faut que les messages soient traités après ils peuvent être rejetés genre t'as vendu un article qui n'est pas en stock donc il n'est plus disponible on peut très bien traiter en disant je rejette ça mais à ce moment là on va traiter le message et faire ce qu'il faut dans ce cas là mais on est toujours dans le processus métier si vous voulez on peut pas se permettre de ne pas traiter le message donc la réponse à combien de temps faut garder les messages donc si potentiellement côté entrepôt on a une panne informatique de 2 semaines il faut que tous les messages restent en attente et puis on va envoyer des excuses aux clients pardon on a eu un problème informatique mais ne vous inquiétez pas toutes les commandes seront honorées on gardera tous les messages et puis est-ce qu'un client qui consomme un message doit le laisser disponible pour les autres ben là c'est pas forcément une question très pertinente ici puisque on va exécuter évidemment que chaque commande une seule fois donc si on est sur on a fait une architecture informatique très compliquée où il y a plein de clients qui se connectent à notre middleware c'est sûr que si il y en a un qui traite le message il faut pas que les autres le traitent aussi on risque sinon d'envoyer deux fois un article à quelqu'un qui ne l'a pas fait une fois donc là la question pareille elle est un peu mal posée dans ce cas là parce qu'on s'en fout de laisser disponible un message pour les autres c'est plutôt non la réponse mais c'est surtout un problème d'architecture à définir pour respecter le processus donc oui le middleware finalement il permet de faire plein de choses différentes et dans certains cas certaines des features vont être disponibles déjà dès les options de base comme on a vu tout à l'heure pour les news qu'heure il est 16h06 et dernier cas peut-être que celui-là on le fera aussi si on a le temps un manip c'est on peut imaginer un système où plutôt que donc imaginons un système où des utilisateurs peuvent ajouter un appareil du style appeler bancaire autoriser un téléphone je ne sais rien et on voudrait faire un système qui identifie l'appareil ça peut être aussi de l'authentification j'aime bien pareil ou bien même s'authentifier par exemple rapidement autoriser un browser etc. vous avez compris on peut imaginer un système qui serait basé entièrement sur RabbitMQ avec des queues et des des exchanges astucieusement fabriqués donc certains à la volée d'autres qui sont là en permanence et puis on va gérer aussi on va utiliser les time to leave les durées d'expiration des messages et tout pour on veut des time out question de sécurité on va utiliser les options de TTL, expiration, tout ça pour si le processus d'ajouter l'appareil aux appareils auxquels on fait confiance et pourquoi pas ne vient pas au bout dans un temps imparti que on soit obligé de recommencer du début vu que le système est faillible on va laisser une fenêtre limitée dans le temps pour que les gens puissent s'en servir on veut des time out par exemple et on veut un truc simple à utiliser du genre code à 6 chiffres donc c'est vraiment type authentification de factor to factor authentication ou ce qu'on appelle les magic links tous ces systèmes là qui permettent de belpasser les authentifications plus traditionnelles de user password je ne parle pas du tout de token là je parle vraiment de ces systèmes qui permettent de rendre une connexion entre deux choses faciles pour l'utilisateur c'est ça vraiment la clé ici ce qu'on désire j'ai implémenté par exemple un système comme ça pour permettre à des utilisateurs sur un portail web d'ajouter des machines ces machines c'est des ordinateurs mais qui ont la capacité de se connecter au middleware ce qu'on voulait c'était dans le portail web pouvoir ajouter la machine pour ensuite pouvoir faire des trucs avec depuis le portail web envoyer des messages vers cette machine voir son statut gérer des conflits éventuellement mais donc ce qu'on a besoin si vous voulez c'est d'infos sur la machine comment communiquer avec elle vraiment du type IP etc mais on n'a pas envie de s'embêter on n'a pas envie de demander à l'utilisateur rentre dans un formulaire et tape toutes les infos sur la machine ce qu'on veut c'est plutôt dire sur la machine appuyer sur un gros bouton qui dit register this device et puis dans notre portail web on appuie sur un gros bouton qui soit register a new device et puis que la machine nous donne un code à 6 chiffres et que dans le portail web on tape les 6 chiffres et puis qu'on récupère les infos de la machine dans le portail et de ça en fait on a implémenté en pure RabbitMQ avec un petit peu de code quand même un moment donné il y a un petit peu de logique à implémenter c'est plus un défi de programmeur mais l'essentiel de la tuyauterie c'est fait avec RabbitMQ et des options de base donc je vous montrerai comment on peut implémenter ça avant la fin de la formation et puis si on a le temps on essaie pas de le faire mais voilà donc ça peut vraiment servir à faire plein de trucs différents c'était le but de cette phase de manip et de discussion alors vu qu'il est 16h11 on s'approche de la fin on n'est même pas obligé de faire un break on suit juste une demi heure de cours ce qu'on peut faire c'est qu'on va finir un petit peu plus tôt tout simplement sauf si vraiment vous êtes en train de mourir vous voulez qu'on s'arrête 5 minutes vous me dites ça va ? ouais je vous ai pas trop assomé ça joue là on a créé nos instances de rabbit on a des machines virtuelles on va se resservir de tout ça demain pour attaquer la partie clusterisation et justement cette fois on parlera d'abord de considération plus système et puis on reviendra après aux questions plus métier pour voir l'impact sur tout ce qu'on a vu une fois qu'on met en cluster où vont les messages et pour finir aujourd'hui simplement je vous proposais de nous parler des problèmes que vous avez rencontrés par exemple ce que je sais pour l'instant c'est uniquement que sur vos instances de dev ça tombe en carafe de temps en temps et vous suspectez un problème de mémoire mais si je m'en souviens vous êtes même pas sûr mais voilà je vous propose d'ouvrir la discussion pour parler de ça et comme ça on sera un peu aussi préparé demain à l'arrivée des dev début d'après-marche c'est ça tu as dit Serge ? début d'après-marche est-ce que alors je sais pas c'est qui Thierry et Mathieu qui ont dû maintenir un peu les instances en dev j'ai bien entendu on parlait d'autre chose Mathieu et Thierry ouais bah vous vous dites voilà on te dit je prendrais quelques notes je note peut-être en même temps moi je vois ouais c'est bon donc ça, ça veut dire que ouais ça fait en fait les messages sont pas je pense c'est des bindings simples du coup tu dois pas mettre non plus de clés de routage j'imagine dans les messages et puis tu balances donc tu fais l'équivalent d'un fan out c'est à dire bah ça j'ai pas encore la réponse à cette question parce que j'ai envie de dire la techno elle est quand même faite pour ça c'est ça qui est voulu au niveau de la distribution encore une fois ça dépend de ce qu'essaient de faire les gens en revanche c'est vrai que si vous utilisez pas les clés de routage à ce moment là autant utiliser un fan out parce que le fan out va même pas comparer les clés donc au niveau perf on va gagner un peu quoi mais c'est la seule chose que j'ai à dire pour l'instant de ce que je veux c'est dur de dire c'est plus une question à discuter en regardant l'architecture et le besoin de tir vous avez tiré des nouveaux nœuds c'est ça et vous avez pris les messages vous avez balancé sur l'autre nœud d'accord ok effectivement on voit que il n'y a pas de 9800 connexions mais que 29 channels donc en fait pour faire quelque chose un client qui se connecte il va établir une connexion et il va forcément créer un channel on a toujours un par défaut minimum même si on fait pas plusieurs channels dans la connexion pour faire des choses de façon élégante et tout ça de toute façon il y a toujours un channel c'est à dire que si tu veux vraiment savoir combien il y a de gens connectés tu vas plutôt regarder les channels que les connexions là ça va te dire il y a potentiellement 30 connexions vraiment actives qui font quelque chose et puis 9800 60 qui en fait peuvent refaire parce qu'ils n'ont pas de channel c'est sûr que là il y en a beaucoup qui continuent alors alors c'est de ce que je vois c'est vrai que c'est plutôt côté client en général les connexions qui restent ouvertes en fait parce que voilà l'architecture fait que c'est possible ah oui oui c'est ça et donc mais je veux dire le client lui il n'a pas les connexions sont pas ouvertes côté client tu dis c'est ça ? ouais c'est ça on pourra peut-être rejeter un œil à ça demain on va s'armer le matin de connaissances sur le fonctionnement interne le cluster oui bien sûr bien sûr ouais ouais je suis content parce que moi dans toutes les formations j'essaye de faire du cli et les gens aiment pas le cli classé le contraire c'est cool tu dis ça s'appelle MQTD connector explorer d'accord ok ouais tout à fait mais c'est en ligne de commande d'accord ? ok d'accord on fera pas mal de on va montrer différentes solutions effectivement mais je trouverai aussi de vous donner des scripts pour faire ces fonctionnalités de base mais on peut faire pas mal de choses en ligne de commande aussi ok merci le mec il revient sur les taux le mec il joue aux échecs pendant l'information et il revient merci ouais c'est vrai très très bien écoutez je regarde encore si au niveau slide je voulais vous montrer autre chose aujourd'hui mais vous n'êtes pas mal là donc on a vu les headers c'est assez important on va parler des ouais elles sont pas bien ces slides on va parler du reroutage des messages en cas d'erreur demain mais ça va être vraiment la notion métier pour l'instant élémentaire qui nous manque encore petit mur qu'on construit là c'est la brique c'est toute la partie attends je suis où là oui je partage plus vite ah bah non évidemment c'est pas bon j'arrive je vais juste vous montrer dans l'interface où ça se trouve et puis ça va faire base de l'info c'est ça ok donc dans mon système avec exchange binding et queue je vais en fait avoir à différents niveaux on pourrait même mettre une slide pour montrer les différents niveaux qu'ils soient pas trop moches si possible j'aime pas celle là en fait voilà c'est ça que je cherchais donc si l'exchange arrive au niveau de l'exchange si l'exchange arrive pas à le router ce message premier cas où on veut pouvoir traiter ça comme une erreur et dire bah envoie le message du coup ailleurs c'est à dire c'est vraiment le ce matin on a parlé de poubelle c'est pas tout à fait une poubelle ça peut faire partie même de votre processus métier bien sûr ça sera aussi les erreurs qu'ont fait les développeurs cette année les développeurs quand ils nous envoient un message bien sûr mais ça peut aussi faire partie du processus normal de dire bah voilà si je n'arrive pas à router le message avec les bindings existants envoie le là parce que peut-être que c'est tel autre cas dans le processus métier vous voyez c'est on peut avoir ça comme une poubelle trop vite donc au niveau ici de l'exchange déjà on a des mécanismes et puis ensuite au niveau de la queue on va avoir des mécanismes en lecture donc au moment où le client va se connecter pour lire un message il va pouvoir dire hey ce message là non seulement je le récupère pas il m'intéresse pas mais en plus je te signale qu'il y a un problème avec ce message là et le client va nous dire problème avec ce message donc c'est ce qu'on va appeler un reject on revira tout ça concrètement je vous rassure on verra des exemples mais le reject va être un deuxième cas comme ça où un message dans notre système va potentiellement devoir aller ailleurs dans le middleware donc pas adressage foiré au niveau de l'exchange rejet au niveau de la lecture et puis les cas typiques par exemple un message il y a une taille limite dans la queue et le message qu'on veut pousser dans cette queue peut pas rentrer parce qu'on a dit que tu sais on a pas choisi FIFO là où le premier il dégage on a dit quand la queue est pleine personne peut rentrer et donc le message qui va se présenter en sortie de l'exchange et à l'entrée de la queue il va pas pouvoir y aller bien que l'adressage soit correct troisième cas où le message va pouvoir se retrouver dans les circuits qu'on avait prévu pour ces cas là donc on verra tout ça demain il y a encore d'autres cas il n'y a pas que ces trois là mais c'est des exemples pour vous dire que on va pouvoir ajouter comme ça de la logique et puis selon le cas ça va faire complètement partie du processus métier où c'est plutôt vous qui allez discrètement entre guillemets sans dire aux devs faire votre truc de votre côté pour dire bon ok quand leur processus là il y a des trucs qui vont pas moi je récupère les choses en fait et je garde l'info sur ce qu'il y a à foire et donc c'est encore une fois quelque chose qui peut se faire en modélisant le métier ou plutôt en mode système donc on verra des exemples voilà dans l'interface ça va se retrouver là quand on définit ici un nouvel exchange voilà c'est parti tout est prêt il y a un petit parlement à l'interface parce que là je replie l'exchange et on garde la liste pour ce moment donc add new exchange ici quand je vais définir un exchange je vous disais s'il a un problème d'adressage ou est-ce qu'il peut l'envoyer ça va être justement l'option qu'on a ignoré tout à l'heure alternate exchange qui nous dit if messages to this exchange cannot be routed on remarquera l'accent français send them to the alternate exchange maintain donc ça va être son alter ego si vous voulez si lui il a pas réussi à envoyer le message ou que ce soit donc ça c'est optionnel au niveau des queues on a ici dead letter exchange si un message expire donc si le message il est dans la queue il disparaît ou qu'il est rejeté par le client donc je vous disais le client il dit il récupère le message il dit ouais celui là je vais je te signale que je le rejette et bah dead letter exchange c'est pareil on va donner comme option ici dans cette queue un nom d'exchange et ça va fonctionner comme le alternate sauf que cette fois ci c'est au niveau de la queue alternate c'est au niveau de l'exchange donc ça s'appelle dead letter le petit acronyme c'est dlx dead letter exchange et puis dead letter routing key c'est une option supplémentaire dans ce cas là pour je vous l'avais dit ce matin vite fait pour réécrire la clé de routage dans les cas où on l'envoie par le dlx ok ? et voilà donc c'est une brève introduction à ce que on verra demain mais comme ça en disant ça maintenant j'ai brossé un tableau à peu près complet de l'utilisation de RabbitMQ là vous pouvez déjà vous lancer dans un petit projet avec ces connaissances et bien sûr nous pendant les jours qui nous restent on va approfondir voilà, vu qu'on n'a pas fait de pause cet après-midi on peut dire qu'on est bon si vous avez des questions je vous écoute et sinon merci et à demain, je vais rester connecté jusqu'à 17 quand même au cas où le mec il veut manipuler et qui boit des trucs c'est bon pour l'enjeu
on 2024-03-13
language: FR
WEBVTT Alors IP, je vous avoue, je ne me suis pas embêté parce qu'il y a l'IP interne sur leur réseau. Alors du coup, moi je crois que ça marche aussi normalement. Mais je fais whatismyip.com et j'ai utilisé celle-là et ça pique aussi. Si on prend celle interne à leur réseau, normalement ils doivent se voir, mais on
on 2024-03-13
Visit the RabbitMQ Cluster Management - Météo France course recordings page