Announcing Traefik Proxy 2.7 | Traefik Labs

Blog
1

We are thrilled to announce the release of Traefik Proxy 2.7. This version carries an array of brand-new features, including service failover support and an SNI regex matcher for TCP routers. Keep reading to learn more about the new features and key improvements in the latest version of our cloud native application proxy.

Application Service Failover

In such an uncertain world, you can never predict a stroke of ill luck. At any moment, a natural disaster can put a crucial data center out of commission, or a cyberattack can flood your servers and lock you out of your files. In mundane circumstances too, your main servers can experience outages for any or no particular reason. Backup plans are always a good idea, but they are essential for those designing distributed applications.

Application Service Failover is a brand new feature in Traefik Proxy 2.7. It was requested by the open source community as well as by some of our customers. This functionality has a use case that is practical for all but often required by enterprise users running business-critical applications at scale.

Application Service Failover allows you to maintain backup services. If something goes wrong in your application, you have nothing to worry about as a replica of your application is running elsewhere. All you have to do is toggle a switch, and your traffic will be quickly redirected to the backup services. Keep in mind that application service failover is neither mandatory nor enabled by default. You have to set it up yourself.

Traefik Proxy 2.7 makes sure your active main service is constantly monitored and, if there’s ever a failure, your requests are automatically switched over to the backup service. The example below shows Traefik Proxy doing so.

## Dynamic configuration
http:
  services:
    app:
      failover:
        healthCheck: {}
        service: main
        fallback: backup

main:
  loadBalancer:
    healthCheck:
      path: /status
      interval: 10s
      timeout: 3s
    servers:
    - url: "http://private-ip-server-1/"
    - url: "http://private-ip-server-2/"

backup:
  loadBalancer:
    healthCheck:
      path: /status
      interval: 10s
      timeout: 3s
    servers:
    - url: "http://private-ip-server-3/"

Application Service Failover is implemented at the service level, meaning it can be referenced by routers. As such, you can mix and match it with existing deployment strategies, such as round robin and weighted round robin load balancing. In the example below, Traefik Proxy integrates Application Service Failover with a weighted round robin.

## Dynamic configuration
http:
  services:
    app-fallback:
      failover:
        healthCheck: {}
        service: app-main-region
        fallback: app-region-c

app-main-region:
  weighted:
    services:
    - name: app-region-a
      weight: 3
    - name: app-region-b
      weight: 1
   
app-region-a:
  loadBalancer:
    healthCheck:
      path: /status
      interval: 10s
      timeout: 3s
    servers:
    - url: "http://private-ip-server-a1/"
    - url: "http://private-ip-server-a2/"

app-region-b:
  loadBalancer:
    healthCheck:
      path: /status
      interval: 10s
      timeout: 3s
    servers:
    - url: "http://private-ip-server-b1/"
    - url: "http://private-ip-server-b2/"

app-region-c:
  loadBalancer:
    healthCheck:
      path: /status
      interval: 10s
      timeout: 3s
    servers:
    - url: "http://private-ip-server-c1/"

In both of these scenarios, an application is deployed in two separate center regions that together make up the main production workload. There is the main region and then a backup region that runs the same application stack but on slower servers and with increased latency. The backup region exists to prevent the application from failing if there is ever a disaster, and it should only be activated if there are no functioning servers in the main region.

Distributed applications can be more resilient — when the network is powerful enough for users to transfer traffic quickly and seamlessly between regions; application Service Failover helps.

TCP Routing Rules

Traefik Proxy 2.7 brings several additions to existing TCP routing rules. It overhauls the TCP multiplexer (muxer or mux for short), which is the piece of software responsible for selecting which service should handle which incoming request, based on configured routing rules.

In Traefik Proxy, the default rule for TCP routing has been to match incoming TCP requests with the hostSNI, or the alias of the server you are trying to reach. You specify the domain name, and your requests are matched to that single domain. While this option works excellently if you run one TCP service behind each subdomain, it has its limits for use cases when multiple TCP services are running behind a single domain (you must route all traffic to a specific port and expose one port per service). Traefik Proxy expands on the existing TCP routing rules to bring you two new matchers: Client IP and hostSNI with regex support.

Client IP Matcher

With Traefik Proxy 2.7, you can match requests to the client’s incoming IP/CIDR address. This is useful in internal networks, as it allows you to limit what a range of IP addresses can access. Here is an example of a matching target hostname and source client address:

## Dynamic configuration
tcp:
  routers:
    app:
      rule: HostSNI(`example.org`) && ClientIP(`10.10.10.10`)

HostSNI with regex

The Server Name Identification (SNI), commonly referred to as the hostname, is an extension to the SSL standard that allows the client to specify the name of the resource it’s looking for in a connection.

Previously in TCP routers, it was only allowed to match against a single server name identification or to match any server name, by using the special wildcard sign.

Traefik Proxy 2.7 introduces support for regular expressions in a new TCP matcher, allowing for more broad and dynamic matching rules. Instead of targeting a single subdomain for your TCP application, you can run regular expressions that you match requests to. For example, you can mention multiple subdomains that will all be redirected to a TCP application.

Below is an example showcasing any subdomain of a base domain name accepting traffic.

## Dynamic configuration
tcp:
  routers:
    app:
      rule: HostSNIRegexp(`{subdomain:[a-z]+}.example.com`)

Next steps

There’s still more to learn about Traefik Proxy 2.7, so be sure to check out the release notes. For more information, check out our documentation pages or visit the Forum to explore all the latest community topics.

As always, we are super grateful to our community of users, contributors, and maintainers! Traefik Proxy would not be what it is today without your ongoing feedback and support.

In particular, we would like to highlight a few community members for their stellar contributions to Traefik Proxy 2.7. Thank you Jason Wang for enhancing the Consul Catalog provider, Sylvain Rabot for bumping the HTTP3 library to the latest version, Dmitry Sharshakob for adding support for InfluxDB v2 metrics, Richard Kojedzinsky for enhancing the configuration reload mechanism, and Tchoupinax for improving the UI on the router detail page. You are all superheroes.

What’s next? There will be many future releases of Traefik Proxy that will bring you even more integrations. Stay tuned.

This is a companion discussion topic for the original entry at https://traefik.io/blog/announcing-traefik-proxy-2-7/