Elixir deployments on AWS(medium.com)
medium.com
Elixir deployments on AWS
https://medium.com/mint-digital/elixir-deployments-on-aws-ee787aa02a9d#.6sl1vuybf
25 comments
I'm part of the core Nanobox team (https://nanobox.io). Members of our team were instrumental in introducing releases in Elixir and helped to lay the foundation for exrm.
Elixir deploys are currently functional, but we're working with the Elixir community to really fine-tune the process (including hot-code-reloads).
DigitalOcean has been supported for a few months now. AWS support was just released yesterday.
Elixir deploys are currently functional, but we're working with the Elixir community to really fine-tune the process (including hot-code-reloads).
DigitalOcean has been supported for a few months now. AWS support was just released yesterday.
Nanobox guide for getting set up on Elixir Phoenix: http://guides.nanobox.io/elixir/phoenix/
Can someone explain the pricing page? How do i get unlimited servers for $99?
Nanobox is a portable "micro" PaaS, we don't provide servers, we integrate with your host of choice and provision servers for you. The cost and number of servers your application needs/uses is between you and your host (AWS, DO, etc).
The $99 you pay to Nanobox is for the use of the Nanobox Dashboard to manage your application on your host (Nanobox Desktop is free).
The $99 you pay to Nanobox is for the use of the Nanobox Dashboard to manage your application on your host (Nanobox Desktop is free).
Nanobox is free for developers to use for personal and open source projects.
Man, the design, icons, and name are awfully similar to Pagodabox: http://pagodabox.io/
Even down to the boxfile.
Even down to the boxfile.
It's the same team that's behind Pagoda Box. Nanobox is in many ways the next evolution of Pagoda Box.
Okay. That makes sense - but is not clear from the site.
Here's the announcement from Nanobox about AWS support: https://www.prlog.org/12618433-amazon-aws-cloud-hosting-now-...
Anything similar for Digital Ocean? Also, it's my understanding that Elixir/ErlangVM deployments do not require the use of NGINX. Is this true?
Correct. Erlang's Cowboy webserver can be included as part of the code base and is actually a built in part of the Phoenix framework.
For what it's worth though, that doesn't mean you shouldn't use nginx. It's easier to configure, very fast, faster than Cowboy for static file serving and small enough that it's usually a good idea to setup nginx as a reverse proxy in front of cowboy. Just let it handle the static files and ssl.
Cowboy can do all of these things, but one of the many lessons of Elixir is that just because you can doesn't mean you should. :-)
For what it's worth though, that doesn't mean you shouldn't use nginx. It's easier to configure, very fast, faster than Cowboy for static file serving and small enough that it's usually a good idea to setup nginx as a reverse proxy in front of cowboy. Just let it handle the static files and ssl.
Cowboy can do all of these things, but one of the many lessons of Elixir is that just because you can doesn't mean you should. :-)
Could you elaborate on that? How would one accept the tradeoff of having one more piece of software to manage vs performance or other considerations? I've heard cowboy does a pretty solid job serving requests, even static files (although not as good as Nginx).
That's basically what it boils down too. Cowboy is more of a pain to configure update and manage so it's less of a choice of managing another piece of software vs choosing which one you want to manage. With Phoenix using Cowboy under the hood you'll never actually touch it.
At that point it just becomes a matter of "do I want to configure nginx or cowboy?"
If you have SSL at the load balancer and you're using a CDN for assets then it's less compelling. If you're looking to deploy a full encapsulated binary (server and all) then avoiding nginx makes sense.
That's basically it though.
At that point it just becomes a matter of "do I want to configure nginx or cowboy?"
If you have SSL at the load balancer and you're using a CDN for assets then it's less compelling. If you're looking to deploy a full encapsulated binary (server and all) then avoiding nginx makes sense.
That's basically it though.
I disagree. I worked with both Nginx and Cowboy for quite some time, and I don't think that Cowboy is harder to "configure, update and manage." I had opposite impression.
I like Nginx very much, by the way - I was very happy when I switched from Apache to Nginx and I never looked back. Nginx is still my default choice for serving static files, as a frontend for Python (and similar) applications, as a (reverse) proxy, etc. However, I don't feel the need for it when working with Erlang or Elixir, exactly because of Cowboy.
Cowboy is not as fast, but it still is quite performant, even for static files handling. I don't have the numbers, and I can't seem to find a relevant comparison (there's one against Node.js and Tornadoweb here: http://www.ostinelli.net/a-comparison-between-misultin-mochi...) right now, unfortunately.
However, upgrading and management of Cowboy are either on the same level as Nginx or simpler. The upgrade process has two steps: change version in mixfile and re-fetch deps, done. I know that it's one step more than plain apt-get, but it's not that complicated, either.
As for management, Cowboy has an advantage that you can configure it in a Turing complete language (with clear semantics - recall if or allow/deny semantics in Nginx config), not only by initial configuration but also by writing handlers, where you can do arbitrary processing. It's also runtime configurable and hot-swappable (you can reload Nginx config, you can't (AFAIK) replace the currently running nginx with newer version "in place", you need to restart it).
On the other hand, Cowboy has much less built-in functionalities, which is why I said it's not good for example for being a plain proxy - you'd need to write your own handler module for that, while in Nginx it's a one proxy_pass directive and it will be faster to boot. However, when you have an Elixir app and you want to just serve some static assets in addition to the app itself I think it's completely fine to rely on Cowboy for this.
Of course, the advantage of Turing-complete language disappears if you use OpenResty. It allows you to write your app inside Nginx in Lua. I used it in a few cases and it was quite pleasant experience, however, then the Elixir backend becomes unnecessary...
So, to summarize: I think that you don't need Nginx if you use Erlang/Elixir for your backend and that you gain almost nothing if you do include it.
I like Nginx very much, by the way - I was very happy when I switched from Apache to Nginx and I never looked back. Nginx is still my default choice for serving static files, as a frontend for Python (and similar) applications, as a (reverse) proxy, etc. However, I don't feel the need for it when working with Erlang or Elixir, exactly because of Cowboy.
Cowboy is not as fast, but it still is quite performant, even for static files handling. I don't have the numbers, and I can't seem to find a relevant comparison (there's one against Node.js and Tornadoweb here: http://www.ostinelli.net/a-comparison-between-misultin-mochi...) right now, unfortunately.
However, upgrading and management of Cowboy are either on the same level as Nginx or simpler. The upgrade process has two steps: change version in mixfile and re-fetch deps, done. I know that it's one step more than plain apt-get, but it's not that complicated, either.
As for management, Cowboy has an advantage that you can configure it in a Turing complete language (with clear semantics - recall if or allow/deny semantics in Nginx config), not only by initial configuration but also by writing handlers, where you can do arbitrary processing. It's also runtime configurable and hot-swappable (you can reload Nginx config, you can't (AFAIK) replace the currently running nginx with newer version "in place", you need to restart it).
On the other hand, Cowboy has much less built-in functionalities, which is why I said it's not good for example for being a plain proxy - you'd need to write your own handler module for that, while in Nginx it's a one proxy_pass directive and it will be faster to boot. However, when you have an Elixir app and you want to just serve some static assets in addition to the app itself I think it's completely fine to rely on Cowboy for this.
Of course, the advantage of Turing-complete language disappears if you use OpenResty. It allows you to write your app inside Nginx in Lua. I used it in a few cases and it was quite pleasant experience, however, then the Elixir backend becomes unnecessary...
So, to summarize: I think that you don't need Nginx if you use Erlang/Elixir for your backend and that you gain almost nothing if you do include it.
I can't vouch for it, but I've previously noted that Digital Ocean offer a "one click install" for Elixir. https://www.digitalocean.com/community/tutorials/one-click-i...
Yeah looks fine but it's using a very old version of Elixir (1.1) and Phoenix (1.0). Lots of dependencies nowadays require Elixir 1.3 at least.
In using cowboy directly, it would be a mistake (at least from personal experience) to rely of cowboy for anything other than your api endpoints and/or dynamic templates. Static assets, including html, are best served via nginx, with cowboy serving requests to your application. I've never had a cowboy + OTP project not lean on nginx in some way (yet).
I'm currently using Heroku right now because everything else seemed so hard to setup for me. This is good news to see so much effort poured into improving that part!
Have you tried anything besides Heroku?
> Not an option on Heroku; Heroku will restart dynos as part of deployment, again losing state.
Do heroku's custom buildpacks not allow you to prevent restarting the dyno?
Do heroku's custom buildpacks not allow you to prevent restarting the dyno?
Not to my knowledge, Heroku claim to restart dynos on any release: https://devcenter.heroku.com/articles/dynos#automatic-dyno-r...
The buildpacks only define the content of the container, and what processes within that containter it can run.
On deploy, the containers are all being replaced.
On deploy, the containers are all being replaced.
Plus heroku regularly restarts dynos, I believe on a daily basis.
Interesting, I was just needing this article... Thank you
update: Ah, Didn't realize it was already released. How quickly things progress! Thanks for the update, folks.