Architecture communication serveur

Bonjour, Dans le cadre de mon travail, je suis en charge de moderniser les échanges clients serveurs pour nos applications afin de rendre le tout plus rapide.

Actuellement, nous avons une plateforme permettant d’héberger et créer des sites web sur différents serveurs distantsdans notre parc. La plateforme web doit pouvoir communiquer avec chacun des serveurs pour demander une installation, demander une modification du paramétrage, changer les accès sur le ftp, etc.. Toutes les commandes à exécuter sont des scripts shell, le php se chargeant de générer un fichier XML contenant le script à envoyer ainsi que les différents paramètres. Le serveur envoie ensuite une réponse à la plateforme qui se charge de l’interpréter en php pour avertir le client. Tout ceci fonctionne correctement actuellement mais est horriblement lent. Le système qui avait été choisi était un système de cron se chargeant de transférer les fichiers XML (exécuté toutes les 5 minutes).

Il y a 4 étapes :

Chaque cron passe à un intervalle de 2 minutes et il y a 4 crons. Il peut donc y avoir au maximum un délai de 8 minutes entre l’envoi de la requête et la réponse.

L’idée est d’accélérer le processus en se passant des crons et en ayant un vrai dialogue en direct entre php sur le serveur de la plateforme et chacun des serveurs distants. La plateforme envoie instantanément une requête au serveur distant qui exécute le bon script shell et qui renvoie une réponse dès que fini. Je viens donc à la pêche aux infos sur les différentes technologies permettant de réaliser ceci simplement. J’ai regardé du côté de node.js ou phpMQ pour gérer la communication serveur mais si vous connaissez des bonnes technos à ce sujet je suis preneur.

Merci du coup de main

Bonjour,

Je pense que ce que tu cherches c’est créer une API REST. https://zestedesavoir.com/tutoriels/299/la-theorie-rest-restful-et-hateoas/
https://openclassrooms.com/fr/courses/3449001-utilisez-des-api-rest-dans-vos-projets-web/3449008-quest-ce-quune-api

Si je devais recoder l’ensemble dans un temps très contraint, je ferais encore plus "simple"

Php génère ton fichier xml (qui je suppose est très léger), pourquoi ne lance t’il pas directement la requête pour envoyer le fichier? 2 requêtes curl par exemple? 1 qui envoi le fichier

curl -T monfichier.xml http://monserveur/monRepo/monfichier.xml 

1 en GET qui va lancer la lecture du fichier

curl http://monserveur/lecturedufichierxml/?fichier=monfichier.xml 

et vice et versa, la requete curl va "tapper" un script, peu importe le langage, il renvoie une autre requête en curl au serveur source pour dire c’est bon, j’ai ce qu’il te faut…, 1 autre requete curl pour envoyer le zip

ou alors je n’ai pas compris (notamment l’interet des cron et du ftp… )

Salut, En fait il n’y a pas réellement d’intérêt à conserver le système actuel de crons et de ftp. C’est un code historique moche et plutôt lent dans son traitement donc on veut moderniser tout ça.

En gros, un client fait une demande, on a un serveur frontal qui doit envoyer des requêtes à X serveurs clients en back. Les requêtes ça peut être une demande de modification du php.ini, d’une installation d’un site complet, d’un paramétrage d’un cron par exemple. Chaque serveur en back a un dossier qui contient tous les scripts shell qui peuvent être exécutés. Il faut savoir que certains scripts peuvent prendre jusqu’à 10 minutes pour s’exécuter donc il n’est pas envisageable de faire patienter le client 10 minutes sur la page en attente de la réponse. Il doit pouvoir continuer à naviguer pendant que tout est traité côté serveur.

Actuellement, pour déterminer quel est le script à exécuter et quels sont les paramètres, on passe par la génération du fichier XML qui contient le script + paramètres. Le frontal sait vers quel serveur il doit envoyer le fichier et le dépose sur le serveur qui le traite ensuite.

Je ne suis pas limité en temps pour mettre en place ce nouveau système donc je cherche à le faire de manière propre et souple. J’ai regardé du côté des gestionnaires de file d’attente comme RabbitMq qui semble plutôt bien correspondre à ce que je recherche. Un moyen d’ouvrir un canal de discussion entre 2 serveurs grâce à un broker, pouvoir pousser X requètes traités à la suite dans la file du serveur back puis récupérer les réponses en direct.

Je vais aussi creuser du côté des liens que tu m’as envoyé le principe a l’air intéressant même si ça m’a l’air un peu compliqué sur un gros parc de serveurs et avec des requêtes qui peuvent prendre jusqu’à 10 minutes.

Merci de ton aide.