material for the slides
14
README.en.md
|
@ -7,8 +7,8 @@ We will start with the general ideas then go deeper to the details.
|
|||
## Why HAProxy and Varnish ?
|
||||
|
||||
They are both open-source, mature and performance-oriented.
|
||||
They are not alon inb their categories, but they are the ones we know and love the most.
|
||||
They are eaisly available on many platforms. They have great documentation and vast/vibrant communities.
|
||||
They are not alone in their categories, but they are the one we know and love the most.
|
||||
They are easily available on many platforms. They have great documentation and vast/vibrant communities.
|
||||
They both are supported by companies that offer professional support and services, while keeping the core open-source and free for everybody.
|
||||
|
||||
### HAProxy
|
||||
|
@ -31,14 +31,14 @@ That's where we begin to mention load-balancing. And when we introduce som logic
|
|||
|
||||
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.
|
||||
|
||||
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.
|
||||
With its default configuration, Varnish has a lot of good practice already in place and just 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.
|
||||
|
||||
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
|
||||
## Let's combine HAProxy and Varnish
|
||||
|
||||
So we have decided to have them work together, in a coordinated way, for an efficient and feature-rich setup.
|
||||
|
||||
|
@ -114,7 +114,7 @@ sub vcl_recv {
|
|||
The response is extremely fast, which allow for frequent checks by HAProxy.
|
||||
|
||||
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:
|
||||
It is then possible to decide if we can pass the requets to Varnish or bypass it:
|
||||
|
||||
```
|
||||
frontend external
|
||||
|
@ -176,7 +176,7 @@ And we can combine several of these conditions together:
|
|||
|
||||
Using the PROXY Protocol is not a necessity at all, but it adds a certain amount of comfort when we have proxies involved, like HAProxy and Varnish.
|
||||
|
||||
At the TCP level, when HAProxy talks to Varnish, then Varnish to HAproxy and finally HAroxy to the final web server, they are all seen as regular HTTP clients.
|
||||
At the TCP level, when HAProxy talks to Varnish, then Varnish to HAproxy and finally HAproxy to the final web server, they are all seen as regular HTTP clients.
|
||||
Without any modification, each element reports the IP of the previous elements as the client IP, and the final server thinks that HAProxy is the only client accessing it. It's bad for IP based filtering, logging…
|
||||
|
||||
At the HTTP level, we've had the `X-Forwarded-For` header for a long time. I you look at its presence and you know how to parse it, you can use the ocrrect value in your web-server of application. It's cumbersome, and error-prone, and at the TCP level, this is invisible.
|
||||
|
@ -260,7 +260,7 @@ Note: If you use Apache, I encourage you to take a look at the "ForensicLog" mod
|
|||
|
||||
With the same focus on tracability easy debugging, we are using HAProxy and Varnosh to add some HTTP headers with information about their behaviour.
|
||||
|
||||
Let'sremember that the HTTP standard has normalized a list of headers. For example : `Host`, `Set-Cookie`, `Cache-Control`…
|
||||
Let's remember 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-*
|
||||
|
|
Before Width: | Height: | Size: 72 KiB After Width: | Height: | Size: 72 KiB |
Before Width: | Height: | Size: 178 KiB After Width: | Height: | Size: 178 KiB |
BIN
code-snippets/haproxy.03.png
Normal file
After Width: | Height: | Size: 49 KiB |
Before Width: | Height: | Size: 63 KiB After Width: | Height: | Size: 63 KiB |
Before Width: | Height: | Size: 59 KiB After Width: | Height: | Size: 59 KiB |
Before Width: | Height: | Size: 127 KiB After Width: | Height: | Size: 127 KiB |
Before Width: | Height: | Size: 119 KiB After Width: | Height: | Size: 119 KiB |
Before Width: | Height: | Size: 54 KiB After Width: | Height: | Size: 54 KiB |
Before Width: | Height: | Size: 121 KiB After Width: | Height: | Size: 121 KiB |
Before Width: | Height: | Size: 106 KiB After Width: | Height: | Size: 106 KiB |
Before Width: | Height: | Size: 90 KiB After Width: | Height: | Size: 90 KiB |
Before Width: | Height: | Size: 67 KiB After Width: | Height: | Size: 67 KiB |
Before Width: | Height: | Size: 153 KiB After Width: | Height: | Size: 153 KiB |
Before Width: | Height: | Size: 243 KiB After Width: | Height: | Size: 243 KiB |
Before Width: | Height: | Size: 153 KiB After Width: | Height: | Size: 153 KiB |
Before Width: | Height: | Size: 93 KiB After Width: | Height: | Size: 93 KiB |
Before Width: | Height: | Size: 33 KiB After Width: | Height: | Size: 33 KiB |
Before Width: | Height: | Size: 32 KiB After Width: | Height: | Size: 32 KiB |
Before Width: | Height: | Size: 67 KiB After Width: | Height: | Size: 67 KiB |
Before Width: | Height: | Size: 89 KiB After Width: | Height: | Size: 89 KiB |
BIN
code-snippets/varnish.01.png
Normal file
After Width: | Height: | Size: 44 KiB |
Before Width: | Height: | Size: 57 KiB After Width: | Height: | Size: 57 KiB |
Before Width: | Height: | Size: 48 KiB After Width: | Height: | Size: 48 KiB |
Before Width: | Height: | Size: 179 KiB After Width: | Height: | Size: 179 KiB |
BIN
images/schema-boost.png
Normal file
After Width: | Height: | Size: 58 KiB |
BIN
images/schema-haproxy.png
Normal file
After Width: | Height: | Size: 52 KiB |
BIN
images/schema-varnish.png
Normal file
After Width: | Height: | Size: 40 KiB |
BIN
images/varnish-logo.png
Normal file
After Width: | Height: | Size: 12 KiB |
BIN
images/with-proxy-protocol.png
Normal file
After Width: | Height: | Size: 34 KiB |
BIN
images/without-proxy-protocol.png
Normal file
After Width: | Height: | Size: 35 KiB |
Before Width: | Height: | Size: 61 KiB |
Before Width: | Height: | Size: 71 KiB |