Tutorial: Deploying Java EE Apps on Azure (Part 3)
In this final blog in a series of posts that explore different options for running Java EE workloads, we will run it on a Kubernetes cluster.
Join the DZone community and get the full member experience.Join For Free
This is the final blog in a series of posts that explore different options for running Java EE workloads on Azure. In this part, we will run the Java EE app on a Kubernetes cluster in Azure.
The example used in the blog post is a simple three-tier application that uses Java EE 8 specifications such as JAX-RS, EJB, CDI, JPA, JSF, Bean Validation. We will use the Payara Server to deploy the application and use PostgreSQL as the relational database.
During the tutorial, we will cover:
- Postgres setup on Azure
- Setup and configure Azure Kubernetes Service cluster and Azure Container Registry
- Dockerize the Java EE app
- Deploy the application to Kubernetes
- Explore its functionality
If you don't have a Microsoft Azure account, go ahead and sign up for a free one!. The Azure CLI is a cross-platform command-line experience for managing Azure resources - please install it using these instructions.
Set your Azure Subscription ID using the Azure CLI which will be used for this tutorial.
To set your Azure subscription ID
export AZURE_SUBSCRIPTION_ID=[to be filled]
az account set --subscription $AZURE_SUBSCRIPTION_ID
Create a resource group that will contain all the services (resources) which you will create as a part of this tutorial. A resource group is like a logical container that holds related resources for an Azure solution. The resource group includes those resources that you want to manage as a group.
To create a resource group
export AZURE_RESOURCE_GROUP_NAME=[to be filled]
export AZURE_LOCATION=[to be filled]
az group create --name $AZURE_RESOURCE_GROUP_NAME --location $AZURE_LOCATION
Azure Database for PostgreSQL is a relational database service based on the open-source Postgres database engine. It's a fully managed database-as-a-service offering which is available in two deployment options, as a single server, and as a Hyperscale (Citus) cluster
We will be using the single server option for this tutorial.
We will use the
az postgres server create the command to create a Postgres server instance on Azure. First, set up some of the server properties such as the name, admin user, etc.
For storage and SKU options, please refer to the documentation.
And, then invoke the command to initiate the database instance creation:
The provisioning process will take a few minutes.
To check the details of the Postgres database instance you just provisioned, invoke
az postgres server show command.
You should get a JSON response. Please note down the value for the
fullyQualifiedDomainName attribute as you will be using this to connect to the Postgres instance later.
It should be of the format:
You need the
az aks create command to stand up a Kubernetes cluster on Azure
To keep things simple, the below command creates a single node cluster. Feel free to change the specification as per your requirements.
Get the AKS cluster credentials using
az aks get-credentials - as a result,
kubectl will now point to your new cluster. You can confirm the same
If you are interested in learning Kubernetes and Containers using Azure, simply create a free account and get going! A good starting point is to use the quickstarts, tutorials and code samples in the documentation to familiarize yourself with the service. I also highly recommend checking out the 50 days Kubernetes Learning Path. Advanced users might want to refer to Kubernetes best practices or the watch some of the videos for demos, top features and technical sessions.
The Postgres database is not accessible to external services by default. We can use the
az postgres server firewall-rule create command to create a firewall rule to explicitly allow Azure services to access the Postgres instance. This will allow the JavaEE application deployed in AKS to communicate with Postgres.
Note: This setting allows network connections from all IPs within the Azure network. For production use, try to configure the most restrictive firewall rules possible
Azure Container Registry is a managed, private Docker registry service to store and manage your private Docker container images (it based on the open-source Docker Registry 2.0). You can use Azure container registries with your existing container development and deployment pipelines or use Azure Container Registry Tasks to build container images in Azure. You can either build on-demand or fully automate builds with triggers such as source code commits and base image updates.
Let's create a registry to store the Docker image for the JavaEE application. We will use the
az acr create command
We are using the
Basic SKU. Valid value is:
You can log in to the registry once it's created and check the login server
az acr login --name $ACR_NAME
az acr show --name $ACR_NAME --query loginServer --output table
You will use the ACR login server name soon. Its value follows the format:
To access images stored in
Azure Container Registry, you must grant the
Azure Kubernetes Service service principal the correct rights to pull images from ACR.
appId of the service principal which is associated with your AKS cluster.
Find the resource ID for Azure Container Registry.
acrpull permissions to AKS service principal.
Our AKS cluster along with ACR is ready to use!
Clone the git repository
You need to enter the Postgres connectivity information to the
<url> attribute of the
<data-source section in
You can find the
The format is as follows:
Here are the list placeholders which form a part of the JDBC URL:
POSTGRES_FQDNwith value of
AZURE_POSTGRES_ADMIN_USERwith the admin user name used to provision PG
AZURE_POSTGRES_SERVER_NAMEwith server name used to provision PG
AZURE_POSTGRES_ADMIN_PASSWORDwith admin password used to provision PG
Set the required values.
Simply use these commands to replace them.
Here is an e.g. of what the
<data-source> section will look like:
The application is now configured. Let's build it!
mvn clean install
You should have the WAR file available. To confirm
ls -lrt target | grep javaee-cafe.war
Our application artifact (
WAR file) is ready. We can now build the Docker image and push it out to Azure Container Registry. Here is a quick look at the Dockerfile used for this
It builds on top of the base image for
payara/server-full, copies the
WAR file to a folder from where it can be automatically detected and deployed, downloads the Postgres JDBC driver and places it in the appropriate location for the Payara application server. That's it!
To push the image
docker push $ACR_NAME.azurecr.io/$DOCKER_IMAGE
For e.g. if the
ACR_NAME (name of the Azure Container Registry) is
javaeecafe-acr, the resulting Docker image will be
az acr repository list command to check the image.
az acr repository list --name $ACR_NAME --output table
Before deploying the application, please update the Kubernetes manifest file
javaee-cafe.yaml with the name of the Docker image. To be specific, update the
spec.containers.image with the name of the Azure Container Registry which you specified above
It is assumed that the name of the Docker image is
javaee-azure, if not please update that as well.
To deploy the application:
kubectl apply -f javaee-cafe.yml
This should spin up a
Pod. Wait for it to transition to
kubectl get pods -l=app=javaee-cafe -w
Running, confirm that the application has been deployed successfully
kubectl logs -f <replace_with_pod_name>
The application deployment should be in progress and finally, you should see the logs similar to the one below (with the
Successfully autodeployed message)
Explore the Application
We use a
Service type to ensure that our Java EE app is accessible outside of the cluster. The creation of a Kubernetes
Service in Azure does exactly what it's supposed to i.e. provision an Azure Load Balancer behind the scenes.
We can get the load balancer IP by using.
kubectl get svc javaee-cafe
javaee-cafeis the name of the
The value of the
EXTERNAL-IP is the load balancer IP and will be used to access the application
Use your browser to access
http://[LOAD_BALANCER_IP]/javaee-cafe. You can use the UI to create, delete, and see coffees.
The application also exposes a REST API for creating, deleting, and listing coffees.
Get all coffees.
curl -H "Accept: application/json" $JAVAEE_AKS_REST
You should see a JSON response listing both the coffee options you just added
Get a coffee by ID.
curl -H "Accept: application/json" $JAVAEE_AKS_REST/1
Delete a coffee by ID.
curl -X DELETE $JAVAEE_AKS_REST/1
curl -H "Accept: application/json" $JAVAEE_AKS_REST
cappuccino is now deleted.
Right now, we have one instance of our application since we had set
1 in the Kubernetes manifest. We can scale our application horizontally and Kubernetes will ensure that it spins up and maintains the required number of
Pods. To add another instance
kubectl scale deployment javaee-cafe --replicas=2
To confirm that another
Pod has been spun up:
kubectl get pods -l=app=javaee-cafe -w
You can continue accessing the application in the same manner and now the requests will be transparently load-balanced amongst your app instances by the Load Balancer.
Once you are done exploring the application, you can delete the resources. Since we used a resource group, it's as easy as executing a single command.
Please be aware that this will delete all the resources in the group which includes the ones you created as part of the tutorial as well as any other service instances you might have if you used an already existing resource group
az group delete --name $AZURE_RESOURCE_GROUP_NAME
You learned how to leverage Docker containers to package your Java EE application and deploy it on a Kubernetes cluster in Azure along with a managed database offering for long term persistence.
That brings us to the end of this series exploring some of the common ways of deploying Java EE workloads to Azure. I hope you found it useful!
Opinions expressed by DZone contributors are their own.