I guess the value of this is to encapsulate away various other command-line tools which could perform the same in a script. Lowers the barrier to entry. To my mind, though, this tries hard to tackle a solved problem.
On the other hand -- if it encourages dev teams to stop the silly habit of returning successful health checks from their microservices even before the back-end dependencies (DBs, other web services, etc) are ready, then it might have some value.
> if it encourages dev teams to stop the silly habit of returning successful health checks from their microservices even before the back-end dependencies (DBs, other web services, etc) are ready, then it might have some value
Deciding what starts when shouldn't live inside the things themselves. They should be able to start independently and react accordingly if their dependencies aren't met.
Two reasons:
Dependencies can vanish anyway, once everything's started, so it's silly to special-case starting a microservice.
Microservices can need to behave differently depending on the deployment situation, so you don't want to bake into them a single way of doing things.
I found this a few months ago and use it for something totally unrelated to containers -- namely on my Tailnet I have machines on my home LAN which I want to connect to even though they are asleep. I haven't been bothered to learn whether I can set up Wake on Lan requests triggered from my router to get them to wake up on demand even when I'm not on the actual LAN, so instead, when I want to connect to them, I use wait4x with a TCP connection to wait till the machine wakes itself up momentarily every few minutes, and then finally run what I want (which is usually either git pull or sshing into the machine).
In addition to the other problems identified by other people here (e.g. account authentication information passed on the command line) the DNS readiness check is counter productive, as negative response caching caused by the very polling that the tool does will obscure the resource record's appearance, and the file existence check is a brute force mechanism that (a) spawns an entire subprocess instead of doing lstat() and (b) does not take advantage of any kqueue() or equivalent mechanism for waiting for filesystem changes.
So the elevator pitch for this is "if wait-for [1] isn't sufficient and you want a go lang binary to evaluate the behavior or response of the request"?
I however suspect that I wouldn't use it, if I was still working in devops. The niche where a simple wait for the port is insufficient is _extremely_ rare in practice... Because almost everything that needs such either already has the concept of a readiness check to make it available (k8s, LBs, etc) or will retry automatically given the port being open (DB connections etc)
Danger: passwords on the command-line are a big no-no! That should probably be removed from examples, possibly adding a way to do it using environment or files.
***
It's amazing how much work people will go through to avoid using systemd.
I guess this is useful for portability to non-Linux though.
I guess the value of this is to encapsulate away various other command-line tools which could perform the same in a script. Lowers the barrier to entry. To my mind, though, this tries hard to tackle a solved problem.
On the other hand -- if it encourages dev teams to stop the silly habit of returning successful health checks from their microservices even before the back-end dependencies (DBs, other web services, etc) are ready, then it might have some value.
> if it encourages dev teams to stop the silly habit of returning successful health checks from their microservices even before the back-end dependencies (DBs, other web services, etc) are ready, then it might have some value
Deciding what starts when shouldn't live inside the things themselves. They should be able to start independently and react accordingly if their dependencies aren't met.
Two reasons:
Dependencies can vanish anyway, once everything's started, so it's silly to special-case starting a microservice.
Microservices can need to behave differently depending on the deployment situation, so you don't want to bake into them a single way of doing things.
I found this a few months ago and use it for something totally unrelated to containers -- namely on my Tailnet I have machines on my home LAN which I want to connect to even though they are asleep. I haven't been bothered to learn whether I can set up Wake on Lan requests triggered from my router to get them to wake up on demand even when I'm not on the actual LAN, so instead, when I want to connect to them, I use wait4x with a TCP connection to wait till the machine wakes itself up momentarily every few minutes, and then finally run what I want (which is usually either git pull or sshing into the machine).
In addition to the other problems identified by other people here (e.g. account authentication information passed on the command line) the DNS readiness check is counter productive, as negative response caching caused by the very polling that the tool does will obscure the resource record's appearance, and the file existence check is a brute force mechanism that (a) spawns an entire subprocess instead of doing lstat() and (b) does not take advantage of any kqueue() or equivalent mechanism for waiting for filesystem changes.
So the elevator pitch for this is "if wait-for [1] isn't sufficient and you want a go lang binary to evaluate the behavior or response of the request"?
https://github.com/vishnubob/wait-for-it
I however suspect that I wouldn't use it, if I was still working in devops. The niche where a simple wait for the port is insufficient is _extremely_ rare in practice... Because almost everything that needs such either already has the concept of a readiness check to make it available (k8s, LBs, etc) or will retry automatically given the port being open (DB connections etc)
If you're using docker you can use https://github.com/jwilder/dockerize
Worked great last time I used it. Has more features than just waiting for a port too.
Cool but isn’t this something we can already do programmatically with more flexibility?
Danger: passwords on the command-line are a big no-no! That should probably be removed from examples, possibly adding a way to do it using environment or files.
***
It's amazing how much work people will go through to avoid using systemd.
I guess this is useful for portability to non-Linux though.
this brings me back some inetd/xinetd memories.