This post is the complete walkthrough of the Phoenix app deployment using
mix_docker. Some of the material here reiterates Tymon Tobolski’s post while adding much more detail specific to packaging a Phoenix app in a Docker image.
This is part 2 of the Deploying Phoenix Apps for Rails developers series. In part 1 we created a bare bones Phoenix application and configured it to build and deploy
distillery releases using
edeliver. In this post we’re going to deploy an upgrade release and use Erlang’s hot code upgrades.
In Rails world Capistrano gem is pretty much a go to solution, it is proven over and over again in production, it has great documentation and everyone seem to agree that this is the way deploy a Rails application. In Elixir/Phoenix there is no such “go to” solution, not yet. In the Elixir Users Survey 2016 done by Josh Adams 33% of respondents use some ad-hoc way, another 30% use Docker, another 30% deploy to Heroku, finally only 14% use edeliver and the rest use some other technique. In this post we’re going to learn how to deploy Phoenix apps by doing, just follow along and if something doesn’t work - feel free to leave a comment and I’ll try to help you the best I could.
Once a customer asked me to move their smallish website to a new server: to deploy enhancements and upgrade OS with latest security patches. They were too afraid to upgrade Linux OS on the old one for it was too far behind with upgrades. There was one requirement: “please keep the downtime to a minimum”.
Any job requires a worker to perform various tasks daily. In some cases there is just one task that never changes. For example, a manufacturing line where workers are forced to do the same operation over and over again.
Exception handling is important and requires design - just like any other part of your program. Bad exception handling design often results in extended troubleshooting time in production, especially for larger applications with a lot of data. This is especially useful for long running background code that runs through a lot of data.
Just found a useful idea in my friend’s code: use transactions in database migrations. This can save you a lot of trouble with partially updated data.