(**) Translated with www.DeepL.com/Translator
Managing the HAPROXY load balancer becomes very tedious very quickly, especially with automation. You have to find the right parser or build it, but that’s all over now.
HAPROXY now provides a REST API, which is installed next to the HAPROXY application, its name : HAPROXY - Data Plane API. All changes made through the API are reported in the configuration file.
Installation
From the Datacenter “Infra” server (main loadbalancer), we will install the “Community” version, (follow this instruction) :
- HAPROXY Installation - Data Plane API
- Add the “stats socket…” directive to the “global” block of the HAPROXY configuration (/etc/haproxy/haproxy.cfg)
- Set up HAPROXY - Data Plane API (/etc/haproxy/dataplaneapi.hcl)
- Add the block to the HAPROXY configuration (/etc/haproxy/haproxy.cfg) :
program api
command dataplaneapi -f /etc/haproxy/dataplaneapi.hcl
no option start-on-reload
- Test the set with the “curl” command
Handling the API
To begin with, you need to get the latest version of the HAPROXY configuration.
The Data plane API works by transaction, like transactional databases (RDBMS):
- Begin transaction,
- actions to carry out
- then commit (validation) or rollback (cancellation of the operations performed).
Examples of procedures
I will not go into detail, but just present the process of adding an acl to an existing frontend.
Adding an acl to a frontend
You need to know the name of the impacted frontend, the name of the future acl, the domain concerned by this acl (internet domain).
For this example, I will use these parameters:
- name of the frontend: “myinternetfrontend
- name of the acl to create: “website_mytinydc_com
- concerned domain: “www.mytinydc.com”
Then execute the API calls in this order:
- Type :GET - Retrieving the latest version of the HAPROXY configuration, api="/services/haproxy/configuration/version”
- Type: POST - Start and retrieve transaction id (parameter: version, retrieved above), api="/services/haproxy/transactions?version=${version}”
- Type: POST - Creation of the acl on the desired frontend (parameters: frontend name, transaction id, retrieved above), api="/services/haproxy/configuration/acls/?parent_name=${frontendlocal}&parent_type=frontend&transaction_id=${tr}" with the necessary json data :
{
"acl_name": "website_mytinydc_com",
"criterion": "hdr(host)",
"value": "www.mytinydc.com",
"index": 0
}
- Type : PUT - Commit of the transaction (parameters: transaction id), api=“services/haproxy/transactions/${tr}”
Now check the contents of the configuration file “/etc/haproxy/haproxy.cfg”
API specification
You will find all the API specification, here.
Conclusion
The management of HAPROXY has become much easier, which will now lead us to the creation of a Kubernetes operator, responsible for automatically updating this configuration, depending on the events detected on the services (addition, deletion, modification).
Indeed my main loadbalancer, does not expose exclusively Kubernetes services, so I made the choice to expose Kubernetes services in “NodePort” and to manage manually the HAPROXY configuration. The procedure is to add an application in kubernetes (nextcloud, git, etc…), then expose them, adding a Kubernetes service in “NodePort” mode, and then set the HAPROXY configuration. If I remove and recreate the service, this requires reconfiguring HAPROXY. Creating a specialized operator, will allow the complete automation of this management through the REST API “Data plane api”.
The next post…