english is done (but not proof-read)
This commit is contained in:
parent
84ca34d4f8
commit
ead4695de0
74
README.en.md
74
README.en.md
|
|
@ -365,11 +365,11 @@ sub vcl_deliver {
|
|||
|
||||
By default, Varnish also adds many HTTP headers with information about the cache : hit or miss, age of the object……
|
||||
|
||||
Note: The syntax of our `X-Boost-*` custom headers is still experimental. Nous plan to change them to be more terse and easier to parse.
|
||||
Note: The syntax of our `X-Boost-*` custom headers is still experimental. We plan to change them to be more terse and easier to parse.
|
||||
|
||||
### Log HAProxy complet
|
||||
### Full HAProxy log
|
||||
|
||||
Dans des situations avancées de debug, nous pouvons aussi activer l'ajout dans un en-tête HTTP de la totalité de la ligne de log :
|
||||
In advanced debugging situation, we can also enable a custome header with the full HAProxy log line:
|
||||
|
||||
```
|
||||
frontend external
|
||||
|
|
@ -379,31 +379,31 @@ frontend internal
|
|||
http-response add-header X-Haproxy-Log-Internal "%ci:%cp [%tr] %ft %b/%s %TR/%Tw/%Tc/%Tr/%Ta %ST %B %CC %CS %tsc %ac/%fc/%bc/%sc/%rc %sq/%bq %hr %hs %{+Q}r"
|
||||
```
|
||||
|
||||
:warning: Il vaut mieux ne pas activer cela en production, mais ça peut être très utile pour permettre à un client en mode test/préprod de vérifier comment se comporte le proxy.
|
||||
:warning: It's probably not a good idea to do that in production, but it can be very useful to see on the client side exactly what happened inside HAproxy.
|
||||
|
||||
## Haute disponibilité
|
||||
## High-availability
|
||||
|
||||
### Côté applicatif
|
||||
### For the application
|
||||
|
||||
Lorsque le site ou l'application web finale dispose de plusieurs serveurs pour gérer les requêtes, on peut prendre en charge directement dans HAProxy la répartition de charge.
|
||||
Lorsque c'est possible, on fait de préférence un `round-robin` sur les serveurs web.
|
||||
Lorsque l'application gère mal les sessions ou des aspects bloquants, on met un serveur en actif et les autres en backup, pour basculer sur un secours si le primaire n'est plus disponible.
|
||||
When a web site or web application relies on multiple webservers to handle the requests, we can use HAProxy to do the load-balancing.
|
||||
When possible, we prefer using the `round-robin` algorithm. It's the simplest.
|
||||
But when the application has trouble with persisted data like sessions or stored files, we can set an active-backup configuration. HAproxy passes all the requests to the same server until it's failing then moves to the next one.
|
||||
|
||||
### Côté HAProxy
|
||||
### For HAProxy itself
|
||||
|
||||
Pour éviter que HAProxy + Varnish ne soient un « Single Point Of Failure », nous avons mis en place 2 serveurs différents dans 2 réseaux différents et nous faisons un round-robin DNS en amont.
|
||||
Cette approche n'est pas la plus avancée, car en cas de panne d'un serveur il faut intervenir au niveau DNS. Cependant elle a le mérite de la simplicité et les pannes complète de machines virtuelles tournant sur de la virtualisation redondante sont heureusement très rares. En revanche, ce système nous permet pas mal de souplesse.
|
||||
To prevent our HAProxy+Varnish server from turning into a "Single Point of Failure", we have installed two of them, in two different networks and datacenters, and we use a round-robin DNS.
|
||||
If a server is not available, we need to change the DNS zone to disable the faulty server. It takes time to detect,change and propagate. But we use virtual servers on redundant hardware. Over the last several years, this has proven to be very reliable. And it is also very easy to change and adapt.
|
||||
|
||||
Il serait aussi possible de faire du « actif-passif » en mettant une IP flottante (keepalived/vrrp) en amont de deux serveurs, pour avoir une bascule automatique sur le secondaire en cas de panne du primaire.
|
||||
On aller encore plus loin et faire du « actif-actif » avec 2 HAProxy en « layer 4 » qui renvoient ensuite sur 2 HAproxy en « layer 7 »
|
||||
Ces approches permettent une reprise d'activité quasi immédiate en cas de panne, mais elles impliquent plus de ressources et une topologie réseau particulière.
|
||||
It would definitely be possible to have an "active-standby" setup, with a virtual IP (with keepalived/vrrp), and have an automatic failover if the main server fails.
|
||||
or we could go even further with an "active-active" setup with 2 "layer 4" HAProxy servers, then 2 or more "layer 7" Haproxy servers.
|
||||
Those options (and some more that I ddn't cover) allow for a much faster recovery in case of an incident, but they are much more complex.
|
||||
You have to decide for yourself.
|
||||
|
||||
## Fonctionnalités complémentaires
|
||||
## Additional features
|
||||
|
||||
### TCP filtering
|
||||
|
||||
### Filtrage TCP
|
||||
|
||||
Dans le frontend « external » qui gère le trafic entrant, nous pouvons vérifier si le client doit être immédiatement rejeté, par exemple selon son adresse IP :
|
||||
The "external" frontend handles incoming requests. We can verify if the client must be rejected, by it's client IP for example:
|
||||
|
||||
```
|
||||
frontend external
|
||||
|
|
@ -412,13 +412,13 @@ frontend external
|
|||
tcp-request connection reject if { src -f /etc/haproxy/deny_ips }
|
||||
```
|
||||
|
||||
Cela ne remplace pas un vrai firewall, mais ça permet de facilement exclure des client au niveau TCP (couche 4).
|
||||
This is not a replacement for a traditional firewall, but it's much more powefull since any ACL can be used.
|
||||
|
||||
### Filtrage HTTP
|
||||
### HTTP filtering
|
||||
|
||||
En analysant la requête au niveau HTTP (couche 7), on peut filtrer de manière beaucoup plus fine.
|
||||
Since HAProxy has access to every aspect of the request on the "layer 4", we can also filter on a much finer level.
|
||||
|
||||
Par exemple, si un site est passé en mode maintenance (détaillé plus loin), on peut contourner ce mode maintenance pour une liste d'IP particulière qui pourra tout de même consulter le site et vérifier par exemple l'état des opérationsde maintenance.
|
||||
For example, if a website is in maintenance mode (detailed further), we can bypass this for a list of IP addresses. Very useful to check on your deployment before opening to the general public.
|
||||
|
||||
```
|
||||
frontend external
|
||||
|
|
@ -435,19 +435,19 @@ backend maintenance
|
|||
# With no server defined, a 503 is returned for every request
|
||||
```
|
||||
|
||||
Pour les outils locaux de monitoring (exemple: Munin) ou pour les challenges ACME, il peut être utile de renvoyer sur un serveur web local (exemple: Apache ou Nginx), au lieu de renvoyer sur Varnish ou les serveurs web appliatifs.
|
||||
For some local monitoring tools (like Munin) or for ACME challenges, it is usefull to directly proxy the requests to a local web-server (like Apache or Nginx), instead or going through Varnish or other servers.
|
||||
|
||||
```
|
||||
frontend external
|
||||
[…]
|
||||
# Is the request coming for the server itself (stats…)
|
||||
acl server_hostname hdr(host) -i my-hostname
|
||||
acl munin hdr(host) -i munin
|
||||
acl self hdr(host) -i my-hostname my-hostname.domain.tld
|
||||
acl munin hdr(host) -i munin
|
||||
|
||||
# Detect Let's Encrypt challenge requests
|
||||
acl letsencrypt path_dir -i /.well-known/acme-challenge
|
||||
|
||||
use_backend local if server_hostname
|
||||
use_backend local if self
|
||||
use_backend local if munin
|
||||
|
||||
use_backend letsencrypt if letsencrypt
|
||||
|
|
@ -463,13 +463,11 @@ backend local
|
|||
server localhost 127.0.0.1:81 send-proxy-v2 maxconn 10
|
||||
```
|
||||
|
||||
### Mode maintenance
|
||||
### Maintenance mode
|
||||
|
||||
Le mode maintenance est une sorte de coupe-circuit qui permet de basculer toute l'installation, ou juste un site web en mode maintenance.
|
||||
The "maintenance mode" is some kind of circuit-breaker that you can use to divert all the requests or only per site.
|
||||
|
||||
Pour la coupure globale, on utilise un backend spécial qui ne définit pas de serveur web final et provoquera toujours une erreur 503.
|
||||
On peut aussi définir une page d'erreur particulière pour cette situation.
|
||||
Nous avons fait le choix de ne pas logguer les requêtes lorsque ce mode et activé.
|
||||
For a global "maintenance mode", we use a special backend that doesn't specify any server, which will trigger 503 errors. If we have defined a custom error page for this backend, it will be displayed
|
||||
|
||||
```
|
||||
frontend external
|
||||
|
|
@ -486,7 +484,7 @@ backend maintenance
|
|||
# With no server defined, a 503 is returned for every request
|
||||
```
|
||||
|
||||
Pour une coupure par site, il faut définir un backend spécial pour ce site et activer l'utilisation de ce backend pour les requêtes. On retrouve notre ACL par domaine.
|
||||
For a "maintenance mode" per site, we also need a custom backend with the same principle as before, and we need to use the domain ACL to restict to this site only.
|
||||
|
||||
```
|
||||
frontend external
|
||||
|
|
@ -499,12 +497,12 @@ frontend external
|
|||
use_backend example_com_maintenance if example_com_domains !example_com_maintenance_ips !maintenance_ips
|
||||
```
|
||||
|
||||
### Personnalisation par site
|
||||
### Per site customization
|
||||
|
||||
On peut définir des ACL pour chaque site et ainsi provoquer des comportements lorsqu'une requête est destinée à ce site.
|
||||
We can use many ACL for each site or application to trigger custom behaviour when a request arrives for this site.
|
||||
|
||||
Par exemple, les redirections http vers https, ou pour des sous-domaines, les en-têtes HSTS
|
||||
A typical exemple is http-to-https redirects, subdomains redirects or HSTS headers.
|
||||
|
||||
## Configuration complète
|
||||
## Complete configuration rundown
|
||||
|
||||
Parcourons la configuration complète de HAProxy puis Varnish, pour commenter petit à petit tout ce qu'on a vu jusque là.
|
||||
Let's go through the whole configuration to see the whole picture and comment what we've seen so far.
|
||||
|
|
@ -116,8 +116,8 @@ frontend external
|
|||
errorfiles boost-default-errors
|
||||
|
||||
# Is the request coming for the server itself (stats…)
|
||||
acl server_hostname hdr(host) -i my-hostname
|
||||
acl munin hdr(host) -i munin
|
||||
acl self hdr(host) -i my-hostname my-hostname.domain.tld
|
||||
acl munin hdr(host) -i munin
|
||||
|
||||
# List of IP that will not go the maintenance backend
|
||||
acl maintenance_ips src -f /etc/haproxy/maintenance_ips
|
||||
|
|
@ -153,14 +153,14 @@ frontend external
|
|||
# Global maintenance mode (### -> uncomment)
|
||||
### use_backend maintenance unless maintenance_ips
|
||||
|
||||
use_backend local if server_hostname
|
||||
use_backend local if munin
|
||||
use_backend local if self
|
||||
use_backend local if munin
|
||||
|
||||
# "letsencrypt" must stay after "local"
|
||||
use_backend letsencrypt if letsencrypt
|
||||
|
||||
# BEGIN frontend_external section for site 'example'
|
||||
acl example_com_domains hdr(host) -i example.com
|
||||
acl example_com_domains hdr(host) -i example.com
|
||||
acl example_com_domains2 hdr(host) -i example.org www.example.org
|
||||
|
||||
# Redirect to HTTPS without Let's Encrypt certificate
|
||||
|
|
@ -236,6 +236,7 @@ frontend internal
|
|||
|
||||
backend varnish
|
||||
option httpchk HEAD /varnishcheck
|
||||
|
||||
server varnish_sock /run/varnish.sock check observe layer7 maxconn 3000 inter 1s send-proxy-v2
|
||||
|
||||
# BEGIN backend section for site 'example'
|
||||
|
|
@ -243,6 +244,7 @@ backend example_com
|
|||
errorfile 503 /etc/haproxy/sites/example/maintenance.http
|
||||
http-response set-header X-Boost-Proto https if { ssl_bc }
|
||||
http-response set-header X-Boost-Proto http if !{ ssl_bc }
|
||||
|
||||
server example-hostname 1.2.3.4:443 check observe layer4 ssl verify none
|
||||
|
||||
backend example_com_maintenance
|
||||
|
|
@ -260,6 +262,7 @@ backend letsencrypt
|
|||
|
||||
backend local
|
||||
option httpchk HEAD /haproxy-check
|
||||
|
||||
server localhost 127.0.0.1:81 send-proxy-v2 maxconn 10
|
||||
|
||||
backend maintenance
|
||||
|
|
|
|||
Loading…
Reference in a new issue