
Deploying Elixir - luk3thomas
http://luk3thomas.com/notes/deploying-elixir/
======
jswny
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...](https://gist.github.com/jswny/83e03537830b0d997924e8f1965d88bc).

~~~
samcat116
Intriguing post!

------
i_s
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.

------
adambrod
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.

~~~
thedoops
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.

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

~~~
juhatl
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...](https://dockyard.com/blog/2018/02/28/elixir-deployment-tools-update-
february-2018)

------
atonse
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)

------
fareesh
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.

------
kanonk
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?

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

~~~
nickserv
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.

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

