SPEAKER: In this video, we're going
to go through how you can migrate
a workload-- in this case, the payment
service for an online store from a virtual machine
to a GKE Autopilot cluster.
Before I dive into the core of the demo,
let me say this demo assumes you are already
familiar with both Migrate for GKE and GKE Autopilot.
If you're not, you might want to pause the video
and go get a quick overview of both of these offerings,
and then come back and rejoin me.
With that being said, let's go ahead
and take a look at where we're at.
This is our initial architecture.
You can see the payment service is there on the left in blue,
and it's running in a VM.
When we're done, that will be migrated
to a container like all the other services
in the online boutique.
So let's go ahead and take a look at that online boutique
and see it actually in action.
So I'm going to go here, and I'm going
to click on this barista set.
I'm going to add to cart, and I'm just going
to go down and place my order.
And you can see everything works as expected.
Lastly, before we jump into the migration,
I want to show you the infrastructure real quick.
I have two GKE clusters, one running
Migrate for GKE, the other running the sample application.
You can see that's an Autopilot cluster.
Now, if I click on Workloads, you
can see all of the services running there
for the online boutique.
To perform the actual migration, I'll
start by running an analysis using Migrate
for GKE's migration fit tool to see if our workload is
a good candidate for migration.
Next, I'll create a migration plan,
and I edit it to specify that we want
to enable the resulting container
to run on GKE Autopilot.
From there, I'll execute the actual migration.
This will result in a set of artifacts,
including a Docker file, a container image,
and a pair of YAML files--
one to deploy the Kubernetes services and deployment
and another to manage the configuration
of those primitives.
I'll then deploy the newly migrated workload
using the Kubernetes YAML.
Finally, I'll edit the configuration
for the currently running services
to point them to the newly deployed Kubernetes service,
replacing the virtual machine's DNS name with the Kubernetes
service name.
The first step in any migration process
should be to ensure that the targeted workload is
a good candidate for migration.
With the 1.8 release of Migrate for GKE,
we've introduced via public preview a new migration fit
assessment tool.
This tool can operate against VMs running on VMware vSphere
by directly interacting with the vSphere APIs
or it can be run directly against a single VM.
In the case of our demo today, I'm
operating directly on the VM I want to migrate,
which happens to be running on Google Compute Engine.
But like I said, it could just as easily be running on VMware.
Additionally, Migrate for GKE also
supports migrating workloads from AWS and Azure.
Let's go ahead and take a look at the fit assessment
tool in action.
I'll run the fit assessment tool,
which will gather information about the processes
and services running on my VM.
Then I'll import the resulting data,
which is stored in a TAR file into the fit assessment
database.
I can use the ls command to get a list of VMs
that I've gathered data from previously.
Next, I'll have the fit tool analyze
the collected information.
Once it's finished its assessment,
I will have it produce a report on its findings.
The report can be in HTML or JSON.
I'm going to specify JSON, so I can upload it to the Google
Cloud console later.
Also, while I'm only analyzing a single VM in this demo,
you can batch process this analysis.
Now that I have the report, I'm going
to upload it to the Google Cloud console,
and you can see the result here.
My application is a good fit for migration.
If I want to see exactly what was found on the VM,
I can drill down and take a look here at some of the details.
Before I can actually migrate a VM, I need to stop it.
So let me move into the shell here and issue the stop
instances command.
I'll speed up the video a little bit and when that's finished,
we can move on.
So I've already created a processing cluster
and defined a source, so let's define our migration.
We'll click Create Migration.
I'm going to call it paymentservice.
We're going to select the source I created earlier.
It's Linux, and the VM name is paymentservicevm.
We're going to use the image intent.
We'll click Create Migration and wait for that to finish.
All right, now, we can move on.
So let's go in and edit the actual migration plan.
Now, I need to make a change in here
to ensure that the resulting containers can
run on Autopilot.
So I'll come in and I'm going to add an annotation up here
near the top.
So I'll hit Enter and I'll paste the annotation in.
Then I'm going to scroll down and I
want to change the service in the image name
from paymentservicevm to just paymentservice.
So we'll change it here and we'll change it here.
We'll click Generate Artifacts.
That will take a few minutes, so I'm
going to speed up this video and rejoin you when it's finished.
The migration is finished and I've downloaded the resulting
artifacts into Cloud Shell, so let's take
a look at the config.yaml file.
The config.yaml file is used to control
a bunch of different aspects of the container that's
going to run, including what processes are running
in the container, some things about the file system
and how it's laid out.
Now, I'm not going to spend a lot of time here.
I just wanted you to be aware of this file
because you may have to edit it in the future.
So let's go ahead and apply the deployment_spec.yaml that was
generated.
This is going to create two Kubernetes primitives,
the service and the deployment.
So let's go ahead and take a look at the pods
and see if our new service is up and running yet.
It looks like it's actually still pending,
so I'm going to pause the video and I'll
rejoin you once it's started.
OK, it's been a few minutes.
Let's clear the screen and take another look.
And it looks like our pod is up and running.
So let's go ahead now, we'll clear the screen again,
and then what we're going to do is
we're going to go ahead and check out the online boutique.
Let's go ahead and get the services
so we can get that external IP address.
And we'll copy that up, and we'll paste it in here,
and let's try to buy something.
So the camera, add to cart, complete the purchase.
You see an error.
Now, that's because while I have the new service running,
my VM is stopped and the application is still
trying to access it.
So what I need to do is I need to edit the deployment spec
for the actual application.
And right here, you can see where we set
that payment service address.
So let me change that from the DNS name of the VM
to the service name of the Kubernetes service.
I'll save that out.
We'll go back into the command line,
and I'll apply that deployment spec so
that we can update the services to look not at the VM,
but at that new container we just deployed.
So we'll apply that out.
You can see all the configuration
changes coming along here.
And now, I'm going to go ahead, once again,
make sure that the pods have started up.
Looks like the pod has started up successfully.
So let's go ahead and move back to the online boutique,
and let's try to buy that camera again.
So we'll click Add to Cart.
We'll click Place Order, and everything works as expected.
We have migrated the payment service
from the virtual machine to a container
running on GKE Autopilot.