Hi, I'm Rahul Gupta,
Product Manager for Azure migrate.
In this video I'll show you how the
latest tool in Azure Migrate's portfolio
can help you containerize your ASP.NET
and Java web application and migrate it
to containers on Azure Kubernetes
Service with minimal to no code changes.
The Azure Migrate App Containerization
tool looks at the running state
of your application to help you
determine how to package that
application into a container image.
You can then use this
app container to deploy your
application to a container platform like AKS.
Before we look at the tool in action,
let's talk a little bit about why you
may want to migrate your application
to AKS and what are the other
options that are available to you.
There are various reasons why
organisations are migrating to Azure.
Typically the migration strategy
chosen is really dependent on what the
migration triggers are and the expected
business outcomes of that migration.
When infrastructure driven
considerations such as datacenter
consolidation or hardware refresh
cycle are driving migration strategy,
the quickest and the most efficient
way to unlock business value is
to rehost or lift and shift your
applications to Azure virtual machines.
Once the app is migrated to Azure,
you can then progressively embark on a
journey of modernizing your application.
But when it comes to other
considerations such as modernizing
your infrastructure and infrastructure
management practices that are really
driving your migration strategy,
there are a few Azure PaasS services
that can help out for web applications.
Azure
App service offers a fully managed platform
that's purpose built to help you build,
deploy and run your web applications.
The App Service Migration Assistant
tool from Microsoft can help you
migrate your ASP.NET, PHP, and Java
based web applications and run
them natively on Azure App Service.
Azure Kubernetes service is a modern
managed infrastructure platform
that's the ideal choice for you to
run your applications on if you
want that extra bit of control over
your infrastructure while driving
key business outcomes such as
improved utilization and consistent
management. As you look at migrating
your applications to AKS there are a
few different ways you could do this.
You could rewrite or refactor your
application to adopt a more modern
paradigm such as microservices and then
run your application as containers on AKS.
However,
rewriting or refactoring your application
requires skilled developers and a level
of investment that you may not be ready
to make for all your applications,
But these other applications could
certainly still benefit from a
modernization of their infrastructure,
and the Azure Migrate App
Containerization tool is intended to
help you with exactly this use case.
The Azure Migrate App Containerization
tool gives you an easy way to quickly
containerize your application
without fundamentally altering
the application structure and then
migrating that application to a
container on Azure Kubernetes Service
to realize some of the key benefits
such as improved utilization.
Let's see how the tool works in a demo.
For my demo, I'll be containerizing and
migrating a Java based music streaming
application called Airsonic that's
deployed in a two tier configuration on
VMware virtual machines on-premises.
The app tier is a Java web app
running on Apache Tomcat and the
application is backed by a database
server that's running MySQL.
The app stores media content such as music
files and downloaded podcasts on the local
file system of the application server.
I'll be using Azure Migrate App
Containerization tool to containerize
the Airsonic app and run it on a AKS.
The App Containerization Tool is
a standalone application that you
will run on a machine with network
access to your app servers.
The machine running the App Containerization
tool could be any Windows machine,
including a desktop or your laptop machine.
The tool has a web based interface
through which you will interact
with it and I have already logged
into the tool's web interface here.
I've also run through an initial
set of prerequisites that validate
things like Internet connectivity.
I also logged into my Azure account
from the tool so that the tool is
able to connect to Azure services
such as Azure Container Registry
and Azure Kubernetes service
that it needs to talk to.
At this point I can specify the
server or a list of servers that are
hosting the application that needs
to be containerized and migrated.
I do that by providing the fully qualified
domain name or IP address along with the
credentials for the application server.
The tool remotely connects to
the specified server to validate
connectivity and credentials.
When I click on continue,
the tool starts the process of discovering
the list of Java web applications that
are hosted on that particular machine.
Now,
once the applications are discovered,
I can select the applications that
need to be containerized and migrated.
Let me select my Airsonic application.
I need to specify the name to
be used for the container image
that's built for this application.
I'm just going to call that Airsonic
and attach a label to this image.
Now the other cool thing that
this tool can do is it detects
the application configurations such
as database connection strings.
For example, here the tool has identified
that this application has a backing
database and by looking at well
defined connection string patterns,
it's able to identify the database
connection string configuration
that is there in the config file
for this application.
It's now giving me the option to
parameterize this such that I can make
it a deployment time configuration.
That way, I don't have to rebuild
the container image every time I
need the application to connect
to a different database,
or if I need to test the application
before I actually do the migration.
The tool also automatically detects
the application files in dependencies
that need to be packaged into the
container image for the application.
But there may be additional
customizations that you may need.
You may choose to copy some specific
directories or folders from the
server other than the ones that
have been detected by the tool.
For example, like I had mentioned earlier,
the Airsonic App stores media
content such as music and podcasts,
to be streamed on the application server's
local file system in a separate directory
called /var/airsonic.
To include this directory and
contents with the container image,
I edit the application folders
section and specify the list of
additional directories and folders. I
can choose to keep these additional
directories in the container image
or I could externalize them
to persistent storage,
which can also help me reduce my container
image size and improve performance.
This particular feature is also useful
to let me scale my application by
adding multiple replicas with all
replicas working on the same shared
content folders accessed through
this particular persistent volume.
Now that I'm done with my application
discovery and I'm ready to build the
container image for the application,
I'm just going to select an Azure
Container Registry that I can use
to store or publish the container
image that gets built.
I have the option of creating a
new container registry from within
the tool itself,
but I'm going to go ahead and select an
Azure Container Registry that I already have.
At this point,
the tool based on detected application
configurations and other selections
that we made generates a Dockerfile
that I can use to build a Docker
container image for this application.
The Dockerfile generation uses
a set of base values for things
such as the image to use.
Other properties such as the ports
to expose the application on are
detected based on the discovered
application configurations.
I have the option of performing
further edits and customizations
to the Dockerfile before using
it to build the container image.
I'm just going to stick with the
base dockerfile that was generated
and use that to build out my
container image for this application.
So let me click build.
At this point,
the container image build process
has started.
The image build itself happens in
Azure Container Registry service
by using the tasks feature of
Azure Container Registry.
That way I don't have to install
Docker tools or any additional tools
on the machine and I can simply use
the build logs that are generated
here to monitor the progress.
Now that the application's
container images is built,
I am ready to start generating
the Kubernetes definitions and
manifest YAML files that are needed
to deploy this application to AKS.
To do that,
I'm going to select the AKS cluster that
I wish to deploy the application to.
If I'm trying to run a quick
proof of concept,
I have the convenient option of
creating a new AKS cluster to
deploy the application to from
right here in the tool. I'm going to
stick with the previously existing
AKS cluster that I already have.
Since I selected the option to
use persistent volumes with
my containerized application,
I need to specify an Azure file share that
the tool can use during the migration
process to upload data that needs to
be stored in the persistent volumes.
The tool uses this file share as
an intermediate store for content
that needs to be moved over.
I then specify the other application
settings that are needed to
generate the YAML files by clicking
the configure button here.
As you can see, I have a
few different options here.
I can specify a prefix string to
use for the Kubernetes resources
that are generated and the number
of replicas to begin with
for the app.
If the application is an
Internet facing application,
I want to select an external
load balancer for the service,
or if it's an internal application.
I just want to select internal.
Let me go ahead and select external for now.
The next piece here is the database
connection string that I had
parameterized before building my
application's container image.
I use this parameter to specify
details of the database that
the application deployed in
AKS should connect to.
For example,
I may want to perform a test right
now using a test copy of the database
before uploading the application to
connect to my production database.
For my demo,
I've already created a test copy of
my on-premise database in Azure on a
Azure database for mMySQL instance.
I'll use this test copy of the database
to test out my application first
before redeploying the application with
the app parameter set to connect
to my actual production database.
So let me go ahead and do that.
Finally,
I can review and specify whether
my persistent volumes should be
shared across application instances
in the container
or should each instance have its
dedicated persistent volume for
the file system dependencies
that we chose to externalize.
I'm going to leave this shared for now
and go ahead and save these configurations.
When I hit the continue button,
the tool will generate the YAML
files that specify the various
Kubernetes artifacts that are needed
to deploy the application to AKS.
Here again,
I have the option of further
customizing the YAML file before
I use it to deploy my application.
As you can see,
the file has put the deployment
spec for the application using the
container image that was just built
as well as the service spec for the
load balancer that needs to be created.
I'm just going to stick with the
defaults and at this point I can
either take these generated artifacts
and use that with Kubernetes
CLI to deploy the application,
or I can use the deploy button here
to kick off the deployment process.
So let me go ahead and do that.
What this is now doing is it's using
the Kubernetes API to start creating
the artifacts defined in the YAML
file that was generated by the tool.
The application deployment is now complete.
As you can see the application is
now deployed to AKS and can be
reached on this public IP address.
Let's see if I'm able to access
the app on this IP address.
So as you can see I was able to
take an existing Java application
that's running on a Linux server
machine and in a few steps successfully
containerize it, and get the application
deployed on Azure Kubernetes Service.
To recap the demo that you just saw,
the Azure Migrate App Containerization
tool is a standalone tool that
can run on any Windows machine.
The tool can remotely connect to a
Linux server running your Java Web
application that you're looking to
containerize and migrate to AKS.
The tool will identify the application
components that need to be packaged
together into the container image
and generate the Dockerfile that can
help you build that container image.
You can use the Azure Container
Registry's remote build feature
to build your application's
container image and even push
it to your container registry.
The tool will then generate the
Kubernetes manifests that are needed
to deploy the application to AKS.
The customizations built into the
tool will help you parameterize your
application configurations and even
move app contents out of the container
image into a persistent volume.
The artifacts generated by the
tool such as the Dockerfile
And the Kubernetes manifests
can be downloaded,
saved, and further used for day 2 operations.
To learn more about the Azure Migrate
App Containerization tool and our roadmap,
reach out to
appcontainerization@microsoft.com.