New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support passing FDs (socket activation) #6296
Comments
Are you looking for the And see https://caddyserver.com/docs/conventions#network-addresses, you can use unix sockets in I'm not sure what you're asking for if not that. |
It sounds like what is being asked for is graceful upgrades/restarts. Caddy 1 had this feature, and I quite liked how it worked: pass the socket directly to the next process. It worked on all Unix systems without relying on a separate system service, and it was smart enough to understand Caddy configuration: if the new config didn't use a socket, it wouldn't be kept; rather than blindly moving all the sockets over. I'd probably rather bring the implementation from Caddy 1 into Caddy 2. |
No, getting this for free is only one side-effect of supporting socket-activation. socket-activation will also cause caddy to get started lazily whenever the first connection to the (externally configured) socket address happens, which simplifies declaring service dependencies too. The article linked from my link elaborates a bit more on this.
This still requires caddy to do manual coordination with its new process and pass it around explicitly. The point of simply taking the FDs passed by the service manager is that caddy does not have to be aware of whether it's the first process being started on the system, or you start a new version with another config. caddy simply gets an FD, where new connections will appear on. |
Ah yes, and because caddy just takes FDs, it doesn't need to |
But what is Caddy supposed to do with that socket? How does it know the configuration associated with it? You can't just hand a server a socket and expect it to know what to do with it, without any configuration... maybe I am missing something about how it works. |
Sockets can have names attached (so the user can name them All these passed FDs also give you a You can play around with this through |
Oh I see, so you'd still have your Caddy config, you'd just specify a different network name for the listener address, and Caddy will then get it from the service manager rather than binding a new socket. |
Yes! Or well, I don't want caddy to do any bind on its own at all, but pass in every socket via this mechanism. |
In that case you can use Anyone is welcome to pick this up. |
@mholt I did some experiments with registering custom network, it's too much trouble to be worth it. Every site block needs an explicit @flokli I'm thinking on unix, we can try preferring socket activation but fallback to the old behavior. What do you think of it? Or should caddy just exit unsuccessfully if socket activation environments variables are found but not sockets matching listening critertia are found? Or if some warning logs are emitted? As mentioned above, you are responsible to pass every socket yourself, including 80 tcp and 443 udp if auto http->https and http3 are enabled respectively. And admin socket if enabled as well. Assuming you restart caddy instead of reload it. |
I would really see it happen and it can greatly reduce my network stack complexity. flowchart TD
A[Caddy] -->|Reverse Proxy| B{Container Network}
B -->|Serve Frontend| C[Caddy]
C -->|Reverse Proxy| D[Server]
When |
I think ti makes sense to first land the feature with explicit configuration, which might mean explicit The good thing is, it's pretty safe to detect whether caddy is running in a socket-activated environment or not, so we are able to change defaults in this case, without breaking existing usecases. |
@flokli So that means you're fine with mixing passing FD and current binding behavior? And since you will use The problem with names is that one name can map to many sockets with different addresses, how do you think caddy handle this situation? |
Until this is implemented: for those that just care about binding to ports <1024 AND not running Caddy as root, can use systemd's SocketBindAllow= (available since systemd 249) |
There was never a need to run Caddy as root on Linux. Our standard systemd unit file is shipped with |
I'm aware of Giving the option to move the whole socket binding business entirely out of caddy is what I'm advocating for, both from a sandboxing (it doesn't need to be allowed to
Yes, I think the This would also mean, caddy would still bind on its own where we don't explicitly configure it to use the FD(s).
Indeed FileDescriptorName= describes such name applies to all sockets in that I think I'd be fine landing support for having to explicitly use |
@flokli You can try it with a plugin for now, |
I wrote a small go library to listen on socket activated fds. |
Interesting, this could be turned into a Caddy plugin by using |
I'd like to use caddy in a socket-activated environments, using FDs passed down from the service manager, rather than binding on addresses on its own.
Combined with signalling readyness (which caddy already does), this will give zero-downtime (re)deployments on Linux systems using systemd (if
.socket
files are used), by simply restarting the process - the socket is held open by systemd, and new connections are passed in once caddy is ready to accept new requests. In these cases, there wouldn't be a need for complicated reload logic anymore.github.com/coreos/go-systemd/activation
provides the necessary methods to check whether FDs are passed, including identifying them by their socket name. https://vincent.bernat.ch/en/blog/2018-systemd-golang-socket-activation gives a nice introduction into the feature itself.In case no explicit listen addresses are specified, caddy could default to do that rather than binding on its own, if it detects it's running in such an environment.
Additionally, Caddyfile could be extended to allow specifying these passed fds as network addresses (something like
sd-listen:$name
orsd-listen:$idx
maybe). This can become useful when you want to expose different things on different sockets.The text was updated successfully, but these errors were encountered: