funktionierende Konfiguration für haproxy mit der force-persist-Einstellung

Question

Ich bin mir nicht sicher, ob mir ein Schlüsselkonfigurationsteil fehlt oder ich missverstehe einfach den Zweck der Zwangserhaltung in haproxy (mit Version 1.5.11 auf Ubuntu 14.04) . Aus der Dokumentation:

Die „Kraft-persistieren“ Anweisung ermöglicht eine verschiedene ACL-basierte Bedingungen zu erklären, die, wenn sie erfüllt ist, bewirkt, dass ein Antrag auf dem Abwärts Status einen Server ignorieren und versucht immer noch zu verbinden zu ihm. Dies ermöglicht es, einen -Server zu starten, der weiterhin einen Fehler bei den Systemdiagnosen meldet, und einen speziell konfigurierten -Browser zum Testen des Dienstes auszuführen.

Das klingt wie genau das Verhalten, das ich will, wo ich alle App-Server in „Wartungsmodus“ für einen Code Roll-out setzen könnte, noch erlauben bestimmte IPs noch zu verbinden, um es zu testen, Post-Roll-out, bevor Sie wieder jedem Zugriff gewähren. Hier ist die Konfiguration Ich habe ein:

global 
    log /dev/log local0 
    log /dev/log local1 notice 
    chroot /var/lib/haproxy 
    stats socket /run/haproxy/admin.sock mode 660 level admin 
    stats timeout 30s 
    user haproxy 
    group haproxy 
    daemon 

    # Default SSL material locations 
    ca-base /etc/ssl/certs 
    crt-base /etc/ssl/private 

    # Default ciphers to use on SSL-enabled listening sockets. 
    # For more information, see ciphers(1SSL). 
    ssl-default-bind-ciphers kEECDH+aRSA+AES:kRSA+AES:+AES256:RC4-SHA:!kEDH:!LOW:!EXP:!MD5:!aNULL:!eNULL 
    ssl-default-bind-options no-sslv3 

defaults 
    log global 
    mode http 
    option httplog 
    option dontlognull 
    timeout connect 300s 
    timeout client 50000 
    timeout server 50000 
    errorfile 400 /etc/haproxy/errors/400.http 
    errorfile 403 /etc/haproxy/errors/403.http 
    errorfile 408 /etc/haproxy/errors/408.http 
    errorfile 500 /etc/haproxy/errors/500.http 
    errorfile 502 /etc/haproxy/errors/502.http 
    errorfile 503 /etc/haproxy/errors/503.http 
    errorfile 504 /etc/haproxy/errors/504.http 

listen mysite 
    bind *:80 
    bind *:443 ssl crt mysite.pem 
    http-request set-header X-Forwarded-Port %[dst_port] 
    http-request add-header X-Forwarded-Proto https if { ssl_fc } 
    redirect scheme https if !{ ssl_fc } 
    balance roundrobin 
    option forwardfor 
    option httpchk HEAD /haproxy_health_check.php 
    acl whitelist src -f /etc/haproxy/whitelist.lst 
    force-persist if whitelist 
    server app-1 10.1.4.32:80 maxconn 20 check inter 10000 

Mit dieser Konfiguration Ich denke ich sollte den folgenden Befehl erteilen können:

echo "disable server mysite/app-1" | socat /run/haproxy/admin.sock stdio 

nehmen die einzelnen App-Server aus der Rotation, Und solange ich von einer IP-Adresse komme, die in /etc/haproxy/whitelist.lst aufgeführt ist, sollte ich die Website immer noch so sehen können, als wäre der Server noch aktiviert. Was ich jedoch am Ende sehe, ist die 503-Fehlerseite, die ich normalerweise erwarten würde, wenn ich ein normaler Benutzer wäre, aber nicht von der IP auf der weißen Liste kommt. Um die Möglichkeit zu entfernen, dass ich falsch die IP-Adressen wurde angibt, oder mit dem Befehl acl falsch, ich habe eine Variation versucht, wo ich einfach eingestellt:

force-persist if TRUE 

Aus meiner Lektüre der Dokumentation, würde ich denke, das wäre tun, als ob ich den Server niemals deaktiviert hätte, egal von welcher IP ich kam. Leider bekomme ich immer noch die 503.

Es gibt clunkier Möglichkeiten, die Weitergabe von zusätzlichen Konfiguration in und Haproxy neu laden, die ich verwenden könnte, um dies funktioniert, aber "force-persist" zusammen mit der praktischen Möglichkeit, über den Befehl zu deaktivieren Linie scheint eine viel elegantere Herangehensweise zu sein, und ich würde es definitiv bevorzugen, wenn ich es zum Laufen bringen könnte.

Hat jemand anderes versucht, Haproxy auf diese Weise arbeiten zu lassen? Ist es falsch, "force-persist" so zu interpretieren? Brauche ich ein bisschen zusätzliche Konfiguration, damit es funktioniert?

Answer 1

Es gibt keine Regel, die angibt, was in dieser Konfiguration beibehalten werden soll. Normalerweise verwenden Sie dies in Kombination mit einer Cookie-basierten Persistenz. Zum Beispiel:

cookie SERVERID insert indirect nocache 
server srv1 1.1.1.1:80 cookie s1 check 
server srv2 2.2.2.2:80 cookie s2 check 
acl from_management_net src 10.0.0.0/8 
force-persist if from_management_net 

Dann auf Ihrem Client, besuchen Sie den ersten Server, erhalten die zugewiesene Cookie, deaktivieren Sie den Server, und es wieder besuchen, und Sie werden dorthin gehen weiter. Normalerweise implementieren Leute eine spezifische HTML-Seite, die alle Server und ihre jeweiligen Cookies auflistet, die helfen, die Server vom Klienten auszuwählen, indem sie einfach auf sie klicken.