Table of contents
1.
Introduction 📃
2.
Spring Boot to Azure Kubernetes Services
3.
Pre-Migration
3.1.
Check whether the supported Java version works correctly
3.2.
Check the file system
3.3.
Check whether an on-premises connection is needed or not
3.4.
Handle OS-specific codes
3.5.
Handle all outside processes and daemons  
3.5.1.
Maven Projects
3.5.2.
Gradle Projects
3.6.
Check your Database Properties
3.7.
Identify APM agents
3.8.
Identify Zipkin dependencies
3.9.
List External resources 
3.9.1.
Databases
3.9.2.
JMS message brokers
3.9.3.
External Caches
3.10.
List the configuration sources
3.10.1.
List passwords or secret strings
3.10.2.
List Certificates 
3.11.
Look over the deployment architecture
3.11.1.
For each Service, document the hardware requirements
3.11.2.
Document distribution/geo-replication
3.11.3.
Identity and Authorization 
3.11.4.
Resources configured through VMware TAS
3.12.
In-place Testing
4.
Migration 
4.1.
Set up the Azure Container Registry and the Azure Kubernetes Service
4.2.
Create a Docker Image for Spring Boot 
4.3.
Build and integrate the Docker Image to Azure Container Registry
4.4.
Make a public IP address available
4.5.
Deploy to Azure Kubernetes Service
4.6.
Make sure console logging is enabled and set up diagnostics
4.7.
Migrate and enable the identity provider
4.8.
Configure Persistent Storage
5.
Post-migration
5.1.
Suggestions 
6.
Frequently Asked Questions
6.1.
What is Microsoft Azure?
6.2.
What is Azure Kubernetes Services?
6.3.
What are nodes and clusters in AKS?
6.4.
How does AKS ensure better resource utilization?
6.5.
How does AKS ensure security?
7.
Conclusion
Last Updated: Mar 27, 2024
Medium

Spring Boot Application to Azure Kubernetes Services

Author Teesha Goyal
0 upvote
Career growth poll
Do you think IIT Guwahati certified course can help you in your career?

Introduction 📃

Azure Kubernetes Service(AKS) is a fully managed container management service. It is provided by Microsoft Azure which is the leading cloud service provider. The Azure Kubernetes Service provides customer serverless, continuous integration and deployment experience. 

This article will discuss migrating a spring boot application to Azure Kubernetes Services. 

Azure Kubernetes Services

Spring Boot to Azure Kubernetes Services

Moving a Spring boot application to Azure Kubernetes Services is divided into three stages. They are:

  • Pre-migration
  • Migration
  • Post-migration

Spring Boot to Azure Kubernetes Services

Some steps under the pre-migration, migration, and post-migration phases are necessary to move a spring boot application to run on Azure Kubernetes Services. Next, we will discuss each of these phases in detail.

Pre-Migration

Before we start with the migration part of Spring Boot applications to Azure Kubernetes Services, some essential things must be checked and taken care of. Such steps come under the pre-migration phase. 

Check whether the supported Java version works correctly

It is crucial to validate that our application works correctly on the supported java version. It becomes more critical when we are dealing with unsupported JDK. 

Java development Kit

To check the java version used in your application, you can run the following command in your production server.

java -version

Check the file system

When we migrate the spring boot application to Azure Kubernetes Services, it becomes vital to reconfigure the file system being used. In rare cases, we may also require changing the file system's architecture. That is why it becomes necessary to determine whether and how the file system is used.

A spring boot application can be static or dynamic, and the approach to handle both situations is different. Following are the three situations regarding file system management:

  • Static Content: If your application is static and has only static content, then it is easier to handle the file system; you just have to change the location of the data. You can move the content to Azure Blob Storage and add Azure CDN. By adding Azure CDN, you can ensure that your site provides high-speed downloading globally. 
     
  • Static Content published dynamically: If your applications allow dynamically publishing or uploading data in a static manner such that it cannot be modified after creation.  Azure Blob storage and Azure CDN can be used. An Azure function handles uploads and CDN refresh. 
     
  • Dynamic Content: If your application is dynamic, that is, it allows users to upload/publish content and also provides them the ability to manipulate or modify the content after creation, then the above two methods won’t work. In such cases, you can mount Azure Storage shares as persistent volumes.

Check whether an on-premises connection is needed or not

As Azure provides both on-premises and cloud storage, there may be chances that your application needs to access the on-premise data. You can use one of Azure’s connectivity services to deal with this situation. It will help your spring boot application connect to the on-premises data when migrated to Azure Kubernetes Services. 

Handle OS-specific codes

If your application contains OS-specific codes that have dependencies on the host OS, it becomes crucial to remove these dependencies. One such way is by removing the / or \ symbols with paths.get or File.Separator in the file system. 

Handle all outside processes and daemons  

It is essential to eliminate or migrate all the processes outside the application server from the production server to elsewhere. To do so, we have to find the migrated application's spring boot version—the method to find the spring boot version is different in Maven and Gradle Projects. We will discuss both ways now.

Maven Projects

The spring boot version is found in the <parent> element of the project object model file.

Following is an example of <parent> element of the POM file:

<parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>1.3.4.RELEASE</version>
        <relativePath/> <!-- lookup parent from repository →
</parent>

Gradle Projects

The spring boot version in Gradle projects is found in the plugins section. Inside the plugins sections, you will find two different versions; the spring boot version is the one found by the id name of org.springframework.boot.

Following is an example of plugins section in the POM file:

plugins {
  id 'org.springframework.boot' version '1.3.7.RELEASE'
  id 'io.spring.dependency-management' version '1.1.6.RELEASE'
  id 'java'
}

Check your Database Properties

If your application uses a database, then it must be able to continue to do so after it is migrated to Azure Kubernetes Services. To ensure that the application can use the database after migration, you have to review the database properties in your application.properties file.

Databases

If your application uses the on-premises data, you would have to provision Azure’s connectivity services or move the data to the cloud. 

Identify APM agents

Determine the APM (application performance management) agents associated with your project/application. When you migrate the spring boot application to Azure Kubernetes Services, you have to reconfigure these APM agents so they can be included in the Dockerfile or Jib configuration.

Identify Zipkin dependencies

If your application has specific dependencies on Zipkin, it must be identified in advance. To do so, you can check the io.zipkin.java group in your Maven or Gradle dependencies.

List External resources 

Identify all the external resources associated with your application. Such resources can be JMS message brokers, data sources, and URLs of other services. To find the external resources in the spring boot application, you can go to the src/main/directory folder, and inside this folder, you can look for application.properties or application.yml file that contains the external resources associated with your application. 

We will now discuss the three external resources in detail. 

Databases

You need to identify the connection string for any SQL database integrated with your application. It is typically found in the configuration files. There are two files in the src/main/directory folder: application.properties and application.yml file. 

Databases

JMS message brokers

Another external resource to be identified is JSM message brokers. You can look in the build manifest to find the brokers in your application. Two files contain this information; they are pom.xml or build.gradle file.

Following is an example of finding a broker in pom.xml file:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-activemq</artifactId>
</dependency>

Following is an example of finding commercial brokers in build.gradle file:

dependencies {
      ...
      compile("com.ibm.mq:com.ibm.mq.allclient:9.0.4.0")
      ...
    }

The next step is to find the corresponding settings. It can be found in the application.properties and application.yml files.  

Following is an example of IBM MQ from application.yaml file:

ibm:
  mq:
    queueManager: qm1
    channel: dev.ORDERS
    connName: localhost(14)
    user: admin
    password: big$ecr3t

External Caches

Yet another external resource is the external cache. You need to identify the external cache in use by your application beforehand. Search for the relevant configuration to determine whether Session data is cached through Spring Session.

List the configuration sources

List passwords or secret strings

Check the application.properties or application.yml file for any secret strings or passwords inside your application. You must check all the configurations, properties, and environment variables for any passwords or secret strings.

List Certificates 

Record every certificate for communication with backend databases and other systems or with public SSL endpoints. To view the list of all certificates on the production server(s), you can run the following command:

keytool -list -v -keystore <path to keystore>

Look over the deployment architecture

For each Service, document the hardware requirements

Document the following hardware requirements for your application before moving it to Azure Kubernetes Services:

  • Count of running instances.
  • Count of CPUs allocated to each instance.
  • Amount of RAM assigned to each instance.

Document distribution/geo-replication

Find out if the instances of your Spring Boot application are currently dispersed across several locations or data centers. Record the SLA and uptime requirements for the migrating application.

Identity and Authorization 

Identify whether your spring boot application requires authentication and authorization. Also, identify all the identity providers. 

Identity and Authorization

Following are the resources you can use to understand how to configure different identity providers:

Resources configured through VMware TAS

For the applications that are managed via TAS (Tanzu application Service), all the external resources are configured through TAS service bindings. The VCAP_SERVICES variable holds all the information regarding the configuration of these external resources. To view the VCAP_SERVICES variable, you can use the Cloud Foundry Command Line Interface (cf CLI)

VMware TAS

Example of how you can view the configuration of external resources:

# Log into Tanzu application service, if needed (enter credentials when prompted)
cf login -a <API endpoint>

# Set the organization and space name containing the application, if not already selected during login.
cf target org <Organization_Name>
cf target space <Space_Name>

# Display variables for the application
cf env <Application_Name>

In-place Testing

In-place testing means examining the application before migrating it to Azure Kubernetes Services. To assure compatibility and performance, properly test your application.

Migration 

Now that you have done the pre-migration procedures and understand all the essential factors, it’s time to move ahead with the migration process of the spring boot application to Azure Kubernetes Services. All the information collected earlier will be handy when moving the application.

Set up the Azure Container Registry and the Azure Kubernetes Service

Following commands can be used to set up the Azure container registry with the Reader role and the Azure Kubernetes cluster. 

az group create -g $resourceGroup -l eastus
az acr create -g $resourceGroup -n $acrName --sku Standard
az aks create -g $resourceGroup -n $aksName --attach-acr $acrName --network-plugin azure

The network model should be chosen carefully, taking into consideration of the networking requirements of your application. Not all applications require similar network settings, so you must consider your application and find an appropriate setting.

Create a Docker Image for Spring Boot 

Now you have to create a Docker image for your application. For creating a docker image, you will need a supported Java development kit, your JVM runtime options, and a way to pass in environment variables. 

Docker

You must set up the CSI Driver for the Secrets Store Azure Key Vault Provider. You will require the secret codes you listed in the pre-migration stage and create an Azure KeyVault and populate it with all the secret codes. Next, you will need to configure the Azure KeyValut to make the secret accessible to pods.

The startup script that bootstraps your Spring Boot application must also be updated. Before launching the application, this script needs to import the certificates into the Spring Boot Keystore listed earlier.

Build and integrate the Docker Image to Azure Container Registry

You have set up the azure container registry and created the docker file. The next step is to build the docker image, integrate the two, and move the spring boot application to the Azure Container registry.

Now we will discuss the commands you can use to build a docker image and push it into your Azure Container registry. 

Run the following commands to build the deployment file:

mvn package

Run the following command to log into your created Azure container registry (Here, MY_AZURE is an environment variable and holds the name of your Azure Container registry):

az acr login -n ${MY_AZURE}

Following command can be used to build and push the docker image(Here, MY_APP is a variable that contains the name of your spring boot application):

az acr build -t ${MY_AZURE}.azurecr.io/${MY_APP} .

You can also use the Docker command-line interface(CLI) to build and test the image. You can perform local testing, which can help you to refine your docker image before the final push to the Azure Container registry. You need to have Docker CLI and ensure that the Docker daemon is running to perform the testing. 

To build the docker image using CLI, run the following command:

docker build -t ${MY_AZURE}.azurecr.io/${MY_APP}

To test the docker image locally on your system, run the following command:

docker run -it -p 8080:8080 ${MY_AZURE}.azurecr.io/${MY_APP}

To access your application, you can visit http://localhost:8080.

After the testing is complete and you are confident with your docker image, you can push the image into your azure container registry. To do so, you must first log into your Azure container registry in the Azure CLI.

Run the following command to log into your Azure container registry:

az acr login -n ${MY_AZURE}

Run the following command to push your Docker image to your Azure container registry:

docker push ${MY_AZURE}.azurecr.io/${MY_APP}

Make a public IP address available

Now that you have migrated your spring boor application to the Azure container register, you need to create a public static IP address so that the application is accessible outside your internal or virtual network.

Make a public IP address available

 It is your responsibility to provide this public static IP address for your application by using the Azure CLI as shown below:

nodeResourceGroup=$(az aks show -g $resourceGroup -n $aksName --query 'nodeResourceGroup' -o tsv)
publicIp=$(az network public-ip create -g $nodeResourceGroup -n applicationIp --sku Standard --allocation-method Static --query 'publicIp.ipAddress' -o tsv)
echo "Your public IP address is ${publicIp}."

Deploy to Azure Kubernetes Service

Now that the docker image is pushed to the Azure container registry and the IP address is generated, the next step is to deploy your application to Azure Kubernetes Services. If you create an external load balancer, then provision the previous IP address as LoadBalancerIP.

Remember to specify RAM and CPU settings when building your deployment YAML to ensure that your containers are the correct size.

Make sure console logging is enabled and set up diagnostics

You must configure the console logging to log in to the console and not the files directly. You can see the logs using kubectl after an application is moved to Azure Kubernetes Services. 

You can use one of the two log aggregation:

  • LogStash/ELK Stack
  • Splunk

Migrate and enable the identity provider

Use the inventory created in the pre-migration stage and ensure that all the authorization and authentication services are configured per the requirements. 

Configure Persistent Storage

If your application requires persistent non-volatile storage, you must configure the Azure Persistent Volumes. The persistent volume can be provisioned statically and dynamically as per the needs. 

Post-migration

You are done with the migration part. You have completed your spring boot application migration to Azure Kubernetes Services. You must ensure that the application is working as expected by monitoring and maintaining the application. We have provided some suggestions you can apply to your application to ensure smooth working. 

Suggestions 

  • Think about giving the IP address assigned to your ingress controller or application load balancer a DNS name.
  • For the cluster, enable Azure Monitoring to gather container logs, usage tracking, etc.
  • Set up auto-scaling to handle peak-load situations.

Read more, kubernetes interview questions

Frequently Asked Questions

What is Microsoft Azure?

Microsoft Azure is a leading cloud platform that lets you access the cloud services and resources provided by Microsoft. It provides various services, including computation, storage, analytics, and networking. It is widely used for deploying applications.

What is Azure Kubernetes Services?

Azure Kubernetes Service(AKS) is a fully managed container management service. It ensures container orchestration. It is provided by Microsoft Azure which is the leading cloud service provider. The Azure Kubernetes Service provides customer serverless, continuous integration and deployment experience. 

What are nodes and clusters in AKS?

Azure Kubernetes Service(AKS) is a fully managed container management service. A node in AKS is a virtual machine on which the applications run in Kubernetes. A collection of nodes is called clusters. Both nodes and clusters are salient components of AKS. 

How does AKS ensure better resource utilization?

AKS integrates with other development tools to provide auto upgrades of resources. By doing so, we can launch the application with minimal resources, and then AKS automatically scales the resources according to the requirements.  

How does AKS ensure security?

AKS integrated with Azure Active Directory (AD) to provide role-based authorization control(RBAC). RBAC ensures security by providing access to only authorized individuals to the classified data. It also ensures what data is visible to whom.

Conclusion

This article discussed migrating a Spring Boot application to Azure Kubernetes Service. We discussed in detail the pre-migration, migration, and post-migrations steps to migrate your spring boot application to Azure Kubernetes Services. 

Recommended Readings:

I hope you would have gained a better understanding of these topics now!

Are you planning to ace the interviews of reputed product-based companies like AmazonGoogleMicrosoft, and more? 

Attempt our Online Mock Test Series on Coding Ninjas Studio now!
 

Happy Coding!

Live masterclass