The course is part of these learning pathsSee 7 more
There are a lot of different options, across a variety of cloud platforms that are well suited for running specific workloads, such as web applications. Things such as Google App Engine, AWS Elastic Beanstalk, Azure App Services: Web Apps, among others.
However, there are still plenty of times where we need to set up our own infrastructure. And so cloud vendors offer IaaS (infrastructure as a service) options. Google provides us with Compute Engine which allows us to create virtual machines, custom images, snapshots, networks, auto-scalers and load balancers.
If we're going to create and implement an application on the Google Cloud Platform system operations, then understanding these services are going to help us to create highly available, highly scalable applications.
All the major cloud providers offer the ability to set up virtual machines, networks, auto-scalers, and load balancers. Where the Google Cloud is different is in the speed of creating and starting up virtual machine instances. As well as the massively scalable software-based, global load balancer; which doesn't require pre-warming. Google also offers per-minute billing for VM instances, after the first 10 minutes.
So Google has a lot to offer. And if you're looking to learn more about the Google Cloud systems operations, then this may be the course for you.
What exactly will we cover in this course?
Course Objectives: Google Cloud Platform system operations
By the end of this course, you'll know:
How to use Compute Engine to create virtual machines
How to create disk snapshots
How to create images
How to create instance templates and groups
How to create networks
How to use the auto-scaler and load balancer
This is an intermediate level course because it assumes:
You have at least a basic understanding of the cloud
You’re at least familiar with general IT concepts
What You'll Learn
Summary A review of the course
|Lecture||What you'll learn|
|Intro||What will be covered in this course|
|Getting Started||An introduction to the Google Cloud Platform|
|Networking||How to create and secure Cloud Networks|
|Disks and Images||An overview of disk types and images|
|Authorization and IAM||How to authenticate and authorise users|
|Disk Snapshots||How to use snapshots for point-in-time backups|
|Cloud Storage Overview||A refresher on Cloud Storage|
|Instance Groups||How to manage instances with managed and unmanaged groups|
|Cloud SQL Overview||A quick primer on how to use Cloud SQL|
|Startup and Shutdown Scripts||Using startup scripts to provision machines at boot time|
|Autoscaling||How to automatically add and remove instances|
|Load Balancing||How to balance traffic across instances|
|Putting It All Together||A demo of how to use some of the services we've learned about|
Hello and welcome. In this lesson, we're going to head into the console and create a cross-region load balanced web application. We're going to use Google Cloud's global load balancer to distribute traffic between two regions. One of the regions is going to reside in the U.S. and the other in Europe.
Google Cloud's load balancer is comprised of a few different components behind the scenes. Requests that are sent by users head to the frontend forwarding rules. A forwarding rule routes requests to a target proxy. A target proxy checks the URL map to determine the backend service for which it should route traffic. It's the job of the backend service to forward those requests on to the instances themselves, and that's based on the instance capacity and health. And instance health is determined by health checks. Once we've built this out, we'll be able to make a request to a static IP address which is attached to the forwarding rule and then we'll be able to receive the response from the most responsive region.
Here's our requirements for this build. We're going to create an instance template so that we can ensure every instance is created consistently. We're going to create two instance groups based on the template. One will reside in US East, and the other in Europe West. We're going to create a firewall rule that will allow HTTP traffic to the servers. We'll create a static external IP address. And we'll create and configure the load balancer. To top it all off, we'll test the traffic flow using curl, and we'll test that through two different machines, one in each region so that we can see how we actually will receive these requests from the region that is the most responsive.
All right, a few notes before we get started, some of the functionality in this demo does require the premium tier networking functionality, so keep that in mind, also we're going to use HTTP rather than HTTPS, though HTTPS is fully supported.
All right, if you're interested in building this out, then let's get started. I'm here on the Google Cloud Platform dashboard and the first thing we need to do is create our instance group template. So let's head over to the compute engine page and let's drill into the instance templates sub-page, right here. Okay, and clicking create instance template. Okay, so remember this template is going to allow us to ensure that whatever instances we create will look exactly the same. So it's going to provide us that consistency. We're going to use a machine type of f1-micro and we'll leave the Debian Linux default OS here set, and then let's expand this management section, and we're going to add a startup script. Now, this is going to be the thing that configures the Apache web server, and we'll scroll over to networking.
Network tags allow us to dynamically lookup instances to have firewall rules applied to them. So, using a network tag, a firewall rule can basically say hey, show me any instances that have a tag of HTTP tag and that just makes things a bit more dynamic because anything with that tag will automatically have that rule applied, so it's a nice easy way to apply firewall rules. We'll specify this as HTTP dash tag, and we'll have to remember that for later. And we'll use an ephemeral IP address and then we can create this instance template.
Okay, with this complete we can create an instance group. So, we're going to create two groups of instances, one in each region, and they're going to based off this template. The first one will be the U.S. East region, and we'll be using HTTP, so I just like to specify that as the name there, and we'll set it to multiple zones, we don't really need to worry about which zone, we'll just have it pick for us, so we'll use east four, and it's already got our template there, perfect. It's using auto-scaling, I'm going to use the default CPU usage, but feel free to change that for yourself.
The minimum number of instances is one, that's fine. The max is 10, it's a bit high, let's set that to two. Okay, and let's create this. So this is going to create instances inside of a group based on our template that are running inside of the U.S. East four region. So, now let's just copy this name, we're going to use the same basic naming convention, and create our European instance group. And so I'm going to just paste this and swap this over. Okay, perfect.
And let's set the region. Actually, I didn't set the multiple zones first, so let's do that again. And set the region. Perfect, and it doesn't have our instance template here so let's set that. And again, let's dial the maximum number of instances down to two. And let's create this.
All right, with this complete, what we've actually done is we've set up our web server running in two different regions using the same instance template and created through instance groups. And those groups are going to allow this to auto-scale. That's going to make it so that we can scale up and down based on the demand, and all of this is going to end up routed through just the one IP address, so there's a lot of functionality here happening in the background, though it's going to be seamless to the user, they're going to be able to just hit that one IP address, and get routed to the region and instance that is the best qualified to handle the traffic.
Okay, so the next thing we need to do is create our firewall rule. Remember, we created our tag on the instance, now let's create a firewall rule that recognizes that tag, and it's going to apply to those instances that we just created. So, we're going to click on create firewall rule. And we'll give it a name. The most creative name you've ever seen, no doubt. And I'll scroll down, this is an ingress rule, we'll allow, and we need to specify the tag here, so HTTP dash tag. Okay, so that will apply to our instances. And we want this to be accessible from everywhere so we'll use zero dot zero dot zero dot zero slash zero. Is there an extra zero in there? I can't tell. Anyway, we're going to specify the port of port 80. And click create.
Okay, so now we have our firewall rule. In theory, because we've linked this together with the tags, these instances are accessible from the internet. We should be able to hit these on port 80 and see the webpage that is running. So let's test this out by copying the URL. Oops, I deleted the five here, there we go.
Okay, so this is running, you can see it's running in U.S. East four, let's try this again with the other region. And we'll drill into Europe. And copying this external IP address, pasting it in here, yeah, there it is, Europe West three. Okay, so our instances are up and running, they are accessible over the internet on port 80, so, so far things are looking good.
The next thing we need do is create our external IP address because we don't wanna have to actually go to the individual instances to view our webpage. So, let's click on the navigation menu and let's go to the external IP address section. Okay, so once this loads, we can click this reserve static address here. And I'm going to select this name from the list, as you can tell I've done this off camera before. I'll make sure it's IPv4, and we're going to set this as a global type. And we'll click reserve.
Notice in the network tier column in a second here, it should pop up, yeah, there it is, it says premium, so this is what I was mentioning earlier at the beginning, some of these features are actually premium network tier.
So, next let's click on the load balancing section, we're going to create the load balancer. And so we'll click create here, and we'll select HTTP, though notice you can use TCP or UDP. And I'll just give this a name real quick. Let's call this webserver map, and let's set a backend. So, we're going to select our backends, though now that I'm here, notice you can actually create a backend off of storage bucket, so that's kind of cool, not really the purpose of this demo, but it's still cool.
So we'll go back to create our backend service, and I'll give this a name, we'll call it web server map backend. Okay, and we need to set our instance group, this is the group of servers that it's going to route traffic to, and we'll now set another one, we're gonna grab the European one.
So now I've added the two backends, I've added the two different groups of web servers, the one in the U.S. and the one in Europe, next thing we need to do is make sure we have a health check. We need to know that the instances are healthy, and so for that, we'll click on this health check and create. And we'll just give this a name of web server map backend, that's probably not the best name since I think I already used that, but we'll go with it for this demo. Okay, and we'll click create.
Notice on this host path and rules page, we can actually specify different rules for how to direct traffic to the different backends. Clicking on this add rule here is going to allow us to specify a host and a path, so maybe you wanna do something like some URL-based routing, you wanna send anything that mentions images, based on this little example here, anything that says images in the URL you wanna send to a specific location, that could be a storage bucket or someplace else, this gives you the functionality to do that. We're not going to do it, we're going to send all the traffic by default to the backend that we've just created. Though keep in mind that you can use content-based routing, which is pretty cool.
The frontend configuration, let's give this a name. And perfect, so we're gonna make sure it's HTTP. It's the premium tier, that's fine, and we wanna use our static IP address, that way it's always the same IP address, we'll be able to use that in DNS if we want to. Clicking on review and finalize, everything looks good here, this is all that we expect, so let's click create. And perfect.
So let's drill into this. It's going to provide for us the IP address for the frontend and let's copy that and paste that in another tab. And we get a 404. Now, don't worry, this is actually expected, this is working as designed. It just takes a little while for some of this stuff to propagate out. So, we're working with some global rules here, it takes a little while for that to get sent all over the globe and wherever it is it needs to be. So don't worry, this can take a few minutes, I think the last time I did this I waited about 10 minutes. So I'm gonna pause here and I will catch you in 10 minutes.
Okay, I'm back, and it's been about 10 minutes, let's click on the refresh button and see if this is working now. And it is. Notice this is running in U.S. East four B. If I was to keep mashing this refresh button, it's really not going to change. I have two regions, yes that is true, I'm distributing the traffic between them, that is also true, however, it's tough to tell because Google is going to route me to the best possible instances that it finds. And now it determines that in different ways, but basically since I am physically close to U.S. East, I'm actually in East US, it's going to send me to that server.
The way we're going to test this is I actually started up two instances earlier, one of them is in the U.S., one of them is in Europe, and we're going to use those as springboards to test this out. I've used the Cloud Shell functionality to SSH into them, and so I'm going to just pivot to that screen and show you them side-by-side. And so here they are. I'm going to add a little space here so that it doesn't overlap with these icons up in the top right. And I'm going to use curl to actually see if this works.
So, this page on the left-hand side is East four, over on this let's do curl, and I paste that in, notice it says this server is running in zone, and then there's a project ID, not gonna read that off, but then it's followed by zone U.S. East four B. So, because this one is the best option it's going to send us to East four, and if we try from this European instance, and again I'll add a little space here, and curl, oops extra period there, and there it is, so Europe West three B. So it actually works.
Okay, with this complete let's stop here and summarize what we've done in this lesson. We built a cross-region web application using compute engine instances which were created based on instance templates and they were created inside of an instance group. Then, we created a firewall rule that allowed IPv4 traffic to port 80 from anywhere and it mapped to our instances using network tags. We created a static IP address that we then linked to the frontend forwarding rule. We also created the backend service which contained the instance groups, that's those two instance groups the U.S. East and Europe West. Then we tested this by sending traffic to our static IP address from different servers, those springboard servers that were located in the U.S. and Europe, and we noticed that we received our traffic from the closest region. So, all things considered, I think this was a successful build-out.
All right, that's going to do it for this course, I hope it has helped you to further your understanding of the Google Cloud Platform. Thank you so much for watching, and I will see you in a future course.
Note: The startup script shown in this video is at https://gist.github.com/whelmed/9b688aa4bf7d1d7d55900753f023d0ae.
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.