FR 3039024 A1 20170120 FR 1501505 A 20150715 - 1 - La présente invention concerne le domaine technique de la répartition de charges, de la gestion de noeuds et de la gestion de services. Dans l'état de la technique, différentes méthodes sont mises en oeuvre afin 5 d'optimiser les résultats des divers requêtes réalisées par les utilisateurs. Une de ces méthodes est la répartition de charges (load balancing) de requêtes sur un service. Le load balancing est connu pour être une méthode de distribution de la charge de travail sur un certain nombre de dispositifs et/ou serveurs pour augmenter la 10 productivité. Cette répartition de charge peut être avec état (statefull), donc possible de suivre et de stocker les sessions des utilisateurs en cours un protocole, une donnée, un paramètre, ou sans état (stateless), qui, de son côté, fournit une réponse après une requête sans stocker d'informations de session, ce qui permet une plus simple élasticité du service (scalabilité). 15 Pour rendre le load balancing performant, des solutions pour rassembler les noeuds, physiques comme basés sur un système d'exploitation, sous un cluster ou une ferme de noeud ont été présentées. Cependant ces solutions ne proposent pas des moyens efficaces pour résoudre le problème de scalabilité des noeuds et des services. En 20 effet, il n'a pas encore été décrit des moyens automatiques de gestion du cycle de vie des noeuds dans une ferme de noeuds dans l'objectif de rendre ces services disponibles, stables et robustes dans des environnements réseaux, considérés aujourd'hui très instables sur Internet. 25 Aussi, plusieurs erreurs peuvent survenir lors de la mise en oeuvre des méthodes précédemment mentionnées. Il ne faut pas considérer les pannes des réseaux informatique comment étant très rares pour construire un système fiable. Il faut prendre en considération ces pannes et savoir qu'elles font partie des réseaux informatique. Les pannes qui doivent être gérées sont: la disparition d'un service; la 30 disparition d'un noeud, l'arrêt d'un noeud, la panne d'un service, la disparition d'un ensemble de noeud, cette liste n'étant pas exhaustive. De plus, dans l'état actuel, l'usage des registres de services publics n'assurent pas la confidentialité des services, étant donné qu'ils sont sauvegardés sur des bases de 3039024 - 2 - registres. Ce qui rend les code source des services potentiellement vulnérables en matière de copies, d'attaques ou d'analyse. Il est donc nécessaire de créer un procédé pour gérer automatiquement le déploiement d'un services à au moins un noeud basé sur un système d'exploitation, en tenant compte des requêtes réalisées par au moins un utilisateur, mais aussi les possibles défaillances, erreurs et échecs qui peuvent provenir des noeuds et des services. Glossaire: Le terme "répartiteur de charge" utilisé dans la présente invention peut être compris de façon non limitative comme "équilibreur de charge", "load balancer", "dispositif de partage de charges", "dispositif de division de flux de réseau". Le terme "noeud" utilisé dans la présente invention peut être compris de façon non limitative comme "serveur virtuel, sur internet", "serveur virtuel, sur cloud", "serveur virtuel, sur une plate-forme en nuage", "serveur sur une infrastructure locale", "noeud de type maître", "noeud de type esclave", "réseaux de serveurs", "cluster", "ferme de serveurs", "ferme de noeuds". Le terme "requête" désigne un ordre d'exécution, il suit un protocole de communication et possède des paramètres en entrée (question), un statut de la réponse et un retour (réponse). Souvent sur les réseaux TCP, INPROC, IPC, UDP ou PGM, une requête dans le protocole choisi par le client et un retour OK ou ERROR dans un format lié au protocole. Le terme "registre de service" ou "base de registre", désigne un service dans lequel est conservé les conteneurs et les configurations des autres services. Le registre de service contient l'ensemble des services et leurs versions. Il est configuré pour permettre le téléchargement d'un service dans une version. L'accès au registre de service se déroule avec authentification ou sans authentification. Dans le cas où il se déroule sans authentification, nous le désignons "registre public", ce registre est vulnérable et non sécurisé. 3039024 - 3 - Le terme "conteneur image de service" représente le logiciel enfermé dans un conteneur et qui une fois téléchargé depuis le registre de service, installé et exécuté permet d'exécuter un service sur un noeud. Il est caractérisé par un programme, un 5 nom, une version et une date de construction. Le terme "système d'exploitation" utilisé dans la présente invention peut être compris de façon non limitative comme "operating system", "Datacenter", "operating system de ferme de noeud" et/ou un ensemble de noeud (ferme de noeud) répondant à 10 des principes déterminés et ayant au moins un maître et de zéro à plusieurs esclaves. Le système d'exploitation, sur sa forme minimale peut ainsi être constitué uniquement d'un noeud. Et il peut aussi être constitué de multiples noeuds. Le terme "identifiant unique de ressource" désigne le nom d'un noeud et son 15 identification. En TCP/IP l'identifiant unique est appelé URI. Le système d'exploitation, selon l'invention, fonctionne avec d'autre protocoles réseau, comme INPROC, IPC, UDP ou PGM, aussi l'identifiant unique de ressource peut prendre d'autres formes non encore connues à ce jour. 20 Le terme "référentiel" utilisé dans la présente invention peut être compris de façon non limitative comme "service centralisé pour maintenir des informations de configuration, de nommage, assurer la synchronisation distribuée, et fournir des services de groupe", "logiciel de gestion de configuration pour systèmes distribués", "système de gestion de noeuds redondants". 25 Le "service" est un programme installé sur un ou plusieurs noeuds et exécuté à la demande ("requête") d'un client sur un noeud maître et/ou esclave. Le terme "orchestrateur" utilisé dans la présente invention peut être compris de façon 30 non limitative comme "module d'orchestration de services de réseau", "système d'orchestration de contenu", "processus automatique d'organisation, de coordination, et de gestion de systèmes informatiques complexes", "orchestration de la gestion de services". 3039024 - 4 - Le terme "service découverte" utilisé dans la présente invention peut être compris de façon non limitative comme un service qui contrôle les conteneurs image de service exécuté par un orchestrateur sur une machine et transmet leurs adresses à l'ensemble des noeuds. 5 Description de l'invention: La présente invention concerne un système et un procédé automatique de déploiement de service sur un noeud réseau. Le système comprend au moins une 10 base de registres et au moins un système d'exploitation composé d'au moins un noeud maître et au moins un noeud esclave. La base de registres est composée de plusieurs registres publics et/ou privées et/ou des registres répliqués. Chaque noeud maître et/ou esclave, qu'il soit virtualisé sur une plate-forme en nuage, communément appelé cloud, ou en infrastructure locale, comporte: un répartiteur de 15 charges et un service découverte. Le noeud maître comporte, en plus, un orchestrateur et un référentiel. Chaque noeud peut accéder aux registres privés par l'intermédiaire de protocoles de communication et de sécurité, préférentiellement TCP, INPROC, IPC, UDP ou PGM 20 ou autres. Chaque noeud (qu'il soit virtuels ou non) possède : des ressources physiques ou virtuelles rattachées, une ou plusieurs unités de calcul (CPU), une ou plusieurs mémoires vive non persistante (RAM), et une ou plusieurs unité de stockage 25 persistante ou toute autre type de ressources. Aussi, chaque noeud est identifié par un nom unique sur son protocole: à titre d'exemple, sur le protocole IP, il sera utilisé l'adresse IP interne à la ferme de ce noeud. 30 Les dessins annexés illustrent l'invention: La figure 1 représente le système composé d'une à plusieurs bases de registres (2), publique et/ou privée, hébergeant au moins un conteneur contenant des images de 3039024 - 5 - service (3), pour chaque service proposé, et aussi composé d'au moins un système d'exploitation (1) composé d'au moins un noeud maître (4) et d'au moins un noeud esclave (9) ayant chacun un répartiteur de charges (5), un service découverte (8) et des moyens pour déployer des services (10). Les noeuds maîtres (4) comportant, en 5 plus, un référentiel (6) et un orchestrateur (7). La figure 2 représente un orchestrateur leader (11) basé sur un noeud maître leader (12). 10 La figure 3 représente l'orchestrateur leader (11) basé sur un noeud maître (4) quelconque. La figure 4 représente la réplication de la base de registres (2), publique et/ou privée, sur une autre base de registres, publique et/ou privée, et/ou la réplication de la base 15 de registres (2), publique et/ou privée, sur un fournisseur ou une infrastructure en nuage (13). La figure 5 représente l'exécution d'une requête pour démarrer un service (10) donné vers un noeud esclave (9) placé sur le système d'exploitation (1), respectant des 20 règles de service configurées qui organisent les noeuds (9) et/ou les services (10) selon un ordre déterminé et respectant l'indication d'un orchestrateur leader (11) sur des ressources disponibles et nécessaires pour déployer le service (10) demandé. La figure 6 représente la confirmation par un service découverte (8) du noeud 25 esclave (9), à qui a été dirigée la requête, qu'un tel noeud esclave (9) ne possède pas la version de l'image nécessaire pour déployer le service (10) demandé. Elle représente aussi l'interrogation de la base de registres (2) par le service découverte (8) du dit noeud (9), paramétré préalablement avec le protocole de communication adéquat, préférentiellement TCP, INPROC, IPC, UDP ou PGM, pour accéder à au 30 moins une image de service (3). Le conteneur contenant des images de service (3) est archivé dans la dite base (2). Il sera téléchargé la version de l'image nécessaire pour déployer le service (10) demandé sur le noeud cible de l'installation. 3039024 - 6 - La figure 7.a représente l'initiation du processus de téléchargement de l'image et la figure 7.b représente l'ajout d'un nouveau service (10) au dit noeud (9), suivi par le démarrage du service (10) demandé par le dit noeud esclave (9). 5 La figure 8 représente la requête dirigée vers le deuxième noeud esclave (9) respectant l'ordre configuré, quand l'orchestrateur leader (11) indique que le premier noeud esclave (9) ne possède pas de ressources disponibles et nécessaires pour déployer le service (10) demandé. 10 En référence à ces dessins, le système comporte des moyens adaptés pour la mise en oeuvre du procédé automatique de déploiement de service sur un noeud réseau caractérisé en ce qu'il comporte : a) d'une à plusieurs bases de registres, publiques et/ou privées (2), périodiquement répliquées, sur un fournisseur ou une infrastructure en nuage 15 (13) ou sur une autre base de registres, publique et/ou privée, et hébergeant au moins un conteneur contenant des images de service (3) pour chaque service proposé, b) au moins un système d'exploitation (1) composé d'au moins un noeud maître (4) et au moins un noeud esclave (9) comportant chacun un répartiteur de 20 charges (5), un service découverte (8), un protocole d'authentification nécessaire pour accéder à la ou les bases de registres (2), en mode privées et/ou des moyens pour déployer des services (10), dont le noeud maître (4) comporte, en plus, un orchestrateur (7) et un référentiel (6). 25 Le procédé automatique de déploiement de service (10) sur un noeud réseau est caractérisé en ce qu'il comporte les étapes suivantes: A partir d'une configuration faite par un utilisateur, le procédé automatique de déploiement réalise une demande de démarrage de service ("requête") pour 30 démarrer un service (10). La soumissions de cette requête de démarrage de service peut être réalisée de plusieurs manière différente et suivant plusieurs protocoles de type réseau, préférentiellement TCP, INPROC, IPC, UDP ou PGM, ou en accès direct sur le système d'exploitation par exécution en ligne de commande, ou par connections au système d'exploitation via prise en main à distance par exemple ou 3039024 - 7 - autre procédés identiques. L'administrateur du système peut également réaliser des requêtes pour démarrer certain services ou pour les mettre à jour. Dans une réalisation, l'utilisateur accède librement aux services (10), dans une autre 5 réalisation, l'accès aux services (10) est conditionné à une authentification au préalable. Un ou plusieurs utilisateurs peuvent réaliser des requêtes en même temps et/ou le même utilisateur peut enchaîner plusieurs requêtes. Parallèlement aux requêtes réalisées par l'utilisateur, des services (10) peuvent 10 également réaliser des requêtes sur d'autres services (10) et ainsi devenir client d'autres services. La requête est donc dirigée vers le répartiteur de charges (5) qui ensuite la transmet à un noeud esclave (9) placé sur le système d'exploitation (1). Chaque noeud est 15 composé d'un répartiteur de charges (5), un service découvert (8), un protocole d'authentification nécessaire pour accéder à la ou les bases de registres (2), en mode privées et/ou des moyens pour déployer des services (10). Les noeuds maîtres (4) comportent, en plus, un référentiel (6) et un orchestrateur (7). 20 De préférence, sur chaque système d'exploitation (1), un noeud maître (12) et un orchestrateur (11) sont élus leader du système. De préférence, sur chaque système d'exploitation (1), un noeud maître (4) est connecté avec un noeud esclave (9), à qui il délègue les services. Un noeud maître 25 (4) peut également contenir un noeud esclave (9) (embouti et intégré) et exécuter les mêmes services (10) qu'un noeud esclave (9). Idéalement, lors d'une défaillance quelconque du noeud maître leader (12), il est possible de le remplacer automatiquement par un autre noeud maître (4), qui devient 30 ensuite le nouveau noeud maître leader (12). Aussi, lors d'une défaillance quelconque de l'orchestrateur leader (11), il est possible de le remplacer automatiquement par un autre orchestrateur (7), qui devient ensuite l'orchestrateur leader (11). 3039024 - 8 - Dans une réalisation, l'orchestrateur leader (11) est basé sur le noeud maître leader (12), dans une autre réalisation, l'orchestrateur leader (11) et le noeud maître leader (12) ne partagent pas la même structure, ainsi, il est possible que le noeud maître leader (12) héberge l'orchestrateur leader (11), qui, à son tour, est basé sur un 5 noeud maître (4) quelconque. Une fois que la requête de l'utilisateur et/ou du service (10) est dirigée vers au moins un noeud placé sur le système d'exploitation (1), la requête est dirigée vers le noeud esclave (9), en fonction des règles de service configurées par l'administrateur du 10 système d'exploitation (1), pour démarrer le service (10) souhaité. Commodément, les règles de service sont définies dans une configuration (fichier ou autre). Préférentiellement, ces règles organisent les noeuds (9) et/ou les services (10) selon un ordre déterminé. Pour répartir la charge d'utilisation de services entre 15 plusieurs noeuds, il est possible de choisir de diriger la requête vers un noeud (9) pris aléatoirement respectant l'ordre configuré, par exemple, ou vers le noeud (9) le moins utilisé déterminé par un calcul de l'historique ou un noeud (9) dans l'ordre séquentiel de la liste ou le noeud (9) ayant le plus de ressource disponible pour exécuter un service. Il est également possible, les combinaisons d'une ou plusieurs 20 de ces techniques. Parallèlement, l'orchestrateur leader (11) met en place plusieurs tâches: il réalise une recherche sur l'ensemble des noeuds maîtres (4) et/ou esclaves (9) pour indiquer les instances de services, les ressources disponibles et les ressources 25 nécessaires pour déployer le service (10) demandé. L'orchestrateur leader (11) indique également la version de l'image nécessaire pour déployer le service (10) demandé dans sa requête vers le registre. Avantageusement les informations sur les ressources nécessaires pour déployer le 30 service (10) demandé sont préalablement fournis et/ou configurées par l'administrateur du système. Dans une réalisation, selon les schémas représentés par les figures, mais de façon non limitative, la requête est dirigée vers le premier noeud esclave (9) respectant 3039024 - 9 - l'ordre configuré, une fois que l'orchestrateur leader (11) ait indiqué qu'un tel noeud (9) possédait des ressources disponibles et nécessaires pour déployer le service (10) demandé. Le service découvert (8) qui compose le dit noeud (9) confirme donc à l'orchestrateur leader (11) qu'un tel noeud (9) possède la version de l'image 5 nécessaire pour déployer le service (10) demandé. Ensuite, l'orchestrateur leader (11) orchestre qu'un tel noeud (9) démarre ledit service (10) et l'utilisateur reçoit la réponse à sa requête. L'utilisateur du service ne voit pas cette mécanique qui est réalisée par le système d'exploitation (1). 10 Dans une autre réalisation, aussi selon les schémas représentés par les figures, mais de façon non limitative, la requête est dirigée vers le premier noeud esclave (9) respectant l'ordre configuré, mais l'orchestrateur leader (11) indique qu'un tel noeud (9) ne possède pas de ressources disponibles et nécessaires pour déployer le service (10) demandé. Ainsi, l'orchestrateur leader (11) demande que la requête soit 15 dirigée vers le deuxième service (10) respectant l'ordre configuré et/ou dirigé vers le deuxième noeud esclave (9) respectant l'ordre configuré. Ensuite, le service (10) est démarré et l'utilisateur reçoit la réponse à sa requête. Encore dans une autre réalisation, selon les schémas représentés par les figures, 20 mais de façon non limitative, la requête est dirigée vers le premier noeud esclave (9) respectant l'ordre configuré, une fois l'orchestrateur leader (11) indiqué qu'un tel noeud (9) possède des ressources disponibles et nécessaires pour déployer le service (10) demandé. Ensuite, l'orchestrateur leader (11) demande à un noeud esclave (9) de démarrer ledit service (10). Cependant, le service découvert (8) qui 25 compose le dit noeud (9) informe à l'orchestrateur leader (11) qu'un tel noeud (9) ne possède pas la version de l'image nécessaire pour déployer le service (10) demandé. L'orchestrateur leader (11) ordonne donc l'interrogation de la base de registres (2), privée et/ou publique, afin que soit téléchargé sur ledit noeud (9) la version de l'image nécessaire pour déployer le service (10) demandé. 30 Commodément, l'orchestrateur leader (11) ordonne l'interrogation de la base de registres (2) publique et/ou privé pour télécharger intégralement l'image nécessaire pour déployer le service (10) demandé ou pour télécharger seulement la partie correspondant à la dernière version mise à jour par l'administrateur du système de 3039024 - 10 - l'image nécessaire pour déployer le service (10) demandé. Un tel téléchargement partiel des différences s'appelle le téléchargement différentiel. De préférence, le système est composé d'une à plusieurs bases de registres (2) 5 privées et/ou publiques, périodiquement répliquées, sur un fournisseur ou une infrastructure en nuage (13) ou sur une autre base de registres (2), publique et/ou privée, et hébergeant au moins un conteneur contenant des images de service (3) pour chaque service proposé. L'accès du noeud à cette base de registre (2) en mode privé est conditionné à un protocole de communication et de sécurité, 10 préférentiellement TCP, INPROC, IPC, UDP ou PGM. Idéalement, le et/ou les noeuds maîtres (4) et/ou esclaves (9) sont paramétrés préalablement par l'administrateur du système avec un protocole de communication et de sécurité, préférentiellement TCP, INPROC, IPC, UDP ou PGM, nécessaire pour 15 accéder à la et/ou les bases de registre (2), en mode privé. Ainsi, seulement les noeuds (4 - 9) ayant été paramétrés préalablement par l'administrateur du système peuvent accéder à au moins une image de service (3) hébergé dans la base de registres (2), en mode privé. 20 Avantageusement, l'administrateur du système a également accès à la et/ou aux bases de registres (2) publiques et/ou privées, ce qui lui permet de gérer les conteneurs contenant des images de service (3). L'administrateur du système a donc les moyens de créer, réorganiser et supprimer, à son gré, les conteneurs contenant des images de service (3). 25 Ainsi, selon les schémas représentés par les figures, mais de façon non limitative, lorsque l'orchestrateur leader (11) orchestre l'interrogation de la base de registres (2) en mode privé pour télécharger sur le dit noeud esclave (9) la version de l'image nécessaire pour déployer le service (10) demandé, le protocole de communication et 30 de sécurité, préférentiellement TCP, INPROC, IPC, UDP ou PGM, est demandé. Une fois authentifié, le noeud (9) à accès au conteneur des images de service (3) du service (10) demandé, le processus de téléchargement de l'image s'initie et un nouveau service (10) est désormais ajouté au noeud (9). 3039024 Ensuite, l'orchestrateur leader (11) ordonne au noeud (9) de démarrer le dit service (10) afin de fournir à l'utilisateur le service demandé et une réponse à sa requête. Idéalement, étant donné que chaque noeud maître (4) et/ou esclave (9) possède un 5 répartiteur de charges (5) et un service découverte (8) et le noeud maître (4) possède en plus un orchestrateur (7) et un référentiel (6), lorsqu'un service (10) est ajouté sur un noeud esclave (9), le service découverte (8) de ce noeud (9) met à jour son répartiteur de charge (5) et informe l'orchestrateur leader (11) sur cet ajout de plusieurs manières différentes, par exemple, par requête dirigée (TCP, INPROC, 10 IPC, UDP ou PGM) ou requête diffusé (broadcast) TCP/UDP, cette liste n'étant pas exhaustive. Une fois que l'orchestrateur leader (11) a reçu la demande de mise à jour, il met à jour le référentiel (6) qui compose le noeud maître leader (12). Automatiquement 15 l'information est transmise aux autres référentiels (6) de chacun des autres noeuds maîtres (4). Parallèlement, les services découverts (8) de chaque noeud, maître (4) et/ou esclave (9), réalisent périodiquement des vérifications sur ses propres noeuds (4 - 9) en 20 tenant compte de la configuration des référentiels (6) du noeud maître leader (12) et des autres noeuds maîtres (4). La périodicité de la réalisation de la vérification par les services découverts (8) sur ses propres noeuds (4-9) est paramétrable par l'administrateur du système. 25 Dans une réalisation, le service découverte (8) d'un noeud esclave (9) vérifie si son noeud esclave (9) à les mêmes configurations que le référentiel (6) du noeud maître (4) auquel il est connecté. Dans une autre réalisation, le service découvert (8) d'un noeud maître (4) vérifie si son noeud (4) a les mêmes configurations que le référentiel 30 (6) du noeud maître leader (12). Préférentiellement, lorsque les services découverts (8) de chaque noeud, maître (4) et/ou esclave (9), vérifient que ses noeuds (4 - 9) n'ont pas les mêmes configurations 3039024 - 12 - qu'aux référentiels (6), automatiquement les dits services découvertes (8) mettent à jour les répartiteurs de charge respectifs. Avantageusement, un même service peut être mis à disposition, c'est à dire, exécuté 5 sur le système d'exploitation (1), en une ou plusieurs versions en même temps. Idéalement, les répartiteurs de charge (5) et les référentiels (6) doivent avoir les mêmes configurations. Les mêmes informations sur les services (10). Cette synchronisation permet d'actualiser automatiquement les règles de service 10 configurées par l'administrateur du système, qui à leur tour sont définies dans un fichier de configuration. Ces règles organisent les noeuds (4 - 9) et/ou les services (10) selon un ordre déterminé et permettent de diriger la requête vers le service (10) souhaité par l'utilisateur, lorsqu'il saisit sa demande par sa soumission au système d'exploitation, ou demandé par un autre service (10), lorsqu'il réalise une requête 15 pour démarrer d'autres services (10). Les vérifications réalisées par les services découvertes (8) de chaque noeud, maître (4) et/ou esclave (9), sur ses propres noeuds (4 - 9) permettent également à l'orchestrateur leader (11) de réaliser des contrôles de performance et/ou de contrôle 20 d'état sur les noeuds (4 - 9) et/ou services (10). Dans une réalisation, le résultat du contrôle de performance et/ou du contrôle d'état indique le bon fonctionnement du noeud (9) et/ou du service (10), lorsque l'orchestrateur leader (11) demande à un noeud esclave (9) de démarrer un service 25 (10) et/ou réalise une recherche sur l'ensemble des noeuds (9) pour connaître les instances de services et les ressources disponibles, et il reçoit les retours des services découvertes (8) de chaque noeud esclave (9). Dans une autre réalisation, le résultat du contrôle d'état indique le 30 dysfonctionnement d'un noeud (9) et/ou d'un service (10), lors d'une défaillance quelconque, notamment une faille de communication, entre l'orchestrateur leader (11) et un service découverte (8) déterminé. 3039024 - 13 - Comme réaction au dysfonctionnement du noeud (9) et/ou service (10), l'orchestrateur leader (11) demande que la requête soit dirigée vers le prochain service (10) respectant l'ordre configuré et/ou dirigé vers le prochain noeud (9) respectant l'ordre configuré. Aussi, comme réaction au dysfonctionnement du service 5 (10), l'orchestrateur leader (11) met à jour le référentiel (6) qui compose le noeud maître leader (12) et automatiquement l'information est répliquée aux référentiels (6) de chacun des autres noeuds maîtres (4). Parallèlement, les services découvertes (8) de chaque noeud, maître (4) et/ou i.o esclave (9), mettent à jour automatiquement les répartiteurs de charge (5) respectifs. Désormais, les requêtes ne seront plus dirigées vers ce noeud (9) et/ou service (10). Ainsi, le système et le procédé selon l'inventions sont particulièrement destinés au déploiement automatique d'un service (10) sur un noeud réseau, en tenant compte 15 aussi des possibles défaillances, erreurs et échecs qui peuvent provenir des noeuds et des services (10). REVENDICATIONS: 1. Procédé automatique de déploiement de service sur un noeud réseau caractérisé en ce qu'il comporte les étapes suivantes: a. Exécution d'une requête pour démarrer un service (10) donné vers un noeud esclave (9) placé sur le système d'exploitation (1): i. respectant des règles de service configurées par l'administrateur du système, qui organisent les noeuds (9) et/ou les services (10) selon un ordre déterminé, ii. et respectant l'indication d'un orchestrateur leader (11) sur des ressources disponibles et nécessaires pour déployer le service (10) demandé. b. Confirmation par un service découverte (8) du noeud esclave (9), à qui a été dirigé la requête, si un tel noeud esclave (9) possède ou non la version de l'image nécessaire pour déployer le service (10) demandé. c. Interrogation d'une base de registres (2) privée ou publique par le service découverte (8) du dit noeud esclave (9), en utilisant un protocole de communication et de sécurité, préférentiellement TCP, INPROC, IPC, UDP ou PGM, permettant d'accéder à au moins une image de service (3) hébergé dans la dite base (2), pour télécharger la version de l'image nécessaire pour déployer le service (10) demandé, quand ledit noeud esclave (9) ne la possède pas. d. Initiation du processus de téléchargement de l'image et ajout d'un nouveau service (10) au dit noeud esclave (9). e. Démarrage du service (10) demandé par le dit noeud esclave (9). 2. Procédé selon la revendication 1, caractérisé en ce que les requêtes sont réalisées par des utilisateurs en saisissant une demande par sa soumission au système d'exploitation (1) et/ou par des services (10) pour démarrer d'autres services (10) et/ou par un administrateur pour démarrer certain services ou les mettre à jour. 3039024 - 15 - 3. Procédé selon les revendications 1 et 2, caractérisé en ce que la soumission de la requête de démarrage de service peut suivre des protocoles de type réseau, préférentiellement TCP, INPROC, IPC ou PGM, UDP ou être en accès direct sur le système d'exploitation (1) par exécution en ligne de 5 commande, ou par connections au système d'exploitation (1) via prise en main à distance. 4. Procédé selon la revendication 1, caractérisé par un choix de diriger la requête vers un noeud (9) pris aléatoirement dans la liste ou vers le noeud (9) 10 le moins utilisé déterminé par un calcul de l'historique ou un noeud (9) dans l'ordre séquentiel de la liste. 5. Procédé selon la revendication 1, caractérisé en ce qu'il comprend les étapes suivantes: 15 a. lorsqu'un service (10) est ajouté sur un noeud esclave (9), le service découvert (8) de ce noeud (9) met à jour son répartiteur de charge (5) et informe l'orchestrateur leader (11) sur cet ajout, b. l'orchestrateur leader (11) met à jour un référentiel (6) qui compose un noeud maître leader (12). 20 c. automatiquement l'information est répliquée aux référentiels (6) de chacun des autres noeuds maîtres (4). 6. Procédé selon les revendications 1 et 5, caractérisé en ce qu'il comprend les étapes suivantes: 25 a. vérification par le service découverte (8) d'un noeud esclave (9) si son noeud à les mêmes configurations qui le référentiel (6) du noeud maître (4) auquel il est connecté. b. vérification par le service découverte (8) d'un noeud maître (4) si son noeud (4) à les mêmes configurations que le référentiel (6) du noeud 30 maître leader (12). c. Mise à jour automatique par les dits services découvertes (6) de ses répartiteurs de charge (5) respectifs, si ses noeuds n'ont pas les mêmes configurations que les référentiels (6). 3039024 - 16 - 7. Procédé selon les revendications 1 et 6, caractérisé en ce qu'il comprend les étapes suivantes: a. Réalisation de contrôle de performance et/ou d'état sur les noeuds (9) et/ou service par l'orchestrateur leader (11), lorsqu'il ordonne qu'un 5 noeud (9) démarre un service (10) et/ou réalise une recherche sur l'ensemble des noeuds (9) pour connaître les instances de services et les ressources disponibles b. Direction de la requête vers le prochain service (10) respectant l'ordre configuré et/ou dirigé vers le prochain noeud (9) respectant l'ordre i.o configuré par l'orchestrateur leader (11), lors d'une défaillance de communication entre l'orchestrateur leader (11) et un service découverte (8) déterminé c. Mise à jour du référentiel (6) qui compose le noeud maître leader (12) par l'orchestrateur leader (11) et réplication automatiquement de 15 l'information aux référentiels (6) de chacun des autres noeuds maîtres (4). d. Mise à jour par les services découverts (8) de chaque noeud, maître (4) et/ou esclave (9), de ses répartiteurs de charge (5) respectifs. 20 8. Système comportant des moyens adaptés pour la mise en oeuvre du procédé selon la revendication 1, caractérisé en ce qu'il comporte: a. d'une à plusieurs bases de registres (2), publique et/ou privée, périodiquement répliquées, sur un fournisseur ou une infrastructure en nuage (13) ou sur une autre base de registres, publique et/ou privée, et 25 hébergeant au moins un conteneur contenant des images de services (3) pour chaque service (10) proposé b. d'au moins un système d'exploitation (1) composé d'au moins un noeud maître (4) et au moins un noeud esclave (9) comportant: c. un répartiteur de charges (5), un service découverte (8), un protocole 30 d'authentification nécessaire pour accéder à la et/ou les bases de registre (2) en mode privé et/ou des moyens pour déployer des services (10), dont le noeud maître (4) comporte, en plus, un orchestrateur (7) et un référentiel (6). 3039024 - 17 - 9. Système selon la revendication 8, dans lequel chaque système d'exploitation (1) est caractérisé en ce qu'il comporte un noeud maître leader (12) et un orchestrateur leader (11) basé sur le dit noeud maître leader (12) ou sur un autre noeud maître (4). 5 10. Système selon les revendications 8 et 9, caractérisé en ce que: a. le noeud maître leader (12) est remplacé automatiquement par un autre noeud maître (4), lors d'une défaillance du noeud maître leader (12) b. l'orchestrateur leader (11) est remplacé automatiquement par un autre 10 orchestrateur (7), lors d'une défaillance de l'orchestrateur leader (11).