« HAProxy » : différence entre les versions

De Justine's wiki
Aller à la navigation Aller à la recherche
(Page créée avec « = Présentation, installation, configuration de base = [https://www.haproxy.com/fr/blog/haproxy-configuration-basics-load-balance-your-servers/ Doc] HAProxy est un load b… »)
 
Aucun résumé des modifications
Ligne 149 : Ligne 149 :
use_backend bookstack if is_bookstack
use_backend bookstack if is_bookstack
</source>
</source>
= Configuration avancée =
== Configuration pour SSL ==
Mon but va désormais être de faire du SSL offloading : mes serveurs web continuent à servir le port 80, mais les clients arrivent sur HAProxy qui répond en SSL avec des certificats gérés par certbot.

Version du 26 septembre 2021 à 10:36

Présentation, installation, configuration de base

Doc

HAProxy est un load balancer très puissant et économe.

Je vais ici l'installer sur une machine seule, et il fera le relai vers mes différents sites.

L'installation sur Debian 11 se fait via les dépôts: <source> apt install haproxy </source>

Configurer l'IP et le port : définir un frontend

Nous allons définir l'adresse et le port sur lesquels HAProxy va attendre son traffic. Cela passe par la création d'un frontend : un frontend est l'élement qui reçoit le traffic. Toute la configuration se fait de base dans /etc/haproxy.cfg. Nous allons donc y créer un frontend en y ajoutant les lignes suivantes : <source> frontend fronthttp bind *:80 </source> Je nomme mon frontend qui recevra du trafic http; le bind se fait sur * car les requêtes qu'il recevra viendront de l'extérieur. Je pourrais le bind sur 127.0.0.1, mais à ce moment-là il n'écouterait que depuis son propre serveur.

On pourrait configurer bind de plusieurs façons:

  • bind 0.0.0.0:80 : similaire à étoile
  • bind :80 : pareil
  • bind :80,81 Ecouter sur les ports 80 et 81. Ne pas mettre d'espace entre les deux.
  • bind :5555-5600 Ecouter sur tous les ports entre 5555 et 5600

Sur ma version Debian 11, le fichier de base est assez chargé: <source> global log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners stats timeout 30s user haproxy group haproxy daemon

# Default SSL material locations ca-base /etc/ssl/certs crt-base /etc/ssl/private

# See: https://ssl-config.mozilla.org/#server=haproxy&server-version=2.0.3&config=intermediate 

       ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
       ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
       ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets

defaults log global mode http option httplog option dontlognull 

       timeout connect 5000
       timeout client  50000
       timeout server  50000

errorfile 400 /etc/haproxy/errors/400.http errorfile 403 /etc/haproxy/errors/403.http errorfile 408 /etc/haproxy/errors/408.http errorfile 500 /etc/haproxy/errors/500.http errorfile 502 /etc/haproxy/errors/502.http errorfile 503 /etc/haproxy/errors/503.http errorfile 504 /etc/haproxy/errors/504.http </source> Je ne vais pas passer toute la conf en revue, mais certains éléments de defaults sont intéressants :

  • timeout connect correspond au timeout de connexion aux backends
  • timeout client correspond au timeout de connexion aux clients
  • timeout server correspond au temps d'attente pour que le backend envoie ses données
  • Le mode http signifie que l'on va travailler en http, mais HAProxy peut aussi fonctionner en mode tcp et balancer beaucoup d'autres protocoles. En mode http, HAProxy peut inspecter les headers, les métadonnées, etc.

Je restart et essaye. <source> root@lb:/etc/haproxy# systemctl restart haproxy root@lb:/etc/haproxy# curl http://localhost

<html><body>

503 Service Unavailable

No server is available to handle this request. </body></html> </source> Ça marche ! On a pas encore de backends.

Vérifier ma config

Je peux vérifier ma config avec la commande suivante: <source lang="bash"> haproxy -c -V -f /etc/haproxy/haproxy.cfg

root@lb:/etc/haproxy# haproxy -c -V -f haproxy.cfg Configuration file is valid </source>

Savoir à qui parler : définir un frontend

Avec HAProxy, on a un frontend qui reçoit le traffic; ce traffic est ensuite dispatché vers un backend, soit un pool de serveurs webs / applicatifs qui sauront répondre. Ici, je vais pour ma part ajouter un backend qui correspondra à mon wiki.

Je modifie mon frontend et ajoute un backend dans ma configuration (puis reload d'HAProxy) : <source> backend wiki server wiki1 10.0.0.112:80 </source>

En me rendant sur http://mon-serveur-haproxy, je suis bien redirigée vers mon wiki. Je n'ai qu'un serveur dans mon backend, mais je pourrais en avoir plusieurs et HAproxy ferait le relai de façon cyclique: <source> backend myservers 

 server server1 127.0.0.1:8000
 server server2 127.0.0.1:8001
 server server3 127.0.0.1:8002

</source>

Créer des ACLs (de base)

Documentation sur les ACLs Syntaxe des ACLs

Nous avons un backend, mais il serait plus intéressant d'en avoir plusieurs et de demander à HAProxy de faire le tri en fonction de ce que je lui demande. Pour cela, nous allons créer des règles (appellées ACL). Une façon simple de faire est de définir comme suit : <source> frontend fronthttp bind *:80 use_backend wiki if { hdr(host) -i wiki.ju.lab } use_backend bookstack if { hdr(host) -i bookstack.ju.lab }

backend wiki server wiki1 10.0.0.112:80

backend bookstack server bookstack1 10.0.0.105:80 </source> Ainsi, en fonction de ce que je lui demande, le traffic est redirigé au bon endroit.

Mais je peux également définir une acl en tant que telle, soit une règle complexe à laquelle je pourrais donner un nom. Cette règle représente un contrôle d'accès et permettra de pouvoir vérifier si cela s'applique à une demande et d'effectuer une action si c'est le cas. L'intérêt de pouvoir utiliser une acl plusieurs fois par exemple. Un exemple d'acl simple: <source> acl is_wiki hdr(host) -i wiki.ju.lab wiki.ns2.tld2 </source>

  • acl est le mot-clef pour dire que l'on créée une acl.
  • is_wiki est le nom de mon acl
  • hdr(host) correspond à un contrôle sur l'hôte demandé
  • -i est un flag, soit le comparateur d'égalité (is)
  • ensuite, je peux donner plusieurs noms d'hôte qui déclencheront l'acl.

L'ACL se base sur le header HTTP Host.

Les ACLs permettent de faire beaucoup de choses. Se réferer à la doc, je ferais aussi plus d'exemples ici quand j'aurais poussé un peu mon utilisation d'HAProxy.

En attendant, je vais reprendre mon fichier de configuration et appliquer des ACLs pour rediriger correctement mon traffic. Mon frontend: <source> frontend fronthttp bind *:80

acl is_wiki hdr(host) -i wiki.ju.lab acl is_bookstack hdr(host) -i bookstack.ju.lab

use_backend wiki if is_wiki use_backend bookstack if is_bookstack </source>

Configuration avancée

Configuration pour SSL

Mon but va désormais être de faire du SSL offloading : mes serveurs web continuent à servir le port 80, mais les clients arrivent sur HAProxy qui répond en SSL avec des certificats gérés par certbot.

Récupérée de « https://wiki.squi.fr/index.php?title=HAProxy&oldid=1729 »