How do you package your Phoenix application for deployment?

Hello! I run a cloud company, we want to build the best possible Phoenix deployment experience. The goal is a CLI based launch command that takes a Phoenix app directory, sets the right configuration secrets on our service (SECRET_KEY_BASE and DATABASE_URL, so far) and then builds + deploys the app as quickly as possible.

For Ruby and Rails, we just use the default Heroku builder. It works very well.

The available Phoenix buildpacks are very slow and incredibly brittle. We can’t really use those, we need a better option.

How do you all package your apps for deployment today? Specifically:

  1. Do you use mix release?
  2. Do you have a Dockerfile?
  3. Do you run a CI system, and which one?

Thank you for the help!

4 Likes

How do you all package your apps for deployment today? Specifically:

  1. Do you use mix release?

Yes, mix release is the inbuilt and easier way to distribute elixir applications. I have used distillery and edeliver also for deployments. There are multiple Elixir PAAS vendors for elixir deployments to try if you want to.

  1. Do you have a Dockerfile?

Yes, Dockerfile based containerization is easier to be embedded into development or deployment.

  1. Do you run a CI system, and which one?

I have used Pipelines, Github Actions, AWS or GCP based Pipelines and also Gitlab runner.

To answer briefly, it’s a mixture of all the three for most of the deployments, based on the Client’s convenience factors and productivity factors.

2 Likes
  1. Yes
  2. Depends - when I was using my own rolled out deployer it used docker to assemble the release locally and then would just deploy it to a target, change the symlink to the new one and restart the systemd service
  3. I’ve only recently started using Github actions but just for running tests before merge on a lib
2 Likes

I use this Gitlab CI

stages:
  - build
  - docker_build
  - deploy

variables:
  IMAGE_TAG: ${CI_REGISTRY}/${CI_PROJECT_PATH}:${CI_COMMIT_REF_SLUG}
  CONTAINER_NAME: ${CI_PROJECT_NAME}_${CI_COMMIT_REF_SLUG}

mix_release:
  stage: build
  image: elixir:1.10.3-alpine
  variables:
    MIX_ENV: prod
    LANG: C.UTF-8
  script:
    - apk add --no-cache curl make openssl openssl-dev
    - mix local.hex --force && mix local.rebar --force
    - mix deps.get
    - mix deps.compile
    - mix phx.digest
    - mix release
  artifacts:
    paths:
      - _build/prod/rel/myapp

build_image:
  stage: docker_build
  image: docker:git
  dependencies:
    - mix_release
  services:
    - docker:dind
  variables:
    DOCKER_DRIVER: overlay
  script:
    - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
    - docker build -t ${IMAGE_TAG} .
    - docker push ${IMAGE_TAG}
  only:
    - /^release-.*$/
    - master


deploy_prod:
  stage: deploy
  image: kroniak/ssh-client:3.6
  script:
    - mkdir ~/.ssh
    - echo "$SSH_KNOWN_HOSTS" >> ~/.ssh/known_hosts
    - chmod 644 ~/.ssh/known_hosts
    - eval $(ssh-agent -s)
    - ssh-add <(echo "$SSH_DEPLOY_ID_RSA")
    - ssh $SSH_DEPLOY_USER@$SSH_DEPLOY_HOST "sudo docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN $CI_REGISTRY"
    - ssh $SSH_DEPLOY_USER@$SSH_DEPLOY_HOST -t "cd ~/webapps/myapp ; sudo docker-compose pull phoenix"
    - ssh $SSH_DEPLOY_USER@$SSH_DEPLOY_HOST -t "cd ~/webapps/myapp ; sudo docker-compose rm --force --stop phoenix"
    - ssh $SSH_DEPLOY_USER@$SSH_DEPLOY_HOST -t "cd ~/webapps/myapp ; sudo docker-compose up --force-recreate --detach phoenix"
    - ssh $SSH_DEPLOY_USER@$SSH_DEPLOY_HOST -t "cd ~/webapps/myapp ; sudo docker image prune --force"

And this Dockerfile

# ---- Application Stage ----
FROM alpine:3.10 AS app

# Install openssl
RUN apk add --no-cache openssl zlib ncurses-libs ca-certificates

# Copy over the build artifact from the previous step and create a
# non-root user
RUN adduser -D app
WORKDIR /home/app
COPY _build/prod/rel/myapp .
RUN mkdir -p var/private-conf
RUN chown -R app: .
USER app

# Run the release
CMD ["./bin/myapp", "start"]

(Those are old versions I have on this computer).

I have a JavaScript build too but currently I just commit the build result. I should add a node docker image for that too.

I should also add a mix test run too.

1 Like

1- Mix release
2- Nope
3- Only started using Sasa’s ci/cd library recently but nothing else.

2 Likes

When you use mix release but don’t package it with Docker, are you bundling everything up into a zip/tarball and deploying that? Or some other package format?

Not really, I just rsync everything.
But that only works because I don’t have to worry about the OS on the host.
I reckon the most common solution is indeed a docker container, maybe others will mention a different package format but I’m not aware of a spread solution other than docker.

1 Like

We actually want to support something rsync-y too. I’m very interested in creating a hot code reload process. :slight_smile: Once we have the first deploy for a given app done, it should be pretty straightforward to just push the release files.

1 Like

On the subject of hot code reload, there might be useful information for you on the erlang docs.

Any type of support for something rsync-y sounds like a good idea to me.

1 Like

I run releases in production but git pull in the prod machine and mix release right there. my dev machine and prod machine are not exactly the same so I don’t want to mess with system libraries.

1 Like

I usually use GitHub - HashNuke/heroku-buildpack-elixir: Heroku Buildpack for Elixir with nitro boost to deploy via Heroku

Not typically.

Nope, I try to avoid docker as much as possible.

I typically use CircleCI or GitHub Actions (although GitHub actions has only been on side projects)

2 Likes

How long do builds take? That buildpack gets us in the 7 minute range. Heroku’s buildpack caching is pretty good, though, are repeated deploys quicker?

  1. Yes we used to use Distillery and have changed to Mix releases for new projects.

  2. Yes in fact I have two Dockerfiles per project, one for testing and one for deployment

  3. Custom TeamCity deployment

1 Like
  1. Yes, built on target server with asdf managed erlang/elixir
  2. Not in prod, where we use systemd to manage services, but we do use it for pr review app deploys and for dev
  3. Yes, use github actions for ci. No real complaints there.

On other simple, small scale projects I’ve used render for everything and was very satisfied with it aside from the lack of shell access

1 Like
  1. Do you use mix release? Yes
  2. Do you have a Dockerfile? Sort of, it’s in an Earthfile
  3. Do you run a CI system, and which one? Github

My builds deploy on every commit with the help of Pulumi

2 Likes

Earthly is very cool. If you have an Earthfile you can share for an Elixir app, I’d love to see it.

2 Likes

Earthly is great although the caching story isn’t quite there yet, but it should get very very interesting soon. Here’s the Earthfile I use for all my projects these days: potionx/Earthfile at main · PotionApps/potionx · GitHub. You can also see the Pulumi code here and the Github Actions code here.

2 Likes

I don’t have an exact time, but I think it’s generally around 4-10 minutes. (But I generally deploy as part of a full CI build, and the CI portion is what takes up the majority of the time on top of that 4-10 minutes)

1 Like

I use mix releases inside Docker containers, and I use Compose for the apps that require another container for the DB, etc.

I wrote my own tool which basically just deploys Compose files to servers via SSH and uses environment variables for configuration: GitHub - jswny/sad: Simple app deployment based on SSH and Docker.

I use it because it’s simple, I wrote support for GitHub Actions, and it puts everything inside a Docker container.

2 Likes
  1. Do you use mix release?
    Yes, always

  2. Do you have a Dockerfile?
    Yes, most of the times. Using multistage builds, I use Docker Hub as base image for building a release and plain alpine as the runner.

I’ve deployed apps in different envs, but always used docker to package the app:

  • multi-cloud k8s abstracted by team infra,
  • heroku
  • AWS ECS
  1. Do you run a CI system, and which one?
    Yes. Using Github Actions now, but also used Jenkins A LOT. I also have used Circle CI and enjoyed it.
    For CI I usually run mix test, check for compile warnings, sometimes use credo, and also dialyzer

extra: no matter where I’m deploying an elixir app, I find it really important to be able to:

  • cluster elixir nodes
  • open a remote iex session to any node
2 Likes