В документации предполагается, что я могу настроить HTTP-проверку для TCP-бэкэнда.
Жизнеспособность моего бэкэнда определяется 405 Method Not allowed
ответ при ударе a-app.com/ap_service
Моя конфигурация выглядит так:
frontend app-api
bind *:443
mode tcp
option tcplog
default_backend app-api_backend
backend app-api_backend
mode tcp
option httpchk GET /app_service HTTP/1.1
http-check expect status 405
server a a-app.com:443 resolvers dns verify none inter 1000 check
server b b-app.com:443 resolvers dns verify none inter 1000 check
Однако в журналах я получаю:
Server app-api_backend/a is DOWN, reason: Layer7 invalid response, check duration: 1ms. 1 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.
Server app-api_backend/b is DOWN, reason: Layer7 invalid response, check duration: 1ms. 1 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.
...
Я думаю, ваша проблема в том, что вы ожидаете, что haproxy будет делать HTTPS-запросы, предполагая, что порт 443 обслуживается на нем, а option httpchk
выполняет только простые HTTP-запросы.
Обслуживайте свое приложение через простой HTTP на другом порту, кроме HTTPS, сделайте его доступным для узла haproxy и используйте HTTP для проверок.
См. Пример в параметр haproxy httpchk документы:
# Relay HTTPS traffic to Apache instance and check service availability
# using HTTP request "OPTIONS * HTTP/1.1" on port 80.
backend https_relay
mode tcp
option httpchk OPTIONS * HTTP/1.1\r\nHost:\ www
server apache1 192.168.1.1:443 check port 80
В вашем случае это будет примерно так:
backend app-api_backend
mode tcp
option httpchk GET /app_service HTTP/1.1
http-check expect status 405
server a a-app.com:443 resolvers dns verify none inter 1000 check port 80
server b b-app.com:443 resolvers dns verify none inter 1000 check port 80