If you host dozens of web services that reside at various subdomains, TCP ports, and paths, then migrating them to live under a single address could simplify how clients access them and make your job of managing access easier. It would mean moving from a hodgepodge of address schemes, such as: to a single address wherein services are designated by the URL’s path: The good news is that you don’t need to rearrange your entire network to make this happen.
An application programming interface (API) provides access to the features of a business application, but with the visual elements stripped away. By using APIs, devices like tablets, self-service kiosks, point-of-sale terminals, and robotic sensors can connect up to apps running on servers in a datacenter or in the cloud. Because they give access to the heart of your business applications, it should come as no surprise that there are some APIs that the general public should not have access to.
Developing a strategy for collecting application-level logs necessitates stepping back and looking at the big picture. Engineers developing the applications may only see logging at its ground level: the code that writes the event to the log—for example a function that captures Warning: An interesting event has occurred! But where does that message go from there? What path does it travel to get to its destination?
With HAProxy situated in front of their servers, many people leverage it as a frontline component for enabling extra security and observability for their networks. HAProxy provides a way to monitor the number of TCP connections, the rate of HTTP requests, the number of application errors and the like, which you can use to detect anomalous behavior, enforce rate limits, and catch application-related problems early.
In HAProxy Data Plane API version 2.6, we continued the effort of expanding support for HAProxy configuration keywords, as this has been the priority with this release cycle, and it will be in the next one too to meet our goal of achieving complete feature parity with both the HAProxy configuration and Runtime API. This will enable you to use HAProxy Data Plane API for configuring HAProxy without any gaps in functionality.
HAProxy Kubernetes Ingress Controller provides custom resources named Backend, Defaults, and Global that let you manage ingress controller settings more efficiently. To start using them right away, check the documentation for steps and examples. In this blog post, you’ll learn why custom resources are such a powerful feature and see tips for getting the most out of them.
We’re proud to announce the release of version 1.8 of the HAProxy Kubernetes Ingress Controller! In this release, we added support for full rootless mode, Prometheus metrics for the controller itself, and examples that are synchronized with our Helm chart. In this blog post, you will learn more about the changes in this version. Register for our webinar to learn more about this release.
HAProxy 2.6 is now available! As always, the community behind HAProxy made it possible to bring the enhancements in this release. Whether developing new functionality, fixing issues, writing documentation, QA testing, hosting CI environments, or submitting bug reports, members of our community continue to drive the project forward. If you’d like to join the effort, you can find us on GitHub, Slack, Discourse, and the HAProxy mailing list.
