3 ms·

Does this handle a host reboot?

• francislavoie 2y ago
  In theory it should, because they do health checking to track status of the upstreams. The upstream server being down would be a failed TCP connection which would fail the health check. Obviously, rebooting the machine the proxy is running on is trickier though. I don't feel confident they've done enough to properly support having multiple proxy instances running side by side (no shared storage mechanism for TLS certs at least), which would allow upgrading one at a time and using a router/firewall/DNS in front of it to route to both normally, then switch it to one at a time while doing maintenance to reboot them, and back to both during normal operations.
  • chipdart 2y ago
    > In theory it should, because they do health checking to track status of the upstreams. I think the PR that pushes this kamal-proxy project explicitly removes supports for healthchecks? So it's unclear. In theory, a reverse proxy like Traefik supports this feature. In practice it does too. So I don't know. It seems there's some rationale that's definitely missing from the whole story. I doubt people haphazardly decide to roll out a custom reverse proxy developed in-house. The reasons laid out in the doc definitely don't seem to be it.
    • francislavoie 2y ago
      I'm looking here https://github.com/basecamp/kamal-proxy/tree/main/internal/server https://github.com/basecamp/kamal-proxy/tree/main/internal/s... which is the code for their v2 proxy. Notice there's a health_check.go which makes requests in a goroutine and sets the health to true/false based on the HTTP status, via a consumer interface. As I said elsewhere in this topic, this is all too basic IMO, (disclaimer: I'm a Caddy maintainer) Caddy does this all in a more robust way.