Deploying Play Framework Apps with the Azure Toolkit for Eclipse

Article
05/12/2015

This post shows how to deploy a Play Framework app using the Azure Toolkit for Eclipse.

Background

I am working on a proof of concept with a customer that has several existing types of applications and is deploying them to Microsoft Azure to better understand application migration capabilities. One of the application types uses the Play framework. While I am not really a Java developer (although I play one on my blog occasionally), I was able to get this up and going in a relatively short amount of time.

Install Java JDK and Play Framework

In a previous post, Creating an Eclipse Development Environment for Azure, I showed how to create a virtual machine that runs Eclipse Luna as an IDE to build Java applications. I am going to use that same VM, but the only thing I am using from it is Eclipse… I don’t need Tomcat or Jetty or even the JRE that is installed on it because Play apps are self-contained and don’t need a container.

I start by installing an older version of the JDK, version 7u79 for Windows 64 bit from https://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html. I need this older version of the JDK because my demo is going to use an older version of Play Framework, version 1.2.5.5 (the latest version at the time of this writing is 2.3.8).

The last thing I did was to edit the environment variables for the machine, making sure that JAVA_HOME points to the right directory where I installed the JDK, and adding the path to Play to the %PATH% variable.

Create an App

Now that we have the JDK and Play installed, we can create an app. Simple enough, just open a command prompt and type “play”. You’ll see some awesome ASCII art and the valid commands.

To create an app, just type “play new <name of app>”. I used “play new playdemo”. You are then asked for a name for the application, I used “Play Demo”.

To test it, run the command “play run <name of app>”. My command is “play run playdemo”.

Now open a browser to https://localhost:9000 and you’ll see the app running. While it looks like just a documentation page, it is actually your app that you can customize.

Open the App Using Eclipse

Now that I have an app, I want to deploy it to Azure. Since I have been doing a bit of work with Eclipse, it’s pretty easy to use the Azure Toolkit for Eclipse to deploy the app. In order to use the Play app with Eclipse, you can use the “eclipsify” command, “play eclipsify playdemo”.

You can now open Eclipse and use the File / Import / General command to import an existing project into the workspace.

Browse for the folder that contains your app.

Click Finish, and you now have an Eclipse project.

Deploy the App Using the Azure Toolkit for Eclipse

OK, now we’ve created an app and opened it with Eclipse. Now it’s time to deploy it using the Azure Toolkit for Eclipse. Choose New / Azure Deployment Project, this project will be used to deploy our application.

Give the project a name and click Next.

I have multiple JDKs installed in my environment, so I choose which JDK to use for this demo.

Normally, I would go to the Server tab and configure my Tomcat or Jetty server, but Play apps don’t need a container… we just click Finish and we’re done. This creates the following project structure.

We now need to tell the deployment project about the Play application. Right-click the WorkerRole1 node and choose Properties. Go to the Components node and see that we are already copying the JDK to the deployment root. Also, notice we have a HelloWorld.war default file that was added to our deployment project. On the Components node, highlight the HelloWorld.war, and remove it.

We now need to deploy the Play framework. On the Components node, click Add. Choose the Directory button and choose the directory where Play is installed. For the Import Method, choose Zip. Click on the “As Name” field and it will generate a name for you. In the deploy method, choose Unzip and leave the To Directory with the default value. This will zip the Play framework directory, upload it to Azure, then unzip the Play framework to the folder we choose.

Choose OK.

We’ll do something just slightly different with our Play app. In the Components node, click Add, then choose Directory and browse to the directory where the Play app resides. The import method this time is Copy, and the deploy method is Copy. This tells the add-in to copy the contents of the folder during deployment.

Click OK.

When we ran our Play app previously, we used port 9000, which is the default. We need to map an external URL to this internal URL. Go to the Endpoints node and add a new endpoint with type “Input”, a public port 80, private port 9000.

We need a way for the cloud service to run our Play application. There are a few ways to do this, but a simple way to do this is to create a .BAT file that will run the same Play command that we ran previously during our smoke test. I just went to my temp directory and created a new .BAT file with the following contents:

PlayDemo.bat

cd play1-1.2.5.5
play run ../playdemo

Here is a screen shot that shows the contents of my file. The filename doesn’t matter, but the relative paths do… they match the relative path structure of how we told Eclipse to deploy our application and the Play framework.

Once we create the .BAT file, we can now add it to our deployment. The import method is Copy, the deploy method is Exec. This will execute the .BAT file in the AppRoot folder, allowing relative paths.

Click OK, and the Components tab looks like the following:

Order matters… we need the JDK first, then the Play framework, then our app, then finally the executable.

Testing Testing… Is This Thing On?

A quick test is to click on the deployment project and then use the menu toolbar button to run in the Azure emulator.

You’ll see a few command prompts pop up, and finally you’ll see a command window with the Play ASCII art (not enough ASCII art in today’s computing if you ask me) and the Azure Compute Emulator will show us that Java is running.

Open a browser and go to https://localhost:9000 (still using our local port for now) and confirm you see the Play app.

Once you’re done playing around, you can reset the Azure emulator to remove the deployment.

Publish to Azure

We’ve confirmed our packaging works as expected, now it’s time to push to Azure. Use the Publish to Azure Cloud button to publish.

On the next screen, you need to provide your publish settings. Click Import, and then download. You are prompted to log in, save the .publishsettings file, and then browse to it.

Click OK, and the details are added for you. You then need to create a Storage account and provide a new Service. Choose the Target OS, I chose Windows Server 2012 R2. You can choose between Staging and Production, I use production to get a clean URL.

Click Publish, and wait. The storage account is created, the cloud service is created, the app is packaged into the .cspkg format, that’s uploaded to Azure, new virtual machines are created, the package is downloaded to the new VM, and its contents unzipped as specified in our settings. There’s quite a bit going on here, so it might take awhile.

The Big Payoff

Of course we have to show the final product is our Play application running in Azure without any modifications.

The bigger payoff is the set of capabilities that the app now has. We can now automatically scale the application automatically as CPU usage dictates, as shown in my post Autoscaling Azure–Cloud Services, with new VM instances being created and destroyed as necessary. The underlying OS doesn’t necessarily need to be managed or patched by us because the guest OS instances are automatically patched as part of the evergreen lifecycle. This is huge… we just focus on the application and data without having to manage the underlying OS.

Another payoff that is maybe not so obvious is that the cloud service role that we just created can be deployed into a virtual network. If we have ExpressRoute or even a site-to-site VPN configured, this means our cloud service can now access on-premises resources without making modifications to our existing code. I showed how to do this in the post Deploy Azure Roles Joined to a VNet Using Eclipse.

Note that in this post, we deployed directly from Eclipse, but it is COMPLETELY possible to use Eclipse to package the solution and then use PowerShell or the cross-platform CLI to upload the artifacts and deploy the package instead of doing this from an IDE.