doc: Material Theme.

docs/configuration/backends/docker.md

@@ -165,4 +165,7 @@ exposedbydefault = false
 | `traefik.<service-name>.frontend.priority`        | Overrides `traefik.frontend.priority`.                                                           |
 | `traefik.<service-name>.frontend.rule`            | Overrides `traefik.frontend.rule`.                                                               |
 
-NB: when running inside a container, Træfik will need network access through `docker network connect <network> <traefik-container>`
+!!! warning
+    when running inside a container, Træfik will need network access through:
+
+    `docker network connect <network> <traefik-container>`

docs/configuration/backends/eureka.md

@@ -29,6 +29,3 @@ delay = "1m"
 #
 # filename = "eureka.tmpl"
 ```
-
-Please refer to the [Key Value storage structure](/user-guide/kv-config/#key-value-storage-structure) section to get documentation on traefik KV structure.
-

docs/configuration/backends/rancher.md

@@ -99,12 +99,11 @@ AccessKey = "XXXXXXXXXXXXXXXXXXXX"
 SecretKey = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
 ```
 
-## Notes
+!!! note
+    If Traefik needs access to the Rancher API, you need to set the `endpoint`, `accesskey` and `secretkey` parameters.
  
-If Traefik needs access to the Rancher API, you need to set the `endpoint`, `accesskey` and `secretkey` parameters. 
+    To enable traefik to fetch information about the Environment it's deployed in only, you need to create an `Environment API Key`.
-
+    This can be found within the API Key advanced options.
-To enable traefik to fetch information about the Environment it's deployed in only, you need to create an `Environment API Key`.
-This can be found within the API Key advanced options.
 
 ## Labels
 

docs/css/traefik.css

@@ -1,61 +0,0 @@
-a {
-    color: #37ABC8;
-    text-decoration: none;
-}
-
-a:hover, a:focus {
-    color: #25606F;
-    text-decoration: underline;
-}
-
-h1, h2, h3, H4 {
-    color: #37ABC8;
-}
-
-.navbar-default {
-    background-color: #37ABC8;
-    border-color: #25606F;
-}
-
-.navbar-default .navbar-nav>.active>a, .navbar-default .navbar-nav>.active>a:hover, .navbar-default .navbar-nav>.active>a:focus {
-    color: #fff;
-    background-color: #25606F;
-}
-
-.navbar-default .navbar-nav>li>a:hover, .navbar-default .navbar-nav>li>a:focus {
-    color: #fff;
-    background-color: #25606F;
-}
-
-.navbar-default .navbar-toggle {
-    border-color: #25606F;
-}
-
-.navbar-default .navbar-toggle:hover, .navbar-default .navbar-toggle:focus .navbar-toggle {
-    background-color: #25606F;
-}
-.navbar-default .navbar-collapse, .navbar-default .navbar-form {
-    border-color: #25606F;
-}
-
-blockquote p {
-    font-size: 14px;
-}
-
-.navbar-default .navbar-nav>.open>a, .navbar-default .navbar-nav>.open>a:hover, .navbar-default .navbar-nav>.open>a:focus {
-    color: #fff;
-    background-color: #25606F;
-}
-
-.dropdown-menu>li>a:hover, .dropdown-menu>li>a:focus {
-    color: #fff;
-    text-decoration: none;
-    background-color: #25606F;
-}
-
-.dropdown-menu>.active>a, .dropdown-menu>.active>a:hover, .dropdown-menu>.active>a:focus {
-    color: #fff;
-    text-decoration: none;
-    background-color: #25606F;
-    outline: 0;
-}

docs/js/extra.js

@@ -0,0 +1,4 @@
+/* Highlight */
+(function(hljs) {
+    hljs.initHighlightingOnLoad();
+})(hljs);

docs/js/hljs/LICENSE

@@ -0,0 +1,24 @@
+Copyright (c) 2006, Ivan Sagalaev
+All rights reserved.
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+    * Redistributions of source code must retain the above copyright
+      notice, this list of conditions and the following disclaimer.
+    * Redistributions in binary form must reproduce the above copyright
+      notice, this list of conditions and the following disclaimer in the
+      documentation and/or other materials provided with the distribution.
+    * Neither the name of highlight.js nor the names of its contributors 
+      may be used to endorse or promote products derived from this software 
+      without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND ANY
+EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE REGENTS AND CONTRIBUTORS BE LIABLE FOR ANY
+DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

docs/styles/atom-one-light.css

@@ -0,0 +1,96 @@
+/*
+
+Atom One Light by Daniel Gamage
+Original One Light Syntax theme from https://github.com/atom/one-light-syntax
+
+base:    #fafafa
+mono-1:  #383a42
+mono-2:  #686b77
+mono-3:  #a0a1a7
+hue-1:   #0184bb
+hue-2:   #4078f2
+hue-3:   #a626a4
+hue-4:   #50a14f
+hue-5:   #e45649
+hue-5-2: #c91243
+hue-6:   #986801
+hue-6-2: #c18401
+
+*/
+
+.hljs {
+  display: block;
+  overflow-x: auto;
+  padding: 0.5em;
+  color: #383a42;
+  background: #fafafa;
+}
+
+.hljs-comment,
+.hljs-quote {
+  color: #a0a1a7;
+  font-style: italic;
+}
+
+.hljs-doctag,
+.hljs-keyword,
+.hljs-formula {
+  color: #a626a4;
+}
+
+.hljs-section,
+.hljs-name,
+.hljs-selector-tag,
+.hljs-deletion,
+.hljs-subst {
+  color: #e45649;
+}
+
+.hljs-literal {
+  color: #0184bb;
+}
+
+.hljs-string,
+.hljs-regexp,
+.hljs-addition,
+.hljs-attribute,
+.hljs-meta-string {
+  color: #50a14f;
+}
+
+.hljs-built_in,
+.hljs-class .hljs-title {
+  color: #c18401;
+}
+
+.hljs-attr,
+.hljs-variable,
+.hljs-template-variable,
+.hljs-type,
+.hljs-selector-class,
+.hljs-selector-attr,
+.hljs-selector-pseudo,
+.hljs-number {
+  color: #986801;
+}
+
+.hljs-symbol,
+.hljs-bullet,
+.hljs-link,
+.hljs-meta,
+.hljs-selector-id,
+.hljs-title {
+  color: #4078f2;
+}
+
+.hljs-emphasis {
+  font-style: italic;
+}
+
+.hljs-strong {
+  font-weight: bold;
+}
+
+.hljs-link {
+  text-decoration: underline;
+}

docs/styles/extra.css

@@ -0,0 +1,15 @@
+.md-logo img {
+    background-color: white;
+    border-radius: 50%;
+    width: 30px;
+    height: 30px;
+}
+
+/* Fix for Chrome */
+.md-typeset__table td code {
+    word-break: unset;
+}
+.md-typeset__table tr :nth-child(1) {
+    word-wrap: break-word;
+    max-width: 30em;
+}

docs/user-guide/examples.md

@@ -129,10 +129,14 @@ entryPoint = "https"
 
 This configuration allows generating a Let's Encrypt certificate during the first HTTPS request on a new domain.
 
-**Note** : This option simplifies the configuration but :
+
-* TLS handshakes will be slow when requesting a hostname certificate for the first time, this can leads to DDoS attacks.
+!!! note
-* Let's Encrypt have rate limiting: https://letsencrypt.org/docs/rate-limits
+    This option simplifies the configuration but :
-That's why, it's better to use the `onHostRule` optin if possible.
+
+    * TLS handshakes will be slow when requesting a hostname certificate for the first time, this can leads to DDoS attacks.
+    * Let's Encrypt have rate limiting: https://letsencrypt.org/docs/rate-limits
+
+    That's why, it's better to use the `onHostRule` optin if possible.
 
 ### DNS challenge
 
@@ -228,7 +232,8 @@ entryPoint = "https"
 This configuration allows to use the key `traefik/acme/account` to get/set Let's Encrypt certificates content.
 The `consul` provider contains the configuration.
 
-**Note** : It's possible to use others key-value store providers as described [here](/user-guide/kv-config/#key-value-store-configuration).
+!!! note
+    It's possible to use others key-value store providers as described [here](/user-guide/kv-config/#key-value-store-configuration).
 
 ## Override entrypoints in frontends
 

docs/user-guide/kubernetes.md

@@ -18,7 +18,8 @@ Kubernetes introduces [Role Based Access Control (RBAC)](https://kubernetes.io/d
 
 If your cluster is configured with RBAC, you may need to authorize Træfik to use the Kubernetes API using ClusterRole and ClusterRoleBinding resources:
 
-_Note: your cluster may have suitable ClusterRoles already setup, but the following should work everywhere_
+!!! note
+    your cluster may have suitable ClusterRoles already setup, but the following should work everywhere
 
 ```yaml
 ---
@@ -683,9 +684,10 @@ spec:
 
 If you were to visit `example.com/static` the request would then be passed onto `static.otherdomain.com/static` and s`tatic.otherdomain.com` would receive the request with the Host header being `static.otherdomain.com`.
 
-Note: The per ingress annotation overides whatever the global value is set to.
+!!! note
-So you could set `disablePassHostHeaders` to `true` in your toml file and then enable passing 
+    The per ingress annotation overides whatever the global value is set to.
-the host header per ingress if you wanted.
+    So you could set `disablePassHostHeaders` to `true` in your toml file and then enable passing 
+    the host header per ingress if you wanted.
 
 ## Excluding an ingress from Træfik
 

docs/user-guide/kv-config.md

@@ -134,7 +134,8 @@ traefik:
     - "8080:8080"
 ```
 
-NB : Be careful to give the correct IP address and port in the flag `--consul.endpoint`.
+!!! warning
+    Be careful to give the correct IP address and port in the flag `--consul.endpoint`.
 
 ## Consul ACL Token support
 

docs/user-guide/marathon.md

@@ -12,11 +12,14 @@ Marathon offers multiple ways to run (Docker-containerized) applications, the mo
 
 Traefik tries to detect the configured mode and route traffic to the right IP addresses. It is possible to force using task hosts with the `forceTaskHostname` option.
 
-Given the complexity of the subject, it is possible that the heuristic fails. Apart from filing an issue and waiting for the feature request / bug report to get addressed, one workaround for such situations is to customize the Marathon template file to the individual needs. (Note that this does _not_ require rebuilding Traefik but only to point the `filename` configuration parameter to a customized version of the `marathon.tmpl` file on Traefik startup.)
+Given the complexity of the subject, it is possible that the heuristic fails.
+Apart from filing an issue and waiting for the feature request / bug report to get addressed, one workaround for such situations is to customize the Marathon template file to the individual needs.
+(Note that this does _not_ require rebuilding Traefik but only to point the `filename` configuration parameter to a customized version of the `marathon.tmpl` file on Traefik startup.)
 
 # Port detection
 
-Traefik also attempts to determine the right port (which is a [non-trivial matter in Marathon](https://mesosphere.github.io/marathon/docs/ports.html)). Following is the order by which Traefik tries to identify the port (the first one that yields a positive result will be used):
+Traefik also attempts to determine the right port (which is a [non-trivial matter in Marathon](https://mesosphere.github.io/marathon/docs/ports.html)).
+Following is the order by which Traefik tries to identify the port (the first one that yields a positive result will be used):
 
 1. A arbitrary port specified through the `traefik.port` label.
 1. The task port (possibly indexed through the `traefik.portIndex` label, otherwise the first one).
@@ -39,15 +42,22 @@ The following sub-sections describe how to resolve or mitigate each scenario.
 
 ### Startup
 
-It is possible to define [readiness checks](https://mesosphere.github.io/marathon/docs/readiness-checks.html) (available since Marathon version 1.1) per application and have Marathon take these into account during the startup phase. The idea is that each application provides an HTTP endpoint that Marathon queries periodically during an ongoing deployment in order to mark the associated readiness check result as successful if and only if the endpoint returns a response within the configured HTTP code range. As long as the check keeps failing, Marathon will not proceed with the deployment (within the configured upgrade stategy bounds).
+It is possible to define [readiness checks](https://mesosphere.github.io/marathon/docs/readiness-checks.html) (available since Marathon version 1.1) per application and have Marathon take these into account during the startup phase.
+The idea is that each application provides an HTTP endpoint that Marathon queries periodically during an ongoing deployment in order to mark the associated readiness check result as successful if and only if the endpoint returns a response within the configured HTTP code range.
+As long as the check keeps failing, Marathon will not proceed with the deployment (within the configured upgrade strategy bounds).
 
-Beginning with version 1.4, Traefik respects readiness check results if the Traefik option is set and checks are configured on the applications accordingly. Note that due to the way readiness check results are currently exposed by the Marathon API, ready tasks may be taken into rotation with a small delay. It is on the order of one readiness check timeout interval (as configured on the application specifiation) and guarantees that non-ready tasks do not receive traffic prematurely.
+Beginning with version 1.4, Traefik respects readiness check results if the Traefik option is set and checks are configured on the applications accordingly.
+Note that due to the way readiness check results are currently exposed by the Marathon API, ready tasks may be taken into rotation with a small delay.
+It is on the order of one readiness check timeout interval (as configured on the application specifiation) and guarantees that non-ready tasks do not receive traffic prematurely.
 
-If readiness checks are not possible, a current mitigation strategy is to enable [retries](http://docs.traefik.io/toml/#retry-configuration) and make sure that a sufficient number of healthy application tasks exist so that one retry will likely hit one of those. Apart from its probabilistic nature, the workaround comes at the price of increased latency.
+If readiness checks are not possible, a current mitigation strategy is to enable [retries](http://docs.traefik.io/toml/#retry-configuration) and make sure that a sufficient number of healthy application tasks exist so that one retry will likely hit one of those.
+Apart from its probabilistic nature, the workaround comes at the price of increased latency.
 
 ### Shutdown
 
-It is possible to install a [termination handler](https://mesosphere.github.io/marathon/docs/health-checks.html) (available since Marathon version 1.3) with each application whose responsibility it is to delay the shutdown process long enough until the backend has been taken out of load-balancing rotation with reasonable confidence (i.e., Traefik has received an update from the Marathon event bus, recomputes the available Marathon backends, and applies the new configuration). Specifically, each termination handler should install a signal handler listening for a SIGTERM signal and implement the following steps on signal reception:
+It is possible to install a [termination handler](https://mesosphere.github.io/marathon/docs/health-checks.html) (available since Marathon version 1.3) with each application whose responsibility it is to delay the shutdown process long enough until the backend has been taken out of load-balancing rotation with reasonable confidence
+(i.e., Traefik has received an update from the Marathon event bus, recomputes the available Marathon backends, and applies the new configuration).
+Specifically, each termination handler should install a signal handler listening for a SIGTERM signal and implement the following steps on signal reception:
 
 1. Disable Keep-Alive HTTP connections.
 1. Keep accepting HTTP requests for a certain period of time.
@@ -57,20 +67,26 @@ It is possible to install a [termination handler](https://mesosphere.github.io/m
 
 Traefik already ignores Marathon tasks whose state does not match `TASK_RUNNING`; since terminating tasks transition into the `TASK_KILLING` and eventually `TASK_KILLED` state, there is nothing further that needs to be done on Traefik's end.
 
-How long HTTP requests should continue to be accepted in step 2 depends on how long Traefik needs to receive and process the Marathon configuration update. Under regular operational conditions, it should be on the order of seconds, with 10 seconds possibly being a good default value.
+How long HTTP requests should continue to be accepted in step 2 depends on how long Traefik needs to receive and process the Marathon configuration update.
+Under regular operational conditions, it should be on the order of seconds, with 10 seconds possibly being a good default value.
 
-Again, configuring Traefik to do retries (as discussed in the previous section) can serve as a decent workaround strategy. Paired with termination handlers, they would cover for those cases where either the termination sequence or Traefik cannot complete their part of the orchestration process in time.
+Again, configuring Traefik to do retries (as discussed in the previous section) can serve as a decent workaround strategy.
+Paired with termination handlers, they would cover for those cases where either the termination sequence or Traefik cannot complete their part of the orchestration process in time.
 
 ### Failure
 
-A failing application always happens unexpectedly, and hence, it is very difficult or even impossible to rule out the adversal effects categorically. Failure reasons vary broadly and could stretch from unacceptable slowness, a task crash, or a network split.
+A failing application always happens unexpectedly, and hence, it is very difficult or even impossible to rule out the adversal effects categorically.
+Failure reasons vary broadly and could stretch from unacceptable slowness, a task crash, or a network split.
 
 There are two mitigaton efforts:
 
 1. Configure [Marathon health checks](https://mesosphere.github.io/marathon/docs/health-checks.html) on each application.
 1. Configure Traefik health checks (possibly via the `traefik.backend.healthcheck.*` labels) and make sure they probe with proper frequency.
 
-The Marathon health check makes sure that applications once deemed dysfunctional are being rescheduled to different slaves. However, they might take a while to get triggered and the follow-up processes to complete. For that reason, the Treafik health check provides an additional check that responds more rapidly and does not require a configuration reload to happen. Additionally, it protects from cases that the Marathon health check may not be able to cover, such as a network split.
+The Marathon health check makes sure that applications once deemed dysfunctional are being rescheduled to different slaves.
+However, they might take a while to get triggered and the follow-up processes to complete.
+For that reason, the Treafik health check provides an additional check that responds more rapidly and does not require a configuration reload to happen.
+Additionally, it protects from cases that the Marathon health check may not be able to cover, such as a network split.
 
 ## (Non-)Alternatives
 
@@ -80,16 +96,21 @@ There are a few alternatives of varying quality that are frequently asked for. T
 
 It may seem obvious to reuse the Marathon health checks as a signal to Traefik whether an application should be taken into load-balancing rotation or not.
 
-Apart from the increased latency a failing health check may have, a major problem with this is is that Marathon does not persist the health check results. Consequently, if a master re-election occurs in the Marathon clusters, all health check results will revert to the _unknown_ state, effectively causing all applications inside the cluster to become unavailable and leading to a complete cluster failure. Re-elections do not only happen during regular maintenance work (often requiring rolling upgrades of the Marathon nodes) but also when the Marathon leader fails spontaneously. As such, there is no way to handle this situation deterministically.
+Apart from the increased latency a failing health check may have, a major problem with this is is that Marathon does not persist the health check results.
+Consequently, if a master re-election occurs in the Marathon clusters, all health check results will revert to the _unknown_ state, effectively causing all applications inside the cluster to become unavailable and leading to a complete cluster failure.
+Re-elections do not only happen during regular maintenance work (often requiring rolling upgrades of the Marathon nodes) but also when the Marathon leader fails spontaneously.
+As such, there is no way to handle this situation deterministically.
 
 Finally, Marathon health checks are not mandatory (the default is to use the task state as reported by Mesos), so requiring them for Traefik would raise the entry barrier for Marathon users.
 
-Traefik used to use the health check results as a strict requirement but moved away from it as [users reported the dramatic consequences](https://github.com/containous/traefik/issues/653). If health check results are known to exist, however, they will be used to signal task availability.
+Traefik used to use the health check results as a strict requirement but moved away from it as [users reported the dramatic consequences](https://github.com/containous/traefik/issues/653).
+If health check results are known to exist, however, they will be used to signal task availability.
 
 ### Draining
 
 Another common approach is to let a proxy drain backends that are supposed to shut down. That is, once a backend is supposed to shut down, Traefik would stop forwarding requests.
 
-On the plus side, this would not require any modifications to the application in question. However, implementing this fully within Traefik seems like a non-trivial undertaking. Additionally, the approach is less flexible compared to a custom termination handler since only the latter allows for the implementation of custom termination sequences that go beyond simple request draining (e.g., persisting a snapshot state to disk prior to terminating).
+On the plus side, this would not require any modifications to the application in question. However, implementing this fully within Traefik seems like a non-trivial undertaking.
+Additionally, the approach is less flexible compared to a custom termination handler since only the latter allows for the implementation of custom termination sequences that go beyond simple request draining (e.g., persisting a snapshot state to disk prior to terminating).
 
 The feature is currently not implemented; a request for draining in general is at [issue 41](https://github.com/containous/traefik/issues/41).

mkdocs.yml

@@ -8,9 +8,9 @@ repo_url: 'https://github.com/containous/traefik'
 
 # Documentation and theme
 docs_dir: 'docs'
-theme: united
+#theme: united
 # theme: readthedocs
-# theme: 'material'
+theme: 'material'
 # theme: bootstrap
 
 site_favicon: 'img/traefik.icon.png'
@@ -20,26 +20,34 @@ copyright: "Copyright © 2016-2017 Containous SAS"
 
 # Options
 extra:
-#   version: 0.2.2
   logo: img/traefik.logo.png
-  # author:
-  #   twitter: traefikproxy
   palette:
     primary: 'blue'
     accent: 'light blue'
+  feature:
+    tabs: false
+  palette:
+    primary: 'cyan'
+    accent: 'cyan'
   i18n:
     prev: 'Previous'
     next: 'Next'
-  
+# version: 0.2.2
-markdown_extensions:
+# author:
-#   - codehilite(css_class=code)
+#   twitter: traefikproxy
-  - admonition
-#   - toc:
-#       permalink: '##'
-  # - fenced_code
 
 extra_css:
-    - css/traefik.css
+    - styles/extra.css
+    - styles/atom-one-light.css
+
+extra_javascript:
+  - js/hljs/highlight.pack.js
+  - js/extra.js
+
+markdown_extensions:
+  - admonition
+#  - codehilite(guess_lang=false)
+  - toc(permalink=true)
 
 # Page tree
 pages:

requirements.txt

@@ -1,3 +1,4 @@
 mkdocs>=0.16.1
 pymdown-extensions>=1.4
 mkdocs-bootswatch>=0.4.0
+mkdocs-material>=1.8.1