Hi Jérôme,
On Sun, Apr 26, 2020 at 02:34:34PM +0200, Jerome Magnin wrote:
> The documentation for check implies that without an optional l7
> check configured, it enables simple tcp checks. What it actually
> does is check that every configured handshake on the server line
> can be established.
Thanks for this, however I don't completely agree with the wording
there (but I do agree that the current one is totally outdated).
The main point is that users don't configure "handshakes", they
rather define transport protocols (typically SSL) so in the end
this is not necessarily clearer this way and may even lead to new
confusion regarding ssl vs check-ssl for example.
Probably that it would be better to take this opportunity to
entirely revisit the description of the "check" keyword to cover
the following points:
- without "check", no check is performed and the server is always
considered "up"
- when "check" is specified and no check method is defined, the
server is considered "up" when a connection can be established
at the highest configured transport layer, which means bare TCP
by default, or SSL/TLS when "ssl" or "check-ssl" are involved,
both possibly combined with possible connection prefixes such as
a proxy protocol header
- when "check" is specified and an application-level check method
is defined, then the application-level exchanges are performed on
top of the configured transport layer, all of which must succeed
for the server to be reported "up".
- by default, checks are performed on the same address and port as
configured on the server, using the same encapsulation parameters
(SSL/TLS, SNI, proxy-protocol header etc). If "port" or "addr"
directives are set, it is assumed that the server isn't checked on
the traffic port but on a proxy port that possibly uses a different
service. In this case, connection headers such as the proxy protocol
are only sent if "check-send-proxy" is set; SSL/TLS is only used if
"check-ssl" is used, and similarly the SNI used on the connection
will be defined by "check-sni". See also "check-ssl", "check-sni" etc.
> # this does a tcp connect + tls handshake
> backend foo
> server s1 192.168.0.1;443 ssl check
beware the semicolon here ^
Be careful below, some lines are slightly longer than the 80 chars limit.
> + always considered available. If "check" is set, the server is considered
> + available when all the handshakes configured on the server line can be
> + established, or when an optional layer 7 health check succeeds. This is to
> + ensure that the server is really able to handle requests. The default
> address
> + and port to send health checks to are those of the server, and the default
> + source address is the same as the one defined in the backend. It is
> possible
> + to change the destination address using the "addr" parameter, the port
> using
> + the "port" parameter, the source address using the "source" parameter, and
> the
> + interval and timers using the "inter", "rise" and "fall" parameters.
> Optional
> + layer 7 checks can be configured with the "httpchk", "smtpchk",
> "mysql-check",
> + "pgsql-check" and "ssl-hello-check" options. When ssl is configured on the
> + server line, "option tcp-check" and "tcp-check connect" can be used to
> refrain
> + from establishing the tls hanshake during health checks. Please refer to
> those
> + options and parameters for more information. See also "no-check" and
> "check-ssl".
Thanks,
Willy
