Integrating Traefik for Reverse Proxy and SSL Management

Working on my project, I encountered the need for a reverse proxy solution. Initially, we used Nginx, but faced challenges in organizing the process for certificate generation. At the early stage of the project, we couldn't afford to spend time on development and needed a ready-to-use solution for working with Let's Encrypt or other providers. That's when I decided to explore Traefik as an alternative to Nginx. In this article, I will share my experience integrating Traefik into my project and discuss how it met the requirements for a reverse proxy and SSL certificate management.

Why Traefik

My project required reverse proxy functionality with automatic generation and maintenance of SSL certificates for various types of domains, including regular and wildcard domains. These domains could be created automatically, so it was crucial to have a quick and straightforward generation process. Traefik fully met these requirements.

Docker Compose Setup

To give you an idea of how Traefik was configured, here is a sample of the docker-compose.yml and frontend.yml files (with sensitive information replaced with placeholders):

# docker-compose.yml
 
services:
  traefik:
    image: traefik:v2.9
    hostname: traefik
    container_name: traefik
    command:
      - --log.level=DEBUG
      - --providers.file.directory=/configs
      - --providers.file.watch=true
      # Set up Let's Encrypt with HTTP challenge
      - --certificatesResolvers.myresolver.acme.email=myemail@example.com
      - --certificatesresolvers.myresolver.acme.httpchallenge=true
      - --certificatesresolvers.myresolver.acme.httpchallenge.entrypoint=web
      - --certificatesResolvers.myresolver.acme.storage=/letsencrypt/acme.json
      # Set up Let's Encrypt with DNS challenge
      - --certificatesresolvers.wildcard.acme.dnschallenge=true
      - --certificatesresolvers.wildcard.acme.dnschallenge.provider=cloudflare
      - --certificatesresolvers.wildcard.acme.email=admin@example.com
      - --certificatesresolvers.wildcard.acme.storage=/letsencrypt/acme.json
      # HTTPS redirection
      - --entryPoints.web.address=:80
      - --entryPoints.web.http.redirections.entryPoint.to=websecure
      - --entryPoints.web.http.redirections.entryPoint.scheme=https
      - --entryPoints.websecure.address=:443
    environment:
      - CF_DNS_API_TOKEN=placeholder_token
    ports:
      - 80:80
      - 443:443
    volumes:
      - letsencrypt:/letsencrypt
      - ./data/traefik:/configs
    networks:
      - mynetwork
 
networks:
  mynetwork:
 
volumes:
  letsencrypt:

# frontend.yml
 
http:
  routers:
    myapp:
      rule: "HostRegexp(`example.com`, `{subdomain:[a-z]+}.example.com`)"
      priority: 1
      service: frontend
      middlewares:
        - removeHost
      tls:
        certResolver: "wildcard"
        domains:
          - main: "example.com"
            sans:
              - "*.example.com"
 
    my-app:
      rule: "Host(`my.example.com`)"
      priority: 2
      service: office
      tls:
        certResolver: "myresolver"
        domains:
          - main: "my.example.com"
 
  middlewares:
    removeHost:
      headers:
        customRequestHeaders:
          X-Forwarded-Host: ""
 
  services:
    frontend:
      loadBalancer:
        servers:
          - url: "http://frontend:53000/"
    office:
      loadBalancer:
        servers:
          - url: "http://office:53001/"

SSL with Let's Encrypt

In the provided configuration, two different certResolvers are used for SSL certificate management. The first certResolver, "wildcard," is configured for DNS challenge and allows for the issuance of wildcard certificates. The second certResolver, "myresolver," operates with HTTP challenge and is used for generating certificates for domains that do not require wildcard certificates.

The DNS challenge is used for issuing wildcard certificates. It requires the client to prove ownership of the domain by creating a specific DNS record. This method is suitable when you need to secure multiple subdomains with a single certificate (e.g., *.example.com). The configuration for the "wildcard" certResolver specifies the DNS challenge, the DNS provider (Cloudflare in this case), and the storage location for the certificates.

On the other hand, the HTTP challenge is a simpler method that requires the client to prove ownership of the domain by serving a specific file at a specific URL on the domain. It is suitable for securing individual domains and subdomains without the need for a wildcard certificate. In the configuration for the "myresolver" certResolver, the HTTP challenge and storage location for the certificates are specified.

Summary

In summary, Traefik proved to be a valuable tool in my project, providing a seamless reverse proxy solution and SSL certificate management. Depending on your project's needs, you can choose the appropriate certResolver and challenge method for managing SSL certificates. I hope my experience and the provided code samples can help others looking for a similar solution.

Anvar Khakimov — Product and engineering leader, 15+ years from developer to IT lead. Building JMP and writing about technology, management, and AI.