Nous utilisons HAProxy 1.8.13 sur Centos 7 avec des backends attribués dynamiquement (les IP et les ports des backends sont attribués par le biais de sockets stats). Cela fonctionne bien.
Nous avons besoin d'une méthode pour faire en sorte que les éléments attribués dynamiquement restent en place lors des redémarrages et nous voulions utiliser le " load-server-state-from-file . Malheureusement, nous nous heurtons à une erreur (ou peut-être est-ce voulu ?) : le fichier d'état ne restaure pas l'adresse IP configurée :
Notre configuration de test :
global
log 127.0.0.1 local2
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 4000
user haproxy
group haproxy
daemon
nbproc 2
stats socket /run/haproxy/1.sock mode 0744 level admin process 1
stats socket /run/haproxy/2.sock mode 0744 level admin process 2
server-state-file /run/haproxy/server_state
defaults
load-server-state-from-file global
timeout server 10s
timeout client 15s
timeout queue 6s
timeout connect 10s
frontend main
bind *:5000
default_backend app
backend app
balance roundrobin
server app1 127.0.0.1:5001 check
server app2 127.0.0.1:5002 check
server app3 127.0.0.1:5003 check
server app4 127.0.0.1:5004 check
Nous configurons les IPs via script et ensuite nous sauvegardons l'état avec :
echo "show servers state" | socat /run/haproxy/1.sock - > /run/haproxy/server_state
Ce qui produit par exemple :
1
# be_id be_name srv_id srv_name srv_addr srv_op_state srv_admin_state srv_uweight srv_iweight srv_time_since_last_change srv_check_status srv_check_result srv_check_health srv_check_state srv_agent_state bk_f_forced_id srv_f_forced_id srv_fqdn srv_port
7 app 1 app1 127.0.0.1 0 1 1 1 60 8 2 0 14 0 0 0 - 5001
7 app 2 app2 10.10.10.115 2 0 1 1 23 6 3 4 6 0 0 0 - 31501
7 app 3 app3 10.10.10.113 2 0 1 1 22 6 3 4 6 0 0 0 - 31375
7 app 4 app4 10.10.10.114 2 0 1 1 22 6 3 4 6 0 0 0 - 31400
Lorsque haproxy redémarre, il rétablit les informations d'état up/down et le port, mais réinitialise l'IP à 127.0.0.1 :
1
# be_id be_name srv_id srv_name srv_addr srv_op_state srv_admin_state srv_uweight srv_iweight srv_time_since_last_change srv_check_status srv_check_result srv_check_health srv_check_state srv_agent_state bk_f_forced_id srv_f_forced_id srv_fqdn srv_port
7 app 1 app1 127.0.0.1 0 1 1 1 7 8 2 0 14 0 0 0 - 5001
7 app 2 app2 127.0.0.1 0 0 1 1 2 8 2 0 6 0 0 0 - 31501
7 app 3 app3 127.0.0.1 0 0 1 1 2 8 2 0 6 0 0 0 - 31375
7 app 4 app4 127.0.0.1 0 0 1 1 1 8 2 0 6 0 0 0 - 31400
Nous avons joué avec " init-addr "mais cela ne concerne que les adresses dorsales basées sur le DNS. Avons-nous fait quelque chose de mal ? Est-ce un comportement attendu ? Ou s'agit-il d'une sorte de bogue ?