Traefik should follow modern IT trends, and use manager/leader/worker/agent, etc. instead of "master/slave".
e.g jenkinsci/jenkins#2007 (https://issues.jenkins-ci.org/browse/JENKINS-27268)
NB: of course, it can only apply where possible, since backends like Mesos should retain their own concepts, and not add more confusion.
Copys the incoming TLS client certificate to the outgoing
request. The backend can then use this certificate for
client authentication ie. k8s client cert authentication
* Adds some raw.githubusercontent.com links to the kubectl examples to
make following along at home simpler.
* Dedupe the config for rbac so it can just be ommited if not needed.
* Add IdleTimeout setting to http.server
Without such a timeout there is a risk of resource leakage from piling up connections, particularly when exposing Traefik to the Internet.
Set the default to be 180 seconds
* Add IdleConnTimeout to Traefik's http.server settings
Without enforcing a timeout Traefik is susceptible to resource leakage, particularly when deployed as a public facing proxy exposed to the Internet.
Set the default to be 180 seconds
* tweak
* Update configuration.go
* add some documentation for the idletimeout setting
* need to cast idletimeout
* update doc to refect format specifics
In Swarm mode with with Docker Swarm’s Load Balancer disabled (traefik.backend.loadbalancer.swarm=false)
service name will be the name of the docker service and name will be the container task name
(e.g. whoami0.1). When generating backend and fronted rules, we will use service name instead of name if a
rule is not provided.
Initialize dockerData.ServiceName to dockerData.Name to support non-swarm mode.
SWARM Mode has it's own built in Load balancer, so if we want to leverage sticky sessions,
or if we would just prefer to bypass it and go directly to the containers (aka tasks), via
--label traefik.backend.disable.swarm.loadbalancer=true
then we need to let Traefik know about the underlying tasks and register them as
services within it's backend.
* Add ability to set authenticated user in request header
Some web applications provide the ability to authorize users based on
the authenticated from Basic Auth. This patch provides a way to set a
key to which the authenticated user can be set in the Header.
For example, if I set `HeaderValue = "X-WebAuth-User"` and authenticate,
my application will be able to read my user name from that header and
provide me with the proper access.
This fixes#802
Prior to this fix the documentation for the swarm example included
syntax that would fail with the following error.
`Error : flag needs an argument: --docker.domain`
This fix specifies flags using the `=` between the flag name and value.
Tested on: Docker version 1.12.2-rc1, build 45bed2c, experimental
