1. Step 01 – Getting Started with Google App Engine (GAE)
Welcome back. Welcome to this new section on App Engine. App Engine is one of the most important managed services provided by Google Cloud Platform. Actually, App Engine is one of the earliest managed services in the cloud. Google Cloud Platform first made App Engine available in 2008. Yes, I’m talking about 2008, which was when the financial crisis started. So it’s been almost a decade and a half since the first version of App Engine came about. So let’s get started with App Engine in this section. App Engine is the most straightforward way to deploy and scale your applications in GCP. It provides end-to-end application management. It provides you with a lot of features. It supports Java, Node.js, PHP, Ruby, and Python using preconfigured runt.
You can also use a custom runtime and write code in any language. App Engine also supports running containers, so you can create a container, use a custom runtime, and write code in any specific language. App Engine has really, really good connectivity with other Google Cloud services. If you want to talk to a database like Clouds, or if you want to talk to object storage like Cloud Storage, or if you want to talk to a queue, even that option is provided by App Engine. There are no usage charges for App Engine itself. However, you need to pay for the resource provision. If you have provisioned compute instances through App Engine, then you’d pay for those. Some of the important features of App Engine include automatic load balancing and automatic scaling.
So you can say, “This is the application I would like to run,” and it can auto-scale to as many users as you would like. App Engine would automatically increase the number of instances in which your application is running and balance the load among them. App Engine can take care of the platform updates and also monitor the health of the application. App Engine also provides versioning for your application. You can have multiple versions of your application running and manage traffic between them. So the app engine supports traffic splitting. You can have two versions, three versions or four versions of the application running, and youkan split the traffic between them. You can say I would want to send 30% of my traffic to the latest version. I would want 70% of the traffic to go to V three. So things like traffic splitting can be done very easily using App Engine. Let’s quickly compare the compute engine versus the app engine. So Compute Engine is infrastructure as a service. It provides you with a lot of flexibility. With increased flexibility comes increased responsibility. You are responsible for choosing the image. What OS do you want on the compute engine? What software do you want to install? I don’t want to install Java. I would want to install Python. I would want to install Node.
You need to control that. You also need to decide what hardware you want to run. You also need to configure access and permissions—like certificates and firewalls—and everything else you need to handle. And you are also responsible for the availability and scalability of your application. However, with App Engine’s platform as a service, which is serverless, you have less responsibility. However, you have lower flexibility. So if you want to add a GPU, you cannot do that with an app engine. So if you have a simple Java application, a Python application, or a containerized application already present and you want to easily deploy that to the cloud, App Engine might be the right option. However, if you’d want a lot of flexibility, you’d want a specific operating system, you’d want specific hardware with a GPU attached, and if you’d want fine-grained permissions, then Compute Engine might be the right option for you. In the previous step, we got a 10,000-foot overview of App Engine to understand it further. Let’s get our hands dirty in the subsequent steps. Let’s dig deeper into App Engine in the next steps.
2. Step 02 – Understanding App Engine Environments – Standard and Flexible
Welcome back. Let’s start with understanding some of the important concepts around App Engine. The first concept that you need to understand is the concept of the different environments that App Engine provides. App Engine provides two different kinds of environments: standard and flexible. When you are using Standard, your application runs in language-specific sandboxes. So there is a sandbox for Java, there is a specific sandbox for Python, and your applications would run in that specific, preconfigured sandbox. You can call this an advantage or disadvantage of going to a sandbox. You have complete isolation from OS, disk, and other apps. You don’t need to worry about any of them. All that you need to worry about is your specific application code. App Engine Standard comes in two versions: one that supports Java, Python, PHP, and Go, and older versions of each of these software’s.
So the older versions of Java, Python, PHP, and Go are supported by V1, and there are a few specific restrictions. For Python and PHP runtimes, you have restricted network access, and there are specific whitelisted extensions and libraries that are allowed. So only for the Python and PHP runtimes are there a few more restrictions. You cannot have any network access, and there is a specific set of extensions and libraries that are available. You cannot use anything else when you’re using Python or PHP runtimes. However, there are no such restrictions for the Java or Go runtimes. even with V1.
There is also a V two. So this is the newer version of Standard, which is recommended by Google. So if you are creating a new application and you are planning to use Standard, then you should use the V2 version of Standard. This would support all the newer versions. V2 supports Java, Python, PHP Node, JS, and Ruby Goal. This provides you with full network access, and there are no restrictions on language extensions. So Standard is when you’d want to run applications in language-specific sandboxes. The other option is to run containers that are flexible, which is also called App Engine. This is also called “App Engine Flexible,” so application instances run within Docker containers. One important thing to remember is that when you’re using Flexible, you’re making use of Compute Engine virtual machines. Flexible supports any runtime; there are no restrictions. As such, it has built-in support for certain specific runtimes.
So if you have Python, Java, Node.js, Go, Ruby, PHP, and Net, the built-in support can even build the container for you before you deploy it to App Engine Flexible. However, you can use any runtime as long as you can build a Docker image for it. And with Flexible, you also get access to background processes that are running on the virtual machine. And you can attach local discs to your virtual machines. In this step, we talked about standard versus flexible.
These are the two kinds of environments that are provided by App Engine. App Engine Standard runs applications in language-specific sandboxes. There are a lot of restrictions when you are talking about standards. App Engine Standard V.2 supports Java, Python, PHP, NodeJS, Rupee, and Go. If you want to run a C++ application, you cannot do that in Standard. If you want to run a C application, you cannot do that in Standard. You have to create a container, and then you have to run it in App Engine Flexible. App Engine Flexible is where you would actually run your applications within Docker containers. You have a lot of flexibility when you’re using AppEngine Flexible because it supports any runtime and has built-in support for a certain set of languages. However, if you are able to build a container image, you’d be able to run it using App Engine Flexible. And because your App Engine flexible applications are deployed to compute engine virtual machines, you get access to the background processes and local discs that are attached to your virtual machines. I’m sure you’re having a wonderful time, and I’ll see you on the next step.
3. Step 03 – Understanding App Engine Component Hierarchy
Come back. In the previous step, we talked about the different environments that are provided by App Engine, both standard and flexible. And in this step, let’s talk about the application component hierarchy that is offered by App Engine. Whenever we talk about App Engine, you need to remember about applications, services, and versions. So, what exactly is an application, a service, and a version? Application serves as a sort of container for everything. You can create only one application per project, and the application is the container for everything that you would create as part of your app engine. For example, if I want to deploy three microservices, the first thing I need is to have one application in a specific project, and underneath it, I can create different services for each of the microservices. If you have a full-stack application, then you can also create services, one for the back end and one for the front end. So services are kind of like the microservices or the different app components that you would want to run as part of your app engine. You can have multiple services in a single application. Each service can have its own settings. Earlier services were also called modules. Underneath the service, you can have multiple versions of each service.
A version is simply a version of your service that is associated with code and some configuration. So I can have Version One, Version Two, and Version Three of the service, allowing me to have multiple versions of the same service. Each version can run in one or more instances. So you can see that for this specific version, we have two instances running, and for this version, there are no instances running, so you can have multiple versions existing at the same time. So you can have versions one and two of this application running at the same time, and you can even split traffic between them. So, for example, I might want 10% of traffic to go to V1 and 90% of traffic to go to V2. So you have options to roll back and split traffic as part of your app engine. In this step, we focused on the high-level structure of App Engine. When we are talking about App Engine, you can only have one application per project, and this application acts as the container for all the services that you’d want to create as part of your project. And each service can have multiple versions, and you can easily split traffic and roll back to specific versions. Let’s talk a little bit more about it when we get to the hands-on part of this particular section. I’ll see you in the following step.
4. Step 04 – Comparing App Engine Environments – Standard vs Flexible
Come back in this step and let’s quickly compare the different app engine environments we talked about, including “standard” and “flexible.” What are the different features that are offered by each one of them? Let’s look at them right now. Let’s start with pricing. How do you price the app engine standard? The instance hours are the basis for the app engine standard. You don’t really need to worry about CPU or memory or any such configuration. However, when it comes to the app engine, you are priced based on the amount of CPU memory that is used by your virtual machines.
You are charged based on the number of persistent discs or storage devices that you connect to your virtual machines. There are three different types of scaling that you can do with the app engine: manual, basic, and automatic. Manual is when you’d want to have full control, so you’d want to manually update the number of instances. Basic is recommended when you have ad hoc workloads, such as when I have some load coming in and then nothing for a few hours, and automatically is recommended when you have a continuous flow of traffic. So based on the number of users, you want to automatically scale up and down. We’ll talk a little bit more about scaling options a little later. However, the important thing to remember is that the app engine Flexible does not support Basic; it only supports manual and automatic scaling. App Engine Standard supports all three. The other important thing is scaling to zero. Can you scale down to zero instances with Standard? Yes, you can scale down to zero instances. With standard, if there is no load, you can go down to zero instances. However, with Flexible, there is no such option. A minimum of one instance must be running at all times. If you want to serve traffic, you need to have at least one instance running all the time.
The instance startup time for Standard is two seconds, and the instance startup time for Flexible is two minutes. So if you have applications that you’d want to quickly start, then Standard might be the way to go. Because the instance startup time is in seconds, standard supports rapid scaling, allowing you to scale up and down quickly. However, with Flexible, because it takes a few minutes to scale up, rapid scaling is not really supported. The maximum request timeout for Standard is between one and ten minutes. It can go up to 60 minutes for Flexible. So if you have application requests that go beyond 2030 minutes, then flexible might be the way to go. You can access local discs from Standard, except for the Python and PHP runtimes. This slash “temp” folder can be used. With Flexible, you can attach disks. However, an important thing to remember is that the data storage is ephemeral. It’s not permanent storage. Once the instance is restarted, you’ll lose everything that is on the local storage. Another important feature that App Engine Flexible allows is SSH for debugging because, in the background, there is a virtual machine you can SSH into it. The idea behind this step is to quickly compare the different environments provided by the App Engine—standard versus flexible. I’m sure you’re having a wonderful time, and I’ll see you on the next.
5. Step 05 – Scaling Google App Engine Instances
Back. In the last step, we talked about the different options for scaling instances. We talked about manual, automatic, and basic. We talked about the fact that the AppEngine standard supports all three. However, the app engine offers flexible support. Only two of those Let’s discuss more about scaling instances in this specific step. Automatic means automatically scaling instances based on load. This is recommended for workloads that run continuously.
If you have an application for which you will continuously have users, automatic scaling is recommended. So you can auto scale based on a variety of configurations. You can say this is a CPU utilisation target. You can configure a threshold. You can also say that this is the throughput that I would want. You can configure a throughput threshold. You can configure the maximum number of concurrent requests. How many maximum concurrent requests do you want to serve from a specific instance? So you can scale based on any of these parameters. And you can also configure the maximum number of instances that you’d want to run and the minimum number of instances that you’d want to run. So that’s automatic. for continuously running workloads The next option is basic. Basic is when you want to create instances as and when requests are received. These are recommended for ad-hoc workloads. Instances are completely shed when there is no load. So instances are shut down if there are zero requests.
So if you have ad hoc workloads and it’s very important for you to keep your costs low, then basic scaling might be a good option for you to consider. However, the disadvantage of basic scaling is that high latency is possible. Why is there such high latency? Because it’s possible that there are no requests being served by a basic scaling instance right now, a new instance has to be created, and then your request would be served. Another important thing to remember for Basic is that it is not supported by app engine flexibility. It is only supported by the App Engine standard. When you’re configuring basic scaling, you can specify what the maximum number of instances you can run is and what the ideal timeout is. So if you have no request for a specific amount of time, then you’d go down to zero instances. The last option is the manual one. This is the easiest one as far as configuration is concerned. However, there is a lot of manual work involved. You can configure how many instances to run, and you can keep adjusting it manually over a period of time.
In this step, we looked at the three options for scaling instances in App Engine: automatic, basic, and manual. We talked about the fact that basic computing is not supported by flexible environments. You’d go for automatic for continuously learning workloads; you’d go for basic if you have document workloads and you’d want to keep your cost as low as possible by reducing the number of instances to zero; and if you have the magic wand and you can predict the load, you can go for the manual option. I’m sure you’re having an interesting time.
6. Step 06 – Playing with App Engine in GCP – Google Cloud Platform
Welcome back. Are you bored with all the theories that you have been hearing about App Engine until now? Let’s get started with playing with App Engine right now. Let’s prepare an application for the cloud using the App Engine standard. The first thing I would do, as usual, is go to our Google Cloud platform. And what we do now is create a new project for this specific app engine. The thing is, I can actually create an app engine for this specific project as well. That should not be a problem. But I would want to show you the creation of the project and all that process as well to you.
So let’s create a new project and create an app engine in there. That also allows us to delete the project and delete everything that is present in it. So your App Engine would be automatically deleted as soon as I deleted the project. So instead of deleting individual resources that are present in the project, let’s try and shut down the project and see that in action too. So let’s go ahead and start creating a project. So I’ll go into the project screen, and I’ll say “New project.” And I’ll call this app engine—or I’ll call this learning app engine project—an app engine. Learning app engine project You can see that there is a limit to how many projects we’ll have. We can have up to 21 projects. So that’s a lot. And you can see that we are under no organization because we are using a free tab account. So all that is fine. So let’s go ahead and say “Create.” So the project would be created in a little while. So, if I go in here and select Learning AppProject, you’ll notice that there’s a new project over here.
And over here, I can switch back and forth between the projects. So my first project is now Let’s get back to focusing on App Engine. So inside this learning App Engine project, I would want to use App Engine. What would I need to do? First, I would need to go to App Engine. Right. So when I go to App Engine, one thing will happen. What would happen? Think about it. Whenever you want to make use of any service within a new project, the first thing that you need to do is enable the APIs for that specific service. So, within this project, if I go into AppEngine APIs so you can see, let me actually close this panel so we can see clearly. As a result, you can see App Engine. If I type it in, I can see the app engine admin API. And if I go to the App Engine admin API for this specific project, let’s see what comes up. You can see that the API is not enabled right now. One thing you can do is enable this API here.
The other way to enable the API in here is if I go back and, let’s say, try to create a new AppEngine application, the first thing that we are choosing is a region. So, when we create an App Engine application, the first thing we need to decide is which region we want to deploy our application in. We already discussed the fact that within one project, you can only have one App Engine application. You can have multiple services under the application, but there can only be one container and one application at the top. And right now, you are also seeing that that application in a specific AppEngine is also associated with a single region. So if you want to create App Engine applications in multiple regions, you need to create multiple projects. So for now, let’s choose the default, which is suggested, and say “Create App.” So this would create our App Engine application, and I can also choose the language and the environment.
You can choose the defaults that are suggested by App Engine. It’s suggesting Python and standard. That’s fine. Let’s go ahead and say “next.” And now you can see that it says your app is being created and that your Apennine app has been successfully created. Now we’d want to deploy a service to the App Engine. How can we do that? The way you can do that is by going to Cloud Shell. So I’ll go to Cloud Shell, and you’ll notice a very interesting option over here. So over here, you can also click “Open Editor” to open an editor. So if I click Open Editor over here, I’m getting an error saying it’s unable to load code Editor because third-party cookies are disabled. I’d go ahead and open it in a new window. So I’ll say, “Open it in a new window.” So what you’d see is that a code editor would be opening up so that we could edit our project in there.
I’m using Safari, and it looks like I’m having a few problems with the code editor in Safari. Let’s go to Chrome. I’ve already authenticated with Google Cloud before. That’s the reason why it would open up the terminal directly without asking me for a password or anything. And I can go in here and say, “Open, editor.” When you click Editor, the editor will open in half-screen mode. I don’t really like half-screen, so I’ll say “Open in New Window,” and this would take a little while, so let’s wait for it to get started. When you open up Cloud Shell Editor, you’ll see that you’ll be able to edit code in here, and you’ll also have the command prompt available if you want to run any commands.
We’ll use both of them. Right now, what I’ll do in here is say “Open Folder,” and I’ll choose my Home folder and say “Open.” Now, over here in the Home folder, that’s where I would copy all the things that we have already in the downloads. If you look at the zip file that you’d have downloaded earlier and extract it, you should see a folder called Downloads. And in Downloads, you should see multiple folders. The specific one in which we are interested right now is App Engine. So if you go into App Engine (apphyphen Engine), there are two services that are present: the default service and my first service. What I’d do now is drag and drop them into this box. So I’m dragging them from here and putting them into the Explorer part of it. You can see that I’m putting it into the Explorer part of it, and you’d see that those files would be automatically copied in. And if I go into the command prompt and say LS, I should be able to see the default service, my first service. And you’d see that these folders have a few files as well. You don’t really need to understand these services in depth.
A high-level overview should be more than sufficient. In each folder, there are three files. One is App YML, which is the configuration for the app engine for that specific application. Main PY is where the Python code for this specific application is present. The requirements text is the place where we are defining the dependencies of this specific application. If you are familiar with Maven, then this is very similar to MavenProm XML. If you’re familiar with JavaScript, this requirements dot text is very similar to package JSON, where you define your node application’s dependencies. So if I open up the requirements text, there is a framework defined, which is Flask, which is a framework that is a Python framework to develop simple web applications or Rest APIs.
And if you open up the main.pi, it’s very simple code. There is nothing complex in here. We only have a standard service that returns a simple response. My default service is V. Now it’s asking me for a preview of the new Python language server to get, and I’m not really worried about it, so I’ll say “close.” So this is a very simple Python application that returns my default service V. and you have an app YAML with some simple configuration in here as well. We are going to use Python 39 as a runtime of Python 39.App YAML is the application configuration that you are providing to App Engine. When you try to deploy this app to App Engine, it will look at this App YML file and see that you are configuring a Python 39 runtime. And if you are deploying it to App Engine Standard, it would make use of the Python Three Nine.
Three-nine Python Let’s first start with the default service. So we have two folders in here: the default service and my first service. We’ll talk about why we have two services a little later. For now, let’s focus on just the default service. So over here, I’ll say “CD default Hyphen service.” So, carefully examine which folder I am in. So I am in the default service folder. And over here, I’d want to do a G Cloud app deployment. We want to deploy this app to Gcloud. But before we deploy the app, one important thing that you always need to be focused on is which project you are deploying this app to, right? And we have two projects; which one are we making use of? Let’s take a look at the configuration settings list to see what credentials it requires. let’s authorise You can see that we don’t really have any projects configured, so let’s start with configuring the project, so gcloud config setproject and we want the app engine project.
So, let’s dive into the app engine project; it has a nice name, “Melodic Furnace,” and the project ID is 304906. Interesting. So let’s set the project to that. Now that we have set the project to that, you can see three things in here, right? which ID I’m making use of. What is the current folder and the project as well? The active project is melodic furnace 304906. Let’s now go ahead and say “G cloud app deploy.” The important thing is that if I actually did a LS in here, you’d see that theapp.dot.YML is present directly in here. So if I actually did cat app dot YML, you’d see the content of cat app YAML right here. As a result, it includes Python 39 runtime. That looks good. So let’s do a clear before deploying the app. So, “cloud app deployment,” let’s give that a shot. Cool, it’s now asking me a few things.
Let me make this a little bigger so that you can see more details. When deploying gCloud app deployment services, you can see that the descriptor used is app YAML. You can also pass the YAML file containing the app’s configuration to the gcloud app deploy command. However, the default is app YAML, and because we have the same name, app YAML, it uses the default configuration, and this is the descriptor. The source is present in this specific folder. The project’s source is default hyphen service, and the target project is shown, and you can see that the target service we discussed is that an application can contain multiple services. One of those services is called a default service. So right now we did not specify a service name at all, which is why it’s making use of the default service, and we did not also specify a version for this specific deployment. So, we’ll look at how to specify a version when deploying it later, but for now, because we didn’t specify one, a calculated version was used.
When I try to deploy a gotan error, it tells me that access to the bucket is denied. It says you must grant Storage Object permission to a specific service account. Now what we’ll do is fix this and then try to understand what’s happening. So what can we do to fix this? What you can do is go over there and search for IAM. IAM is where you can configure permissions for different things. You can configure permissions for people and configure permissions for applications, identity, and access management. Let’s go over to IAM and Admin. Over here in the members, you can see all the different members who are present. And if you look at this specific thing, this is a specific name, and you can see that there is this specific member with that specific name. And what I’ll do now is click Edit Member. I would need to give him a new role. So I’ll go ahead and say, “Add another role,” and what is the name of the role? The role of storage object viewer permission is also present inhere, storage Object Viewer Permission.So I’ll go ahead and grant storage-object viewer permission and save. Now that this role has both of these permissions, I can return to our GCP and AWS deployments. Let’s say this is successful this time. So do you want to continue?
Yes. Beginning deployment. It’s saying “Uploading zero files” because the cloud files were already uploaded, but the failure happened with the build enough. It says “updating service.” Now, let’s try to figure out what was going on and why we needed to assign additional roles whenever we deployed something to the App Engine standard. What happens in the background is that a deployment package is created, and the deployment package is sent to an object storage service that is present in Google Cloud, which is called Google Cloud Storage. However, the package is created using a continuous integration and continuous deployment tool that is present in Google Cloud and called Cloud Build. Cloud Build needs to access the package that was uploaded to Google Cloud Storage. And the error we got was that CloudBuild was not able to access the package, which is present in Google Cloud Storage.
And the way we give permission to Cloud Build is by giving access to something called a Cloud Build service account. So there is a service account that was automatically created when we started the deployment, and we went to that service account and gave it permission to access data that is present in cloud storage. So we gave it Storage Object Viewer permissions, and within a little while, I see that the deployment was successful and the URL is printed in here. If I actually pick up the URL from here and go and execute it, you would see my default service setting of 1. Where is this coming from? We saw that earlier. This is where it’s coming from. Main PY is my default service v one. So this is where that text is coming from, and it’s a very, very long step. We were able to finally deploy our application to the Google App Engine. Let’s try to understand it a little more in the next step.
7. Step 07 – Exploring App Engine in GCP – App, Services and Versions
Welcome back. In the previous step, we created our first version of the service and were able to successfully deploy it to App Engine. Let’s now go into the UI and see what’s happening there. So let’s go into the app engine. So I’m in the same project learning the app engine project. I’m off to the app engine. I’d like to see what’s available in the app engine. So this is the App Pinching dashboard, where you can look at some of the metrics around specific versions. You can see that this is a beta version, and right now there is no data present because we have just launched it up.If you give it a little time, you should see some data come up in here. If you scroll down, you can also see what the billing status is, what the cost is, and what the current load is on this specific application. You can also see if there are any application errors, server errors, or client errors.
We don’t really have a fair value configured, so don’t really worry about it. Now let’s go to services. Services is where you would see the default service. We have created one service, which is the default service, and that’s what you would see in here. You can see that there is one version for this specific service. So, if you go to versions, you’ll be able to see which version is currently serving traffic. So you can see that 100% of the traffic for that service is being served by this version. And you can see that if I go to instances right now. If I go to instances and scroll down a little, I can see the current instances that are running now. You can also get the same information on the command line as well. So it was Google Cloud Compute for compute and Google App Engine for app engine. It’s it’s.
As a result, all commands begin with app earlier. To deploy the application, we use Gcloud App Deploy, but for now, we want to list the services. So I would say “Gcloud App Services List.” So I’d want to list all the services that are present. You can see that there is only one service and one version by default. You can also list versions in the gCloud App versions list. So what are the different versions that are present? So you can see that there is one default version, which is present and handling all the traffic. And you can also list the different instances that are part of the app. So it is with the list of cloud app instances. So this would list all the instances that are present right now. So that’s cool. We have one version of this service deployed. Now, you don’t want to deploy another version of this service. How can I do that? The way we can do that is by actually using V Two.So my default service, V2, is what we would want to use, and now I would want to deploy V2 of the new service. As a result, V2 of the new service would return V2.
How can I make Version 2 of the service available? So I can say “Gcloud app deploy,” and then the version label would be automatically assigned by the app engine. Or I can take control as well. I can say I would want to specify the version, so I can say the gCloud app deployed version is equal to V Two.So I’ll specify the version, the new version, as “2,” and see what happens. So it’s trying to now deploy the V-2, and it says, “Okay, app YML is where your configuration is.” This is the target project; that’s fine. The target service is “default.” That’s good. And the target version is V two.And there is also a URL that is present here.
So it says, “Do you want to continue?” I’ll say yes, so let’s go ahead and say yes. and this would deploy the application. So it would upload the changed file alone to Google Cloud Storage, and it would start running the cloud build to deploy the package to the App Service. So all that happens in the background without V worrying about it at all. But what is important is that while deployment is in progress, you’d see that this application (V1) is still running. So you can keep sending a few requests for this. So you will see that this is still running. So even when we are deploying a new version, you’d see that version one of the application is still running. So let’s wait for the deployment to be complete. It should take a minute or so, not more than that. Okay, it says “updating service” and “setting traffic split for service” are completed. And I’ll try to refresh this once it comes back.
You can see that V-2 is now live. As soon as V-2 was deployed, traffic was switched to V-2. So that’s what was done when this was updated. So the traffic split for the service default has been set. Whenever we are just doing a deployment, traffic is automatically switched over to the new version of the service. And if I actually try and access this NAV, you can see that V-2 is the one that is responding back. What do you expect? You can see that there are two versions. You can see the traffic split. You can see that Version 2 is serving all the traffic, whereas the earlier version is not serving any traffic. However, both instances are up and running. Now I want to find out the URL for this specific version. So I would want to be able to see if this version is still running. How can I find the URL? So you can say “gcloud app browse” – oh, that should be “gcloud app browse,” not “browser.” Let’s see if it works. You can see that it’s giving me the link to the active version. I want the link to a specific version so that I can say something like “gcloud app browse version equals let’s go and specify the version from there.” Let’s go and pick up the version from here and paste it in. I don’t need the double quotes. Let’s smooth out the double quotes.
The version is equal to this or version space this.So you can see that there is a way you can access the old version as well. So when you deploy the new version, the old version is still running. However, it is not serving any traffic. You can see that this is written one back if I click that link with CTRL and click that or command and click that. If you look at these URLs, the difference is over here in the version name of the service, a specific suffix. So that’s how the URLs are built. However, if you looked at the default URL, you’d notice that it only had the service’s name plus a specific suffix. In this step, we deployed a couple of versions of our application and were able to successfully do that. I’ll see you in the following step.
8. Step 08 – Splitting Traffic between Multiple versions in App Engine
Welcome back. In the previous step, we deployed version two of the service, and we saw that the traffic was automatically shifted to version two. Sometimes you don’t really want that to happen automatically. You want to deploy the new version and slowly switch traffic to the new version. How do you do that? Let’s look at that in this specific step. So earlier we did G Cloud app deployand we specify the version V two.Now we want to slowly control the migration of traffic to the new version. How can I do that before then? Let’s create a new version. So let’s call this V three.So I’ll save this. So I’m changing the main dot from PY to V three.
And what I would do now is go in here and say, “Now I’ll go into the command prompt, and I’ll say this is V three.” However, I don’t want to shift the traffic immediately to V three.I would want to see one of them live. I want to test V3 before switching traffic to V3. And the option that is provided is “no promotion.” So the option hyphen is no promote. iPhone No, this is the option where you can deploy a new version without switching traffic to it. So this traffic would still be going to the old version, which is V2. Right? So let’s go ahead and do this Gcloud app deployment version. You can see that it shows all the details. The version is 3. That looks good; let’s go ahead and say yes; the default is to promote. However, we chose the hyphen option. “Hyphen no Promote” indicates that it will not be promoted. So a lot of these yes and no options in Google Cloud would have very, very similar options. So hyphenate and promote. And hyphenaven is the inverse of that. No. Promote. I really like that because it makes it very, very easy to remember.
Now let’s see if the service is deploying fine. It’s going in. So the service is getting updated right now. However, you would see that after updating the service, there is no switching of traffic. So if you go over to the URL, the default URL, the service URL is still there; what is it referring to? V two. You can, however, go ahead and say, “I want to actually test V 3.” So you can go and say “app browse version 3” and create the URL for it. Actually, you can test version v3 by saying “gcloud app browse version v3” and taking that URL. Hey, I got the right response back. So my V3 is operational. Basically, you would have your users test it, and then you could go and say, “I don’t want to make it live, but I don’t want to make all the traffic go to Channel 3 directly.” I don’t want to actually switch some of the traffic and observe what’s happening in production. How can I do that? So I can say to Cloud App Services that what I want to do is set traffic, and I would want to split the traffic. So the split is equal, and I would want to specify the split. I’d like to split it so that I only send v three and zero five. Probably.
If it was a production application, I would probably send zero five or zero one. I just moved the traffic between V3 and V2 over here. So, with the traffic at three and half of the traffic at two, I can say that comma v two equals zero five. So have the traffic go to v. two; have the traffic go to v. three. That’s what we would want. Let’s press enter. Oops, I had a typo. It should be splits rather than splits. So Gcloud app traffic, set traffic, splits, splits, and it should be specified with the hyphen. As a result, hyphen hen splits equals this. Okay? Now it says “setting the traffic.” As a result, for v 3.5, v 2 0.5. And it says “splitting traffic by IP.” So the default way to split traffic is by IP address. So, depending on where the traffic is coming from, it would be split. So let’s go ahead and say yes. So now I’ll take this URL, and what I would do in here is curl. So I’ll do a watch curl on this URL. Curling this URL will therefore send a Get request to this URL. Watch curl. URL would actually send a Get request to this URL every 2 seconds. So let’s see what would happen.
V two, v two, v two, v two, v two. So over here, I’m getting v. 2. You might have gotten two; you might even get three. But the important thing is that because I’m sending this request from the same IP address, I’ve decided to split it by IP address. Once a request comes from my address, it will serve the same version. and that’s not good. Let’s do a Control C or Command C, and let’s actually change how we set traffic. Splitting by IP might be useful in a lot of scenarios, but in the one that we are in right now, where I’m sending all requests from a single IP, I want to split by a different option.
As a result, I can state that it was divided at random. so randomly split between the two versions. Half of the traffic should be directed to v3 and v2. So, splitting traffic at random is fine. Let’s go ahead and say yes. and you’d see that the traffic change is immediate. So it’s happening; it’s dividing the traffic. And if I actually start watching curl again, so I’m executing the watch curl for that URL again, you can see enough v. two and v. three. So it would actually randomly split traffic between two and three. There is one other option for splitting traffic by.You can also use a cookie, so your application can set a cookie with a specific name. With this specific version, you’d want to serve the request from now on. I’ll do a Control-C or Command-C to break this. In this specific step, we looked at how you can actually control the traffic migration from one version to another. We deployed V Three without migrating any traffic toward it. After that, we sent half the traffic towards V Three. And now we are happy that all the traffic to V Three is looking good. So I don’t really want to actually split traffic. So I want to send all traffic to just V Three.
You can go in here and say V-3 is equal to 1. So, for the time being, we are sending all traffic; please go to V Three and press Enter. So now I can say yes. So this would send all traffic to V Three. And now, if I send watch curl requests, you’ll notice that for a short period of time, about two or three minutes, I noticed that traffic was flowing towards V Three and V Two. As a result, V Three is the only aversion. It only took a few minutes to go live. Following that, I noticed that all of their requests were being served solely by V3. So this update took a little while, but at the end, we just have V3 live. I’m sure you’re having an interesting time, and I’ll see you in the next step.
9. Step 09 – Create a New Service and Playing with App Engine
Let’s go find the latest version. So I can go to versions, and it’s showing the versions for the default service. Let’s switch to my first service. and you can actually type in this version. So I’ll copy this and paste it in here. So this would give me the URL to a specific version. So you can see that the version is now attached to that specific URL. The idea behind the last few steps is to help you play with App Engine. We saw that you could create multiple services. Each of the services can have multiple versions, and if you don’t specify a name for the service in the app, then it would be deployed to the default service. We also saw how the URLs are formed. In terms of the exam, App Engine is one of the most important topics. So what I would recommend you do is play around with App Engine a little bit more, and I’ll see you in the next step.
10. Step 10 – Understanding App Engine app.yaml
Welcome back. In a previous step, we saw that you could configure the runtime to use in App YML, as well as the service name App YML. Let’s take a look at what else you can configure in your app’s YML in this step. So we looked at runtime earlier. This is the runtime. This is if you want to use Python 2.8; previously, we used Python 39, which is Python 3-9 over here. You can also specify the API version here. We were specifying the API version using the hyphen-v or hyphen-hyphen version. In addition to specifying it on the command line, you can also specify it inside your app’s YAML itself. You can specify whatever API version you want to specify.
However, the recommended option is to actually use it from the command line. You can also specify the instance class here—what type of instance you would want to use—and if you want to use the flex environment, that’s the flexible app engine environment. You can also specify an environment variable. So the environment must adapt. This will make it a flexible environment. This would be using containers. You can also specify if you want to warm up the containers or your app engine instances. If you have any environment variables, you can configure them under “environment variables,” “env underscore variables,” and “environment variables and values,” values in here.In addition to that, you can also configure handlers. So you can say, “Okay, this is the URL, and this maps to this particular script.” The last but most important configuration that you can make in your appYML is your auto-scaling configuration. Remember that the place where you make the autoscaling configuration in the app engine is in the app YML.
We talked about three types of scaling: automatic scaling, basic scaling, and manual scaling. So, depending on which one you want, you can configure them here. If you’d like automatic scaling, you can configure what you want to scale by. For example, zero point 65 is the target CP utilization. You can configure a minimum number of instances. maximum number of instances If you want to auto scale based on the maximum number of concurrent requests, you can also specify a maximum number of concurrent requests per instance; if you want to use basic scaling, you can specify basic scaling as well as a maximum number of instances and an idle timeout. If you want to use manual scaling, you can specify how many instances you want for that specific service. In this step, we looked at some of the important things that you can configure through app YAML. I’m sure you’re having an interesting time, and I’ll see you on the next step.
