We wanted to deploy a Play! framework application to the cloud but we didn’t want to take care of all security updates on a virtual machine. Heroku is very expensive and Amazon has had no suitable solutions for our needs. We decided to go with Windows Azure.
The previous process
(& its problems)
Without automation our process was:
- Creating a compressed file containing all the resources and dependencies of our Play! framework Application
- Deploying according to Martin Sawicki’s article on Running Play Framework Applications in Microsoft Azure Cloud Services
With this concept, automation was really hard, but this was a stable starting ground.
The .startup.cmd describes how the environment should be set up to start your cloud service. We need to modify the .startup.cmd executable according to the code below. As you can see I use ZuluJDK because it has all the capabilities to run this Play! framework application.
The next file we need to edit is the definitionFile. You can define your vm size, the name of your project and most importantly, the Endpoint. (The latter should look similar to the code below.)
The name property doesn’t count but the localPort should be set to 9000 or whatever your application listens to. The port property needs to be set to 80, because it redirects your request to your application listening to port 9000.
As mentioned in the article above, you have to modify a few things in <appName>.bat. I think it is easier to set the JAVAOK flag to true instead of setting the JAVAINSTALLED flag to 1. Of course, there is still a problem with the argument list being too long, so you shouldn’t forget about shortening the APP_CLASSPATH variable either. Those two operations can be easily replaced with one single command line script.
If you are new to powershell you can use this:
After you are done with all the modifications, you need to create the WorkerRole package. On our deployment server this cspack is added to the Enviroment Variables.
Now you have everything ready to deploy your packed application to Azure. Just a quick overview of what’s going on during the deployment process:
- You will be “signed in” with the help of your PublishSettings file and the Name of your Subscription; this will identify you.
- Your package will be uploaded to your storage.
- This is kinda necessary. I wasn’t able to deploy from my local machine, because the connection timed out – deployment failed.
- Checking if the given slot of your CloudService is free.
- If the slot is free, a new deployment will be created. It will publish your package from your storage account to the given slot of the CloudeService (with the Configuration you described in you ServiceConfiguration file (*.cscfg).)
- If the slot is ‘taken’ there it will be replaced by your package.
- Checking if the deployment was successful.
Using it is pretty easy: you will need
- the name of the appropriate storage and container,
- the name of your subscription,
- the name of your CloudService,
- the configuration and package files and
- to decide which slot you want to use (Production or Staging)
According to this description you can create a Jenkins job which helps your productivity even more. If you have any questions, don’t be afraid to ask. I’m not an expert but spent a few hours finding a solution to our deployment problem – maybe I can help you even more.
I’m not really satisfied with the concept of deploying your Play! framework application like it’s described above. The solution Heroku provides is quite smooth, but Heroku is more expensive compared to Microsoft Azure, hopefully Microsoft will provide better support for deploying Play! framework Apps to Azure.
Latest posts by Barnabás Oláh (see all)
- The Best Scala Code Formatters and Linting Tools - May 4, 2017
- Environment-dependent database drivers with Slick - August 17, 2016
- Deploying Your Play! Framework App to Azure as a PaaS - May 19, 2016