more english translation
This commit is contained in:
parent
32d493f2f3
commit
75d86e62c2
82
README.en.md
82
README.en.md
|
|
@ -29,51 +29,55 @@ That's where we begin to mention load-balancing. And when we introduce som logic
|
|||
|
||||
### Varnish
|
||||
|
||||
Varnish va servir à mettre en cache le résultat de certaines requêtes pour ne pas avoir à solliciter le serveur applicatif final. Il va appliquer des règles plus ou moins complexes pour décider s'il met en cache,s'il sert depuis le cache…
|
||||
|
||||
Varnish propose par défaut un fonctionnement courant et relativement conventionnel qui nécessite généralement peu de configuration. Il y a des bonnes pratiques qui s'appliquent bien à la plupart des situations.
|
||||
Les étapes clés du traitement d’une requête-réponse HTTP sont gérées par des fonctions dédiées, qu’il est possible de personnaliser et d'empiler/composer pour modifier le comportement.
|
||||
Varnish is going to store in cache the result of some requests. Later on, a client who makes the same request might get a result from the cache if it is preset andfresh enough.
|
||||
|
||||
Varnish expose toute la requête et la réponse aux fonctions afin de décider s’il faut modifier le contenu (ajouter/supprimer/modifier des en-têtes), servir une réponse depuis le cache ou la transmettre au serveur, mettre en cache ou pas la réponse d’un serveur…
|
||||
With its default configuration, Varnish has a lot of good practice already in place and jst a few adjustments might be necessary to work with most of the situations.
|
||||
Every step of the request/response processing is done by functions that can be customized by something that looks a bit like inheritance in programming. At startup, everything is validated and compiled into optimized code.
|
||||
|
||||
Varnish stockant toutes les données de cache en mémoire, il est aussi important de décider selon quel algorithme décider ce qui doit être détruit lorsque la capacité maximale est atteinte…
|
||||
Like HAProxy, Varnish parses the whole request/response inside the functions, so we can decide if the request/response needs to be modified (like adding or removeing headers), if a response can be served from the cache, if it need to talk to the final server, and if the responsae can be stored in cache for future use.
|
||||
|
||||
Varnish stores the content, its objects, into memory to be really fast. if you have a lot of trafic, give it enough RAM to keep a lot of content available.
|
||||
|
||||
## Comment combiner HAProxy et Varnish
|
||||
|
||||
Nous avons donc choisir de mettre ces 2 logiciels ensemble, de manière coordonnée, pour un résultat performant et riche en fonctionnalités.
|
||||
So we have decided to have them work together, in a coordinated way, for an efficient and feature-rich setup.
|
||||
|
||||
Comme dit précédemment, HAProxy utilise des _frontend_ comme point d'entrée et des backends commepoint de sortie.
|
||||
Has we've seen earlier, HAProxy uses frontends as entry-points and backend asexit-points.
|
||||
|
||||
Dans notre cas, après avoir pris en charge la requête du client HTTP, HAProxy va la transmettre à Varnish, via un backend spécifique.
|
||||
Nous avons choisi de placer HAProxy et Varnish sur le même serveur, et de les faire communiquer par socket, mais c'est un détail et rien n'empêche de les mettre sur des serveurs différents.
|
||||
In our case, after accepting the request from the HTTP client, HAProxy will pass it to Varnish, via a dedicated backend.
|
||||
We have chosen to place HAProxy and Varnish on the server server, and connect them with unix sockets, but it's an implementation detail andwe could have placed them on separate servers, communicating through regular TCP sockets.
|
||||
|
||||
Une fois la requête transmise à Varnish, il va également l'analyser pour décider s'il peut servir une réponse depuis le cache ou s'il doit la faire passer. Et s'il l'a fait passer, lors du retour il va décider s'il peut la mettre en cache.
|
||||
Once the request is passed to Varnish, it will parse it too and decide if it is able to serve a resposne from the cache or pass it to the final server.
|
||||
|
||||
Dans le cas le plus courant d'utilisation de Varnish, lorsqu'il doit faire passer une requête, il le fait directement au serveur d'application (lui aussi appelle ça un _backend_). Nous avons choisi de faire un peu différemment et de ne pas gérer dans Varnish la partie load-balancing et tolérance de panne, car elle est gérée de manière plus complète par HAProxy, et c'est ce que nous maitrisons le mieux.
|
||||
In the most common case with Varnish, the request to the final server and passed directly. It is evencapable of some rather basic load-balancing. But since we have HAProxy at hands and it is more capable in this area, we have decided to pass the request back to HAProxy.
|
||||
|
||||
Varnish va donc renvoyer la requête à HAProxy, le même que celui qui a traité la requête entrante.
|
||||
Mais pour ne pas tomber dans une boucle, et pour ne pas refaire certaines analyses déjà faites au début, nous faisons rentrer la requête par un autre _frontend_. Celui-ci sera plus simple et aura comme principale responsabilité de choisir le _backend_ final à utiliser pour la requête. Si vous gérez des sites ou applications qui sont réparties sur des groupes de serveurs différents, il faut avoir autant de _backend_ que de groupes de serveurs.
|
||||
To prevent loops, and to bypass the processing that has already been done, the request will reenter HAProxy throughanother frontend. This one is much simpler and its responsibility is basically to choose which backend to use for each request. If we manage sites and apps on more than one set of servers, we have to create as much backends as we have sets of servers.
|
||||
|
||||
Au final on passe donc la requête aux serveurs web qui vont effectivement traiter la requête.
|
||||
In the end, the request is passed to a server in a backend, be it a static web site, a dynamic application programmed with a framework, or the ingress of a big Kubernetes cluster.
|
||||
|
||||
La réponse fera ensuite le chemin inverse, en revenant à HAProxy, puis Varnish (qui décidera s'il met la réponse en cache), puis HAProxy puis le client HTTP qui a fait initialement la requête.
|
||||
|
||||
Chaîne :
|
||||
The response will eventually travl the same way backwards, through HAProxy, Varnish (which will decide to store it in the cache or not) and HAProxy again to the original HTTP client.
|
||||
|
||||
1. HAProxy _frontend_ « external » (général)
|
||||
Chain :
|
||||
|
||||
1. HAProxy _frontend_ « external » (general)
|
||||
2. HAProxy _backend_ « varnish »
|
||||
3. Varnish
|
||||
4. HAProxy _frontend_ « internal » (général)
|
||||
5. HAProxy _backend_ « site X » (par site)
|
||||
4. HAProxy _frontend_ « internal » (general)
|
||||
5. HAProxy _backend_ « site X » (per site)
|
||||
6. Web-server
|
||||
|
||||
## Multi-sites
|
||||
|
||||
Même en faisant passer tout le trafic entrant (http/https) par un seul _frontend_, il est tout à fait possible d'avoir des serveurs finaux spécifiques pour chaque site, ainsi que des traitements intermédiaires spécifiques aussi.
|
||||
|
||||
Il n'y a pas dans HAProxy de logique ressemblant aux `VirtualHost` de Apache ou Nginx, mais on peut utiliser des primitives conditionnelles plus bas-niveau pour cela.
|
||||
On crée (au moins) une ACL pour détecter si l'hôte demandée est lié à tel ou tel site, et ensuite on utilise ces ACL pour conditionnement un comportement.
|
||||
Une ACL est comme une variable booléenne.
|
||||
Even if we have only one frontend to manage all the requests with the same settings, we can have many groups of web-servers,for differents web-apps of web-sites. In our case, we have many clients on one HAProxy, with one frontend, but many backends, one for each client and their own servers.
|
||||
|
||||
HAProxy does not have a concept of VirtualHost as Apache or Nginx do, but we can use some lower-levels conditionals to have a similar result.
|
||||
We can write (at least) an ACL t detect if the Host header is for a web site or another and then use this ACL to trigger some processing adnd chose the backend to use.
|
||||
|
||||
An ACL is like a boolean variable.
|
||||
|
||||
```
|
||||
frontend external
|
||||
|
|
@ -84,9 +88,9 @@ frontend external
|
|||
use_backend foo_bar if foo_bar_domains
|
||||
```
|
||||
|
||||
## Transmettre la requête à Varnish
|
||||
## Pass the request to Varnish
|
||||
|
||||
Dans la configuration de HAProxy, nous avons créé un _backend_ « varnish », avec un seul serveur final.
|
||||
In the HAProxy configurtion, we've put a "varnish" backend, with only one server.
|
||||
|
||||
```
|
||||
backend varnish
|
||||
|
|
@ -94,9 +98,9 @@ backend varnish
|
|||
server varnish_sock /run/varnish.sock check observe layer7 maxconn 3000 inter 1s send-proxy-v2
|
||||
```
|
||||
|
||||
L'option `httpchk` permet à HAProxy de vérifier l'état de santé de Varnish, au niveau 7.
|
||||
The `httpchk` option tells HAProxy to use the "layer 7" to check for Varnish health, by regularly checking on a special URL.
|
||||
|
||||
Dans la configuration de Varnish on retrouve l'URL `/varnishcheck` :
|
||||
In the Varnish configuration we have a behaviour for this URL:
|
||||
|
||||
```
|
||||
sub vcl_recv {
|
||||
|
|
@ -107,9 +111,10 @@ sub vcl_recv {
|
|||
[…]
|
||||
}
|
||||
```
|
||||
La réponse est extrêmement rapide et permet de faire une vérification chaque seconde.
|
||||
The response is extremely fast, which allow for frequent checks by HAProxy.
|
||||
|
||||
Dans HAProxy, au niveau du frontend il y a une ACL qui permet de savoir si Varnish est disponible ou pas. Nous pouvons donc transmettre à Varnish s'il est dispo ou le contourner s'il est absent :
|
||||
In the frontend section of HAProxy, there is an ACL that tells if Varnish is knownto be available.
|
||||
It is then possible to decide if we can pass the requets to VArnish or bypass it:
|
||||
|
||||
```
|
||||
frontend external
|
||||
|
|
@ -130,10 +135,9 @@ backend default_backend
|
|||
server example-hostname 1.2.3.4:443 check observe layer4 ssl
|
||||
```
|
||||
|
||||
Nothing forces us to use VArnish for every request and all web-sites of apps.
|
||||
|
||||
Rien n'oblige à utiliser Varnish tout le temps et pour tous les sites.
|
||||
|
||||
On peut soit utiliser une ACL :
|
||||
We ca either use an ACL :
|
||||
|
||||
```
|
||||
frontend external
|
||||
|
|
@ -142,7 +146,7 @@ frontend external
|
|||
use_backend varnish if example_com_domains
|
||||
```
|
||||
|
||||
Soit utiliser un système plus dynamique, avec un fichier dans lequel on met les domaines pour lesquels on veut utiliser Varnish :
|
||||
We can use a more dynamic condition, with a file containing all the domains whose trafic should go through Varnish:
|
||||
|
||||
```
|
||||
frontend external
|
||||
|
|
@ -151,24 +155,24 @@ frontend external
|
|||
use_backend varnish if use_cache
|
||||
```
|
||||
|
||||
Nous pouvons économiser le passage par Varnish dans certains cas. Par exemple lorsque la requête n'est ni `GET`, `HEAD` ou `PURGE` :
|
||||
In some cases, we could decide to bypass Varnish when caching makes no sense. For example, if the HTTP method is neither `GET`, `HEAD` or `PURGE`:
|
||||
|
||||
```
|
||||
frontend external
|
||||
acl varnish_http_verb method GET HEAD PURGE
|
||||
acl varnish_http_verb method GET HEAD PURGE
|
||||
[…]
|
||||
use_backend varnish if varnish_http_verb
|
||||
```
|
||||
|
||||
On peut donc combiner ces conditions, pour passer à Varnish ou le contourner :
|
||||
And we can combine several of these conditions together:
|
||||
|
||||
* le domaine doit-il être mis en cache ?
|
||||
* la requête est-elle éligible au cache?
|
||||
* Varnish est-il disponible ?
|
||||
* should the domaine be cached?
|
||||
* is the request eligible for cache?
|
||||
* is Varnish available?
|
||||
|
||||
## PROXY protocol
|
||||
|
||||
### Pourquoi ?
|
||||
### What for?
|
||||
|
||||
L'utilisation du PROXY protocol n'est pas du tout indispensable, mais elle ajoute un confort significatif dans la gestion de toute cette chaîne.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue