Loadbalancing with Caddy #

What does Caddy do? #

Caddy is a new feature and is currently tested with a few select customers. Please get in touch if you're interested in using it.

When you get a cluster from us, we give you the ability to use Caddy as an ingress router on Docker nodes.

Usage #

Make sure the service is attached to the public network to be able to use the service labels to configure how Caddy should serve traffic to it.

See the following example to get started:

version: '3.8'

services:
  example:
    image: wordpress
    networks:
      - public
    deploy:
      labels:
        caddy: wordpress.example.org
        caddy.reverse_proxy: "{{upstreams 80}}"

networks:
  public:
    external: true
    name: public

Advanced Usage #

As mentioned in the intro, Caddy can do a lot more. And you can do everything using labels. If, however, labels are not your domain, you can also look into customizing the Caddy image instead.

The following examples show you how the labels can be used. As a rule of thumb: you can build almost anything with the available directives from the official Caddy documentation.

Multiple Domains per Service #

This example also showcases segments:

deploy:
  labels:
    caddy_0: wordpress.example.org
    caddy_0.reverse_proxy: "{{upstreams 80}}"
    caddy_1: wordpress-new.example.org
    caddy_1.reverse_proxy: "{{upstreams 80}}"

Path prefixes #

When the public URL needs to be re-written from /blog/... to /:

deploy:
  labels:
    caddy: www.example.org
    caddy.handle_path: "/blog/*"
    caddy.handle_path.0_reverse_proxy: "{{upstreams 80}}"

When the service listens to /gatsby, but is available under /wordpress:

deploy:
  labels:
    caddy: www.example.org
    caddy.handle_path: "/wordpress/*"
    caddy.handle_path.0_rewrite: "* /gatsby{uri}"
    caddy.handle_path.1_reverse_proxy: "{{upstreams 80}}"