Ensure some commands are executed only when a service is up is a common need of
docker-compose or even
Kubernetes when using some container to setup some state. If you can use
wget, it has almost this feature built-in.
For a HTTP backend, awaiting it is ready – most of the time its healthcheck too – is often testing a resource returns a HTTP 200 (can be a version endpoint, an asset or whatever simple and not writing anything).
There are a ton of
curl based script doing some
while loops to solve that, even some custom
node scripts but if you have
wget if you base image, it is actually quite trivial since
wget supports retries:
wget \ --no-check-certificate \ (1) --read-timeout=30 --timeout=30 \ (2) --retry-connrefused \ (3) --waitretry=5 \ (4) --tries=60 \ (5) "https://$MY_SERVICE_HOST:$MY_SERVICE_PORT/some/resource" (6)
|1||(optional) ignore SSL errors, depends your environment,|
|2||the common request timeouts, just ensure to fail if it hangs,|
|3||consider a connect refused as a retryable case,|
|4||wait 5s before retrying again – depends how fast/slow is your backend,|
|5||retry max 60 times (so 5 minutes max with the wait configuration),|
|6||the test endpoint configured using Kubernetes service environment variables (for a |
Adding this kind of
wget at the beginning of a script or custom
entrypoint.sh enables to ensure some dependency are available or at least await for them a few before giving up. The big advantage compared to what we find on the net is that it does not need any shell knowledge with loops or whatever to implement it which is always a concern in a team but the assumption you have
wget in the base image is required.
curlhas similar option if you have a recent enough version:curl \ --connect-timeout 30 --max-time 30 \ --retry-connrefused \ --retry-all-errors \ --retry 60 \ --retry-delay 5 \ --retry-max-time 300 \ "https://$MY_SERVICE_HOST:$MY_SERVICE_PORT/some/resource"
if you need a compatible debian based image you can use