Introduction

The idea here is to harness the power of Git hooks and Docker to automatically deploy your Play app in a new Docker container upon a simple git push to your production server

 Requirements

1. Git and SSH on your deployment server (easy setup instructions can be found here)
2. Docker installed on your deployment server, as well as a a ‘deploy’ user that will have the Git repository and should be able to access docker (either through sudo or not. Also, I fancy my sudoers file with a bit more organization, so this is what my sudoers looks like [the relevant part at least]).
3. A template Docker container with Play installed. Taig’s container is based on Play 2.2.3 out of the box, but his Dockerfile can serve as inspiration for your own version of Play (yep, you only have to change the version number)

Why

After playing a bit around with Dokku and googling for a dokku-like framework to do this deployment, I realised that fiddling with Dokku to do just what I needed was too cumbersome for the simple objective that I had in mind.

I did went through other frameworks, but everything seemed too complicated. If you actually have a suggestion on a system/framework to do this, please let me know (it can even be dokku, and actually be more simple than I expected [e.g. a custom buildpack that I don’t know about, whatever, let me know]).

The magic

So, all of the magic involved is done through the use of a Git hook. I got the inspiration of the usage of the lock on another post-commit hook that I found on Github (sorry, this was a bit ago and I didn’t took note of the link) and I also got the idea of making sure that the play compilation occurs before we try to build the new container from this great article with tips and lessons on automating deployment with docker (do read, some other lessons might apply in your case), otherwise we might end up with lots of faulty containers just because we had some fortuitous compilation error.

So, the Git hook follows:
As you can see, I’m compiling the code that I receive to the

workspace="/home/deploy/sandbox"

directory, replacing the production conf files that are found at

conf_files="/home/deploy/fb/conf"

with the ones that are on Git (so that you can easily leave your passwords/API keys outside of Git [yep, you should never do that :)]) The rest of the file is pretty much straightforward. I add the JAVA_OPTS when compiling the code with play stage because the arguments -JXmx=512 and -Xmx=512m do not work to lower the memory usage of the compilation itself, that actually does not need 1Gb of memory to run Also, I have set up on the root of the Git repository a Dockerfile that is called into action  with this command:

sudo docker build --tag="joantune/feedburner-prod:$last_commit" .

The Dockerfile that I use is based on Taig’s one, and as you can see, it is pretty basic:

Next steps

I will probably in the future change the build to accommodate a loadbalancer (like Nginx or other) for ‘hotdeploy’ (although with this solution we have only a few seconds of downtime) and more importantly for caching, or eventually even using a CDN for the static files (see this for a great article on how to optimize the serving of static files for play)  .

Anyway, any thoughts on these matters are appreciated. Hope you have found this useful.

Cheers!