11. Step 11 – Understanding Request Routing in Google App Engine
Back in this step, let’s look at how you can do request routing for App Engine. You have multiple services and multiple versions. You have default services and default versions. How do you route traffic to different versions? Over here, you can actually use a combination of three approaches. One method is to use URLs. The URLs themselves can be used to route to different services and versions. This is the default service in that project if you use projected Region ID on appspot.com. If you do service projected region ID rapspot.com, this will call the default version of a specific service. If you want a specific version of a specific service, you can say “version service.” Projected region ID: rappspot.com We already saw examples of this earlier and executed the app browse command that we executed earlier. My first service is the G cloud app browser. The hyphenated version is equal to the specific version of that specific service. You’d see that it shows me the URL, so it says 2021.
That’s basically the version So up to 81 is the version, the name of the service, the name of the project, the region, which is US Central, which is UC. I dot appspot.com. Now, if I go in here and just say “service” and remember to remove the version, then the URL would point to the default version. Right now, this service has just one version, which is also the default version also. So both of these URLs would give me the same response. But you can see that the URL changes. If you want to go to a specific version, this is the kind of URL you want. If you want to go to the default version of a specific service, this is the URL. So service name, project name, UC r appspot.com, and if I want to go to the default service, I just say “gcloud app browse,” which gives me the URL and https:/merit-furnace, which is the project name region-rapspot.com.
So if I want to get the version v2 of the default service, I can say this G Cloud apprise, and if one version is equal to v2, this gives me the URL to the v2; I can click that and go to the v two. So that’s one option. The URLs would change a little if you were using a custom domain. Let’s look at AppEngine settings if you’re connecting App Engine to your own custom domain. App Engine application settings are over here, and you can attach a custom domain for your application. So if you want to redirect to this specific application in 28 minutes, you can configure that here. So, if you already have one, you can add it here, or you can go ahead and register a new one from here. If you’re using a custom domain, then instead of that, you can actually just use “.
Now, in addition to routing with URLs, you can also route with a dispatch file. So there is a dispatch. yml file that you can configure with the routes in the dispatch. yml file you can configure. Okay, if the request comes to this URL, you need to route it to this service. If the request comes to this URL, you need to route it to this service. And once you have a dispatch ML configured, you can actually say “gcloud app deploy dispatch TML.” That’s the second option. The third option is that you can also route traffic using cloud load balancing. You can have App Engine as the back end, and you can configure routes on the load balancing instance. In this quick step, we’ll look at how you can do request routing to different versions of your services in App Engine. I’m sure you’re having an interesting time, and I’ll see you in the next step.
12. Step 12 – Deploying New App Engine Versions without Downtime in GCP
Welcome back. In this step, let’s look at how you can actually deploy new versions without any downtime. How do I upgrade from Version One to Version Two without experiencing any downtime? During our hands-on, we looked at this a little bit. So if you are confident, I want to deploy my version immediately and shift the traffic. All you have to do is deploy a Gcloud app. So the new version would be deployed, and the traffic would be immediately shifted from V1 to V two. The other option is that you’d want to manage the migration from V1 to V two. You can deploy V2 without disrupting traffic. We had already considered the alternative. Hyphen hyphen no, promote. So don’t promote the V-2 version; just deploy it. As a result, the Gcloud app does not promote itself. And after that, you can actually shift the traffic to V Two.
Now after that, you can test it and then shift traffic to V two. Even with shifting the traffic, you can actually shift all traffic to V2 at once. Or you can probably do some kind of canary. So you can deploy V2 to a certain number of instances and then slowly promote V2 to all instances. So you can migrate all at once to V Two. You can instruct Gcloud App Services to set traffic for a specific service and instruct it to send all traffic to V 2. Or you can also go for a gradual migration option. You can add a Hyphen-Hyphen migrate option if you want to use gradual migration to the earlier command.
So what it does is, instead of shifting all traffic at once, it slowly migrates traffic to V Two. One important thing to remember is that gradual migration is not supported by App Engine’s flexible environment. The third option is to control the pace of migration. You can manually do it. So you can say I would want to split traffic. As a result, traffic s one splits v two equals zero one. V1 is equal to zero nine. Slowly, you can increase the amount of traffic that you’d want to send to V two. Once you are confident, you can send all the traffic to V two. Splitting the traffic is useful. Also, to perform B testing, you have a feature that you don’t know if users will like, so you’d want to trial it. With a few users, you can perform B testing instead. We talked about deploying new versions to App Engine without any downtime.
13. Step 13 – Splitting Traffic Between App Engine Versions in GCP
Welcome back. In the previous steps, we talked about the fact that you can split traffic between multiple versions. What are the ways in which you can split traffic? How do you decide which version receives which traffic? There are multiple options. One is IP splitting. This is the default, and it is based on the request’s IP address. However, IP addresses can change. My IP address can change from one thing to another. That can cause accuracy issues. My pairings would change if I could start working from home and then move to a coffee shop. The other problem is also that if all the requests originate from a corporate VPN, those VPNs probably have a single IP.
So you have a proxy, and the proxy has an IP, and all the requests go through the IP. This can cause all requests to go to the same version. So IP splitting is the default, but you need to identify the right use cases where you’d want to use IP splitting.The other option is to go with cookie splitting. So you can set a cookie called GeoIPUID so you can set it into the header, and based on that cookie, you’d be routed to the appropriate version. The great thing is that this can be controlled from your application as well, so your application can generate the appropriate cookie and you can redirect to a specific version. So this can accurately assign users to versions. The other option is to do it randomly, and we already looked at how you can do it. So, in the set traffic command, you can include a hyphen and a split by option, and one of these values can be used as a cookie IP random. In this step, we looked at the three ways you can decide which version receives the traffic: IP slicing, cookie slicing, and random. I’ll see you in the following step.
14. Step 14 – Exploring App Engine and Gcloud – gcloud app
Back in the previous steps, we played a lot with the app engine. In this step, let’s look at some of the commands that you need to remember. Let’s take a look at some of these commands: gcloudapp browse create deploy describe open console.
Earlier, we created the app from the web console. However, you can also create the app from the command line. So if you are going into a new project and you want to create an app, you can just say, “gcloud appcreate hyphen iPhone region is equal to the region in which you would want to create the app in.” We already looked at the deploy command, “gcloud app deploy.” The default is app YML, so you don’t really need to specify app YAML, but if your YAML file has a different name, then you can specify the name of the YAML file. App Engine Flexible also supports containers, so in that kind of situation, you can also specify an image URL. What is the URL of your Docker image or your container image? So gCloud apps that deploy iPhones have an image URL and a URL from the container repository.
The next important option for which to deploy support is “hyphenate promote” or “hyphenate no promote.” We saw that the default is hyphen promote. However, if you don’t want the new version to receive the traffic, then you can say, “Hyphen, Hyphen, no promote.” There is another option that you can deploy support for, which is to stop the previous version. Should the old version be stopped after the new version receives all traffic, the default is “Hyphen hyphen” to stop the previous version; if you want to stop the previous version, you can say “Hyphen hyphen” to stop the previous version. We saw that.
You can also assign an aversion to your deployment version. If you don’t assign a version, a version number is generated. We’ve already experimented with the Browse gCloud app. browse, you can specify the service and the version, and it will give you the URL and, ideally, open it up in the web browser. However, because there is no browser installed in the cloud shell, we have to click it and then open it up. Similar to browse, there is also an open console command. What does the “open console” command do? Let’s give it a shot, so gcloud appOpen Console: what will it do? So it gives you the URL to the console, so it’s not giving the deployed application URL, but this is actually giving you the URL to manage that specific service in the app engine dashboard.
So you can come in here and start looking at that particular service. Now you can also directly go over to the logs of the application, so you can say “g cloud appOpen Console Logs,” which would take you to the logs, and this also supports all the options. So you can also specify a service and the version. You can also use describe to describe a specific service or version. There are a couple of other commands that might be interesting, such as “gcloud app logs tail.” You can tell by looking at the logs generated by your application. And you can also list the regions where App Engine is supported. Gcloud App regions list, so if you run this command, you’ll see a list of regions where App Engine is supported. So you can see which region supports standards and which region supports flexibility. And as of now, all the existing regions here support both standard and flexible. Let’s play with App Engine from the command line a little bit more in the next step as well. I’ll see you in the following step.
15. Step 15 – Exploring App Engine and Gcloud – gcloud app instances
Welcome back. Let’s continue playing from the command line in the next two steps as well. In this step, let’s do the boring thing of playing with instances from the command line. The great thing about all the app engine commands is that they are very consistent. So you should be able to easily guess the command for most of these things. So let’s quickly browse through them. As usual, all the App Engine commands start with “GcloudAmp,” and until now we were playing with other commands, and over here we would want to play with instances. S
o it’s G Cloud App Instances followed by the action you’d want to perform: delete an instance, describe an instance, list all instances, or you can also do SAP or SSH. As a result, you can delete a specific instance from a specific service version. If you don’t specify the service and the version, then you’ll be deleting the inactive instance of the default service. If you want to delete from a specific service, then you can specify the specific service and the version as well. You can also say I would want to describe the details of a specific instance; I’d want to see what the details are related to a specific instance. You can also perform a Gcloud app instance list. Let’s just quickly execute this. So in the “gcloud app instances list,” it would list the number of app instances that we have running right now.
Now, when I did a Cloud App Instances List, it actually listed zero items, but when I did a GcloudApp Services List, it was showing both the services and the number of versions that are running. And when I did an Gcloud App Versions List, it showed me the list of all the versions, and all the versions were in serving status. However, there were no instances running for any of the versions. Why? Because we are using App Engine Standard, it scales down to zero instances when there are no requests to be served. So that’s what happened, and as a result, I went in and fired a few requests. So if you fire in a lot of requests, you’d see that if you go and again execute “Gcloud AppInstances List,” you’d be able to see a specific instance. If you are using App Engine Flexible, then you can even copy files. So you want to securely copy files from your local machine, from a local directory, into a directory that is present on the instance. The way you can do that is by using the SCP command, and if you’re using App Engine Flexible, you can even SSH into the VM of the App Engine instance. So you can say “Gcloud App Instances” over SSH and specify the details of the instance. In this quick step, we looked at some of the important commands related to instances for App Engine.
16. Step 16 – Exploring App Engine and Gcloud – gcloud app services and versions
Welcome back. Let’s continue playing from the command line in the next two steps as well. In this step, let’s do the boring thing of playing with instances from the command line. The great thing about all the app engine commands is that they are very consistent.
So you should be able to easily guess the command for most of these things. So let’s quickly browse through them. As usual, all the App Engine commands start with “GcloudAmp,” and until now we were playing with other commands, and over here we would want to play with instances. So it’s G Cloud App Instances followed by the action you’d want to perform: delete an instance, describe an instance, list all instances, or you can also do SAP or SSH. As a result, you can delete a specific instance from a specific service version. If you don’t specify the service and the version, then you’ll be deleting the inactive instance of the default service. If you want to delete from a specific service, you can specify the service as well as the version.
You can also say I would want to describe the details of a specific instance; I’d want to see what the details are related to a specific instance. You can also perform a Gcloud app instance list. Let’s just quickly execute this. So in the “gcloud app instances list,” it would list the number of app instances that we have running right now. Now, when I did a Cloud App Instances List, it actually listed zero items, but when I did a GcloudApp Services List, it was showing both the services and the number of versions that are running. And when I did an Gcloud App Versions List, it showed me the list of all the versions, and all the versions were in serving status. However, there were no instances running for any of the versions.
Why? Because we are using App Engine Standard, it scales down to zero instances when there are no requests to be served. So that’s what happened, and as a result, I went in and fired a few requests. So if you fire in a lot of requests, you’d see that if you go and again execute “Gcloud AppInstances List,” you’d be able to see a specific instance. If you are using App Engine Flexible, then you can even copy files. So you want to securely copy files from your local machine, from a local directory, into a directory that is present on the instance. The way you can do that is by using the SCP command, and if you’re using App Engine Flexible, you can even SSH into the VM of the App Engine instance. So you can say “Gcloud App Instances” over SSH and specify the details of the instance. In this quick step, we looked at some of the important commands related to instances for App Engine.
17. Step 17 – Creating Cron Jobs in App Engine
Welcome back. In your app engine, you can also schedule jobs. This can be done by configuring a simple YAML and making your app engine use that YAML. So App Engine allows you to run scheduled jobs at predefined intervals. A few use cases would be: I want to send a report by email every day, or I want to refresh cache data every 30 minutes. So if you have things that can be done on a schedule, you can do that using a Cron job. This is typically configured by using a file called Cron YAML. So Cron, what is the job description, and what URL do you want to call? You can configure a YAML similar to this with the configuration.
And you can do a schedule so you can say “every 24 minutes,” “every ten minutes,” “every 5 hours,” so you can configure the schedule, and then you can call Gcloud app deploy Cron YML, which would deploy the Cron onto your App Engine. So this would perform an HTTP get request by default on the configured URL on a schedule. In the previous step, we looked at how you can actually configure a cron job for something that is running on App Engine. I’ll see you in the following step.
18. Step 18 – Exploring App Engine YAML files – dispatch and queue
Welcome back. In the app engine, there are a couple of other YAML files that are important. We already talked about dispatching EML. We talked about this when we talked about routing requests. So if you want to configure specific paths and specific redirection to specific services, you can do that through dispatch YML. So, if you can configure a dispatch TML so that you can say this URL pattern, send it to this service. Send this URL pattern to this service if it matches this pattern. So based on the URL pattern, the app engine would route it to the appropriate service. You can deploy this file very, very easily by just saying “gcloud app deploy dispatch TML.” You can also configure your app engine to pick up tasks from a queue. You can make the configuration in a file called Queue YAML and store it there. You can configure the name of the queue, at what rate you’d want to pick up tasks, and also a few retry parameters. In this step, we’ll update a couple of app engine YAML files. I’ll see you in the following step.
19. Step 19 – Important Things to Remember – Google App Engine
Welcome back. In the last few steps, we played around with App Engine a lot. In this step, let’s look at a few important things to remember about App Engine. App Engine is regional, and your services are deployed across zones. Another important point to note is that you cannot change the region of an application. So your app engine is tied to a project that’s one-to-one mapping. Furthermore, App Engine is linked to a region that is also one-to-one mapped.
and you cannot change this. And App Engine is a good option for simple microservices. I mean, when you have multiple microservices that are part of a single app, you can use App Engine. However, keep in mind that App Engine is not as powerful as Kubernetes. So most of the advanced container orchestration features that Kubernetes provides through App Engine won’t do that for you. So, if you have very simple microservices and very simple requirements, then you can go for App Engine. You can use Standard V-2 when you’re using any of the supported languages. So if you are using Java, Python, or any of the supported languages, go for Standard V Two.If you’re going to use CC Plus and other languages, you should go with flexible. You need to build your containerized apps.
One important thing to remember is that AppEngine Flexible will not scale down to zero. App Engine’s standard can scale down to zero when there is no load. However, because App Engine is flexible, there is always one container running. So go for Standard if you want to be able to scale down the number of instances to zero when there is no load. So if you have intermittent loads in those kinds of situations, the recommendation is to go for App Engine standard. Always go for a combination of resident and dynamic instances. Resident instances are instances that run continuously. When we set the minimum number of instances, we mean the number of instances that should always be running. And we also have dynamic instances, which should be added in based on the load. If there is a high load, more instances come in. If there is less load, those instances would be removed. So if you are very cost-sensitive, then you can actually use all dynamic instances. So make sure that you don’t have any. The minimum for resident instances is zero. And if you are not cost-sensitive but still want good performance, the recommendation is to keep a set of resistance instances running. In this episode, we looked at some of the important things to remember about App Engine. I’ll see you in the following step.
20. Step 20 – Scenarios – Google App Engine
Welcome back. In the last few steps, we played around a lot with App Engine, and now it’s time to look at a few scenarios related to App Engine. I want to create two Google AppEngine apps in the same project. Will you be able to do that? The answer is no; it’s not possible. You can only have one App Engine app per project. You can have multiple services inside that app, and you can have multiple versions for each service. But you can only have one app at the root, and that app is tied to the specific project. So if you don’t want to create two Google AppEngine apps in the same project, that’s not possible. But you can create a new project, and you can create a new Google App Engine app in that project. I want to create two Google AppEngine services inside the same app. Yeah, that’s easy, right? You can create multiple services under the same app. Typically, when you have a simple microservices architecture, let’s say I have five or ten microservices, I can create a service for each of these microservices under the same app.
And each of these microservices can also have multiple versions: V1, V2, V3, and so on. I want to move my Google AppEngine app to a different region. Is that possible? When we create a Google App Engine app, we need to choose the region, and once we choose it, it’s permanent. an app engine. The app is region-specific. You cannot move it to a different region. If you want to create an App Engine in a different region, you need to create a new project and a new App Engine app in the new region. You want to perform canary deployments using App Engine. We looked at it earlier. You can deploy the app using no promote, so you can deploy version two of the app without shifting traffic, and then you can shift some traffic to version V Two.So you can use Gcloud App Services, set traffic, and say, “I would want to split it in this specific way.” I would want 90% of the traffic to go to V1, and 10% of the traffic to go to V Two.You can test that, and then you can migrate all traffic to the new version. In this EP, we looked at some of the important scenarios related to App Engine. I’m sure you’re having a wonderful time, and I’ll see you in the next.
