Deploying Elixir | Hacker News Reader

Deploying Elixir

luk3thomas.com

67 pointsluk3thomas13 comments

Awesome post! I really like the idea of the custom config provider and the approach to config that is taken in this post. Config is definitely a pain point for Elixir deployment, but the core team knows this and is working on it.

My strategy is similar to the one in this post, however it is optimized to allow for separate stages for complication and runtime, so that you can compile your apps wherever you want and separately run them wherever you want. For this I use two different Fockery images. Docker also makes it really easy to manage multiple apps running at the same time.

If anyone is interested in my deployment strategy, I wrote up a post on how I do things and why I do them that way: https://gist.github.com/jswny/83e03537830b0d997924e8f1965d88....

Intriguing post!

I also try to use the {:system, "MY_VAR"} convention to get around the weird "lets-compile-in-config-values" problem, but unfortunately, it is not supported by many libraries. Even some of the essential libraries, like Ecto, support it for some config variables (db_url), but not for others, which seems crazy to me.

For some dependencies (like exq), I've needed to take them out of the "start" list, and start them manually, hand feeding them the configuration values.

This issue has been the biggest annoyance by far in what is otherwise a really nice platform/ecosystem.

Thanks for the article! I find it really surprising how difficult it is to deploy Elixir apps when it's so much more popular now and the Elixir team is so great at the developer experience.

Deployment and configuration is among the top priorities from both the core team and the community from what I can tell. There's been a lot of discussion about it and some resources being dedicated in the last year. So only a matter of time, but a little heavy on initial deployment for sure.

That's great to hear. Would be nice to have an "official" sort of tool for deployment.

In case you haven't heard yet, there's ongoing work [1] from Paul Schoenfelder for just that! Dockyard (employer of Chris McCord, father of the Phoenix framework) hired him some time back for this very reason.

[1] https://dockyard.com/blog/2018/02/28/elixir-deployment-tools...

This article was great mostly as an affirmation that my cobbled together practices are sound. (I follow all these exactly, except my build server is a VM)

Nearly every article like this seems to have long verbose steps. For me in 99% of cases my development machine and target machine have mostly the same configuration, and so it feels like I have it down to a 3-4 step process which can be scripted.

Why do you use additional versioning?

1.0.0-v1, 1.0.0-v2 istead of just 1.0.0 and 1.0.1

are vX meant as pre-release?

I'm curious as to why docker is chosen for build artifacts but not for running the app itself. Any info available here?

Generally speaking there is no way I'm installing a compiler on production servers, so having a builder is needed.

And rather than having a bunch of different machines for each stack, much cheaper and easier to have docker images.

Then you can deploy easily to any kind of production server: physical, VM, docker, cloud, etc.

So basically you're using an overcomplicated chroot as nothing more than chroot.

Reply on news.ycombinator.com