Get all Latest Tech news here

Stay with us and get all latest tech news and updates in one place

How we can migrate for Anthos with Cloud Run 2022

Hey guys, This is from, Welcome to our website. If you are new in our website then please subscribe to our newsletter and
stay updated with all the latest news and information.In this post, 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 writing you how you can utilize our migration tools to move your existing VM-based workloads to Cloud Run, Google Cloud’s fully managed server less platform. 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 “server less.”

Serverless platforms allow developers to abstract infrastructure management for a simpler developer experience. With server less 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 ad deploy highly scalable, containerised applications on a fully managed server less platform that allows you to deploy containe rised 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 Server less 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 post 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 post, 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 Server less provides you with the resulting Docker file, you can easily manage updates to your code via standard deployment pipelines. To illustrate how Migrate for Server less 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 Server less 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 post, 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 post 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 post 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.

If you are new then subscribe to our newsletter for useful posts. Stay safe and follow our website for more latest informative posts.
Take care and Bye Bye. Best regards

Leave a Reply

Your email address will not be published.


Stay with us and get all latest tech news and updates in one place