Traefik a Reverse Proxy/Load Balancer
Traefik is an open-source Edge Router that is made to deploy services with ease. It is brilliant enough to request on behalf of your system and for finding which components are responsible for handling those requests.
This is a 4 series blog where PART1 includes Introduction to Traefik with key Concepts and Configuration. Part2, Part3, and Part4 are to follow.
In its essence, it is a dynamic reverse proxy written in the Go language.
But before exploring how Traefik works and handles the requests, let’s first take an idea about what exactly the terms edge router and reverse proxy mean.
EDGE ROUTER:
A router basically is something that gives routes to your data as per your definitions whereas edge routers are special network devices that resides at the boundary of a network (acting as a gateway) ensuring that your network is connected with an external network and the data traffic flows according to the rules defined.
Traefik as an Edge Router acts as a door to your platform intercepting and routing every incoming request: it knows all the logic and every rule that determine which services handle which requests (based on the path, the host, headers, and so on …).
REVERSE PROXY/LOAD BALANCER
A reverse proxy is a server that sits in front of web servers and forwards client (e.g. web browser) requests to those web servers. They provide a layer of security and reliability over our web servers meanwhile also increasing the performance of the requests served by our web servers.
It acts as a filter and barrier for our servers deciding which requests to be allowed to pass to the servers and which are to be filtered as discarded. Most reverse proxies also have the ability to load balance the requests distributing the incoming traffic according to the defined load balancing algorithm/strategy.
Traefik integrates with your existing infrastructure components (Docker, Swarm mode, Kubernetes, Marathon, Consul, Etcd, Rancher, Amazon ECS, …) and configures itself automatically and dynamically. Pointing Traefik at your orchestrator should be the only configuration step you need. It is as simple as that.
AUTO SERVICE DISCOVERY
Another major concept of Traefik is Auto Service Discovery. Now a question might have popped in your mind that what exactly do we mean here and how does Traefik achieve it?
Service discovery aims to reduce the configuration efforts required by users and administrators. It requires a configuration file where all the services which are to be integrated are mentioned. Their configuration parameters are represented in a key-value pair making it much easier to understand and manage.
Traefik goes a level above that by implementing the concept of auto service discovery where we don’t need to have a separate configuration file for any service like Docker, Kubernetes, Rancher, etc instead Traefik gets them from the services themselves. In order to achieve that, we just need to mention the provider in the traefik.toml configuration file.
Configuration in Traefik :
Configuration in Traefik is available in 2 ways :
- Dynamic Routing Configuration.
- Static Startup Configuration.
Static configuration is used to define entry points (where to connect) and Providers (Which service is connected) whereas the Dynamic configuration is used to define how the requests of the incoming traffic are going to be handled.
Traefik needs a configuration file to start naming traefik.toml or traefik.yaml. It follows an order of directories searching for the config file. The orderlies as:
Static Configuration:
There are 3 ways to define static configuration in Traefik but all of them are mutually exclusive i.e., only one of them can be used at a time.
- Configuration file.
- CMD arguments.
- Environment Variables.
Their priority is the same as they are stated.
Dynamic Configuration:
Traefik gets its dynamic configuration from providers: whether an orchestrator, a service registry or a plain old configuration file. For example,
Traefik is an edge router that reduces the overhead of maintaining separate configuration files for different providers in the market. It does act as a layer that routes traffic and acts a one-shot access point for the infrastructure below.
The next part of this series will continue with the magic of Traefik. We’ll talk in detail about its architecture and its installation, both on microservices as well as standalone, and a neat bonus link for its ansible role. Till then Ciao!
Originally published at http://blog.opstree.com on September 28, 2021
