deploy(docker): Add prestart endpoint to docker-entrypoint#900
Conversation
|
Q: Is it usual to do something like this? It seems quite excessive for something that I would expect to be handled outside of the container by orchestration. |
|
Kubernetes unfortunately doesn't currently support the concept of sidecars properly, so we're on our own here. There are some hacks (e.g. this one) but they are, well, hacks. The solution is not the prettiest, but supporting this in the entrypoint will also allow image users to reuse these patterns for self-hosted setups, if necessary. |
untitaker
left a comment
There was a problem hiding this comment.
If you're in the middle of trying things out and need this deployed, let's merge this for now
I would argue this should make RELAY_DELAY_STARTUP_SECONDS obsolete, and ideally we would bake this into the main healthcheck (i.e. relay checks upstream healthcheck as condition of own healthcheck) instead of writing shell wrappers
Did this to see how ugly it looks in the end.
This is a bit smarter hack to allow "service dependencies" when using image in environment like Kubernetes.
E.g. for PoP relays we want to make sure that the Relay container is started after Envoy sidecar is up and running, otherwise first auth requests to the upstream will just fail. They are retried, yes, but it doesn't make sense to even try them before Envoy is up.
By default, this doesn't change the entrypoint behavior. If
RELAY_PRESTART_ENDPOINTis defined (e.g.RELAY_PRESTART_ENDPOINT=http://127.0.0.1:12345), the entrypoint will try to reach it before proceeding further.#skip-changelog