I wanted to solicit the educated opinions of the forum-folk when it comes to the deployment of Elixir apps. Is using Docker in the deployment (and/or in the development) of Elixir apps idiomatic? When so many deployments for different technologies rely on containers of some sort, some SysAdmins/DevOps people push for a Dockerize-able application as the de facto standard for any deployment scenario. Most DevOps people I’ve interacted with are very much coming from the “Cattle” side in the “Pets vs. Cattle” analogy where containers are thought of as disposable entities. However, with Elixir, I haven’t had as much use for Docker as I have when working with other languages, and I am wondering if this is a fluke or indicative of the inherent nature of Elixir/Erlang? I have rarely had to snuff out a running Elixir app – the adage of “write once, run forever” really has held true from my experience, but this doesn’t seem to be something DevOps people expect or even want.
The pros for deploying with Docker is that it represents a “package format” that is more standard – the DevOps guys wouldn’t need to think much about what’s inside an image.
The cons would be the hits to performance. Elixir/Erlang is already running inside a VM, so it seems redundant and a hit to performance to containerize a container. (I know has been especially true for development).
What are others seeing out there? Are Dockerized Elixir deployments common and/or appropriate? And why, or why not?
Probably on MacOS, as it requires virtualization (and may be Windows, not sure about WSL… never tried), but on linux it should be just a tiny layer on top of the host system. So I would not rush prioritizing performance, as long as the server is running on linux, when comparing deployment options.
Running in a container with all its best practices while provides benefits, it discourages “hot code swapping”, at least, because if container gets restarted - it will run the previous version of the application.
For example, distillery provides with tools that help with hot upgrades and downgrades and could be used in combination with edeliver. It kinda reminded me of Capistrano for Ruby apps.
However, in elixir’s docs there is a separate section explaining why that functionality is not included with regular mix release
The reason we don’t provide hot code upgrades is because they are very complicated to perform in practice, as they require careful coding of your processes and applications as well as extensive testing. Given most teams can use other techniques that are language agnostic to upgrade their systems, such as Blue/Green deployments, Canary deployments, Rolling deployments, and others, hot upgrades are rarely a viable option. Let’s understand why.
All in all if we don’t want to do hot upgrades I would describe the deployment as, we gotta:
somewhere somehow build the release
somehow deliver that release to the production server
run it there
Using docker/contrainers is probably the most popular option out there today.
Some PaaS, such as Heroku, Gigalixir, Fly.io etc. provide with tools that help to do that, though some of them probably still will run your app in container (fly.io does, for sure)
At job, we used docker for elixir deployment and running pull request test. No real performance issue coming from docker so far. And it really help to be able to standardize from a single dockerfile about testing/deployment so no issue like it passed on test but not on deployment.
I use Docker for all of my personal projects and enjoy its usage at work. It provides a convenient layer of abstraction for packaging and running your application. If you use it and configure your app via ENV vars, then you can pretty much move between cloud providers in an instant (assuming there is no other vendor lock in).
I would advise for using Docker paired with mix release. I’d say that most of the time zero-downtime deployments are enough and you’d do hot-code upgrades when you really, really need it.
