Closed alexander-bauer closed 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?
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
Describe the bug When starting Backrest under Kubernetes without specifying
BACKREST_PORT
, the default value seems to betcp://${detected_ip}:9898
, which raises an errortoo many colons in address
. Overriding the environment to0.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:
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 inenv
(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.