Re:Elixir on Google Cloud Platform and App Engine
by jclulow on Tuesday January 23, 2018 @03:05AM
(#16211836)
The behaviour you are attributing to Node is really just the behaviour of poorly constructed software. There are at least some Node-based software products which correctly come up and wait for dependencies to become available -- and gracefully handle their subsequent transient unavailability.
Re:Elixir on Google Cloud Platform and App Engine
by atopuzov on Tuesday January 23, 2018 @08:41AM
(#16213455)
There are 2 types of probes: readiness and liveness [1]. Define your readiness probe so it passes when you are ready to take the traffic (eg. connected to the db).
[1] https://kubernetes.io/docs/tasks/configure-pod-container/con...
BEAM VM comes up and tries to connect to the database. The database is temporarily unreachable from that machine, but only the Ecto process dies and BEAM VM doesn't die. Since the last process (BEAM) in the Dockerfile is running, Kubernetes thinks it's healthy and will try sending traffic to it.
Compare this to something like node, where the node process will die if it can't connect to the database, and Kubernetes won't try to direct traffic to it and will restart it for you. You can do this with Elixir supervisors as well - that's why I said Kubernetes replicates some of Elixir's functionality.
It's definitely possible to work around all this which is why we ended up using Kubernetes for our Elixir deployment (and I'd recommend it). It's just these little things that make it clear that Kubernetes was designed with something like node in mind and not BEAM.