Archive for June, 2018

Deploying a phoenix app to production, II

June 30, 2018

Consequent to my earlier investigations, I found that edeliver failed to provide what I needed to run a phoenix app in production – although I was able to have a brute force workflow to deploy something to a digital ocean server.

That too, was limited however, in that I was unaware as to how to run my app as a background process (daemonised).

Fast forward a bit, and I found an alternative deployment tool called bootleg: https://github.com/labzero/bootleg

I hence followed the following steps:

1. Added these dependencies to my mix.exs
{:distillery, "~> 1.5", runtime: false},
{:bootleg, "~> 0.7", runtime: false},
{:bootleg_phoenix, "~> 0.2", runtime: false}

2. Ran mix deps.get
3. Ran mix release.init
4. Modified .gitignore so that I was able to commit prod.secret.exs to my repo. Used environment variables instead
5. Modified deploy.exs:
role :build, "server_ip", user: 'root', identity: "~/.ssh/id_rsa", workspace: "/app_build"
role :app, "server_ip", user: 'root', identity: "~/.ssh/id_rsa", workspace: "/app_release"

6. Modified deploy/production.exs:
role :app, [“178.128.34.45”], workspace: “/root/app_release”
7. ssh’d into my server and made sure those directories existed
8. mix bootleg.build
9. mix bootleg.deploy
10. mix bootleg.start

This turned out to be sufficient to deploy my app.

One last thing: I needed to set a blank password for my ssh key. Hopefully bootleg will fix this in a later release.

Screen Shot 2018-06-30 at 12.00.57 PM.png

You can view said site at http://marbles.cthulu.tk:4000/.

Advertisements

Deploying a phoenix app to production

June 25, 2018

I recently followed this tutorial: https://www.digitalocean.com/community/tutorials/how-to-automate-elixir-phoenix-deployment-with-distillery-and-edeliver-on-ubuntu-16-04 to deploy a phoenix app to production. Following the steps, I found that it was helpful in that it built my confidence in the following:

* scp to transfer files or folders to a server
* ~/.ssh/config to ssh into a server on digitalocean via an alias
* I learned about what nginx actually does, in that it is a reverse proxy – and what a reverse proxy actually is
* I learned about edeliver and roughly how it works in conjunction with distillery

However, I found that I failed to progress in the tutorial beyond the point of “mix edeliver upgrade production”. edeliver was failing to work for some reason.

Eventually I just gave up and following an alternative process which I’ve documented in a messy sort of way here (with references): https://github.com/token-cjg/spinning_cat/tree/master .

Basically, to upgrade a release:

On personal computer:

* on personal computer, make and test a change
* push to github

On github:

* merge to master
* make a new release with tag ‘tag’

On production machine:

* wget the new release on production machine
* tar -xzaf
* cd spinning_cat_’tag’
* Install dependencies with mix deps.get
* Create and migrate your database with mix ecto.create && mix ecto.migrate
* Install Node.js dependencies with cd assets && npm install
* Start Phoenix endpoint with mix phx.server

This flow, although more convoluted and less streamlined, works.

However, in the process of doing this, I discovered potentially why I was stuck in the previous tutorial. Essentially, I was missing a few dependencies in order to run things directly on the production machine:

* curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash –
* sudo apt-get install -y nodejs
* sudo apt install npm
* sudo apt-get install gcc g++ make
* curl -sL https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add –
* echo “deb https://dl.yarnpkg.com/debian/ stable main” | sudo tee /etc/apt/sources.list.d/yarn.list
* sudo apt-get update && sudo apt-get install yarn
* sudo apt install nodejs-legacy
* sudo apt-get install inotify-tools

However, I as have yet not tested this.

So I guess, next steps here:

* See if I can get edeliver working
* Learn properly about nginx reverse proxy
* Learn about dns records

Then, further afield:

* Purchase a domain name
* Customise website

Unity project progressions: 50% completion towards first roadmap item!

June 22, 2018

You may recall (well, likely not) that the last time that I wrote in detail (February this year was not in detail) about my Unity project was here: https://confusedgremlin.wordpress.com/2016/11/19/further-thoughts-regarding-unity-project/ (wow, 2016! has it really been that long?) and further back I wrote about roadmap items here: https://confusedgremlin.wordpress.com/2015/02/28/dungeons-and-dragons-video-and-alpha-brainstorming/ (in the dark depths of 2015 …).

In the 2015 post I mentioned:

Hence, it now becomes possible to start working towards a first version of my dungeons and dragons dungeon master style multiplayer game.  In particular, I think there are a number of things that I’d now like to do:

  • Plumb in the multiplayer functionality from my previous project.
  • Introduce a simple and straightforward database model for players and dungeon masters.
  • Allow players to spawn in a world in an appropriate way (without falling forever).
  • Allow the dungeon master to move players around.
  • Allow the dungeon master to switch their camera to a creature under their control and move it around.

I realised pretty quickly that this was an ambitious task, and could take years to progress on.  Fortunately, due to the relatively recent acquisition of some code masterfully written by another developer, and due to the continued reworking of the Bolt multiplayer framework by Photon, I have finally made a small breakthrough.

You can see it in its full glory here:

Basically, I have succeeded in synchronising certain assets between different clients running an instance of a runtime level editor.  So pretty cool! (at least I think so).  Essentially very little done here on my behalf, merely mashing together two codebases (the bolt network library and some code I purchased from somewhere in the internet) until something fell into true.

I also found the BoltEngine cheatsheet extremely useful in this: https://docs.google.com/document/d/1CvN1E2GOvd_AHnkFOSMSJTR96EBGhPRDPgPMiOuJoSg/view#.

So in terms of the above objectives for the first milestone:

  • Plumb in the multiplayer functionality from my previous project.
  • Introduce a simple and straightforward database model for players and dungeon masters.
  • Allow players to spawn in a world in an appropriate way (without falling forever).
  • Allow the dungeon master to move players around.
  • Allow the dungeon master to switch their camera to a creature under their control and move it around.

I suppose I could say that I’ve mostly met the first and second of these.  There is a little bit more work to do in synchronising textures and working on the client UI, as well as determining how much control a client should have over editing, and whether the host/server should determine privileges, but that is well on its way now – I’d say at least 50%, and maybe 75% done.

Next steps would be to provide the ability for clients to drag and drop avatar tokens (first person controller prefabs), and then provide them the option to select one of their avatars and ‘avatar in’ to first person perspective, then allow them to ‘avatar out’.

After that, more segregation of privilege work, in terms of:

  • first figuring out how to allow client A to move certain entities around, which client B (which might be the same as A) has placed.
  • then figuring out how to isolate this power to a particular client (which would likely be the server) iff A is not equal to B

But as you can see, this work is finally on its way!  Very exciting!  It only took three years =P