homelab/traefik
1
0
Fork 0
Code Activity

Clean Documentation

Browse source
This commit is contained in:
Nicolas Mengin 2025-08-25 14:35:04 +02:00 • committed by GitHub
parent 8ac8473554
commit 1997bc7432
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
77 changed files with 2561 additions and 1247 deletions
Download patch file Download diff file Expand all files Collapse all files

193
docs/content/reference/routing-configuration/http/load-balancing/service.md
View file

@ -133,6 +133,164 @@ Below are the available options for the health check mechanism:
| `method` | Defines the HTTP method that will be used while connecting to the endpoint. | GET | No |
| `status` | Defines the expected HTTP status code of the response to the health check request. | | No |
#### Sticky sessions
When sticky sessions are enabled, a `Set-Cookie` header is set on the initial response to let the client know which server handles the first response.
On subsequent requests, to keep the session alive with the same server, the client should send the cookie with the value set.
##### Stickiness on multiple levels
When chaining or mixing load-balancers (e.g. a load-balancer of servers is one of the "children" of a load-balancer of services), for stickiness to work all the way, the option needs to be specified at all required levels. Which means the client needs to send a cookie with as many key/value pairs as there are sticky levels.
##### Stickiness & Unhealthy Servers
If the server specified in the cookie becomes unhealthy, the request will be forwarded to a new server (and the cookie will keep track of the new server).
##### Cookie Name
The default cookie name is an abbreviation of a sha1 (ex: `_1d52e`).
##### MaxAge
By default, the affinity cookie will never expire as the `MaxAge` option is set to zero.
This option indicates the number of seconds until the cookie expires.
When set to a negative number, the cookie expires immediately.
##### Secure & HTTPOnly & SameSite flags
By default, the affinity cookie is created without those flags.
One however can change that through configuration.
`SameSite` can be `none`, `lax`, `strict` or empty.
##### Domain
The Domain attribute of a cookie specifies the domain for which the cookie is valid.
By setting the Domain attribute, the cookie can be shared across subdomains (for example, a cookie set for example.com would be accessible to www.example.com, api.example.com, etc.). This is particularly useful in cases where sticky sessions span multiple subdomains, ensuring that the session is maintained even when the client interacts with different parts of the infrastructure.
??? example "Adding Stickiness -- Using the [File Provider](../../../install-configuration/providers/others/file.md)"
```yaml tab="YAML"
## Dynamic configuration
http:
services:
my-service:
loadBalancer:
sticky:
cookie: {}
```
```toml tab="TOML"
## Dynamic configuration
[http.services]
[http.services.my-service]
[http.services.my-service.loadBalancer.sticky.cookie]
```
??? example "Adding Stickiness with custom Options -- Using the [File Provider](../../../install-configuration/providers/others/file.md)"
```yaml tab="YAML"
## Dynamic configuration
http:
services:
my-service:
loadBalancer:
sticky:
cookie:
name: my_sticky_cookie_name
secure: true
domain: mysite.site
httpOnly: true
```
```toml tab="TOML"
## Dynamic configuration
[http.services]
[http.services.my-service]
[http.services.my-service.loadBalancer.sticky.cookie]
name = "my_sticky_cookie_name"
secure = true
httpOnly = true
domain = "mysite.site"
sameSite = "none"
```
??? example "Setting Stickiness on all the required levels -- Using the [File Provider](../../../install-configuration/providers/others/file.md)"
```yaml tab="YAML"
## Dynamic configuration
http:
services:
wrr1:
weighted:
sticky:
cookie:
name: lvl1
services:
- name: whoami1
weight: 1
- name: whoami2
weight: 1
whoami1:
loadBalancer:
sticky:
cookie:
name: lvl2
servers:
- url: http://127.0.0.1:8081
- url: http://127.0.0.1:8082
whoami2:
loadBalancer:
sticky:
cookie:
name: lvl2
servers:
- url: http://127.0.0.1:8083
- url: http://127.0.0.1:8084
```
```toml tab="TOML"
## Dynamic configuration
[http.services]
[http.services.wrr1]
[http.services.wrr1.weighted.sticky.cookie]
name = "lvl1"
[[http.services.wrr1.weighted.services]]
name = "whoami1"
weight = 1
[[http.services.wrr1.weighted.services]]
name = "whoami2"
weight = 1
[http.services.whoami1]
[http.services.whoami1.loadBalancer]
[http.services.whoami1.loadBalancer.sticky.cookie]
name = "lvl2"
[[http.services.whoami1.loadBalancer.servers]]
url = "http://127.0.0.1:8081"
[[http.services.whoami1.loadBalancer.servers]]
url = "http://127.0.0.1:8082"
[http.services.whoami2]
[http.services.whoami2.loadBalancer]
[http.services.whoami2.loadBalancer.sticky.cookie]
name = "lvl2"
[[http.services.whoami2.loadBalancer.servers]]
url = "http://127.0.0.1:8083"
[[http.services.whoami2.loadBalancer.servers]]
url = "http://127.0.0.1:8084"
```
To keep a session open with the same server, the client would then need to specify the two levels within the cookie for each request, e.g. with curl:
```
curl -b "lvl1=whoami1; lvl2=http://127.0.0.1:8081" http://localhost:8000
```
## Weighted Round Robin (WRR)
The WRR is able to load balance the requests between multiple services based on weights.
@ -141,7 +299,7 @@ This strategy is only available to load balance between services and not between
!!! info "Supported Providers"
This strategy can be defined currently with the [File](../../../install-configuration/providers/others/file.md) or [IngressRoute](../../../install-configuration/providers/kubernetes/kubernetes-ingress.md) providers. To load balance between servers based on weights, the Load Balancer service should be used instead.
This strategy can be defined currently with the [File](../../../install-configuration/providers/others/file.md) or [IngressRoute](../../../install-configuration/providers/kubernetes/kubernetes-crd.md) providers. To load balance between servers based on weights, the Load Balancer service should be used instead.
```yaml tab="Structured (YAML)"
## Dynamic configuration
@ -260,6 +418,37 @@ http:
[[http.services.appv2.loadBalancer.servers]]
url = "http://private-ip-server-2/"
```
## P2C
Power of two choices algorithm is a load balancing strategy that selects two servers at random and chooses the one with the least number of active requests.
??? example "P2C Load Balancing -- Using the [File Provider](../../../install-configuration/providers/others/file.md)"
```yaml tab="YAML"
## Dynamic configuration
http:
services:
my-service:
loadBalancer:
strategy: "p2c"
servers:
- url: "http://private-ip-server-1/"
- url: "http://private-ip-server-2/"
- url: "http://private-ip-server-3/"
```
```toml tab="TOML"
## Dynamic configuration
[http.services]
[http.services.my-service.loadBalancer]
strategy = "p2c"
[[http.services.my-service.loadBalancer.servers]]
url = "http://private-ip-server-1/"
[[http.services.my-service.loadBalancer.servers]]
url = "http://private-ip-server-2/"
[[http.services.my-service.loadBalancer.servers]]
url = "http://private-ip-server-3/"
```
## Mirroring
@ -271,7 +460,7 @@ The mirroring is able to mirror requests sent to a service to other services. Pl
!!! info "Supported Providers"
This strategy can be defined currently with the [File](../../../install-configuration/providers/others/file.md) or [IngressRoute](../../../install-configuration/providers/kubernetes/kubernetes-ingress.md) providers.
This strategy can be defined currently with the [File](../../../install-configuration/providers/others/file.md) or [IngressRoute](../../../install-configuration/providers/kubernetes/kubernetes-crd.md) providers.
```yaml tab="Structured (YAML)"
## Dynamic configuration

2
docs/content/reference/routing-configuration/http/middlewares/addprefix.md
View file

@ -3,8 +3,6 @@ title: "Traefik AddPrefix Documentation"
description: "Learn how to implement the HTTP AddPrefix middleware in Traefik Proxy to updates request paths before being forwarded. Read the technical documentation."
---
![AddPrefix](../../../../assets/img/middleware/addprefix.png)
The `addPrefix` middleware updates the path of a request before forwarding it.
## Configuration Examples

2
docs/content/reference/routing-configuration/http/middlewares/basicauth.md
View file

@ -3,8 +3,6 @@ title: "Traefik BasicAuth Documentation"
description: "The HTTP basic authentication (BasicAuth) middleware in Traefik Proxy restricts access to your Services to known users. Read the technical documentation."
---
![BasicAuth](../../../../assets/img/middleware/basicauth.png)
The `basicAuth` middleware grants access to services to authorized users only.
## Configuration Examples

2
docs/content/reference/routing-configuration/http/middlewares/buffering.md
View file

@ -3,8 +3,6 @@ title: "Traefik Buffering Documentation"
description: "The HTTP buffering middleware in Traefik Proxy limits the size of requests that can be forwarded to Services. Read the technical documentation."
---
![Buffering](../../../../assets/img/middleware/buffering.png)
The `buffering` middleware limits the size of requests that can be forwarded to services.
With buffering, Traefik reads the entire request into memory (possibly buffering large requests into disk), and rejects requests that are over a specified size limit.

2
docs/content/reference/routing-configuration/http/middlewares/circuitbreaker.md
View file

@ -3,8 +3,6 @@ title: "Traefik CircuitBreaker Documentation"
description: "The HTTP circuit breaker in Traefik Proxy prevents stacking requests to unhealthy Services, resulting in cascading failures. Read the technical documentation."
---
![Circuit Breaker](../../../../assets/img/middleware/circuitbreaker.png)
The HTTP circuit breaker prevents stacking requests to unhealthy Services, resulting in cascading failures.
When your system is healthy, the circuit is closed (normal operations).

2
docs/content/reference/routing-configuration/http/middlewares/digestauth.md
View file

@ -3,8 +3,6 @@ title: "Traefik DigestAuth Documentation"
description: "Traefik Proxy's HTTP DigestAuth middleware restricts access to your services to known users. Read the technical documentation."
---
![DigestAuth](../../../../assets/img/middleware/digestauth.png)
The `DigestAuth` middleware grants access to services to authorized users only.
## Configuration Examples

2
docs/content/reference/routing-configuration/http/middlewares/errorpages.md
View file

@ -3,8 +3,6 @@ title: "Traefik Errors Documentation"
description: "In Traefik Proxy, the Errors middleware returns custom pages according to configured ranges of HTTP Status codes. Read the technical documentation."
---
![Errors](../../../../assets/img/middleware/errorpages.png)
The `errors` middleware returns a custom page in lieu of the default, according to configured ranges of HTTP Status codes.
## Configuration Examples

2
docs/content/reference/routing-configuration/http/middlewares/forwardauth.md
View file

@ -3,8 +3,6 @@ title: "Traefik ForwardAuth Documentation"
description: "In Traefik Proxy, the HTTP ForwardAuth middleware delegates authentication to an external Service. Read the technical documentation."
---
![AuthForward](../../../../assets/img/middleware/authforward.png)
The `forwardAuth` middleware delegates authentication to an external service.
If the service answers with a 2XX code, access is granted, and the original request is performed.
Otherwise, the response from the authentication server is returned.

2
docs/content/reference/routing-configuration/http/middlewares/headers.md
View file

@ -3,8 +3,6 @@ title: "Traefik Headers Documentation"
description: "In Traefik Proxy, the HTTP headers middleware manages the headers of requests and responses. Read the technical documentation."
---
![Headers](../../../../assets/img/middleware/headers.png)
The Headers middleware manages the headers of requests and responses.
By default, the following headers are automatically added when proxying requests: