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