经过一年多的实践,对于使用 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