Rapid Play Framework Development Subscribe Pub Share

My setup for quickly developing and deploying play apps

My websites (like this one) are all hosted on the same play server and have a small audience (couple thousand hits a day and a couple hundred user accounts) so I can be quite agile. I have settled into a quick play development and deployment setup that may benefit some.

Environment

In terms of environment, I have two development laptops setup quite identically. The code is shared via a private git repository.

Locally, I have a mongo database that I can reload with the production data and I do all my tests locally. For IDE I am just switching from Eclipse to IntelliJ (there drawbacks and advantages to each) with the obligatory VIM plugins for each (the IntelliJ VIM is so annoying, by the way).

I use the play ~run most of the time so play reloads updated code files and re-deploys them instantly. Debugging works well, but I rarely use it - mostly I use IntelliJ as a vi editor with full content assist and stuff.

On the cloud, I have a couple of Ubuntu VMs on Digital cloud's network:

  • an apache proxy - this is the only internet-facing bit. All other boxes are firewalled.
  • a mongo database, secured, firewalled and available from where needed
  • a play/JVM application server,
  • a script engine, separate so hacking it will not expose anything else - using JVM to run scala and JavaScript scripts - see github.com/razie/scripster
  • and usually one more clone/test server

Be very careful when you setup a VM : firewalling and securing them are big issues, quite obviously, especially the database.

Number 1 - SSH

Make sure you setup SSH key authentication between your development laptop(s) and your test and production cloud VM. You cannot believe how much time and effort this will save... as well as no more passwords blogged in clear-text :)

Once you do that, you will be able to simply do ssh vm3.coolscala.com "pwd" to run commands directly on the remote VM. Also easy scp and others. Look it up: setup ssh auto login.

Number 2 - local scripts

I have three local scripts to manage the remote servers:

restart

This will login to the remote application box and restart - certain configuration settings will only take effect only after a restart. A restart is fast and usually non-eventful, under 10-20 seconds on average.

ssh vm3.coolscala.com "cd ~/app; . ./restart"

The remote restart script will kill any Java process mercilessly, save the nohup, look for and apply patches if any and restart:

#!/bin/bash
# restart the process
. ./settings

DT=`date +%F-%T | sed 's/ //g'`

. $APP/stop

rm $APP/RUNNING_PID
mv nohup.out nohup.out.$DT

. $DIST/start
sleep 1
ps -u $RKUSER | grep java

The stop (killer) will try a play stop then kill every living java process, then save the logs:

$PLAYDIR/play stop
sleep 1
kill -9 `ps -u $RKUSER | grep java | sed 's/^ //' | cut -f 1 -d " " | tr '\n' " " `

mv $APP/logs/log.log $APP/logs/log.log.$1.$DT

I haven't used restart in a long time - the app is quite stable now and I usually have changes to deploy anyways.

db backup

The third script is the database backup - it will ssh-hop on three VMs until it reaches the Mongo DB, do the backup, then zip it and scp the file from hop to hop until back on my laptop.

I locally have a "mongorestore" script as well, which will reset my local development DB to be a clone of the production DB - very useful, as it erases any local tests.

Upload

This script will upload any local changes, either assets or code and restart the server.

rm rk.zip
rm RUNNING_PID

cmd /C "play package"

scp target/scala-2.10/racerkidz_2.10-0.1.3-SNAPSHOT.jar modules/wcommon/target/scala-2.10/wcommon_2.10-0.1.3-SNAPSHOT.jar modules/wiki/target/scala-2.10/wiki_2.10-0.1.3-SNAPSHOT.jar vm3.coolscala.com:app/

ssh vm3.coolscala.com ". ~/.bashrc; cd ~/app; . ./update"

Yes - I am developing on Windows with Cygwin and I am using play package and then only copy over the files I am working on. I also have a reset script to copy over everything - but that is too heavy so only done when updating versions of other libraries etc.

Next time we'll see why I've done it this way and how the update mechanism works, in more detail.

Read more play framework posts:


Was this useful?    

By: Razie | 2014-09-11 .. 2017-05-26 | Tags: post , scala , play , programming


See more in: Cool Scala Subscribe

Viewed 1753 times ( | History | Print ) this page.

You need to log in to post a comment!