garethgeorge / backrest

Backrest is a web UI and orchestrator for restic backup.
GNU General Public License v3.0
787 stars 31 forks source link

Issue starting Backrest in Kubernetes without specifying BACKREST_PORT #323

Closed alexander-bauer closed 3 weeks ago

alexander-bauer commented 3 weeks ago

Describe the bug When starting Backrest under Kubernetes without specifying BACKREST_PORT, the default value seems to be tcp://${detected_ip}:9898, which raises an error too many colons in address. Overriding the environment to 0.0.0.0:9898 fixes it.

To Reproduce Steps to reproduce the behavior:

I'm not entirely sure how best to reproduce this. I can share my sanitized Kubernetes manifests if necessary, but I suspect this is an unexpectedly-formatted value coming out of the logic to pick the default bind address.

Expected behavior A clear and concise description of what you expected to happen.

I expected Backrest to automatically bind to 0.0.0.0:9898, rather than crashing on startup.

Screenshots If applicable, add screenshots to help explain your problem.

No screenshot, but here are pod logs:

 ⇒  kubectl -n backrest logs deployments/backrest  -f
2024-06-05T18:35:34.152Z        INFO    generating new auth secret
2024-06-05T18:35:34.156Z        INFO    applying oplog migration        {"migration_no": 0}
2024-06-05T18:35:34.156Z        INFO    applying oplog migration        {"migration_no": 1}
2024-06-05T18:35:34.156Z        INFO    applying oplog migration        {"migration_no": 2}
2024-06-05T18:35:34.165Z        DEBUG   scanning oplog for incomplete operations
2024-06-05T18:35:34.170Z        DEBUG   scan complete   {"duration": "4.343739ms"}
2024-06-05T18:35:34.170Z        INFO    scheduling default tasks, waiting for task queue reset.
2024-06-05T18:35:34.170Z        INFO    reset task queue, scheduling new task set.
2024-06-05T18:35:34.170Z        INFO    scheduling task {"task": "collect garbage", "runAt": "2024-06-05T18:36:34Z"}
2024-06-05T18:35:34.170Z        INFO    orchestrator created
2024-06-05T18:35:34.170Z        INFO    starting orchestrator loop
2024-06-05T18:35:34.170Z        INFO    starting web server tcp://10.43.179.52:9898
2024-06-05T18:35:34.170Z        ERROR   error starting server   {"error": "listen tcp: address tcp://10.43.179.52:9898: too many colons in address"}

Platform Info

Additional context Add any other context about the problem here.

Based on the log message, the incorrect-seeming value appears by this line, and is set by the BindAddress() function in env (definition).

It seems likely to me that I'm in the case which returns ":9898", so I'm not sure where the "tcp://${ip}:9898" value is coming from.

garethgeorge commented 3 weeks ago

Hmm, sorry you're running into trouble here -- I suspect this is a configuration issue since backrest has no special handling of kubernetes and you're right that the default is always :9898 unless there is an env variable set that's overriding it.

But I have some familarity with kubernetes though I've not actually tried running backrest on it, some debugging ideas --

I assume you must have a service / pod definition that you put together? Are you sure an environment variable isn't being overridden somewhere? Perhaps you can try checking the output of kubectl describe pod <your backrest pod> to see what the env / configuration looks like?

alexander-bauer commented 3 weeks ago

So, I've just spent some time trying to marshal up a working example to reproduce the behavior I saw yesterday, and I can't seem to. In a new namespace, I put together a deployment resembling the one I had yesterday, and it worked as expected this time. I definitely did something that led to this behavior, but whatever it is, I can't seem to find it. I'll attach my (working) minimal example in case it helps anyone else stumbling on this issue in the future, but in any case, it seems like my problem was between my keyboard and chair.

Thanks for this great project! deployment.yaml.txt