C'est quand même dingue qu'a vous lire, toute la puissance de haproxy réside dans son code de reload de config
Je réexplique pour les personnes un peu lente.
Toute la puissance d'haproxy vient du fait qu'il est à processus unique, piloté par évennement. (Single process, event driven).
Sur ce genre d'appli (un proxy en mode processus unique) il n'est pas possible de mettre à jour la config de façon dynamique. Il n'existe pas de méthode pour aglomérer intelligeament l'ancienne config et la nouvelle (les serveurs peuvent avoir changés d'ip ou de nom, certaines sessions autorisées peuvent être interdite, le poids de load balancing peut avoir été changé etc.)
A partir de la quand on modifie la config d'un proxy la seule bonne façon de faire est de tuer et de relancer les processus de proxification et de repartir à 0.
Si il y a un controlleur dédié (ie le daemon n'est pas le processus de proxification) alors le controlleur relance les processus fils un par un (c'est le cas pour nginx) mais dans le cas d'une appli à processus unique la SEULE façon de faire est de relancer complètement le processus.
A partir de là forcément il faut créer un "pseudo controlleur" pour devenir compatible avec systemd. Le "pseudo controlleur" ne fera rien d'autre que de lancer haproxy et de lui passer les messages systemes (d'ou le "pseudo").
Donc en fait : proxy+architecture à processus unique = on relance tout en cas de changement de config.
Le pseudo controlleur ne sert à rien d'autre qu'à faire plaisir à systemd d'ou le terme de wrapper.
[^] # Re: systemd, c'est bien
Posté par Kaane . En réponse au journal et ce qui devait arriver, arriva .... Évalué à 7.
C'est quand même dingue qu'a vous lire, toute la puissance de haproxy réside dans son code de reload de config
Je réexplique pour les personnes un peu lente.
Toute la puissance d'haproxy vient du fait qu'il est à processus unique, piloté par évennement. (Single process, event driven).
Sur ce genre d'appli (un proxy en mode processus unique) il n'est pas possible de mettre à jour la config de façon dynamique. Il n'existe pas de méthode pour aglomérer intelligeament l'ancienne config et la nouvelle (les serveurs peuvent avoir changés d'ip ou de nom, certaines sessions autorisées peuvent être interdite, le poids de load balancing peut avoir été changé etc.)
A partir de la quand on modifie la config d'un proxy la seule bonne façon de faire est de tuer et de relancer les processus de proxification et de repartir à 0.
Si il y a un controlleur dédié (ie le daemon n'est pas le processus de proxification) alors le controlleur relance les processus fils un par un (c'est le cas pour nginx) mais dans le cas d'une appli à processus unique la SEULE façon de faire est de relancer complètement le processus.
A partir de là forcément il faut créer un "pseudo controlleur" pour devenir compatible avec systemd. Le "pseudo controlleur" ne fera rien d'autre que de lancer haproxy et de lui passer les messages systemes (d'ou le "pseudo").
Donc en fait : proxy+architecture à processus unique = on relance tout en cas de changement de config.
Le pseudo controlleur ne sert à rien d'autre qu'à faire plaisir à systemd d'ou le terme de wrapper.