What kind of server/infrastructure are your Elixir apps hosted on?

production
deployment
Tags: #<Tag:0x00007fbcaba8a3a8> #<Tag:0x00007fbcaba8a268>

#1

We get quite a few hosting related questions, so I wonder whether it might be helpful if we can have a thread that talks about the kind of production set-ups everyone is using?

Do you use a dedicated server? VPS? The Cloud? Or…?


DevOps CI/CD/CD for Elixir/Phoenix best practice?
Please suggest server specs for a large scale Phoenix application
#2

I use a DigitalOcean VPS. They just bumped up their pricing to be competitive with Vultr/Linode and I find their service the easiest and fastest to use.

I don’t really know much about AWS but I like to have full control of my server and apps, which is why I use a VPS.


#3

Currently I am evaluating Gigalixir via its free tier.


#4

Amazon ECS.


#5

Heroku. It’s been working well enough for us and we have other applications hosted there as well.


#6

Currently using bare metal servers from Scaleway for my projects.


#7

Amazon ECS for the application. Postgres database using Amazon RDS.


#8

Smaller local VPS Hoster for me.


#9

Really cheap when i compare to digital ocean. 3 euro for 2gb memory. I am not familar other vps company prices. Is digital ocean expensive or scaleway is cheap for a reason ? How long have you been using scaleway?


#10

Currently using scaleway over a year and had no problems so far.


#11

Used to use DigitalOcean, but for about a year now I use Scaleway for almost all my applications. However I am also investigating Gigalixir


#12

Dockerized on AWS ECS via Fargate. A bit of work went into auto clustering but it was worth the effort.


#13

Great topic :heart_eyes:

What do you use to install on Amazon ESC. ?

Do you use some container registry? Do you have some CI/CD pipeline like push code to git -> build container -> push container to registry -> install container from registry to AWS?

Also are there some best practices to put Erlang VM into container? For example for JVM


#14

Dedicated server from online.net. I should probably actually get a few boxes instead of one big one to split things up. Too much running on one machine.


#15

I mostly have to use clients’ IT infrastructure, so the choice is not always mine. That creates deployment and operational challenges. Recent deployments have been to virtual servers running Centos 7. While I am responsible for operation of the servers, clients sometimes perform underling updates without notice! The most recent incident broke my Distillery deployment and left me with and Erlang crash dump. For occasions where I do have a choice, I am currently looking at Nixos.


#16

VPS (CentOS)


#17

I use a Digital Ocean Droplet that I set up using Docker Machine. This makes it easier (in my opinion) to run your docker containers in the “cloud”. My Elixir app, AlloyCI, is packaged as a container image and deployed using Docker Compose.

I still don’t have it set up as a CI job, but I would be really easy to have AlloyCI build and deploy itself :stuck_out_tongue_winking_eye: I would just need to add a build job for mix docker.shipit and one for docker-compose up -d, both on the deploy stage, which would only be run after all the jobs in the previous stages have passed :slightly_smiling_face:


#18

I’m managing the infrastructure of a small startup developing a phoenix application. Our main host is a dedicated server serving as dom0 (xen hypervisor, dns server, firewall, vpn) hosting the following VMs:

  • Production
  • Staging
  • Internal services (gitlab, …)
  • Monitoring (Icinga, munin, …)
  • Critical services (dns, mail, certificates, ldap, …)

Backups are managed from a remote server using rsnapshot and barman (for postgres).

The phoenix application is built and tested by gitlab-ci. A merge to the deployment branch automatically builds the application for production and deploys it to the staging environment. If everything went fine, the repository’s administrator can manually trigger the final job of the pipeline to deploy to production [0]. We build the release using distillery (+ conform): we don’t have (and don’t want!) elixir installed on the production host [1].

All our hosts run debian and we don’t use containers [2] for now : the overhead is too high for the current scale of our infrastructure/services. Don’t use containers unless you need to, they add a layer of complexity and often create as many problems as they solve, if no more.

It’s a basic overview, feel free to ask for details (software, config, scripts, …) :slight_smile:

[0] There are a few more checks not relevant for this overview (versions, configuration, …)
[1] If elixir, mix & co are installed on your production host, you’re most likely doing it wrong
[2] Except for gitlab-ci


#19

I’m using the container registry at AWS. Our Jenkins server builds code on commit, and deploys it to either development environment or production. The pipeline on jenkins looks roughly like this:

Fetch source -> Build -> Run Test Suite -> Run Dialyzer -> Build Docker Image -> Deploy

The deployment is done in two phases: First, a “staging” version is deployed in the real environment (with the real database), and a number of (additional) tests are performed on it. If all tests succeed, the docker image is deployed into the “live” environment.

This approach is not perfect, but it works fairly well. The ECS service concept along with the AWS load balancer, make it easy to upgrade the system.


#20

Forgot to mention, mix docker uses Distillery internally to build a release binary. This is what gets copied to the final Docker image. The image I use for release is Debian based. (It would be possible to do it with Alpine, but I prefer to have a full Debian distro in the image)

Also the reason I chose Docker, is that it is by far the easiest way for someone to install AlloyCI in their servers. All they need to do is pull the image, and set it up with the correct ENV variables. It would be a lot more difficult to install otherwise. It is still possible to do it manually (we have instructions for this in the docs) but that requires manually building the release, and manually deploying it to a compatible server.