It would be great if you can explain the type of difficulties you've met. There are probably certain points that could easily be improved to satisfy users with your needs.
In 2.0 we've set a number of things by default to work better and use all the capacity with no need for tweaking. Just doing this will start a proxy on all CPU cores, support both H1 and H2 and will automatically enable round robin load-balancing, tune the maxconns, something which used to be a hassle in previous versions, and enable connection pooling and reuse by default:
listen foo
bind :80
mode http
server www1 192.168.1.1:80
server www2 192.168.1.2:80
server www3 192.168.1.3:80
Same here. We wanted to use haproxy from day zero because it could inject proxy protocol headers.
However, haproxy actively fights being compared to nginx.
There's no 101 guide to setup haproxy as a reverse proxy for nodejs application with separate domain names, ssl certificate configuration (I don't even know how to create the correct chain for haproxy after buying it from a commercial vendor), good security defaults (CORS/CORB) and docker defaults.
As of RIGHT NOW, haproxy has not updated it's official docker image and has 6 day old docker images which docker hub flags as having vulnerabilities (screenshot at https://imgur.com/a/SiYoZzc). So I'm a little hesitant at calling this release "Cloud Native"
Latest nginx docker image is not flagged for any vulnerabilities.
> As of RIGHT NOW, haproxy has not updated it's official docker image and has 6 day old docker images which docker hub flags as having vulnerabilities (screenshot at https://imgur.com/a/SiYoZzc). So I'm a little hesitant at calling this release "Cloud Native"
3. There's a pull request created by me to switch from 2.0-rc to 2.0: https://github.com/docker-library/haproxy/pull/89. I created it immediately after learning about the release. Any further delay is caused by the Docker Official Images team.
Disclosure: I'm a community contributor to HAProxy and I help maintain the issue tracker on GitHub. I also maintain a few “official” Docker images and by that I know the process.
in which case is there your own registry where you maintain docker images ?
I'm not trying to be an ass. I've been looking forward to haproxy to be more docker/k8s/cloud friendly. This release claims so, but how do I deploy to k8s now ?
should everyone be compiling their own images ? If haproxy is not able to support official docker images, then we are back in "let's just use nginx. they atleast have official images"
and in replying to the comment that this thread belongs to ...this is one of the "difficulties"
The "official" HAProxy docker builds are strictly controlled by the Docker team. For builds created directly by HAProxy Technologies you can find them here: https://hub.docker.com/u/haproxytech
> in which case is there your own registry where you maintain docker images ?
Please note that I'm a community contributor. I am not employed by HAProxy Technologies and I cannot speak for the open source project in any official capacity either.
It’s been awhile since I’ve used HAProxy (changed roles, loved the product). But are there drawbacks running on all cores? I seem to remember sticky routing and acls not working properly as each core had its own set. Has that changed?
In 2.0 we've set a number of things by default to work better and use all the capacity with no need for tweaking. Just doing this will start a proxy on all CPU cores, support both H1 and H2 and will automatically enable round robin load-balancing, tune the maxconns, something which used to be a hassle in previous versions, and enable connection pooling and reuse by default:
It's hard to do much simpler, even with nginx.