even more english
This commit is contained in:
parent
9d6050ecd5
commit
6bad78e8fd
59
README.en.md
59
README.en.md
|
|
@ -245,23 +245,30 @@ But it's an example and it's good to know that you can do that manually if you w
|
|||
|
||||
### What about the final servers?
|
||||
|
||||
Si on contrôle les serveurs web finaux et qu'il ssont compatibles, on peut aussi faire la liaison finale avec le PROXY protocol. On sera alors aussi tenté d'ajouter au serveur web un port d'écoute sans PROXY protocol, et bien protégé.
|
||||
If you have control over the final servers and they support the PROXY protocol, you can event do this final connection with the PROXY protocol.
|
||||
You might want to do the same trick and use a custom port for this and keep the regular 80/443 without the PROXY protocol.
|
||||
|
||||
Note: si vous utilisez Apache, je vous recommande d'étudier le module "ForensicLog" qui permet facilement un debug détaillé de tous les en-têtes échangés. C'est très pratique pour débug des chaînes de proxy et voir si tout arrive bien au serveur web final. Je ne sais pas s'il existe quelque chose de similaire pour Nginx.
|
||||
Note: If you use Apache, I encourage you to take a look at the "ForensicLog" module. It adds a special log where you can find a complete trace of each request with all the headers. It is specially useful to see what arrives at the end of the chain. I don't know if something similar exists for Nginx or other web servers.
|
||||
|
||||
```
|
||||
+X@Ike1sspdiNAko5YHK9HAAAAC4|GET /blog/ HTTP/1.1|user-agent:curl/7.64.0|accept:*/*|host:jeremy.lecour.fr|x-forwarded-for:1.2.3.4, 4,5,6,7|accept-encoding:gzip|x-varnish:65545|x-forwarded-port:443|x-forwarded-proto:http|connection:close
|
||||
-X@Ike1sspdiNAko5YHK9HAAAAC4
|
||||
|
||||
```
|
||||
|
||||
## HTTP tagging
|
||||
|
||||
Toujours dans une optique de traçabilité et de facilité de debug, nous nous servons de HAProxy et Varnish pour ajouter dans les en-têtes HTTP des informations sur leur fonctionnement.
|
||||
With the same focus on tracability easy debugging, we are using HAProxy and Varnosh to add some HTTP headers with information about their behaviour.
|
||||
|
||||
Rappelons que la norme HTTP définit des en-têtes normalisés, dont la syntaxe et l'utilisation sont bien codifiés : `Host`, `Set-Cookie`, `Cache-Control`…
|
||||
Mais nous pouvons ajouter n'importe quel en-tête no standard avec un prefix `X-`. Certains sont quasi standards, d'autres sont totalement personnalisés.
|
||||
Let'sremember that the HTTP standard has normalized a list of headers. For example : `Host`, `Set-Cookie`, `Cache-Control`…
|
||||
But it also normalized a way to use custom, non-standard, HTTP headers with an `X-` prefix. Some have almost become standard and are used very frequently.
|
||||
|
||||
### X-Forwarded-*
|
||||
|
||||
Bien que nous utilisions le PROXY protocol en interne (et éventuellement vers certains serveurs finaux), nous conservons généralement l'en-tête HTTP `X-Forwarded-For`.
|
||||
Even though we use the PROXY protocol internally (and possibly to the final servers) we usually keep the commonmy used `X-Forwarded-For` HTTP header.
|
||||
|
||||
Nous ajoutons aussi `X-Forwarded-Port` pour indiquer à quel port de HAProxy le client s'est adressé.
|
||||
Et enfin nous ajoutons `X-Forwarded-Proto` pour indiquer si la connexion initiale était chiffrée ou pas.
|
||||
We also use the `X-Forwarded-Port` header to tell on which port of HAProxy the request arrived to.
|
||||
Anf finally, we use the `X-Forwarded-Proto` header toindicate if the original request was on a secure connecion or not.
|
||||
|
||||
```
|
||||
frontend external
|
||||
|
|
@ -276,11 +283,11 @@ frontend external
|
|||
http-request set-header X-Forwarded-Proto https if { ssl_fc }
|
||||
```
|
||||
|
||||
Ce dernier en-tête est souvent imortant lorsque la requête finale est utilisée par des framework qui impose un accès en https te ne peuvent pas s'appuyer sur le fait que la requête leur arrive au final en https.
|
||||
That last header is important when the request goes to an application that enforces HTTPS. If it receives a request from HAProxy on a clear-text HTTP connection, it ight trigger a redirect. But many framework detect the `X-Forwarded-Proto https` header and understand the external part of the request was encrypted.
|
||||
|
||||
### X-Unique-ID
|
||||
|
||||
Il est très utile de marquer une requête entrante d'un identifiant unique qui pourra être transmis d'étape en étape jusqu'au serveur final (et pourquoi pas au retour aussi).
|
||||
It is very useful to mark an incomming request with a unique identifier that can be transmitted from proxy to proxy, un tile the final server. It even canbe sent back by the application and be tracable all the way back to the original client.
|
||||
|
||||
```
|
||||
frontend external
|
||||
|
|
@ -288,17 +295,19 @@ frontend external
|
|||
http-request set-header X-Unique-ID %[uuid()] unless { hdr(X-Unique-ID) -m found }
|
||||
```
|
||||
|
||||
Il n'y a pas de réel consensus sur le nommage de l'en-tête. On trouve souvent `X-Unique-ID` ou `X-Request-ID`.
|
||||
There is no real consensus on the name of the header. You will commonly find `X-Unique-ID` or `X-Request-ID`.
|
||||
|
||||
### X-Boost-*
|
||||
|
||||
Boost est le nom que nous avons donné à notre système basé sur HAProxy et Varnish.
|
||||
Nous ajoutons donc plusieurs en-têtes `X-Boost-*` pour ajouter des informations utiles.
|
||||
"Boost" is the name we've given to our HAProxy and Varnish setup.
|
||||
Hence the name `X-Boost-*` of a few custom HTTP headers that we add to the request and the response
|
||||
|
||||
Sur le frontend « external » nous marquons la requête comme étant passée en étape 1 par « haproxy-external ». Les autres étapes de la requête sauront alors que la requête est entrée par là.
|
||||
On the "external" frontend, we add one to tell that the request passed this step.
|
||||
This is usefull for the final server to know which steps the request passed.
|
||||
|
||||
Lorsque réponse resortira de ce backend pour aller au client, on la marque aussi pour indiquer que l'étape 1 était « haproxy-external » en précisant si la connexion était en http ou https.
|
||||
On indique aussi le nom du serveur Boost qui a traité la requête.
|
||||
When the response exists to the original client, we also add the same header to inform the client of the same steps.
|
||||
|
||||
We also inform the client of the name of the Boost instance that processed the request.
|
||||
|
||||
```
|
||||
frontend external
|
||||
|
|
@ -310,7 +319,7 @@ frontend external
|
|||
http-response set-header X-Boost-Server my-hostname
|
||||
```
|
||||
|
||||
Au niveau du frontend « internal » on applique le même principe, mais en indiquant que c'est pour l'étape 3.
|
||||
On the "internal" frontend, we apply the same principle, but this time it's "step 3" instead of "step 1" :
|
||||
|
||||
```
|
||||
frontend internal
|
||||
|
|
@ -321,8 +330,7 @@ frontend internal
|
|||
http-response add-header X-Boost-Step3 "haproxy-internal; no SSL to backend" if !{ ssl_bc }
|
||||
```
|
||||
|
||||
Dans le backend final du site, on marque la réponse pour indiquer si la connexion avec le serveur final s'est faite en http ou https.
|
||||
|
||||
In the final backend, we add a header to indicate if HAProxy used an encrypted connection or not.
|
||||
```
|
||||
backend example_com
|
||||
[…]
|
||||
|
|
@ -331,16 +339,15 @@ backend example_com
|
|||
server example-hostname 1.2.3.4:443 check observe layer4 ssl verify none
|
||||
```
|
||||
|
||||
Au niveau de Varnish, nous marquons la requête transmise pour indiquer qu'elle est passée par Varnish :
|
||||
In Varnish (the "step 2"), we tag the request to tell the final server that Varnish has seen it.
|
||||
|
||||
```
|
||||
sub vcl_recv {
|
||||
[…]
|
||||
set req.http.X-Boost-Layer = "varnish";
|
||||
set req.http.X-Boost-Step2 = "varnish";
|
||||
}
|
||||
```
|
||||
|
||||
Lorsque la réponse est renvoyée, elle est marquée sur l'étape 2 de détails à propos des modalités de cache
|
||||
And when the response is sent back, we tell in a header if the server has set cache-control or some cookies.
|
||||
|
||||
```
|
||||
sub vcl_deliver {
|
||||
|
|
@ -356,9 +363,9 @@ sub vcl_deliver {
|
|||
}
|
||||
```
|
||||
|
||||
Par ailleurs, Varnish ajoute par défaut de nombreux en-têtes sur l'utilisation ou non du cache, l'âge de la ressource…
|
||||
By default, Varnish also adds many HTTP headers with information about the cache : hit or miss, age of the object……
|
||||
|
||||
Note: La syntaxe de ces en-têtes `X-Boost-*` est encore expérimentale. Nous prévoyons de les rendre plus compacts et faciles à traiter automatiquement.
|
||||
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.
|
||||
|
||||
### Log HAProxy complet
|
||||
|
||||
|
|
@ -388,7 +395,7 @@ Pour éviter que HAProxy + Varnish ne soient un « Single Point Of Failure », n
|
|||
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.
|
||||
|
||||
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 encor eplus loin et faire du « actif-actif » avec 2 HAProxy en « layer 4 » qui renvoient ensuite sur 2 HAproxy en « layer 7 »
|
||||
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.
|
||||
|
||||
## Fonctionnalités complémentaires
|
||||
|
|
|
|||
Loading…
Reference in a new issue