Shortcut for hostnames in local domain

[sinopsysHK]

Allow to label a container with

--label caddy="@(myservice)"

which will translate to reverse proxy to "myservice" and "myservice." where local domain is provided as config parameter.

This is a very naive implementation as this is my first try of GO so do not hesitate to comment on the implementation and I'll try to improve.

I made an attempt to rather use GO template but this creates too much burden.

Tentative implementation for #652

[francislavoie]

I don't understand the motivation or goal here. I'm confused. This needs more explanation.

Also using syntax like this is risky because there's no guarantee Caddy may use the same kind of syntax in the future for something else. In fact, technically @(whatever) is a valid named matcher token right now (see https://caddyserver.com/docs/caddyfile/matchers#named-matchers)

[sinopsysHK]

Hello,Motivation is to be able to easily reach all my web services hosted on my server with docker in a convenient way in my LAN within my private domain (no public exposure) by accessing them through a short and user friendly name rather than through a port number.And to make it even more convenient I want to be able to request my web apps without having to key in every time the full FQDN address but of course FQDN should work as well.I was relying so far on a url shortener to achieve something close to what I described but this workaround has limitations (confusing password safe that do not support properly urls with non standard ports).To achieve that with existing features of caddy (same issue with the alternate reverse proxies) I would have to register manually the 2 addresses for every web app I have such as:—label caddy=“webapp webapp.mydomain“Note: double registration is made mandatory once willing to use auto https (2 certificates are to be created).So I am looking for something more compact that would avoid to repeat things and reduce the dependencies between containers and the topology of my network.I’m happy to consider alternate syntax and agree that @() might be the most suitable if conflicting with existing one (sorry I am new adopter of caddy): any suggestion?On 19 Aug 2024, at 11:37 PM, Francis Lavoie @.***> wrote: I don't understand the motivation or goal here. I'm confused. This needs more explanation. Also using syntax like this is risky because there's no guarantee Caddy may use the same kind of syntax in the future for something else. In fact, technically @(whatever) is a valid named matcher token right now (see https://caddyserver.com/docs/caddyfile/matchers#named-matchers)

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[lucaslorentz]

I think the same can already be achieved with CADDY env variables. See https://caddyserver.com/docs/caddyfile-tutorial#environment-variables Use label:

--label caddy="{$SITE_ADDRESS}"

You might need some escapes though. And setting SITE_ADDRESS as an ENV variable in caddy container.

[sinopsysHK]

well variable substitution will only achieve one part: decoupling a bit network topology with container but it will not avoid repeatingexport LOCAL_DOMAIN=myprivatedomaine.localSet for portainer:—label caddy=“portainer portainer.{$LOCAL_DOMAIN}”Set for Bitwarden:—label caddy=“bitwarden bitwarden.{$LOCAL_DOMAIN}”On 22 Aug 2024, at 2:40 AM, Lucas Lorentz @.***> wrote: I think the same can probably be achieved with CADDY env variables. See https://caddyserver.com/docs/caddyfile-tutorial#environment-variables Use label: --label caddy="{$SITE_ADDRESS}"

You might need some escapes though. And setting SITE_ADDRESS as an ENV variable in caddy container.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[lucaslorentz]

@sinopsysHK Thanks for the attempt to implement this.

Your current implementation is complex for such a niche feature. If we simplify it a bit, it might be more interesting for the project to support it.

I agree with @francislavoie, I would rather not define a new special syntax like @(whatever).

You mentioned problems using templates, could you please clarify what problems you had with it?

We already process go templates on all labels, it is already in place. Probably all you need to do is to add another function here: https://github.com/lucaslorentz/caddy-docker-proxy/blob/master/generator/labels.go#L15

If you create a function called createDomain, that expects 1 string parameter that will be the domain prefix, then concatenate the prefix with the suffix defined in an ENV variable. You would be able to configure your containers with --label 'caddy={{createDomain "myservice"}}'

[lucaslorentz]

Or, an even more flexible alternative would be to create a function that returns any env variable content and use it as:

--label 'caddy=myservice.{{env \"LOCALDOMAIN\"}}'

I know it's not the best syntax for your use case, but it is a feature that is more likely to be used by others.

[sinopsysHK]

This is the first solution I tried and I felt notation was a bit too heavy because to set the expected prefix as a parameter of the expected function it has to be either a string literal either a variable. As a consequence prefix has to be surrounded with double quotes which might requires extra escaping when used with docker cli.

All together something like —label caddy=‘{{createDomain “myservice”}}’ or —label caddy=“{{createDomain \“myservice\”}}” appeared to be a bit wordy.

But I understand that there is a trade off to find between lightness and consistency. Let me backtrack to the template based approach…

[sinopsysHK]

Ok I backtracked the implem to revert on the template based approach.

I used config to hold the Local Domain rather than an env variable to bring more control over it

[polarathene]

Motivation is to be able to easily reach all my web services hosted on my server with docker in a convenient way in my LAN within my private domain (no public exposure) by accessing them through a short and user friendly name rather than through a port number.

And to make it even more convenient I want to be able to request my web apps without having to key in every time the full FQDN address but of course FQDN should work as well.

This is XY problem. Your interest is only in short URL for navigation reasons.

You instead want separate service like Homepage (links to Docker label service discovery feature). That will provide you single page you visit with all your services available to navigate to.

Caddy / CDP will handle the actual routing from there and you don't have to think about ports in URL.

For any other needs with containers connecting to each other directly, you can use the Docker networks embedded DNS like you would with reverse_proxy directive in Caddy.

---

I don't understand the value this PR is trying to bring to CDP. It doesn't seem necessary or in high demand?

[sinopsysHK]

If my motivation is a XY problem, your proposal is a workaround.

I came with a comprehensive user story and proposed an implementation for it.

Happy to rework if the implementation do not follow caddy coding standard or if convention isn't consistent with CDP.

Then your call to take this feature or not.

As commented in another thread CDP and caddy could be seen also as an alternate solution to suggested homepage which also avoids the need to recall each service port number.

[polarathene]

For context, PR was closed as there are valid alternatives that can be used for the functionality they were seeking.

The alternative solutions are covered at the associated issue: https://github.com/lucaslorentz/caddy-docker-proxy/issues/652#issuecomment-2322727435