经过一年多的实践，对于使用 Traefik 有了一些更深入的体会，本篇先来介绍如何简化使用，后续会逐步展开聊聊如何在云上使用这款“云原生”工具，以及结合它做一些提升业务效率和开发效率的实践。

在 Traefik 2 使用指南，愉悦的开发体验、配置基于Traefik v2的 Web 服务器 文章中，使用 Traefik 的方案引入了比较多的配置，如果你并不是在一个复杂场景使用，这样的配置是可以简化的。

简化程序配置文件

一般情况下将参数变为配置，更利于在版本控制软件中进行版本管理。在 v2 版本中，因为有了动态配置的概念，传统的固定配置，使用简写的参数来替换，并记录在容器启动配置中，可以在减少分发文件数量的情况下，达到相同的效果。

使用参数取代 traefik.toml

在之前的文章中，我提供了一般情况下，使用的默认配置内容：

想要达到相同的效果，只需要在 command 字段内添加下面的内容即可：

现在，你就可以将 traefik.toml 配置文件删除掉了。

简化 dashboard.toml

前文中，我们将 Traefik 的内置 dashboard 等路由通过配置文件来定义，像下面这样。

其实，只需要将配置保留剩下这两条需要被预先定义的“中间件”即可，如果你不需要页面压缩，或者不需要访问密码，那么也可以不对下面的内容进行保存：

接着在容器配置中添加一些 traefik 能够解析处理的规则在 labels 字段中即可：

单独抽象保存的 default.toml 配置

虽然我们将 90% 的内容都迁移到了 compose 配置文件中，但是还是有一些内容暂时是不好进行重写的，比如下面提到的“内容Gzip压缩”和“HTTP转发HTTPS”：

这里倒不是说不能够在应用内配置，而是如果这两个中间件在应用内配置，会出现每个应用都需要配置重复配置的问题。尽管独立的配置会让应用的可迁移性更好，然而这份配置可以提供不论是在本地、私有云，还是公有云 SLB 环境下的一致行为，维护一份配置，总比维护几份要来的方便，不是吗？

完整的容器配置

一如既往，这里给出完整的 compose 配置：

最后

官方在前一阵推出了 https://traefik.io/traefik-pilot/，除了作为统一的管理中心之外，还提供了许多有用的中间件，比如请求/响应头改写、IP 禁止名单、IP地址转换、fail2ban 等等。

因为暂时官方无意将 pilot 开源（可能也会是长期状况），如果你不介意“联公网”使用，可以试试注册 pilot 使用。

–EOF