If getting Let's Encrypt to work with HAProxy is your only struggle, you'll soon overcome it and be loving HAProxy. And there are multiple ways to set up Let's Encrypt, if you don't want to use acme.sh. For example, you could use certbot. There are blog posts that cover that pretty well.
You can think of it as having layers of redundancy.
* Retries are one layer. By default set to 3 retries. HAProxy will retry the failed connection or request with the same server.
* "option redispatch" is another layer. If HAProxy can't connect to a server that is reporting as healthy, it will send the request to a different server.
* health checks are a layer. HAProxy removes unresponsive servers from load balancing.
* Backup servers are another layer. If all servers fail their health checks and are down, then backup servers come online to service requests.
All these things can be enabled in combination, and it would reduce the chance of a client getting a server error.
To answer your question, HAProxy will not connect with a server that is down (failed all its health checks). It will not retry with it either.
One approach that some users who want this mechanism use is the "on-error sudden-death" mechanism: the server responses are inspected, and upon error (from selectable types), the server can be marked dead. If all of them are dead the backup server will come into the dance and the last attempt will end up on it.
kzrdude, great feedback. These big version announcements gather the attention of people who may not be familiar with HAProxy and so, I'd say they are a unique case where we should introduce the product for newcomers.
The HAProxy Data Plane API performs a validation check: it sends the -c flag to the HAProxy process before reloading to make sure that it is a valid configuration. If the configuration is invalid, the changes will not take effect and you will see errors in your console or log. With transactions, it's not quite stateless (as HTTP is). Transactions provide a way to make multiple changes and apply them with a single commit. The main benefit of an API is towards program-ability (is that a word?), in which configuring HAProxy can be controlled by "control plane" software, slick looking UIs, tools like Ansible, etc. in an automated way. You can also generate client-side code from the API, such as for Go/Python/[insert language] coding. It goes beyond the use case of "I'm a human who wants to control HAProxy manually or with templates".
This is so cool. Time to rewrite my 5 year old nginx configs to haproxy.
P.S. in typical haproxy vein, its a bit hard to get started. for example the Docker page doesnt have a trivially runnable version for haproxy 2.0 (https://hub.docker.com/_/haproxy/).
It was fun writing this blog post because the API covers a lot of ground in terms of what can be done programmatically with the configuration. I've wanted something like this for integrating into a CD pipeline, for example.
We are using NGINX with its core Stream module to receive HTTP/2 encrypted traffic, and loadbalance it (with random or least_conn) algorithms -- to each of our backends.
Traffic stays encrypted end-to-end, and it remains HTTP/2 (because the Stream module works at TCP level, not http so it does not care http/2 or http/1 is used).
It seems that in the ticket [2] that you mentioned, the commenter at the end is asking exactly for this. And that works well.
It is called often 'pass-through proxy'.
The article here explains how to set it up
We loose information about the Web-browser's IP address at our backend.
For for privacy-enforcement reasons, we actually do not want to have it at our terminating points (our backend apis).
And also, if we ever need it -- I thin this can be enabled with the proxy protocol.
Thus it's just a plain TCP proxy and cannot route the traffic intelligently (based on Host or path) nor cache it. Following the same principle it could be said that haproxy has been supporting end-to-end H2 since version 1.0 long before H2 even existed!
With haproxy you can combine any set of H1/H2 on any side (protocol translation). It can even dynamically choose H1 or H2 depending on the negotiated ALPN the server presents, just like a browser does!
Thx. Yes, NGNIX will not be able to balance HTTP/2 traffic based on HTTP headers. But HAProxy 2.0 can.
In our case, we are not un-encrypting at the load balancer, so we cannot see the HTTP headers anyway. Instead we use NGINX to load-balance based on TCP-level info.
> * ACL rules with full support for logical if statements [1]
That is a terrifying "feature".
Turing completeness is not a feature. That "feature" allows complete emulation of other computation types.. Including an infinite ways of doing something wrong or bad.
