Oh, wow, I somehow missed that option! I guess I was expecting gen_tcp:listen(Fd) and not gen_tcp:listen(Port, [{fd, Fd}]). But yes, this look like it should work. I’ll have to give it a try with systemd soon.
tristan
Rebar3 Core Team
1
garazdawi
Erlang Core Team
brentjanderson
Approach A would fit well if you use Kubernetes to manage Elixir/Erlang containers AND you absolutely need hot-code upgrades. I would suggest that for serious production cases the operator pattern could be very useful.
From the linked post:
An Operator is an application-specific controller that extends the Kubernetes API to create, configure, and manage instances of complex stateful applications on behalf of a Kubernetes user. It builds upon the basic Kubernetes resource and controller concepts but includes domain or application-specific knowledge to automate common tasks.
So, an Erlang/Elixir operator would:
- Accept API calls for rolling forward and backwards between versions
- Translate those calls into commands directly into your running Erlang containers for:
- Fetching the next Erlang code release from some artifact storage (Could still be using Docker, or you could fetch it from S3)
- Performing the hot-code upgrade to the new version
- Reporting on the progress of the upgrade
- Handling an automatic or manually triggered rollback if the upgrade is failing for some reason
This would give you k8s-level APIs for managing the process without having to drop into containers by hand. I suspect this approach would be best-fit for applications running in k8s, but other orchestration systems could benefit from the general idea as well.
2