Ways to distribute a phoenix project?

Questions / Help
, , , , ,
1

Hi, I have been working on a side project/tool in the elixir for loading which loads CSV files to the database.

It is an umbrella project, with 2 apps: an elixir application which holds the main logic, and a phoenix live view application that provides an interface to the user to use the tool. The user has to run the phoenix server locally and use the browser as an interface to the app. It just like other tools like phpMyAdmin that use the browser to provide an interface.

Now, I want to distribute this application to users, and my requirement is that there should be minimal dependencies and the user experience should be good.

There are some ideas to do this but I haven’t found a solution yet.

I have thought of 3 options to do this…

  • 1st idea, using an Escript: I have earlier used escripts to distribute this app, and it worked fine, escripts only require the user to have erlang installed and have no OS dependency like releases. Also, escripts is a single binary file which makes it convenient to distribute and use.

Problems: Since now the project is an umbrella project and with the addition of the phoenix live view app, now I am not sure if escript will work. Not sure if things like assets and node modules in the phoenix app can be packed inside an escript. Can anyone guide me on this?

  • 2nd idea, using releases: This seems like a good idea to me, there are no dependencies that the user needs here.

Problems:

As the docs say…

Once a release is assembled, it can be packaged and deployed to a target, as long as the target runs on the same operating system (OS) distribution and version as the machine running the mix release command.

So should I make a different release for each different OS distributions?
I work on ubuntu 18.04, in order to make releases for other OS distributions can I run the OS distribution in docker and execute mix release from inside the docker container running the required OS distribution, will this work? Any ideas anyone?

  • 3rd idea, using Docker: I can package my app as a docker image using a docker file, we can get rid of all the dependencies on OS, etc. This seems good idea but…

Problems:

The users now will have to install docker first and run my app’s docker container to use it.

Also, my elixir application needs to access files from the user’s system, using docker means we will have to use docker volumes or bind mounts to access CSV files on the host machine, all this adds complexity and hampers user experience, which I would like to avoid.

These are the approaches I can think of there might be a better way to do this, that is not listed above, please share any ideas or suggestions you have.

Thank you! :slight_smile:

1 Like
2

Yes, this works. Using Docker to build a release in the same environment as where the application will be executed is a common approach to working with releases.

1 Like
3

You could use something like Github Actions (free/cheap) or another CI tool that supports multiple OSs to basically build on each platform then distribute those binaries?

1 Like
4

Hi, thanks for replying. :slightly_smiling_face:

Can you give some idea, what are the major platforms for which I have to build separate releases?

The mix release documentation says…

The following must be the same between the host and the target:

  • Target architecture (for example, x86_64 or ARM)
  • Target vendor + operating system (for example, Windows, Linux, or Darwin/macOS)
  • Target ABI (for example, musl or gnu)

This is often represented in the form of target triples, for example, x86_64-unknown-linux-gnu , x86_64-unknown-linux-musl , x86_64-apple-darwin .

So to be more precise, to deploy straight from a host to a separate target, the Erlang Runtime System (ERTS), and any native dependencies (NIFs), must be compiled for the same target triple.

I want to support all major Linux distributions, what releases should I build using docker, any idea?

5

Architecture hopefully is clear: x86 doesn’t run on arm based hardware.
For Vendor you already said Linux.
So you’re left with ABI / NIF dependencies.
This is difficult to answer, because some of those dependencies are of otp itself (e.g. ssl – musl vs gnu) while other dependencies are because of third party code you pulled in or NIFs of your project, which of cause nobody here knows about.
In general even major version changes on the same linux distribution might require you to build separate releases.

1 Like