Open mohammed90 opened 1 year ago
Previous to having this wrapper I stood up an ngrok agent in a docker container and pointed it at my caddy container. I still exposed my caddy port locally and would access the port on my local network when I didn't want to go out to the internet. That would be my usecase.
But after further thought I can just do the following couldn't I?
{
servers :80 {
listener_wrappers {
ngrok {
auth_token $NGROK_AUTH_TOKEN
tunnel http {
}
}
}
}
servers :8080 {
}
}
:80, :8080 {
root * /path/to/site/root
file_server
}
If that's the case then caddy already provides the solution to this and we likely don't need to do this.
That works too. However, I've been doing some thinking. Given the module is within listener_wrapper
, it might be a bit confusing for the user to have a Caddy network address that is never used. The multilistener
Go module makes sense here.
We can extend this repo by adding another module that makes use of Caddy's custom network registration to obtain only an ngrok listener for the given address. The address in this case an indicator of which ngrok tunnel to use. The code for that is as so:
An example configuration for such is:
What do you think?
[@jtszalay copying and moving to an issue for easier tracking 🙂]
Ignoring Caddy's listener just felt natural for the purpose of the module 😂
Intriguing! But I'm not sure whether users will naturally expect both listeners to work, because it's a "wrapper", or only ngrok's listener because it's ngrok. Do you think it's possible to have a toggle? You don't have to go the toggle route, I'm genuinely curious which way is better.
I don't personally use ngrok, even though I drafted this module, so I can't have a solid opinion on it. What do you think users expect?
Originally posted by @mohammed90 in https://github.com/mohammed90/caddy-ngrok-listener/pull/4#issuecomment-1472777212