[MUSIC PLAYING]
Google Cloud offers a first-class experience
for Windows workloads that can help
you reduce your license costs.
Today, we are going to migrate and modernize a legacy web
application built on the .NET Framework to Google Cloud
Platform without changing the source code.
Doing so can make your apps more scalable and more reliable
while helping to reduce operations costs.
We're starting with this familiar e-commerce shop.
It was built using the .NET Framework version 2.0 and still
works.
We'll take the existing application code
and move it to managed SQL server and Windows containers
on Google Kubernetes Engine.
The original Pet Shop architecture
is a typical application deployed on a single VM.
It has two tiers, a presentation layer which is .NET hosted
on IIS on Windows and a data layer with four SQL Server
databases deployed on the same VM.
We want to modernize the presentation layer
to leverage the scalability and resiliency of Kubernetes.
By using containers, we can reduce the footprint
of the application and make it agile for both day-to-day work
and future development.
But first, we want to migrate the data layer
to a managed SQL Server using Cloud SQL for SQL Server.
In the Google Cloud Console, we'll
create our managed SQL Server instance.
There are several details you will need to provide,
such as the name of the instance and the region you prefer.
Be sure to create your database instance in the same region
where you will run your Kubernetes cluster.
Once the instance is created, we need to migrate the databases.
With Import, we can restore an existing database backup file.
In this case, we'll restore a BAK
file we already uploaded to a Cloud Storage bucket.
We'll select our file, give it a name, and import.
Once we do this for each of the four original databases,
we can see the SQL Server instance and the databases
right here from the Cloud Console.
With Cloud SQL for SQL Server, we
can use some of our favorite tools,
such as Microsoft SQL Server Management Studio.
We'll need to use SQL Proxy to help ensure
the connection between our local machine
and Cloud SQL is secure.
Once SQL Proxy is installed, we'll
launch it and point to the instance we just created.
As you can see, the proxy is saying
it is ready for connections.
We'll use SSMS.
We'll provide authentication details.
Note that the server name is localhost--
this is because we use SQL Proxy, which
abstracts the actual address of where the server is located.
After this connection is established,
we can see the databases and interact with them.
We have now migrated our data layer to GCP.
That means we can turn our attention to the presentation
layer and the .NET web application.
Now, we don't need to change anything in the existing web
app code.
All we need to do is create a Docker file.
With Docker, containerization of our app is just three steps.
First, base off of the ASP.NET 3.5 base image.
Second, step into the working directory of IIS.
And third, copy the content of this application
into the container.
To build the container image using the Docker file
we just made, we'll run the command docker
build on a Windows machine that has Docker CLI installed.
Then, to push this new container image into the Google Container
Registry, we'll use docker push.
The Google Container Registry is what
will allow us to reference this image in a Kubernetes cluster.
Before we deploy the web app, we need to resolve one issue--
how to allow the web app to communicate with the databases.
Our new architecture is built around containers.
We can install the Cloud SQL Proxy as a sidecar
alongside our web app.
This means that the web app and Cloud SQL Proxy
will be on the same network, and this will allow the web app
to communicate with the database using localhost as a server.
So we'll need to update the web.config of our web app
so it uses localhost in the SQL Server connection strings
and then rebuild our container image
and push it to the Container Registry.
We'll also build a container image for the SQL Proxy.
First, we'll need a SQL Proxy Docker file.
This time, we'll base off of Microsoft base container
image for Windows Server 2019 Core,
then add SQL Proxy to that, and then invoke the proxy
and point it to the SQL Server instance.
In Docker, we'll build a container image
and then push this image into the registry.
We now have two images, Pet Shop IIS
is the image of the web application
that was containerized, and SQL Proxy Sidecar
is the SQL Proxy that allows the app to connect to the managed
SQL Server.
We'll deploy the application and the SQL Proxy
on the same Pod in a Kubernetes cluster.
But first, we need to provide a YAML file that
describes the state we want for the containers.
Fortunately, we can use a fairly standard boilerplate YAML.
The important part is the node selector,
where we can indicate that we want to deploy into a Windows
node pool.
This means that we want to deploy
our containers as Windows containers running on a Windows
node.
Then we list the containers we want to deploy, the Pet Shop
IIS and SQL Proxy Sidecar images we just made.
Finally, we'll expose this application
using an external IP.
We'll use kubectl to deploy our containers
and check the status of our web app.
Apply starts the deployment.
Get services lists the external IP address of the web app.
Get deployments lists our deployment, now
living in the cloud.
And get pods list the Pods, showing that the application is
up and running.
At this point, we've modernized our web app
into a Kubernetes-managed app running in Pods with one
container for the .NET app and a second container for the SQL
Proxy with secure connections to the managed SQL Server
database.
The advantage of an architecture like this
is that we can scale to two Pods with a single kubectl command.
Check the documentation to get started
and try it out for yourself.
[MUSIC PLAYING]