Sanjibukai
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..
Where Next?
Trending in Discussions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Elixir, Erlang & messaging conferences from Code Sync. Next up: ElixirConf US (10–11 Sep) & Code BEAM Europe (21–22 Oct), Haarlem + online.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 8- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
LostKobrakai
Releases are a self contained package of files for running a beam project in production. Both
mix releaseas well asdistilleryare tools to build a release based on a mix project (mix releasewas mostly build by the learnings of the olderdistillery). Today most people seem to usemix releaseoverdistilleryfor being included in elixir and the consolidation of configuration options, butdistilleryhas better support for hot code updates as it generates appup/relup files, while formix releaseyou’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.
Sanjibukai
I guess that you’re right..
Particularly I found this particular chapter in the docs mix release — Mix v1.20.2 where doing so is not encouraged.
So I guess I’ll stick with
mix releaseand docker for generating new images and then use the methods used for green/blue deployment.. I assume it’s a common way to do it after all so I’ll be able to find some resources to read..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.
sasajuric
Wouldn’t it work without modifying the instance if the release was mounted instead of being kept in the image?
LostKobrakai
I guess so, but even just mounting the app into the running container is as much against the idea of immutable images as changing the files inside it would be.
sasajuric
Well, technically the image remains immutable
but I agree that it goes against the grain of how docker images are typically used.
LostKobrakai
Yeah, it’s for sure no longer an immutable image of your application, but at best an immutable image of your apps running os.
d-led
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