How do you package your Phoenix application for deployment?

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.

2. Do you have a Dockerfile?

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

3. 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.

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

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- Mix release
2- Nope
3- Only started using Sasa’s ci/cd library recently but nothing else.

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.

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

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.

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.

I usually use GitHub - HashNuke/heroku-buildpack-elixir: Heroku Buildpack for Elixir with nitro boost · GitHub 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)