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.
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:
Be very careful when you setup a VM : firewalling and securing them are big issues, quite obviously, especially the database.
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.
I have three local scripts to manage the remote servers:
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.
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.
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:
Viewed 1459 times
(
| Print
) this page.