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:
- 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,
MIX_ENV=prod mix release beta1
- Use
Ansible
(and itsgcp_compute
plugin) to get an inventory of “webserver” instances andcopy
all of_build/prod/rel/beta1
out to the instance(s) – and this tutorial helped a lot - Manually
chmod
permissions on erl and releases folders, make tmp writeable - Start
cloud_sql_proxy
./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