Host your front-end app on Google Cloud Platform (GCP) at scale

In this article, we'll learn about the different components of GCP as well as how to host our front-end app on it at scale.

Satyam Sundaram's photo
Satyam Sundaram
·

9 min read

Host your front-end app on Google Cloud Platform (GCP) at scale

Table of contents

Motivation

Do you have a front-end app ready and running well on your local host? And, now you want to host it somewhere for the world to access it? In this article, we are going to use Google Cloud Platform (GCP) to host our app and expose it to the world. We're also going to scale it to handle large traffic. Are you ready? Let's go.

For our demo, we'll host this 2048 game on a GCP. This repo only contains HTML, CSS, JS code and some assets. You can use your own repo instead.

So, in a gist this is what we will do (if you don't understand the terms below, don't worry we will uncover them as we go):

  1. Host the front-end app on a GCP compute instance VM. Test that it is working properly.
  2. Create an instance template based on the instance created above.
  3. Create a Managed Instance Group for the Instance template.
  4. Create HTTP(s) Load Balancer for the instance group.
  5. Stress test the setup.

Let's get started:

  1. If you don't have a GCP account, set it up by adding a credit/debit card to get $300 credits for free for 90 days.
  2. Install gcloud on your terminal

Now, we'll enter commands on our terminal, so I hope you are using a UNIX-based terminal.

# setup gcloud
gcloud init
# create a new configuration
# enter the name for your configuration
# choose your account or add a new account
# choose your project or add a new project
# choose region and zone: we'll go with us-west1 & us-west1-a

Step 1. Create a GCP compute instance

  • A compute instance is a virtual machine (VM) hosted on Google's infrastructure.
  • It can run the public images for Linux and Windows Server as well as docker containers.
  • We can modify the machine properties of our instances, such as the number of virtual CPUs and the amount of memory.
  • By default, each Compute Engine instance has a small boot persistent disk that contains the operating system.
  • Each network interface of a Compute Engine instance is associated with a subnet of a unique VPC network.
  • A Virtual Private Cloud (VPC) network is a virtual version of a physical network that is implemented inside of Google's production network. It provides connectivity for our Compute Engine virtual machine (VM) instances, distributes traffic from Google Cloud external load balancers to backends, etc.

So, for our compute instance VM, we'll:

  • use an Ubuntu 20.04 image loaded in a 10GB boot disk which is the default
  • use the e2-medium machine which provides us with 1-2 vCPU (1 shared core) 4 GB memory
  • install apache2 on it to host our game. Apache is one of the most commonly used Web servers on Linux systems (apart from Nginx)
  • configure the firewall rule to allow HTTP and HTTPS traffic to our VM with tags flag
gcloud compute instances create instance-1 \
--zone=us-west1-a \
--tags=http-server,https-server \
--machine-type=e2-medium \
--image-family=ubuntu-2004-lts \
--image-project=ubuntu-os-cloud \
--metadata=startup-script='#!/bin/bash
apt-get update
apt-get install apache2 -y
service apache2 restart
rm /var/www/html/index.html
git clone https://github.com/gabrielecirulli/2048.git /var/www/html'

Now, you will see the internal_ip and external_ip for your VM. We'll use the external_ip to connect to our VM. While visiting the IP in your browser use HTTP instead of HTTPS like this: http:// because we haven't configured SSL. We'll use HTTP for this tutorial.

If your front-end app is not loading, wait for some time as it takes time for the VM to be up and install what's necessary. Now, your front end should be accessible on the external_ip. Great! It's working now. We can share it with the world but what if we go big? Our solo VM won't be able to handle all that traffic so we need to scale it. And, for that, we'll use a load balancer to balance the traffic over numerous VMs. Let's scale!

Step 2. Create an instance template based on our VM instance

  • An instance template is a resource that you can use to create virtual machine (VM) instances, managed instance groups (MIGs), or reservations.
  • Instance templates define the machine type, boot disk image or container image, labels, startup script, and other instance properties.
  • Instance templates are a convenient way to save a VM instance's configuration so that you can use it later to create VMs, groups of VMs, or reservations.
gcloud compute instance-templates create instance-template-1 \
--region=us-west1 \
--tags=http-server,https-server \
--machine-type=e2-medium \
--image-family=ubuntu-2004-lts \
--image-project=ubuntu-os-cloud \
--metadata=startup-script='#!/bin/bash
apt-get update
apt-get install apache2 -y
service apache2 restart
rm /var/www/html/index.html
git clone https://github.com/gabrielecirulli/2048.git /var/www/html'

Step 3: Create a managed instance group (MIG) for our instance template

  • An instance group is a collection of virtual machine (VM) instances that you can manage as a single entity.
  • Managed instance groups (MIGs) let you operate apps on multiple identical VMs. You can make your workloads scalable and highly available by taking advantage of automated MIG services, including: autoscaling, autohealing, regional (multiple zone) deployment, and automatic updating.
  • It is great for stateless serving workloads, such as a website frontend.

MIG

# create the instance template with health-check
gcloud compute instance-groups managed create lb-backend-example \
--base-instance-name=instance-group-1 \
--size=1 \
--template=instance-template-1 \
--zone=us-west1-a \
--health-check=health-check-ig-1 \
--initial-delay=300 \
--no-force-update-on-repair

# set auto-scaling on with min-replicas as 1 and max-replicas as 4. Auto-scale when the CPU utilization of a VM crosses 60% with a cool-down-period of 60s
gcloud compute instance-groups managed set-autoscaling lb-backend-example \
--zone=us-west1-a \
--cool-down-period=60 \
--max-num-replicas=4 \
--min-num-replicas=1 \
--mode=on \
--target-cpu-utilization=0.6

Step 4: Create an HTTP(s) load balancer for the MIG created above

  • An external Application Load Balancer is a proxy-based Layer 7 load balancer that enables you to run and scale your services behind a single external IP address. The external Application Load Balancer distributes HTTP and HTTPS traffic to backends hosted on a variety of Google Cloud platforms (such as Compute Engine, Google Kubernetes Engine (GKE), Cloud Storage, and so on), as well as external backends connected over the internet or via hybrid connectivity.
  • It is a global load balancer that is implemented as a managed service on Google Front Ends (GFEs).
  • Use this load balancer for external HTTP(S) workloads with globally dispersed users or backend services in multiple regions.

We'll need to setup an IPv4 forwarding rule, target HTTP(s) proxy, URL map and a backend service for our load balancer. It is evident from the image below, how each of these components work together. LB

Add a named port to the instance group

For our instance group, define an HTTP service and map a port name to the relevant port. The load balancing service forwards traffic to the named port.

gcloud compute instance-groups set-named-ports lb-backend-example \
--named-ports http:80 \
--zone us-west1-a

Configure a firewall rule

Create the fw-allow-health-check firewall rule. This is an ingress rule that allows traffic from the Google Cloud health checking systems (130.211.0.0/22 and 35.191.0.0/16). This example uses the target tag allow-health-check to identify the VMs.

gcloud compute firewall-rules create fw-allow-health-check \
--network=default \
--action=allow \
--direction=ingress \
--source-ranges=130.211.0.0/22,35.191.0.0/16 \
--target-tags=allow-health-check \
--rules=tcp:80

Reserve an external IP address

Now that our instances are up and running, set up a global static external IP address that our customers use to reach our load balancer.

gcloud compute addresses create lb-ipv4-1 \
--ip-version=IPV4 \
--network-tier=PREMIUM \
--global

# Note the IPv4 address that was reserved:
gcloud compute addresses describe lb-ipv4-1 \
--format="get(address)" \
--global

Set up the load balancer

We are using HTTP (front end) between the client and the load balancer. For HTTPS, we need one or more SSL certificate resources to configure the proxy. Using a Google-managed certificate is recommended.

Even if we're using HTTPS on the front end, we can use HTTP on the back end. Google automatically encrypts traffic between Google Front Ends (GFEs) and our backends that reside within Google Cloud VPC networks.

# Create a health check.
gcloud compute health-checks create http http-basic-check \
--port 80

# Create a backend service.
gcloud compute backend-services create web-backend-service \
--load-balancing-scheme=EXTERNAL_MANAGED \
--protocol=HTTP \
--port-name=http \
--health-checks=http-basic-check \ 
--global \

# Add our instance group as the backend to the backend service.
gcloud compute backend-services add-backend web-backend-service \
--instance-group=lb-backend-example \
--instance-group-zone=us-west1-a \
--global

# For HTTP, create a URL map to route the incoming requests to the default backend service.
gcloud compute url-maps create web-map-http \
--default-service web-backend-service

Setting up an HTTP frontend

# For HTTP, create a target HTTP proxy to route requests to our URL map.
gcloud compute target-http-proxies create http-lb-proxy \
--url-map=web-map-http

# For HTTP, create a global forwarding rule to route incoming requests to the proxy.
gcloud compute forwarding-rules create http-content-rule \
--load-balancing-scheme=EXTERNAL_MANAGED \
--address=lb-ipv4-1 \
--global \
--target-http-proxy=http-lb-proxy \
--ports=80

Connect your domain to your load balancer

After the load balancer is created, note the IP address that is associated with the load balancer—for example, 30.90.80.100. To point your domain to your load balancer, create an A record by using your domain registration service. If you added multiple domains to your SSL certificate, you must add an A record for each one, all pointing to the load balancer's IP address. For example, to create A records for example.com and example.com, use the following:

NAME   TYPE     DATA
www     A       30.90.80.100
@       A       30.90.80.100

Step 5: Stress test our app

Now that the load balancing service is running, we can send traffic to the forwarding rule and watch the traffic be dispersed to different instances.

gcloud compute addresses describe lb-ipv4-1 \
--format="get(address)" \
--global

# After a few minutes have passed, you can test the setup by running the following curl command.
curl http://IP_ADDRESS

stress testing using apache2-utils

ab is a tool for benchmarking your Apache Hypertext Transfer Protocol (HTTP) server. It is designed to give you an impression of how your current Apache installation performs. This especially shows you how many requests per second your Apache installation is capable of serving.

apt-get install apache2-utils
# simulate 10,000 concurrent requests
ab -n 10000 -c 100 http://<external_ip>

Conclusion

In conclusion, if you have a front-end app running on your local host and want to make it accessible to the world, Google Cloud Platform (GCP) offers a powerful solution. In this article, we've walked through the process of hosting a 2048 game on GCP and ensuring it's accessible to users, even under heavy traffic. By following the steps outlined above, you've learned how to:

  1. Create a GCP Compute Instance: We set up a virtual machine instance on GCP, installed Apache to host the game, and made it accessible via an external IP address.
  2. Create an Instance Template: An instance template was generated based on the configured VM instance, laying the foundation for consistency in future deployments.
  3. Set Up Managed Instance Groups: Utilizing managed instance groups, we enabled auto-scaling, allowing the application to handle increased demand by distributing traffic across multiple instances.
  4. Configure an HTTP(s) Load Balancer: We established an HTTP load balancer to intelligently distribute traffic across instances in the managed group, ensuring high availability and efficient resource utilization.
  5. Stress Tested the Setup: To validate the auto-scaling capabilities, we employed stress testing tools to generate significant load and observe how the system responded.

Throughout this journey, we've harnessed the capabilities of GCP to take a local front-end app and scale it to handle real-world demands. By following these steps and utilizing Google's powerful infrastructure, you're well-equipped to confidently deploy and manage your applications on a global scale. So, with your app now accessible to the world, you're ready to face the challenges of traffic spikes and ensure a smooth user experience for all.

GCPgoogle cloudLoad BalancinghostingTutorial