Hacker News Reader

Comment by whalesalad | Hacker News Reader

It’s difficult to deploy Erlang apps in Erlang-style using Docker. The style I speak of is zero downtime deploys where the VM is never turned off, but is updated with new software as a living organism.

You can run BEAM apps in a container the same way you’d run any other app. It’s possible. But BEAM is less like a PHP/Python/Ruby etc interpreter and more like an abstraction for the OS (some might even consider it to be one). When you’re in Erlang you think in Erlang and the runtime abstracts things like processes, threads, and network partitions away... so you tend to want a big beast BEAM instance (or a few big beasts) rather than a lot of tiny ones (as one might scale up a horizontally scaled app like one on Heroku dynos).

It can be done. It’s just kinda going against the grain.

View on HN

It is not going against the grain. Using release upgrades (upgrading a release without restarting the VM -- unless the version of erts has changed) should only be used where necessary and they rarely are.

They are great to have when you need them but should not be chosen lightly.

Part of the point of this booksite is to show integrating Erlang into a modern environment and not being the oddball deploy at the company. It is the lack of libraries for services used for deployment/monitoring and lack of documentation that is the reason for this.

Also, there is no abstracting away network partitions.

I deploy the Erlang system I use at work using Docker and it's working very well for me. Like you say, it's not a zero-downtime relup but rather just replacing one app container by an updated one. It was a little bit tricky to get the image built properly (the right combination of dependencies, ERTS inclusion, etc) and things like remote_console are slightly more cumbersome than they would be otherwise (it becomes a docker exec command) but overall I feel like the advantages (mainly very smooth deployment and declarative configuration) outweigh the disadvantages.

This is what I've been thinking. At the very least, I know that Docker interferes with the BEAM VM's default behaviour for port management, and node discovery. Docker containers require developers to select which ports containers communicate through. Isn't that right?

This is ultimately not very different than what you would get with any firewall or network rules in any business, and it's an issue shared by most deployments regardless of whether you get containerized or not.

Reply on news.ycombinator.com