bedis9

Stay tune (tips: dataplaneapi)

Well, HAProxy Community can do all this :)

As you explained, HAProxy does support OCSP stapling through flat file, but also support it through the runtime API.

v1 of the ingress controller does not update OCSP. That said, this is planed for a next release.

Stay tuned :)

Yes, it does. We'll blog about those use cases during the summer.

Partially true. Sub matching is stored in chained lists and could take some CPU if improperly used

Traefik performance sucks... In my bench, it is like 6 times slower than haproxy on an AWS instance. It eats up a huge amount of memory and burns all the cups.... As well, traefik configuration is not flexible enough to match haproxy power...

But this is not the purpose of the thread.

But nginx does not do basic load balancing related features such as health checking, persistence (some apps still need that), DNS service discovery, stats, observability, etc...

Graphql seems to be limited because of its single endpoint design. So some features are applied globally while you may want them per route.

I could not have answered in a better way.

Just adding we love and do open source.

This is part of part-2 of our blog post about api gateway with haproxy. It will feature token validation in Lua and much more fancy things..

Well this looks doable with Lua, as an http action probing an api that would let it now if the destination service is available and where. One point about routing, do you mean that server for handling /foo/bar may not exist yet in haproxy's configuration? If so, we could enforce the destination IP at runtime, based on the response provided at the step above.

All of this is on it's way. depending on what you mean by distributed tracing, it may already be doable

Hi,

I did write this blog post. Feel free to ask if you have any questions.

LOL this software does not even understand HTTP/1.0...

Yes, cached A records get expired in HAProxy (both community and enterprise).

HAProxy won't follow-up the TTL returned by the server. It's up to the administrator to decide how HAProxy should behave with DNS responses.

From my point of view, you don't need synapse any more if your usage of synapse is limited to this single feature.

No way to register new frontends, new binds neither new backends. We can only add/remove servers in backends for now. The "registration" you mentioned may happen later.

Please note that you can already do dynamic routing using ACLs or MAPS and updating your ACLs or MAPs content at runtime using the Runtime API (stats socket). there are "set map" and "set map" commands for this purpose.

Let me say it again: no disks I/O in HAProxy at run time. Simply put an nginx locally and use HAProxy's cache (or nginx one).

> The only thing I could ask for is a REST admin api to assist with my deploys.

For now, there is one in HAProxy Enterprise, and it manages HAProxy's configuration file and triggers reload.

We're working on opening it, as soon as we have improved it: make it use both HAProxy Runtime API (stats socket) and configuration file to trigger reloads only when required.

Stay tuned as we say :)

and also that LVS does it well in kernel!

Server side is on its way for next release, haproxy 1.9.

We first developped DNS in HAProxy for our AWS users who wanted HAProxy to follow-up a node when it is restarted (and it's IP is changed)... That was the very first request from both community and customers. After we released this feature, the community came back with some requirements regarding the ability to use DNS resolution to resolve all the servers (or a set of servers at list) of a backend. So we had to improve a lot the first dev we did to make this possible. Support for SRV record is just the last stone we put on top of many other devs :)

We're quite proud of the result because it makes HAProxy able to scale up / down at run time without being reloaded and compatible with any service registry able to export a list of nodes delivering a same service through DNS.

HAProxy can use multiple name for the resolution, pointing to different set of DNS servers, enforcing custom "hold" timers (to bypass server's TTL or negative TTLs in case of NX, etc...) and mix all of this with "old style hardcoded" servers in the backend...

HAProxy is flexible :)

Unfortunately, this is not possible! The DNS in HAProxy relies on the internal task scheduler which is itself event-driven.

I do agree on this statement!!! I personally validated HAProxy SRV records with both Kubernetes and Consul and I was positively supersized of how simple is consul. (Well, it does not cover all the stuff kubernetes does, you may need nomad for this purpose).

The advantage of using SRV records with consul, is that any load-balancer supporting SRV can replace any loadbalancer already in place, almost seamlessly :) This applies to any Service Registry (I tested the feature with both Kubernetes and Consul)

So yes, this feature was missing in HAProxy and we catched up because our community and some customers asked for it. So they can now use the power of HAProxy with their current consul deployments.

no, this feature is already available in -dev community branch. So it's already available for free.

Note this feature has not yet been backported into HAProxy Enterprise...

All the features developed in HAProxy, are pushed in the -dev branch of the community version. They are available for free at your own risk (running a -dev code in prod), or you have to wait until -dev become stable. HAProxy Enterprise users might already benefit from this feature in a stable way.

On the opposite, in nginx, some features are developed only in their proprietary solution. Sometime, nginx inc passes for heroes because they open source some of them...

Well, nignx inc does first develop their proprietary software... Then, they "open" some features. With nginx plus, you're locked to nginx, like when you were using a F5 load-balancer!

HAProxy Technologies pushes first its developments in the -dev community branch. Check the commits for the feature given above (SRV records, non exhaustive list of patches): http://git.haproxy.org/?p=haproxy.git&a=search&h=HEAD&st=com...

HAProxy technologies simply makes the effort of maintaining a branch of HAProxy in which some -dev features are backported. That way, users of HAProxy Enterprise have the most stable and feature reach version of HAProxy. And as Willy stated, every user of HAProxy Enterprise also have access to the source packages.

So from a business point of view, the main difference between HAProxy and nginx is that HAProxy is the respects both its community and customers.

And HAProxy supports Consul out of the box thanks to this new feature :)

What about giving the ability to HAProxy to perform the SRV requests directly???

"pure" opensource doesn't exist: There is open source and there is closed source. HAProxy is open source, products developed by HAProxy Technologies are also open source for our customers!!!

on the other side, you have varnish plus and nginx plus which are closed source, which means their clients can't have access to the source code, they don't know what they run.