It appears edeliver and distillery are the preferred way to do deployments, but my understanding is that the production server OS has to be the same as the dev environment OS. Is that right?
I want to deploy to a freebsd droplet on digitalocean from my mac.
Is there a preferred way to do this without using docker (I’m not a fan of it)?
The target os doesn’t necessarily have to be the same as the one in your dev environment.
While Distillery does include your system’s Erlang binaries in the release by default, you can also tell it not to include them or include an ERTS of a different architecture/binary type instead.
If you don’t include ERTS, you simply need Erlang on the target system.
Check out Distillery’s Walkthrough guide for more details on this:
https://hexdocs.pm/distillery/walkthrough.html#deploying-your-release
look at A Beginner's Guide To Deployment with Edeliver and Distillery - it’s on ubuntu, so minor adjustments might be needed…
You could use a docker image to do the job.
Having Erlang installed on the server and using releases without ERTS is the approach I’m now taking as I didn’t want to have to worry about which OS/version I build releases in, even though I’m usually on Linux. (I’m also not keen on using Docker when I don’t have to.)
I used asdf to install Erlang on the server, and as I’m using systemd I found I had to add asdf’s shims directory to $PATH in the app’s service/unit file:
ExecStart=/bin/bash -c 'PATH=/home/appuser/.asdf/shims:$PATH exec /home/appuser/app/bin/my_app start'
Also, I know you said you didn’t like Docker, but do take a look at mix_docker. I think they have a very useful approach for deployment.
You can also easily adapt this concept. I have, for example, transformed it so that I can automatically deploy my application when I push it to Bitbucket.
Maybe one of these days I’ll write a blog post about it …
Thanks, this is the approach I was thinking of although it’s meant to be less secure as it opens up use of erlang on the server if it’s compromised, but I think there are benefits to having it installed too, and it must be possible to lock its useage down.
I could easily be wrong, but until developing and releasing from a mac is easy, sans docker, I think releasing will remain an impediment to the growth of elixir/phoenix, simply because so many developers use macs.
But the same can be said for developing on windows and releasing to a linux/unix server on DO or whatever cloud - it has to be easier for elixir/phoenix to go mainstream without use of docker.
Thanks!
Thank you!
I’m not sure I agree that it’s an impediment - Erlang/Elixir are similar to any other language where you may have native dependencies which need to be compiled on the target architecture/OS, golang is a great example of a language where it’s super easy to deploy generally, but you still need to cross compile, and if you have native dependencies, you have to do some extra work to setup a build environment to automate deployments. Using something like Docker just for builds can save you an awful lot of pain, and has the benefit that it can be entirely automated. Vagrant is another option, and is very widely used for that reason (as well as others), but I tend to avoid it because it’s so much heavier than Docker for just doing builds.
If you are not consuming any native dependencies, things are easier, just don’t include ERTS and as long as your target machine has the same version of Erlang, you are good to go. You can go a step further and do a one-time export of an ERTS compiled on your target (or in a matching Docker/Vagrant setup), and then just configure Distillery to include that ERTS instead of your build machine’s ERTS. It’s extra up front effort, but can save you a ton of time if you are deploying without a build server or some kind of automation in the mix.
However if you do depend on native dependencies, and it’s very common to have at least one NIF floating around (in my experience) - then you are back to doing your builds on a dedicated server or in a container/VM which matches the production environment. In my opinion, tackling this upfront is the way to go, because you can change your application drastically but keep your deployment setup more or less the same the whole time. It’s much easier to automate as well, and tools like edeliver can take most of the work out of the automation bit.
I think the reason nobody has created the “end all be all” tool to abstract away all the Docker bits is simply that due to the nature of most applications, you will have native dependencies which dynamically link against specific system libraries which your build/prod machine must have installed - so then whatever is building your release needs to have those things too, not to mention you are probably targeting a specific OS and version of that OS - it’s just plain easier to throw the bits together yourself. As an example of what I mean, I threw this together awhile back as an example of how to automate the creation of Docker images containing just a release (it builds the release in a “dev” container with all the bells and whistles, and then passes it into a “prod” container with only the bare necessities). It’s similar to what I put together for our projects at work, and it relies on nothing more than the shell, make, and Docker. You could tweak it to just build the release in Docker and export it so you can manually deploy it, or hook that bit into some other piece of automation you have - the point is that “painless” deployment is going to require some degree of elbow grease up front (IMO). Even environments like Node, Python, Ruby, etc. still have to deal with native dependencies from time to time, and you end up doing more or less the same thing we’re doing here.
There are still improvements to working with releases in Elixir being made, and I know I plan to continue doing so until there isn’t any work left I can do - but I also think that where we are at now is actually really good. Setting up and deploying a project via releases can be done with very minimal effort - the caveat is that you need to understand how to do that, and I think that’s where a lot of work remains to be done. In my experience, the vast majority of problems people have when transitioning to releases is due to thinking they can add Distillery to their deps, run mix release and be done with it - it’s not much more complicated than that, but it’s not that easy. I unfortunately haven’t been able to do a good enough job with either documentation or UX of the tooling to help guide people down the “happy path”, but it’s absolutely an area I would love help with.
Just to confirm, am I right in thinking that when ERTS is omitted from a release due to the server having Erlang installed, as long as the version of Erlang (e.g., 20) is the same, the OSes/architectures of the server and the release build machine don’t matter?
As long as you have no native code.
Exactly. As soon as native code enters the mix, you have to either cross compile (which is typically non-trivial) or just build on a machine/VM matching your target.
Disclaimer, I work for Nanobox… That said, we’ve invested quite a bit of time into elixir deployments. I would recommend taking a look: https://nanobox.io
I just used nanobox to deploy to Google Compute Engine, it takes 10min and they have a very nice Slack channel support, I’m loving it!
My not be ideal but I have always ran builds on a build server(5$ digital ocean box) and just used that build across servers.
I don’t understand the desire to dockerize everything. That’s yet another layer in an already complex build and deploy.
This feels like a classic simple vs easy to me. Docker is easy because you can forget about binary compatibility and be up in 5 minutes. Binary compatibility is simple and will keep your deploys from complecting as you add features.
lol. That sounds ideal to me.
Have since changed to building in CI/CD and storing the artifact to be deployed later.
© Copyright Elixir Forum | Terms | Privacy & Cookies
