Sanjibukai
Regarding deployments strategies (for zero downtime)
Hello,
Until now I was using docker container to build and deploy my phoenix apps.
Something as following:
- I have a
dev.Dockerfileand adocker-compose.dev.ymldedicated for development - I have a
prod.Dockerfileand adocker-compose.ymldedicated to production - The reason I have 2 Dockerfiles (despite I heard that it’s not very good) is because the dev one has some development dedicated tools and the prod one is a multistage Dockerfile with a build stage (where I use Releases) and a very lightweight actual image (with only the Releases copied over).
The compose files are barely different, mainly ports and envs. - To deploy, I SSH into the prod server, pull the repo and run
docker-compose up -d.
So, nothing too fancy.
And in the meantime I even started to bring into play some CI/CD with Gitlab CI, and it seems even easier and cleaner to deploy, but the workflow is the same.
Now I wanted to tackle the downtime issue.
At first I thought about solving this “manually”. I mean like the green/blue strategy by having a load balancer and managing the replacement of the old image manually (here is a good blog post I find about the subject How to do Zero Downtime Deployments of Docker Containers · Coderbook)
Another solution seems to be using docker swarm abilities (with docker services) to update containers. I just heard of it and it seems to be a pretty interesting solution. This could also allow me to gradually get rid of docker-compose.
The other solution I want to discuss here, is using Elixir/Erlang own abilities to perform code reloading.
But first I want to say that I’m completely lost about the current tools and the “best way” to do it. I heard of distillery, edeliver, and also elixir releases. I don’t get what’s doing what.
Elixir Releases seems to be a recent tool and it seems that it’s not so spread.
In fact I’m already using releases but only because I had some hard try to figure out in my docker containers approach how to handle my env variable. Following some recipes I found, I’m mostly using it because I put all my env variables within the config/releases.exs file and it just works.
Edeliver seems to be a tool that automates what we could do manually otherwise like SSH’ing into the prod server and copying the files.
Distillery, I don’t get its usage.
So, I wanted to know more about this topic.
Where Elixir/Erlang intrinsic hot code reloading abilities come into play?
Also, is it possible to have docker containers and those Elixir/Erlang code reloading at the same time?
Thank you for all your insights about this topic.
I’ll be happy to hear more about your workflows.
Have a good day..
Most Liked
d-led
5 years later …
I’ve opened this post in a tab while thinking of trying out a hot code deployment without the normal release/appup/distillery approach, and take it to an extreme - continue an animation while crashing (and restarting) the process behind it, and later, tolerating a node failure (making the demo a bit chattier to support that). I’ve been reading the Elixir docs saying: “don’t do the usual thing, try other mechanisms”, and this is my answer to this with some patterns that are well-known (I don’t think there’s anything new apart from trying it out for real): GitHub - d-led/ssr-robust-live-svg: Sometimes you just have to externalize the thoughts by implementing them. Zero downtime upgrade of a server-side rendered animation of svg. No k8s, extra databases or message brokers needed (trade-offs may apply) · GitHub
I wished there were more (automated) demos on that subject with all the different trade-offs and idea combinations
LostKobrakai
Releases are a self contained package of files for running a beam project in production. Both mix release as well as distillery are tools to build a release based on a mix project (mix release was mostly build by the learnings of the older distillery). Today most people seem to use mix release over distillery for being included in elixir and the consolidation of configuration options, but distillery has better support for hot code updates as it generates appup/relup files, while for mix release you’ll need to create them manually.
Edeliver as you’ve gathered is a more high level tool wanting to handle the whole deployment process, where building a release is just one piece.
As for docker: You can do hot code updates with docker (gigalixir does support that afaik), but it goes kinda against the grain of docker and the idea of immutable images/throwaway instance. Basically you’ll need to modify your docker instance while it’s running.
benwilson512
The main thing to note here is that, once your release is running inside a container, doing blue green deployments with Elixir is basically the same as doing blue green deployments with any other language. Therefore, don’t limit the material you read to only material that talks about Elixir specifically. Pick one of the various ways to deploy applications with docker and use whatever built in blue green deployment mechanism it has.
Popular in Discussions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









