<div dir="ltr"><div><div><div><div><div><div><div><div><div><div>I'm using Docker with Erlang and have found it extremely useful.<br><br></div>I think that there's some hostility towards Docker because much of the buzz around Docker seems to treat it as the perfect technology for solving all your problems. This is untrue, of course, but I think "stupid people like it" is a bad reason to reject something. So now I'll out myself as a stupid person...<br><br></div>Here's an example of how I'm using Docker:<br><a href="https://gist.github.com/waisbrot/3415d53f7c0b66a36013">https://gist.github.com/waisbrot/3415d53f7c0b66a36013</a><br><br></div>I use Kerl to install Erlang into a base image and then use that base image to build my applications. The applications are simply releases made with Rebar. There's a little Docker work to keep it from needing to download all dependencies every time, which is optional but nice. Inside the container, everything is normal Erlang world and there's no surprises.<br><br></div><div>You could use the official image, but we wanted to customize our images and having a shared base image is valuable for saving downloading time and disk space.<br></div><div><br></div>So that's the "how". As for the "why":<br></div>- We started out in Node.js and Python. Containerization was helpful here, mostly to segregate Python2 and Python3 headaches (a bunch of tools that incompatibly expected "python" to be the right Python for them).<br></div>- We were doing deployments via `git`, which was not great. Using Docker as a packaging system was nice because it's simpler to learn than RPMs and is uniform across all languages (don't have to learn wheels/eggs/gems/etc).<br></div>- We didn't have any Ops staff to handle deployment and manage the machines<br></div>- After the container infrastructure is set up, it's easy to introduce new languages and we were able to ease Erlang into the mix<br></div>- Our development environment runs the same containers as our production environment, just using container-linking and running all on one machine<br></div>- Or CI environment does the same thing. We regularly run our functional test suite against multiple copies of the production system simultaneously on a single machine (one run per pull-request), and it doesn't take any more effort than a single production deploy (which is also easy)<br><div><div><div><div><div><div><div><div><br></div><div>My main complaint with Docker so far is that if I want my containers to launch with the system I need to set their restart policy to "always", but this causes it to restart crashed containers which interferes with Erlang's own restart system.<br><br></div><div>Some day in the far future, we may reach a point where Erlang is the only language we're running (or at least the only one on a particular server) and then it might be attractive to un-containerize it. On the other hand, maybe not. Adding another layer of virtualization in the form of Docker has cost us very little so far.<br><br></div></div></div></div></div></div></div></div></div>