MIKE COLEMAN: Hi.
I'm Mike Coleman, a developer advocate here at Google Cloud.
In this video, we're going to take a look
at what might be the quickest way to move workloads running
in VMs onto containers.
Specifically, I'll be showing you
how you can utilize our migration
tools to move your existing VM-based workloads to Cloud
Run, Google Cloud's fully managed serverless platform.
[MUSIC PLAYING]
Before we get into the details on Cloud Run and our migration
tooling, let's level set by what we mean when
we use the term "serverless."
Serverless platforms allow developers
to abstract infrastructure management for a simpler
developer experience.
With serverless tools, tasks like managing the underlying
infrastructure are handled by Google Cloud.
This infrastructure scales dynamically as needed.
By handling these day-to-day tasks,
you're freed up to focus on additional value
added tasks, which can ultimately
increase your speed to market.
Cloud Run allows you to develop and deploy
highly scalable, containerised applications
on a fully managed serverless platform that
allows you to deploy containerised workloads
in seconds.
In addition to reduced complexity,
Cloud Run also offers several key benefits,
including increased security via automatic HTTPS and flexibility
with custom domains.
You can write your code using your favorite language--
Go, Python, Java, Ruby, and more.
It's built upon the container and Knative open standards,
enabling portability of your applications.
And you can abstract away all infrastructure management
for a simpler developer experience.
When looking at modernizing existing workloads,
I like to break it down into two big buckets.
The first is the modernization of the underlying
infrastructure, such as running workloads on Cloud Run.
The second is modernizing your existing workloads.
One way to do that is to take an application that
is running inside of a VM and convert it
to run inside of a container.
Migrate for GKE and Serverless is
a set of services that helps with that process
by automating a significant chunk of that work.
When looking at migrating an existing workload,
there are four discrete steps that you'll want to go through.
First, discovery and assessment--
Migrate has a fit assessment tool
that can be used to help identify
what workloads you have running and which are
best candidates for migration.
Take a look at our fit assessment
video for more information.
Next is the setup and planning phase.
Migrated workloads can be run on Cloud Run,
as well as in GKE in Standard or Autopilot mode, or on Anthos.
Additionally, you can orchestrate migration pipelines
to help automate the migration process.
In this video, we're focused on the third phase.
So I won't spend a lot of time on it right here.
The final phase deals with how you manage applications
after they've been migrated.
Because Migrate for GKE and Serverless
provides you with the resulting Docker file,
you can easily manage updates to your code
via standard deployment pipelines.
To illustrate how Migrate for Serverless
works with Cloud Run, I'm going to show you
a demo of taking a Django application's web front
end from a VM and running it on Cloud Run.
We're actually joining the migration process
in the middle.
The application was originally a monolithic VM
that had a front end and the database running together
in the single VM.
We use Google Cloud's Database Migration Service
to move the database to Cloud SQL,
and the web front end is still in a VM.
In this demo, I'll use Migrate for Serverless
to move the Django application out of the VM
and into a container that I will deploy to Cloud Run.
To start the demo, I'll provide Migrate for GKE and Serverless
a source VM.
The Migrate processes will inspect the VM
and then generate a migration plan
that I will edit as needed.
From there, it will generate the deployment artifacts,
including a Docker container.
Once we have that container, I'll deploy that to Cloud Run.
With that background, let's take a look
at the process in action.
Let's start by taking a look at our application in action.
So it's basically just a database of Unicode characters.
So if I click on the waving hand,
I can see different characters for different operating
systems.
Now, because this is Django application,
we are using Nginx and Gunicorn in tandem,
where we have Gunicorn running on a socket,
and we bind that to a port that Nginx is listening on.
We're going to need to change that in our application.
And all of that is being served out
of this virtual machine, which I'm
going to shut down right now.
Shutting down the VM is a prerequisite to migrating it.
So let me stop that VM, and we'll get on
with the actual migration.
With the VM stopped, let's go ahead and create our migration.
So I'll click Create Migration, give the migration a name,
select a source, which I created earlier,
choose Linux system container for the workload
type, the Django GCE instance, and we're just going
to migrate the base image.
So that's going to take a couple of minutes.
I'm going to go ahead and stop the video,
and I'll join you when it's finished.
All right, we're finished now, so let me go ahead
and review and edit my migration plan.
The first thing I need to do is I
need to set this value to True so that we
can use our enhanced runtime and run on Cloud Run.
I also want to disable all these services.
Some of these are used for that Gunicorn Nginx pattern
that we talked about earlier.
Other are services that I don't actually
want to run in production, such as SSH.
So I'm going to disable all of these.
And when I have all of those disabled,
I can come down here and click Save and generate artifacts.
That's going to generate the Docker file as well
as a couple of Docker container images, which I will eventually
deploy onto Cloud Run.
So let me go ahead down here.
I'll click Save and generate artifacts.
Again, this takes a little bit, so I
will fast-forward the video and rejoin you when it's finished.
OK, we've generated those artifacts.
So let's go ahead and move back over here
and take a look at what we've generated.
So if I click on Review Artifacts, we can come in.
And we talked about before-- here's
a Docker file, a Kubernetes deployment spec,
as well as the container image base
layer and the runtime layer.
So we're going to go ahead and move into Cloud Shell here.
I'll use migctl to download my artifacts.
And I can list them out here, and you can see them.
Now, services-config.yaml is a file that we can use to define
services that we want to run in our new container.
And I'm going to use that to define the Gunicorn service
ingress.
So this replaces sort of the systemd configuration
we looked at earlier.
Since I want to include this updated services-config
in my new container, I'm going to go ahead and run Cloud Build
to rebuild my container image.
And that's going to incorporate that services-config
and give me a new version of my container image
that I can deploy into Cloud Run.
So let's let this finish here.
I'll speed it up a little bit.
With that container image created,
let's move into Cloud Run and create a new Cloud Run service.
So we're going to come in here.
We choose that container image we just updated.
We're going to scroll down and we're going
to set an environment variable.
That environment variable tells Cloud Run
that we're using the enhanced runtime from the Migrate
for Containers system.
So let's go in and set that to True.
Then we're going to come in here.
We're going to define the connection to our Cloud SQL
database.
So we'll select that there.
And then we're going to come in here
and we're going to allow unauthenticated invocations so
that we can reach the service more easily.
This will take a second to deploy,
so let's let it run through its thing.
We've got the URL.
I'm going to paste it up here and create a new tab.
Let me grab that, and new tab.
And there's our application running on Cloud Run.
You can see everything working as you would expect it to.
Well, I hope this video showed you
how you can use Google Cloud's Migrate tooling
to move applications out of VMs and into Cloud Run.
For more information, check out our documentation,
and be sure to like and subscribe
so you'll be alerted whenever we publish new content.
[MUSIC PLAYING]