Skip to content

DevOps for the Collective Experiences Platform

Jump to bottom
Kevin Chen edited this page Jun 12, 2016 · 6 revisions

Last updated by Kevin: 6/2016.

Quick Reference

Deployment Tech

Our primary deployment tool is mupx. mupx bundles up Meteor apps into normal, better performance node apps (e.g. removing unnecessary overhead like file watching) and deploys that to a server of your choice inside a Docker instance. This configuration is controlled through a mup.json file in the root of the project directory.

Digital Ocean manages the machine our app is hosted on. If you need to manage the machine settings, you can log into the Digital Ocean control panel with the DTR credentials (ping Haoqi on Slack). Otherwise, you can SSH in with ssh [email protected] once your SSH key has been added to the machine (see below for how to do that; you have to do this).

Kevin currently owns the yo-star.xyz domain name that the site's deployed at. We don't have a clear DTR policy or shared account for domain names yet (as of 6/2016), so feel free to do whatever. Ping Kevin on Slack if you need to change the records for some reason.

Deviations from the Standard

The collective experiences platform uses GraphicsMagick on the server to create thumbnails and attach metadata to the images (imports/api/images/images.js). In order for this work, you need to have GraphicsMagick or ImageMagick installed on the machines running the server.

For your local machine, you can just go download either of those pretty easily. If you're on a Mac and have Homebrew (you really should if you don't) you can brew install graphicsmagick. Ubuntu users can apt-get install graphicsmagick. Not sure about Windows. Take a look at the logs as the server is starting up (e.g. should indicate if it could find the GraphicsMagick binary) and upload an image to test.

For production, this means we'll have to install GraphicsMagick in the Docker image. Unfortunately, mupx by default doesn't have options for configuring your what Docker image you want to use, so we had to create and fork the repo. Usually, you'd installed mupx via npm i -g mupx, but you should instead do npm i -g https://github.com/aspin/meteor-up/tarball/v2.0.0 for the custom deployer. If you're curious, the difference is in templates/linux/start.sh, for the lines indicating what Docker image to pull (Docker has a Github like hub that you can specify username/name to ref an image).

In the future, we'd ideally like to move to the version of mup in development by kadirahq, but it's still somewhat in progress. (The last time Kevin tried this it didn't really work.) This isn't particularly high priority unless something in the deployment workflow breaks.

Setup for Newbies

Adding SSH Keys

Refer to this: https://www.digitalocean.com/community/tutorials/how-to-use-ssh-keys-with-digitalocean-droplets. If you've already generated SSH keys previous (for say Github), then you can skip steps 1-2.

mup.json setup

You'll need to make a few changes to the commit mup.json file. Namely, change the servers/pem field to match your SSH private key if it's not named by default id_rsa, and replace the app field with the current full working directory path of your project (e.g. /Users/Kevin/ce-platform).

Do git update-index --assume-unchanged mup.json afterward (ignore any further changes to the mup.json file) so teammates don't have to continuously change the path to the project directory ;).

Deploying

You should be able to just deploy via mupx deploy. Consult the mupx documentation for more info on these commands (e.g. start, stop, reconfig, etc.). Of particular note is mupx logs: the -f argument tails the logs (e.g. lets you just observe it as it grows) and --tail=[n] to retrieve the last n lines.

SSL

We're using Let's Encrypt for free SSL, because Google Maps has some warnings and unsupported behaviors for non-HTTPS domains. These certificates last for a year, so this'll expire and be insecure every spring. Refer to this for directions on using letsencrypt or the Let's Encrypt Getting Started Guide for usage details. The first link's a bit out of date and you only the details on using the letsencrypt client (recently renamed to certbot though), but it's still ok.

I'm not completely clear on these details, but I do believe you want to generate the keys on the server itself, then include copy them from your server back to your local machine, overwriting ssl/fullchain.pem and ssl/privkey.pem in the project directory. Do not commit these files to Github.

Resources

Clone this wiki locally