Refresh on "solutions to deploy from Mac to Ubuntu"?

Questions / Help
1

Hello!

Now that Distillery 2.0 is out, I’m in a situation where I need to deploy from a Mac (and probably later, from Windows!) to a single-node Ubuntu server. The blog post specifically mentions that cross-compilation support has not evolved.

The various solutions I’m aware of are:

  • Using a local Docker container (or VirtualBox VM) to create the release and push it to the server
  • Using a “build server”, but at this point with a single-node target, it appears like a waste
  • Building the release on the server itself (may work nicely for a staging server, I know some are doing this, but I would like to avoid doing that on a heavily used production server!)
  • Having Erlang installed on the server (e.g. using asdf) and using releases without ERTS (include_erts: false etc), but then you have to be careful with NIF
  • Building from CI (as reminded by @LostKobrakai)

I would love to get more feedback from people who are dealing with this and are happy with their current, 2018-flavored solutions (not involving a build server ideally).

Thanks!

– Thibaut

1 Like
2

I’d add:

  • Build the release in CI

This is really the “build” server option, but people might not realize that they could just use what they might already use for CI/CD for building and don’t really need to have some dedicated servers just for building. With GitLab there are even free options available.

3

Yes, build the release on CI or the release server. Use distillery 2.0 with dynamic runtime config (rel/config/config.exs) and read sensitive information from environment variable / external config files on the server as the release starts. Forget about REPLACE_OS_VARS :slight_smile:

4

I have just used a VM to build the release. That works just fine

5

Yeah, a VM or a VM on a CI server. The fairly important bit is that your VM OS & architecture versions match the ones on your live server, otherwise you may end up building a release that does work on CI/VM but not on destination server.

I just think it’s simplest solution to keep these two in line, i.e. both running on Ubuntu 16.04 for example. If you build releases locally, even on more recent version of Linux, you might have trouble as the libs/dependencies changed. Common problem has been mismatch of the SSL libraries.

1 Like
6

I like that these solutions being listed here, IMO, this short and concise list should live somewhere in docs or pinned. It’s good for newcomer, also for reminding state of deployment options (2018?).

  • Build on local container or vm I have used this and do not like much having entire OS on my local machine although disk space is cheap (not ture yet for SSD). I’m aware of some very tiny containers (e.g cri-o) going around but we are talking about build not running prod pod.
  • Build on remote server: Yep, ok only if already have a staging server thus is not waste
  • Build on production server: True, I had faced peaking memory while building (without swap). To be fair, it’s mostly about node_modules.
  • Build on local machine excluding erts: I guess this should be most discouraging since NIF could be anywhere in dependencies or none who knows.
  • Build on CI: I like this one. For MVP, use free plan, run test locally mostly. It’d be nice if there is a CI that has a pretty good permission levels policy that we can share (i.e. not seeing each other project)
1 Like