Introduction
Pour pratiquer Python et me familiariser avec les sockets, mon professeur m'a donné ce projet.
Ce projet consiste à exécuter du code sur un serveur distant avec un équilibrage de charge entre les serveurs pour gérer plusieurs clients sans problème.
Ou est il ?
Architecture globale
Serveur principal
- Agit comme un proxy entre les clients et les nœuds (esclaves)
- N'exécute pas de code, mais transmet les requêtes aux nœuds
- Gère toutes les tâches d'équilibrage de charge
Serveur de contrôle
- Sécurisé avec SSL
- Gère les requêtes de "gestion" des nœuds et des clients
Serveur de données
- Transmet les données entre les nœuds et les utilisateurs
- Non sécurisé avec SSL, mais les données sont chiffrées avant envoi par le client ou le nœud
Nœud (esclave)
- Exécute le code réel du client
- Peut gérer plusieurs clients en même temps
Client (interface graphique)
- Se connecte d'abord au serveur principal
- Demande un nœud et, lorsque le serveur principal lui en fournit un, se connecte au serveur de données, envoie le code au nœud et affiche le résultat
Choix
J'ai dû choisir des solutions pour mettre en œuvre les différentes parties du projet, voici les choix que j'ai faits et pourquoi je les ai faits
Communication
J'ai choisi d'avoir deux connexions pour une vitesse élevée, même avec un grand nombre de nœuds et de clients.
J'ai choisi SSL pour sécuriser la connexion de contrôle car il offre une bonne sécurité.
Gestion de la charge élevée
Mon serveur principal crée un nouveau processus pour chaque nouvelle connexion de données, ce qui permet d'exploiter pleinement le potentiel du serveur et de gérer un grand nombre de connexions en même temps.
Transfert de données
J'ai choisi d'utiliser principalement JSON pour transférer des données car cela offre un moyen sûr de transférer des données entre les différentes parties du projet.
À l'intérieur (dans le serveur principal), j'ai utilisé des files d'attente de processus pour transférer des données entre les processus sans interférer avec les sockets et sans compromettre la sécurité du projet.
Difficultés
Manque de temps
La plupart du temps, je l'ai passé à la maison pendant mon "temps libre" (qui n'était plus libre), et j'avais jusqu'au 31/12/2024 pour terminer le projet.
Pour surmonter cela, j'ai dû ne pas me concentrer sur la compréhension des bugs, mais sur la façon de ne pas faire crasher l'ensemble du processus.
En raison du manque de temps, je n'ai pas eu le temps d'apprendre comment chaque bibliothèque fonctionne, et je n'ai pas eu le temps de tester extensivement le projet, mais la plupart des bugs sont corrigés.
SSL
J'ai dû apprendre à mettre en œuvre SSL et à comprendre son fonctionnement, j'ai vu que deux connexions SSL sur le même processus ne sont pas possibles ou du moins, il est très complexe d'avoir quelque chose de stable.
Compatibilité avec les systèmes d'exploitation
J'ai dû coder certaines fonctions pour les rendre compatibles avec la plupart des distributions Linux, le meilleur exemple est le nom de l'exécutable Python, parfois c'est python3, parfois c'est python.
Améliorations potentielles
Équilibrage de charge
J'aurais dû mettre en œuvre un algorithme d'équilibrage de charge plus performant qui anticipe la charge que peut mettre un client sur un nœud.
Sécurité
Au lieu d'exécuter le code sur le nœud, j'aurais dû l'exécuter dans un conteneur Docker, ce qui permet de ne pas compromettre le nœud si le code est malveillant.
Fichiers multiples
Actuellement, je ne peux envoyer qu'un seul fichier à exécuter, j'aurais dû mettre en œuvre un moyen d'envoyer un projet entier à exécuter.
STDIN
En raison du manque de temps, j'ai dû oublier d'ajouter un canal STDIN du client utilisateur au nœud, ce qui aurait permis à l'utilisateur d'interagir avec le code en cours d'exécution sur le nœud.
Conclusion
C'était un projet intéressant, avec beaucoup de défis et de possibilités, mais en raison du manque de temps, j'ai dû faire certains choix que je n'aurais pas faits si j'avais plus de temps.