[MUSIC PLAYING]
MIKE COLEMAN: Hi.
I'm Mike Coleman, a Developer Advocate here at Google Cloud.
In this video, I want to walk you
through how you can use Google Cloud's Migrate for Anthos
to move existing Linux workloads from virtual machines
to containers in just a few steps.
This video builds on an earlier one,
Introducing Migrate for Anthos.
If you haven't watched that video yet,
definitely go check it out, as this one
assumes you've performed the prerequisites we outline there.
Building on what you learned in the first video, let's
jump into an actual migration.
As a brief recap, Migrate for Anthos
has three primary components.
The discovery tool assesses how successful
a migration of a given application might be.
The processing cluster is a Kubernetes cluster
that is used to examine the source VM
and create the migration plan, as well as execute
the actual migration.
And finally, migctl, a command line tool,
like kubectl, for interacting with the processing cluster.
We'll do most of our work today in the Google Cloud Console,
but I will show you a bit of migctl.
And again, to quickly recap, a migration
generally consists of the following steps.
First, create a Google Cloud project,
set up the necessary service accounts,
and enable the appropriate APIs.
Then you create a migration processing cluster.
After that, choose and qualify your target workload.
Then you define your migration source,
create a migration plan, and adjust that plan
to ensure it meets your needs.
After that, you create the actual deployment artifacts.
And then finally, you can deploy the newly containerized
application.
The first two steps were covered in the previous video,
so we'll start by discussing choosing the right workload.
There are some applications that are well-suited for migration
and some that are not.
Linux applications that are a good fit for migration using
Migrate for Anthos include the following application
architectures-- web and application servers,
business logic middleware-- for example, Tomcat--
multi-VM, multi-tier stacks-- for example, lamp--
small and medium sized databases,
like MySQL and PostgreSQL.
In addition, applications best suited
for migration with Migrate for Anthos
have the following operational characteristics.
They have a low duty-cycle and bursty workloads,
they're always-on with low load services, or deployment,
testing, and training-lab environments.
In general, most Linux workloads are compatible with migration.
However, there are some types of workloads that
are not really recommended.
These would include high performance and large in-memory
databases, VMs with special kernel drivers-- for example,
kernel-mode NFS--
apps with dependencies on specific hardware,
and software with licenses tied to certain hardware ID
registration.
For this demo, I'm using a Java application housed in a VM
which also has a Postgres database.
So I have a good feeling that this application
is an appropriate candidate to migrate.
But how can I be sure?
Well, we have a utility for that--
the Migrate for Anthos discovery tool.
The discovery tool has two parts.
The first is a collection script that runs on the source VM
and analyzes the running application.
The analysis script then looks at that information gathered
from the collection phase and gives us a score of 1 to 10
on the likelihood of a successful migration.
You can run your analysis script on a centralized server,
allowing you to batch process collected data.
So let's jump into our demo and look at the discovery
tool, which I've already installed
on the source VM running on Google Compute Engine.
You can consult the Migrate for Anthos docs
for info on how to install the tool.
Before we look at the discovery tool,
I wanted to take a quick overview of the sample
application we're working with, which is the Cymbal Bank app.
So I'm going to go ahead, come down here, and click Sign In.
And what you're going to see here
is a typical banking application.
We're looking at the ledger view here.
I can come up and I can click Send Payment.
I can choose another user from the dropdown.
We'll use Alice here.
I'm going to send her $100, and we're going to click Send.
And you can see the ledger update.
So everything is working the way we expect it to.
Let's look a little bit at how that application
is deployed on the back end.
The application is actually made up
of a combination of Kubernetes services
and then a monolithic service running in a virtual machine.
So on the Kubernetes side, we have four services running.
They handle everything from managing the accounts database
to the web front end we just interacted
with to that dropdown list that we saw,
where we can pull up associated accounts
that the main user has.
We come into here.
This is our VM that we're going to migrate,
and that's the ledger service.
So everything you saw there that dealt with the ledger, that
is handled here-- so how do we update the ledger,
check balances, those sort of things.
The other thing is that this monolith includes the database,
the ledger database.
So there's an accounts database and a ledger database,
and the ledger database lives inside of this VM.
So when we're done, we're going to have migrated this VM
into a Kubernetes service.
So let's get started with that.
So here I am.
I've SSH'd into that ledger monolith service VM.
And as I mentioned before, I've already
installed the Migrate for Anthos discovery tool,
so what we want to do here is, let's take a look
at what that's comprised of.
You have the collect script and the analysis script.
So we're going to go ahead and run that collect script first.
So let me run that, and that's going
to produce a TAR file here.
And we're going to go ahead and then run the analysis
script against that TAR file.
So we'll go ahead and run that.
And then that gives us a CSV file, and let's
cat out the contents of that file.
So this is a little hard to read on the screen.
So what I've done is, I've actually taken and moved
that CSV onto my local machine and loaded it up
into a Google Sheet.
There's a lot of information here.
I'm only going to point out a couple of things.
First, our fit score is a 9, and that is right here.
So we've got a 9 out of 10, and that
means it's a great fit with none to very little manual work,
based on the glossary here.
The other thing I want to point out
is that we do have a Postgres database in the VM
that the fit tool discovered, and we'll
have to deal with that during our migration.
But with a score of 9, we should feel pretty good
that we should be able to migrate this application
with very little effort.
So the next step is to actually create a migration source.
So we're going to do that by moving back here in the Cloud
Console, and we're going to go to Anthos, Migrate
to containers.
Remember, we've already set up our processing cluster.
We did that in our last video.
So the processing cluster is right here.
So now we're going to create a source.
So we'll come in and we'll say Add Source.
And we're going to select our processing cluster.
Click Next.
We're going to go and give this source a name.
And it's going to come from Compute Engine.
Remember, it can come from VMware or AWS or Azure,
as well, but in this case, we're using Compute Engine.
We'll click Next.
In the first video, we created one service
account to actually let us install the components
on the processing cluster.
And now we're going to create a second service
account that lets us deal with that Compute Engine
as a source.
So we will put the Compute Viewer and the Compute Storage
Admin roles onto the service account.
We'll click Next, and we'll go ahead and add the source.
So we come back here.
We have our source all ready for us to go.
Next, let's move on to create our migration.
Now one thing to note is that before I can actually
migrate a VM, I have to stop it, which I've already done.
I've gone into the Google Cloud Console
and I've stopped that ledger service VM,
so it's not running any longer.
With that, I would come in here now
and I click Create Migration.
I take the migration name, and I'll give it a name here.
We'll come down and we'll select the source
that we just created, Linux operating system.
And the virtual machine ID is ledgermonolith-service, so
right there.
And we're going to migrate both the image and data.
In this case, that monolith VM has Postgres running in it,
so we need both the application code and the data.
So let's click Create Migration.
This will take a couple of minutes,
so I'll fast forward the video, and I'll
rejoin you when it's done.
Our migration plan has been generated.
So the next step here is now to make sure
that migration plan is accurate for what we want to do.
So we can come here into Options,
and we can Review and edit the migration plan.
Now I know one thing I'm going to need to change
is, down here under data volumes,
I need to go ahead and tell it that I want to use the Postgres
folder, right?
So we're going to point it at that Postres subdirectory,
because remember, we have that database running there
in our monolithic VM.
So with that, I can save this and generate my artifacts.
So let's click Save and Generate Artifacts.
And it'll save it, and it'll start generating the artifacts.
Again, this will take a couple of minutes,
so I'll pause the video, and I'll
rejoin you when it finishes.
So the migration has completed, and our artifacts
have been generated.
I can click on the link of the migration
here, and click on the Artifacts tab,
and you can get a list of all of them.
So we have a Docker file, but the Docker image has actually
already been created and uploaded
to Container Registry for us, so we don't
need to do anything with that.
What we really care about is this deployment spec.
Now there's a couple of ways you can
grab the deployment spec or any of the artifacts
for that matter.
One is they're stored in a storage bucket
up on Google Cloud Storage, and you
could download them from here.
The other way to do it is to use migctl, the command line
utility, and that's what we're going to do.
So I'm going to move over into Cloud Shell,
and I'm going to issue a migctl migration get-artifacts
command, and that's going to download the artifacts for me.
So let me go ahead here and I'll list out
the deployment_spec.yaml, just to verify it got downloaded.
And that's a standard Kubernetes yaml
file for deploying the service and some other stuff.
We're not going to spend a lot of time going into that.
But what we are going to do now is actually apply it.
Now the processing cluster is different from the production
cluster where I run my applications.
So I need to actually authenticate
into that production cluster.
So let me go ahead and issue the gcloud command
to authenticate into my production cluster,
and we will list out the nodes, just to make
sure I have the right cluster.
And I do.
So the next step is to actually just do a kubectl minus f apply
and apply the deployment spec.
And that's going to create a stateful set.
It's going to create a service, a Persistent Volume,
and a Persistent Volume Claim.
The Persistent Volume and the Persistent Volume Claim
will be used to handle that Postgres database we migrated
over from our monolith VM.
The next thing we need to do is ensure all of the services
can find each other.
The Cymbal Bank app does this through a set
of configuration variables.
Currently, the variables associated with the ledger
service are pointing to the Compute Engine internal DNS
name of the ledger monolith VM, which
has the format of instance name dot
c dot project ID dot internal, which you can see right here.
I'm going to swap those out for the Kubernetes service
name, which is simply ledgermonolith-service.
And if I list my Kubernetes services,
you can see that service listed right here.
So the next thing to do is actually apply that config map,
so those new service mappings take place.
So we'll apply the config map here.
Next, let's go ahead and delete all the existing pods,
and that will force them to pick up the new mappings when
they regenerate.
And after that, what we're going to do
is we're going to list our services,
so we can grab the IP address of our front end,
and check out and make sure the application
is still working as expected.
So I'll copy this.
I'm going to paste it up here into my browser.
So the Cymbal Bank, the app has loaded.
Let's sign in again.
So we're signed in.
Here's the ledger.
Let's go and do a send payment to Alice again.
Let's give her $250 this time, and we'll click Send.
And we can see, the ledger is updated.
So our application is working exactly
as we expect it to after a successful migration.
So there you have it.
In this video, you learned about using Migrate for Anthos
to move Linux workloads into containers, including
how to assess your application, create the migration plan,
execute the migration, and deploy your newly
containerized application.
Be sure to like and subscribe, because we'll
be posting subsequent videos in this series
to cover topics such as best practices
for evaluating your application, how to migrate Windows
workloads, and more.
To get started Migrate for Anthos today,
visit cloud.google.com/migrate/anthos.
[MUSIC PLAYING]