What?
If you run anubis (you should), esmero-web can be set to depend on it and on a fairly fast enough server that will be enough.
But, if your server is overloaded/slow to start then chances are that from time to time esmero-web will fail IF Anubis's container is UP but the service is not not yet available at the upstream unix port used by NGINX. And NGINX will not retry, it will just fail.
Its could be actually as simple as:
We add a health check for esmero-anubis
healthcheck:
test: ["CMD-SHELL", "something we call on the Anubis server to know its up and serving"]
interval: 10s
timeout: 5s
retries: 5
start_period: 30s
and then on esmero-web
depends_on:
anubis:
condition: service_healthy
Now, bc the anubis container is MINIMAL (and based on Golang, basically no other binary/service available)
we might need to use the existing healthchecker container (with a new service name) to call anubis externally and use that as dependency instead.
Will figure this out. Not a big deal, worst case scenario one restarts esmero-web but we had reports people depend on docker-compose up -d complete cycle and that is fine
What?
If you run
anubis(you should),esmero-webcan be set to depend on it and on a fairly fast enough server that will be enough.But, if your server is overloaded/slow to start then chances are that from time to time
esmero-webwill fail IF Anubis's container is UP but the service is not not yet available at the upstream unix port used by NGINX. And NGINX will not retry, it will just fail.Its could be actually as simple as:
We add a health check for
esmero-anubisand then on esmero-web
Now, bc the anubis container is MINIMAL (and based on Golang, basically no other binary/service available)
we might need to use the existing healthchecker container (with a new service name) to call anubis externally and use that as dependency instead.
Will figure this out. Not a big deal, worst case scenario one restarts esmero-web but we had reports people depend on
docker-compose up -dcomplete cycle and that is fine