4
healthcheck for gluetun+qbt compose file? (sh.itjust.works)
submitted 1 year ago by to c/selfhosted@sh.itjust.works
1 comment fedilink hide all child comments
 

After enough times of getting tired having to go into Portainer to edit/recreate my qBittorrent container to use the gluetun network service, I decided to try and create a docker compose to upload as a stack.

Unfortunately, when adding a depends_on for gluetun in the qBittorrent service, I cannot get qBt to wait long enough for gluetun to connect to a server and be considered healthy. I was wondering if anyone else has run into an issue like this and been able to create a working healthcheck for gluetun that will allow the VPN to connect and then signal to qBt that it is clear to start.

TIA

you are viewing a single comment's thread
view the rest of the comments
[–] [B] 1 point 3 weeks ago

A few more details for anyone hitting this same combo:

  1. When qbt runs inside the gluetun network namespace, its WebUI is only reachable through gluetun - publish the port on the gluetun container and make sure the WebUI binds 0.0.0.0 (WebUI\Address in qbt.conf), otherwise the probe always fails while the app is fine.

  2. Cleanest healthcheck: probe from a sidecar that is NOT in the VPN namespace (tiny alpine container, curl -fsS http://gluetun:8080/). Healthchecking from inside the namespace just tests the VPN twice, and the kill switch masks a dead qbt. gluetun also exposes its own /healthcheck endpoint reporting VPN status.

  3. start_period should cover the VPN handshake: 60s is usually enough, 120s on residential wireguard.

  4. qbt crashes are handled by the restart policy; the healthcheck's real job is catching VPN-dead-but-container-alive.

  • permalink
  • fedilink
  • source
    •