Endereço do servidor dinâmico HAProxy baseado no valor do cabeçalho

Question

Olá, estou tentando direcionar o tráfego de volta para uma máquina de usuários para executar um site localmente, mas selecionando os cabeçalhos / cookies / lógica de roteamento para outras origens que o HAProxy fornece. Até agora, porém, não consegui descobrir como fazer isso. A documentação diz que o uso de variáveis de ambiente é utilizável link

Any part of the address string may reference any number of environment variables by preceding their name with a dollar sign ('$') and optionally enclosing them with braces ('{}'), similarly to what is done in Bourne shell.

mas eu imagino que há uma maneira de usar uma busca acl ou de amostra, mas para a vida de mim não consigo descobrir como. Abaixo está um exemplo de uma coisa que eu tentei. Eu fiz uma prova de conceito removendo $ {hdr (originalIp)} e usando meu IP, mas eu quero que ele use dinamicamente o IP do solicitante se o cookie estiver presente

### Sample config
acl has_local_cookie cook_sub(local) -i true
use_backend local    if has_local_cookie
backend local
server local-origin ${hdr(originalIp)}:443 ssl verify none

    

Answer 1

O problema com o que você está tentando é que você está tratando toda a configuração como se ela estivesse sendo constantemente analisada e interpretada em tempo de execução, o que obviamente não é o caso.

Certos argumentos para as várias diretivas são estáticos, outros dinâmicos, mas as declarações server são mais estáticas. Um servidor representa exatamente um endereço de destino, não um endereço diferente por solicitação.

Você precisará configurar um back-end para cada desenvolvedor ou colocá-los todos em um back-end, backend local com uma declaração de servidor único para cada desenvolvedor, server dev-1 192.168.1.1:80 ... , server dev-2 ... , etc.

Então use_backend local if { cook_sub(local) -i true } .

Em seguida, no back-end, adicione um use-server para corresponder aos nomes dos servidores ao IP de origem use-server dev-1 if { src 192.168.1.1 } para cada desenvolvedor.

Observe que { ... } é uma ACL anônima, uma maneira muito mais limpa (imho) de testar condições simples, principalmente quando as condições são avaliadas apenas em um local na configuração. Se você está testando a mesma condição em vários lugares, as ACLs nomeadas são melhores porque elas são editadas em apenas um lugar, para que você não precise atualizá-las em vários lugares, como faria se copiasse e colasse a mesma ACL anônima a configuração.