Mix release on WSL deployed phoenix to GCE, same architecture :-) and a few questions

mix-release
ansible
google-compute-engine
#1

Sharing my deployment experience, fyi:

I wanted managed SQL and I decided to try Google Compute Engine for my first phoenix app, and had the pleasant discovery that the architecture and OS can be set to match my WSL dev laptop (x86, Ubuntu 16, gnu).

There are a lot of detailed steps (and quirks) but they’re (mostly) understandable in retrospect; in brief, the general steps were:

  1. create a cloud SQL Postgres instance and run laptop MIX_ENV=prod mix phx.server pointed at it (using cloud_sql_proxy on the laptop); once that was confirmed to work,
  2. MIX_ENV=prod mix release beta1
  3. Use Ansible (and its gcp_compute plugin) to get an inventory of “webserver” instances and copy all of _build/prod/rel/beta1 out to the instance(s) – and this tutorial helped a lot
  4. Manually chmod permissions on erl and releases folders, make tmp writeable
  5. Start cloud_sql_proxy
  6. ./bin/beta1 start

If anyone is interested I can write up the details once I get it automated more with ansible and gcloud. ( I won’t build any roles, just playbooks.) (It’s also talking to couchdb on another instance.)

A few questions:

Q1. Is there any reason not to proceed with this WSL build-straight-to-GCE approach? (I know I could build on GCE, but if WSL works, why not?)

Q2. Everything under the /rel/beta1 folder was 59MB, which took a very long time (2 hours? why?) to copy out with ansible. Wondering about how to approach this: Compress to a file and unpack on the server?

Q3. Regarding the “Directory Structure” section at https://hexdocs.pm/mix/master/Mix.Tasks.Release.html, it would be great to see a table with 3 columns: files, purposes, typical permissions settings. (I assume /tmp is only one that needs write?)

Thanks for reading,
DA

1 Like
#2

For commercial apps I’d usually build a release artifact on a CI server and publish it to some storage for deployment. Eg if you want to auto scale scale nodes at runtime they can fetch the release at startup.

The release should contain a tar file with everything included. Haven’t tried the built in mix support, but I think it is created by default with distillery in prod mode.

#3

Thanks for the reply. That tutorial that I linked to used the storage/autoscale approach you describe, but I’m not getting into that yet. Too much to learn. Keeping it simple as possible and grow slowly.

I’ll tar up the release. I just didn’t remember ansible being so slow to push only 59MB.