-
Notifications
You must be signed in to change notification settings - Fork 172
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #61 from dwyl/elixir-pheonix-deployement
recap elixir deployment
- Loading branch information
Showing
1 changed file
with
162 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,162 @@ | ||
| # Deploy an Elixir or Phoenix application | ||
|
|
||
| This markdown summarises the research done | ||
| on how to deploy a Phoenix application. | ||
|
|
||
|
|
||
| ## PaaS vs VPS | ||
|
|
||
| In the past we have mostly used Platform as a Service (PaaS) providers | ||
| to deploy Elixir applications. The main advantage of PaaS | ||
| is it is quick to setup and have your application running | ||
| for your users. | ||
| However in the longer term using a PaaS can become costly (per unit of compute e.g. RAM/CPU). | ||
| Virtual Private Server are in contrast normally cheaper to run | ||
| but require more setup time and DevOps knowledge to maintain. | ||
|
|
||
| ### PaaS | ||
|
|
||
| #### Heroku | ||
|
|
||
| We are used to deploy Elixir/Phoenix on Heroku | ||
| and we have already a ["how to"](https://github.com/dwyl/learn-phoenix-framework/blob/master/heroku-deployment.md) guide of this process. | ||
|
|
||
| However there are some limitations when using Heroku with Phoenix (see https://hexdocs.pm/phoenix/heroku.html): | ||
|  | ||
|
|
||
| pricing: | ||
|  | ||
|
|
||
| The pricing above doesn't include the database which needs to be added to the total cost, see https://elements.heroku.com/addons/heroku-postgresql | ||
|
|
||
|
|
||
| ### Gigalixir | ||
|
|
||
| Similar to Heroku [Gigalixir](https://www.gigalixir.com/) provides | ||
| a platform which focuses _exclusively_ on deploying Elixir/Phoenix application. | ||
| Having an exclusive focus on deploying Elixir Apps gives Gigalixir several key advantages: | ||
| 1. Zero-downtime blue-green continuous deployment. | ||
| see: https://martinfowler.com/bliki/BlueGreenDeployment.html | ||
| 2. No limit to concurrent connections. | ||
| 3. All clustering handled transparently. | ||
| (so if you need to scale your app beyond 10k concurrent users, | ||
| you don't have to pay exponentially more for bigger "dynos" | ||
| the way you are forced to scale vertically on Heroku) | ||
|
|
||
| Deploying: https://elixircasts.io/deploying-with-gigalixir-%28revised%29 | ||
|
|
||
| Pricing: | ||
|
|
||
|  | ||
|
|
||
| Gigalixir vs Heroku: | ||
|
|
||
|  | ||
|
|
||
| Like Heroku you need to add the cost for using the database: | ||
|
|
||
|  | ||
|
|
||
| see also tiers pricing page: https://gigalixir.readthedocs.io/en/latest/tiers-pricing.html | ||
|
|
||
|
|
||
| ### Render | ||
|
|
||
| [Render](https://render.com/) is another Paas similar to Heroku | ||
|
|
||
| pricing: | ||
|
|
||
|  | ||
|
|
||
|
|
||
|
|
||
| ## Virtual Private Server | ||
|
|
||
| VPS allow us to manage ourself the deployement | ||
| setup. This allow us to customise the server and | ||
| the costs linked to it. | ||
|
|
||
|
|
||
| ### Linode | ||
|
|
||
| #### Ubuntu | ||
|
|
||
| Linode provides and support Ubuntu: | ||
|  | ||
|
|
||
|
|
||
| From there the idea is install Erlang and Elixir on the server | ||
| and then to run the application. | ||
|
|
||
| - Install Erlang/Elixir with asdf: | ||
| - `git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.7.8` | ||
| - Edit `~/.bashrc file` and add `. $HOME/.asdf/asdf.sh` and run `source ~/.barhrc` to access the `asdf` command | ||
| - Install required pacakges for Erlang `sudo apt install libssl-dev make automake autoconf libncurses5-dev gcc` | ||
| - Add erlang plugin to asdf: `asdf plugin-add erlang` | ||
| - Install Erlang: `asdf install erlang latest` | ||
| - Install Elixir: `asdf install elixir latest` | ||
| - Define which Elixir version to use `asdf global elxir <version>` | ||
|
|
||
| - Instsall Nodejs using nvm | ||
| - `wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.35.3/install.sh | bash` (from https://github.com/nvm-sh/nvm#installing-and-updating) | ||
| - run `nvm install node` | ||
|
|
||
| - Clone and run the Phoenix application | ||
| - Clone the application, e.g. `git clone https://github.com/dwyl/hits.git` | ||
| - Make sure to have all the environemt variables for the application defined | ||
| - e.g. for the secret key: `mix phx.gen.secret` then `export SECRET_KEY_BASE=<secret>` | ||
| - Compile assets (see https://hexdocs.pm/phoenix/deployment.html#compiling-your-application-assets) | ||
| - `npm run deploy --prefix ./assets` | ||
| - `mix phx.digest` | ||
| - Start the server with `Mix`: `MIX_ENV=prod mix phx.server` | ||
|
|
||
| - Another way to run the server is to use `mix release`: https://hexdocs.pm/phoenix/releases.html | ||
|
|
||
| #### FreeBSD/OpenBSD | ||
|
|
||
| I've also been investigating how to run | ||
| an Elixir/Phoenix applicaiton on FreeBSD (and OpenBSD) | ||
|
|
||
| Linode provides a way to create server from image, | ||
| however the backup system won't support server running FreeBSD: | ||
|  | ||
|
|
||
| The following guide explain how to install FreeBSD on Linode: | ||
| https://www.linode.com/docs/tools-reference/custom-kernels-distros/install-freebsd-on-linode/ | ||
|
|
||
| I've also tested the installation on one of my machine: https://github.com/SimonLab/FreeBSD-installation | ||
|
|
||
| The idea is then to use the FreeBSD package manager to install Elixir and Erlang: | ||
| - `pkg install erlang` | ||
| - `pkg install elixir` | ||
|
|
||
|
|
||
| ### DigitalOcean | ||
|
|
||
| DigitalOcean provides a FreeBSD droplet: | ||
|  | ||
|
|
||
| see https://www.digitalocean.com/products/linux-distribution/freebsd/ | ||
|
|
||
| However OpenBSD can't be installed directly. | ||
| There are some way we could install it and investigate | ||
| if it can be used safely and without any blockers with DigitalOcean: | ||
| https://dev.to/nabbisen/custom-openbsd-droplet-on-digitalocean-4a9o | ||
|
|
||
| see also: https://www.digitalocean.com/community/tutorials/how-to-get-started-with-freebsd | ||
|
|
||
|
|
||
| ## Current Conclusion | ||
|
|
||
| After reading and testing some Elixir/Phoenix/Linux/BSD installations | ||
| I can see that Linode (or similar) can be on a longer term a better tool | ||
| to manage the applications. | ||
|
|
||
| The simple deployement used above with Ubuntu works well, | ||
| however I still have some research and testing to do especially | ||
| linked to continuous deployment without downtime. | ||
| From reading the chapter 11 "Deploy Your Application to Production" of | ||
| Real Time Phoenix, the solutions to deploy witout downtime are based on running | ||
| applications on Elixir clusters. I'd like to learn more about this aspect | ||
| but from a MVP perspective this point might take too much time to assimilate | ||
| and I think a PaaS might be best to use at the moment. |