Gérer le Loadbalancer HAPROXY (répartiteur de charge) devient très vite fastidieux, surtout par l’automatisation. Il faut trouver le bon parser ou bien le fabriquer, mais tout cela est terminé.
HAPROXY met maintenant à disposition une API REST, qui s’installe à côté de l’application HAPROXY, son nom : HAPROXY - Data Plane API. Toutes les modifications effectuées au travers de l’API, sont reportées dans le fichier de configuration.
Installation
A partir du serveur “Infra” du Datacenter (loadbalancer principal), nous allons installer la version “Community”, (suivre cette instruction) :
- Installation HAPROXY - Data Plane API
- Ajouter la directive “stats socket…” au bloc “global” de la configuration HAPROXY (/etc/haproxy/haproxy.cfg)
- Paramétrer HAPROXY - Data Plane API (/etc/haproxy/dataplaneapi.hcl)
- Ajouter le bloc à la configuration HAPROXY (/etc/haproxy/haproxy.cfg) :
program api
command dataplaneapi -f /etc/haproxy/dataplaneapi.hcl
no option start-on-reload
- Tester l’ensemble avec la commande “curl”
Manipulation de l’API
Pour commencer, il faut récupérer la dernière version de la configuration HAPROXY.
Le Data plane API fonctionne par transaction, comme les bases de données transactionnelles (SGBDR) :
- Begin transaction,
- actions à mener
- puis commit (validation) ou rollback (abandon des opérations effectuées).
Exemples de procédure
Je ne vais pas rentrer dans le détail, mais juste présenter le déroulement d’une opération d’ajout d’acl à un frontend existant.
Ajouter une acl à un frontend
Vous devez connaître le nom du frontend impacté, le nom de la future acl, le domaine concerné par cette acl (domaine internet).
Pour cet exemple, j’utiliserai ces paramètres :
- nom du frontend : “monfrontendinternet”
- nom de l’acl a créer : “website_mytinydc_com”
- domaine concerné : “www.mytinydc.com”
Puis exécuter les appels API dans cet ordre :
- Type :GET - Récupération de la dernière version de configuration HAPROXY, api="/services/haproxy/configuration/version"
- Type: POST - Démarrage et récupération de l’id de transaction (paramètre : version, récupéré ci-avant), api="/services/haproxy/transactions?version=${version}"
- Type: POST - Création de l’acl sur le frontend souhaité (paramètres : nom du frontend, id de transaction, récupéré ci-avant), api="/services/haproxy/configuration/acls/?parent_name=${frontendlocal}&parent_type=frontend&transaction_id=${tr}" avec les données json nécessaires :
{
"acl_name": "website_mytinydc_com",
"criterion": "hdr(host)",
"value": "www.mytinydc.com",
"index": 0
}
- Type : PUT - Commit de l’opération (paramètres : id de transaction), api=“services/haproxy/transactions/${tr}”
Vérifier maintenant le contenu du fichier de configuration “/etc/haproxy/haproxy.cfg”
Spécification de l’API
Vous retrouverez toute la spécification de l’API, ici.
Conclusion
La gestion de HAPROXY est devenu beaucoup plus facile, ce qui va maintenant nous entraîner vers la création d’un opérateur Kubernetes, chargé de mettre à jour automatiquement cette configuration, fonction des événements détectés sur les services (ajout, suppression, modification).
En effet mon loadbalancer principal, n’expose pas exclusivement des services Kubernetes, j’ai donc fait le choix d’exposer les services Kubernetes en “NodePort” et de gérer manuellement la configuration HAPROXY. La procédure est d’ajouter une application dans kubernetes (nextcloud, git, etc…), puis les exposer, en ajoutant un service Kubernetes en mode “NodePort”, et de régler ensuite la configuration HAPROXY. Si je supprime et recrée le service, ceci nécessite de reconfigurer HAPROXY. Créer un opérateur spécialisé, permettra l’automatisation complète de cette gestion au travers de l’API REST “Data plane api”.
Le prochain post…