Problemas com haproxy reqrep

Question

Cenário

Eu tenho uma fazenda haproxy de 3 (apache) webservers. 2 estão ativamente equilibrados e o terceiro é um backup normalmente.

De vez em quando, quero tirar o terceiro servidor da função de backup e torná-lo um servidor de 'patch'. Mas eu quero fazer isso sem mudar o URL (por exemplo, eu não quero usar patch.mysite.com)

O que quero que aconteça é que visito http://mysite.com/patch e que o haproxy ofereça ao servidor um cookie para uso posterior em uma ACL, mas remova o /patch e envie um GET / para o servidor backend.

Onde estou agora, a ACL está funcionando bem, mas o reqrep não está removendo a solicitação / patch antes de enviá-la ao back-end.

Configuração:

global
    log 127.0.0.1   local0 info

    maxconn 25000
    daemon
    spread-checks 2 

defaults
    log     global
    mode    http
    balance roundrobin

    option  httplog
    option redispatch
    option abortonclose
    option forwardfor
    option http-server-close

frontend webfarm :80 
  # FILTERING
  acl acl_patch path_end /patches

  use_backend patch if acl_patch
  default_backend default_farm

backend default_farm
  cookie SERVERID insert indirect
  server prod1 192.168.100.18:80 cookie live01 check
  server prod2 192.168.100.22:80 cookie live02 check weight 2
  server prod3 192.168.100.20:80 cookie live03 check backup

  # do not let this cookie tell our internal IP address 
  rspidel ^Set-cookie:\ IP=

backend patch  
  cookie SERVERID insert indirect
  server prod3 192.168.100.20:80 cookie live03
  reqrep ^([^\ ]*)\ /patch     \ /

  # do not let this cookie tell our internal IP address
  rspidel ^Set-cookie:\ IP=

O log haproxy ainda especifica um GET /patch sendo enviado para o backend. O que estou perdendo sobre o reqrep (não me importo com nada depois do diretório / patch)?

    

Answer 1

Primeiro, sua regra também deve manter a parte da versão HTTP.

Em segundo lugar, por que você não usa a declaração "force-persist" para isso? Foi projetado exatamente para esse papel. Basta encontrar algo em sua solicitação que o torne diferente dos seus visitantes, defina um cookie para acessá-lo e, em seguida, você poderá usar esse servidor. Este mecanismo foi feito precisamente para operações de manutenção sem ter que fazer com que o servidor aparecesse como para outros usuários.

Como alternativa, no seu caso, você também pode usar o método "redirect", pois ele suporta a opção "set-cookie"; Em seu frontend, você substituiria a regra use_backend por algo assim:

redirect location / code 302 set-cookie SERVERID=live03 if acl_patch

Seu navegador então aprenderá esse cookie e redirecionará para o /, onde o servidor 3 manipulará a solicitação. Há até uma opção de cookie claro que pode ser usada para se livrar da viscosidade se você quiser.