The Adventure Begins
Azure offers many interesting opportunities. For a longest time, I had no reason or time to explore different stacks. Over time, Azure has changed the way I play the game, now it’s all about using the best tool for the right reasons.
Azure is a rich ecosystem of services (a.k.a. Lego Blocks), technology stacks and standards. If something is missing, we can usually overcome the challenge by bring our dependencies with us. Infrastructure as a Service (IaaS) allows us to work in a familiar environment. And Platform as a Service (PaaS) offerings, like Azure App Service, allow us to focus more on delivering business value at a faster pace.
This adventure marks the first of many, where I will explore how I can use multiple stacks on Azure App Service. Let’s start with JSP. Azure Web App has supported Java for a while, and this post is all deploying that first workload. Let’s dive in!
- Azure Java Developer Center
- Download the Azure SDK for Java
- Create a Java web app in Azure App Service
- Upload a custom Java web app to Azure
Deploying a JSP Web App to Azure App Service
Azure App Service supports Tomcat, Jetty, Hudson and Liferay. You can configure the App Service httpPlatform through the portal or by providing its configuration through the web.config.
Custom Configuration Guidelines
The following describes the settings expected for custom Java web apps on Azure.
- The HTTP port used by the Java process is dynamically assigned. The process must use the port from the environment variable HTTP_PLATFORM_PORT.
- All listen ports other than the single HTTP listener should be disabled. In Tomcat, that includes the shutdown, HTTPS, and AJP ports.
- The container needs to be configured for IPv4 traffic only.
- The startup command for the application needs to be set in the configuration.
- Applications that require directories with write permission need to be located in the Azure web app’s content directory, which is D:\home. The environmental variable HOME refers to D:\home.
You can set environment variables as required in the web.config file.
For the purpose of this post, we will configure Azure Web App to use Tomcat through the Application Settings blade.
Saving these configurations will create a webapps folder in the wwwroot.
The webapps folder is important. This is where the WAR file is uploaded in order to deploy the JSP Web App. When a new version of the WAR file is placed in the folder it will get reloaded by the configured httpPlatform (Tomcat or Jetty)
Once the Web App is successfully configured, a place holder JSP Web App is provisioned. It then allows us to validate that everything is working as expected from our favorite browsers.
To replace the place holder JSP Web App with our own, rename the WAR file to ROOT.war and place it in the webapps folder.
Initially, walking through this example, I used an FTP client to upload my WAR file to the webapps folder. Doing so is quite practical and also quite limited. When we work with Azure, we rapidly understand that we must automate everything.
Fortunately we can Automate JSP Web App deployments by configuring Continuous Deployments from DropBox.
Note: I’m using DropBox, because WAR files are binary files. If I were deploying from source code, I would choose to deploy from Source Control solutions like BitBucket, CodePlex, Dropbox, GitHub, or Mercurial.
- Deploy To Web Apps from Dropbox
- How to use the Azure Portal to set up Dropbox deployment.
- Dropbox Deployment to Web Apps. This video walks through the process of connecting a Dropbox folder to a web app and shows how quickly you can get a web app up and running or maintain it using simple drag-and-drop deployment.
This is quite useful, because Azure Web App keeps a historical archive of previous deployments.
And it gives us the ability to redeploy previous versions when things goes horribly wrong.
When Azure Web App Continuous Deployment is connected to our DropBox account, it creates a folder hierarchy under the Apps folder.
By placing the WAR files in the webapps folder, which is a child of the Web App folder, the files get copied to the corresponding webapps folder in the Azure Web App. This then kicks off the automated deployment of the App.
Some applications built using this technology stack can require significant memory, the Web App needs to run on a medium or large dedicated worker pool (VMs), which can provide enough memory. Depending on the application and frameworks, it may also takes several minutes to start-up. For that reason, it is recommended that you set the Web App to Always On.
Please share your questions and observations in the comments below.
The information was useful.
Could you please suggest, how to package a .property file, that I use in my application, and refer to it using a relative path …. so as not to get a FileNotFoundException.
In code, I am referring to the file, only by its name – no path.
So locally in my DEV in Eclipse + WTP, the file is expected to be in the same folder as eclipse.exe.
When deployed in a local Tomcat installation – it is expected in the \bin (C:\apache-tomcat-7.0.65\bin)
When deployed in an Azure AppService, the file was expected in D:\home\site\wwwroot
PS: Snippet of my code, which ends an sb.properties – FNFE
Hi Jeevan, you could store the location in an Environment Variable. This would allow you to specify different paths for each environment (dev/ and cloud).
Can you please tell me how can I set tomcat environment variables? (i.e) org.apache.catalina.session. StandardSession.ACTIVITY_CHECK
Have a look at this page (https://azure.microsoft.com/en-us/documentation/articles/web-sites-java-custom-upload/)
Nicely done, very helpful.