Caddy-incus-upstreams: routing based on incus config

1

I wrote a Caddy plugin that can automagically route to Incus instances based on user config settings :nerd_face: This is inspired by the likes of Traefik (amongst others) and Docker label handling. I’ve not tested it a lot but the first localhost tests are working out nicely! Please feel free to give it a shot, I’d love to hear if it works for you. Patches always welcome!

decentral1se/caddy-incus-upstreams: Incus dynamic upstreams for Caddy v2+ 🧨 - caddy-incus-upstreams - Co-op Cloud Code

7 Likes
2

Cool! Does this work with the wildcards?

*.your-subdomain.example.com {
  reverse_proxy {
    dynamic incus
  }
}
3

I’d love to know myself @Tetrov if you get time to test :upside_down_face:

1 Like
4

@Tetrov ended up diving in, it works! You just need to follow the DNS plugin route (described here How to use DNS provider modules in Caddy 2 - Wiki - Caddy Community) due to that being the main way most providers support issuing wildcard certificates. In general, my code seems to behave well so far and not interfere with the usual Caddy feature set, so that’s good :upside_down_face:

2 Likes
5

SWEET! I was going to start on this soon, I’m glad you did it!

1 Like
6

Can this run from within a instance/container on a incus cluster? What would be need to have this work in a container?

7

I have no idea @slefevre but I am willing to review / merge / help along any changes you need to make it work. I imagine nobody tried yet! If you give it a shot, let us know :relieved:

8

You could try proxying the Incus host’s Incus socket into the container:

$ grep incus-admin /etc/group
incus-admin:x:<ID of group incus-admin>:

$ incus config device add <container-name> incus-socket proxy connect=unix:/var/lib/incus/unix.socket listen=unix:/var/lib/incus/unix.socket bind=container uid=0 gid=<ID of group incus-admin> mode=0660 security.uid=65534 security.gid=99

Afterwards install incus-client (from the Zabbly repos if you’re on Debian/Ubuntu) inside the container. Then the container is able to communicate with the host’s Incus socket directly. This should translate to caddy-incus-upstreams behaving as if it’s running on the Incus host directly, too. At least that’s what I’m getting from looking at its code.