SPEAKER: Hi, everyone.
Thanks for joining us today to see a quick demo of Migrate
for Anthos.
This demo shows how a multi-tier application running
on VM or on prem can be migrated and run on GKE containers.
It also shows how to update an image using the Create a Doctor
file and how to deploy the updated image
as part of day two operations.
So just a little bit of an orientation.
The demo covers an application server and a database server
running on VM or on prem.
We're going to migrate them to a GKE cluster
where the relevant services, like load
balancer and the database application,
were moved as well.
We'll extract the image, apply it to the cluster,
and then we'll go through an image update using Cloud Build
and apply that update using rolling upgrade to the cluster.
This is the VMware deployment we have on prem.
As you can see, the application server and the database server
are running two different operating systems, one SUSE
Linux and the other CentOS.
And for the purpose of this demo,
we already migrated the Suite CRM database as a StatefulSet
and will now migrate the SUSE web and application server.
First, let's look at the application running on prem.
This is an open source CRM application.
It's using a LAMP stack.
You can see here the application running.
Now let's switch over to the Kubernetes cluster side.
And here you can see suitecrm-db container already running
as a stateful set.
We also have the load balancer setup for the application.
And it will serve it once the application
is executed on the cluster.
Let's go and install the Migrate for Anthos software
on that cluster.
For that, we will use the migctl setup install command.
The migctl is available on Cloud Shell.
And the setup install command will connect to the cluster
and apply the different solution components.
You can then run migctl doctor to see
that installation is complete.
And in that case, it will return a check on deployment.
If there are any issues, it will be shown here instead
of the check on deployment.
Next, we will configure the source
from virtual machines that are going to be migrated.
And you configure multiple sources.
In this demo, we will define the VMware on prem as a source.
So we'll configure the manager address for Migrate
for Compute Engine and the cloud extension to which we
want to connect to so that we can use migrate for Compute
Engine as a transport and you can
see the source as configured.
Next, we'll create a migration plan.
For this, we'll identify the VM we would like to migrate.
This is the VM we saw on the VM side.
And since it is a stateless application,
we will specify an image for the intent flag
and then create the migration command
to ask only for image extraction.
The migration plan is written into a YAML file that
can be reviewed and customized.
In the YAML file, you'll see the definitions
for the different artifacts that are going to be generated,
as well as default filters for exclusions of directories
and files that are not going to be included in the image as
well as the target image names for deploying into GCR
once these are built.
Next, we're going to generate the artifacts.
Basically, feeding this migration plan
into the Migrate for Anthos will execute
the migration and the breakdown of these different artifacts.
For this, we will use the makectl
generate artifacts command.
First, the migration plan is validated.
And then it's applied to the cluster.
The migration is applied as a CRD
so you can also use the CRD as an API
to automate this migration.
Then you'll use the makectl migration status
to monitor the status and progress of this migration
throughout its different activities.
What you'll see now is that since we're communicating
with the on prem VMware system, the VMs
that are still running on prem will be picked into a snapshot.
And from that we will start extracting the image.
Here we can see that the image extraction applied
into GCR with the image name that we configured
into the migration plan.
So we skipped the entire upload process to GCR.
In addition, in a bucket in GCS, you
will find the set of created artifacts as doctor file
and deployment artifacts that are
usable for further deployment and day
two operations when you'd like to update this image later.
To download the artifacts, you can
use the migctl migration get artifacts command
with the migration name.
And you can see the deployment spec that was automatically
created or the image that was automatically built.
And this deployment spec can be applied
to this or any other cluster where you would
like to run these workloads.
So let's go ahead and apply the deployment
so that we can see the application running.
Now that the deployment is applied,
it is inserted into the environment we precreated.
Just as a reminder, we have a load balancer set up.
And we also have an autoscaler configured.
So when this deployment goes into place,
the autoscaler kicks in automatically
and sets up a minimum and maximum pods and the monitoring
on the CPU metrics according to those conditions.
So you can immediately see some of the Kubernetes capabilities
in action.
Now let's connect to the load balancer.
And you can see the application running.
We'll just connect to this internal load balancer
and you can see the application now running in GKE.
Now that the application is running,
we're switching to talk about day two operations.
Let's say that we have a package that
is a user mode package in the image
and we would like to update it.
In this case, we will put the user mode package
for update in the doctor file that we downloaded as part
of the generate artifacts.
This is, for example, an Open SSH package.
Then this doctor file can be fed into Cloud Build
with a single G Cloud command.
And we get a new built image that
includes the updated package.
We're using here an update for SUSE Linux.
So we're using the package manager in Zipper
to update the image.
We want you to see the image built.
We've accelerated this process.
It usually takes 12 to 13 minutes to complete,
but we sped this up a bit for the sake of this demo.
Now that the image is updated and built,
if we go to the repository, we can see the updated image
version.
And we can go and perform a rolling update
on the actual deployment.
Remember that we have now a deployment with three pods
running the web front end, so we're
going to apply a live update.
In this live update, you will see the new version
being provisioned alongside the old version and then
the old version being decommissioned.
During this process, the application is staying up.
And you can see that here.
While this process is going on, the application
is still accessible.
And in a few seconds, the update process will be completed.
And now we can see the updated image version has been applied.
And we did not have to touch any of these instances
individually.
That concludes our demo of Migrate for Anthos today.
Thank you so much for taking the time to watch it.
And we look forward to more demo videos in the future.