[MUSIC PLAYING]
MIKE COLEMAN: Hi, I'm Mike Coleman, a developer advocate
at Google Cloud.
And today I want to talk about some key considerations
you should be aware of when looking to migrate existing
applications from VMs to containers using Migrate
for Anthos.
In a couple of our earlier videos on Migrate for Anthos,
we covered how to use the Discovery
tool to discover what applications
are a good fit for migration.
If you've not checked those out you
may want to watch them and come back.
You can find the links in the description below.
For the remainder of this video, I'm
going to assume that you've already chosen an application,
run the Discovery tool and found that your application is well
suited for migration.
While this is a great place to be,
there are some additional questions
you'll want to answer before proceeding with a migration.
What should I do with any databases I might be using,
how should I handle a VM with multiple applications running
in it, how do my networking requirements translate
to a Kubernetes deployment.
Let's start by looking at handling multiple apps
or services running in a single VM.
A common scenario we often see is an application
where multiple components are running on the same VM.
For instance, perhaps you have a web front end,
a middleware component, and a database
all running together in a monolithic virtual machine.
Now ideally, and with Kubernetes you
have a single process running in each pod.
However by default, Migrate for Anthos
will not create a separate container image
for each service running in VM.
Since Migrate for Anthos will try
to migrate each running service, what you do in a situation
where you have multiple application components
is to ensure that only one is running when
you run the migration process.
For instance, shut down the middleware and the database,
run Migrate for Anthos, and capture the web front end.
Then shut down the web front end and the database,
run Migrate for Anthos and capture the middleware.
With those two components migrated into containers
you'll need to decide what makes the most
sense for your database.
With the database tier you first need
to decide whether or not you're dealing with a mission
critical component.
In some cases, you might be migrating or configuring
a dev test deployment of your application
or perhaps your production application
is configured as a monolith and you
don't want to break out the separate components.
Now you realize, of course, that this configuration doesn't
offer you the ability to easily scale or provide
fault tolerance, but it works for what
you're trying to accomplish.
In this case, you would use Migrate for Anthos
to migrate the data to a persistent volume,
attach that volume to the pod at the appropriate spot
in the file system.
If it's possible to migrate your database to Cloud SQL,
that's a great choice.
You can use Google Cloud's database migration service
to migrate the data, then configure your application
to use Cloud SQL or other managed database service.
From there, you can start to benefit
from the advantages of running your database on a managed
service offering.
Now if Cloud SQL is not a fit, then your next option
could be to run your database natively on Kubernetes.
You would build a cluster and install and configure
the database software using Kubernetes Stateful
Set and persistent volumes.
Then use Migrate for Anthos to export the data from the VM
to the new database.
Finally, if running the database on Kubernetes
is not a good fit, you could migrate the database tier
into a Google Cloud Compute Engine VM using
Migrate for Compute Engine.
There's a great blog post up on our site
providing some additional details
on how to decide where to run your database.
We'll put the link in the description below.
Now that you have individual images
for each of your services, you'll
want to think about networking.
In many cases different services within an application are
accessed using a DNS based resource name. ,
However when migrating to Kubernetes you'll use a service
name.
A good recommendation is to choose short, yet descriptive
service names and ensure your services are all
running in the correct Kubernetes name space.
One way to handle the move from DNS names to service names
is to provide your service names via a Kubernetes config map.
So let's take a look at using that config map
to alter the service discovery.
So I have an application that I migrated over,
a service and an application.
So if I do a get services here, you
will see this ledger monolith service.
That came from a virtual machine using Migrate for Anthos
but I have not changed the DNS mapping
to Kubernetes service mapping.
So it doesn't work.
So I'm going to go ahead and go in
and we're going to open the editor
and we're going to edit the config map.
And we're just going to remove these DNS suffixes.
And when we do that, that will take that
from being a DNS based name to the Kubernetes service
name, which is ledgermonolith-service.
So let me do this last one here.
And then we'll save that out and move back to our terminal
and let's clear the screen and we're
going to go ahead and apply the config map.
And that's going to update the services
on how they communicate.
So if we clear that, now what we need to do
is we need to restart our pods and we'll
do that by deleting them and then
they'll recreate automatically.
So we'll delete them and then let's come up
and let's watch those pods get reloaded.
And this will take a second, so I've sped up the video
and then now we can bounce out here and let's
take a look at our services and make sure we've
got the right IP address.
So we'll do a get service and there's that IP, we'll
move up here into our browser.
We'll do a refresh and you can see
that it's actually working now.
So that is using a config map to move
from DNS based name resolution with a virtual machine
to Kubernetes service based name resolution using
the internal Kubernetes service discovery mechanisms.
As an aside, when dealing with sensitive configuration data,
you want to take advantage of Kubernetes secrets.
For instance, if you need to provide a password
to connect to the database, you can store that
in a Kubernetes secret rather than in a config map.
Check the Kubernetes documentation
for more information on how to configure and use secrets.
Now the next thing to consider is controlling access
to your application.
By default, the deployment spec generated by Migrate
for Anthos contains a suggested headless service
object of type cluster IP.
This means no load balancing and a single cluster internal IP
reachable only from within that cluster.
In the case of our web front end service,
we want to change that to the type load balancer
to allow external access.
You should also consider using some of Kubernetes network
policy features to restrict access
to your various application tiers.
For instance, you might want to use network policies that
allow only the web front end to talk
to the middleware tier and another policy that
allows only the middleware tier to talk to the database.
We've hit a few of the highlights
with regards to things you should
consider as you plan your VM migration using
Migrate for Anthos.
To learn more about Migrate for Anthos,
be sure to check out the Migrate for Anthos documentation.
And this is one video in a series,
so be on the lookout for other Migrate for Anthos videos
and like and subscribe to be notified
as we add additional content.
[MUSIC PLAYING]