Cloud Services / Networking

Deploy an Elastic Web App with Portworx and Google Cloud Run

10 May 2019 3:00am, by

This is the final part of the series on Google Cloud Run. In this tutorial, we will explore how to deploy a Cloud Run service that interacts with existing services already deployed on a Google Kubernetes Engine (GKE) cluster.

When the Cloud Run service targets an existing GKE cluster, it is treated like a classic Kubernetes deployment that can talk to internal services exposed through a ClusterIP.

I am going to take a different approach than the scenario covered in the previous tutorial where I demonstrated how a stateless Cloud Run service leveraged a MongoDB instance provisioned in mLab. In the current scenario, a highly available MongoDB instance runs within the default namespace of the GKE cluster. The stateless web application deployed as a Cloud Run service discovers and uses the existing MongoDB instance.

Below is a detailed walkthrough of this scenario:

Step 1: Launch a GKE Cluster

Let’s start by configuring the tools and the environment. Set the PROJECT_ID variable to your GCP project.

At the end of this step, we have a GKE cluster enabled for Istio and Cloud Run.

Step 2: Install Portworx on the GKE Cluster

We will use Portworx storage engine to bring high availability to our MongoDB deployment. For a detailed step-by-step guide on configuring Portworx, refer to one of my past tutorials.

Run the below command to deploy the trial version of Portworx storage cluster.

The below screenshot confirms that Portworx is successfully deployed and ready to run stateful workloads.

Step 3: Deploy HA MongoDB Instance

Let’s start by creating the Portworx storage class that supports replication which ensures high availability of MongoDB pod.

Taking advantage of dynamic provisioning, we will create a persistent volume control (PVC) based on the above storage class.

Now, we are ready to deploy the MongoDB pod.

Since the pod is backed by a replicated Portworx volume, deleting and recreating the pod wouldn’t impact the data. Based on Storage Orchestration for Kubernetes (STORK), Portworx ensures that the pod is placed on a node with the volume that contains the data.

We should now have a MongoDB pod running in the default namespace

Finally, it’s time to expose the pod internally through a ClusterIP. Create the below service with the name db.

Step 4: Deploying the Web App as a Cloud Run Service

Since Cloud Run can only deploy containers with images stored in Google Container Registry (GCR), we need to push the image to GCR.

You can either build the image from the scratch or pull it from Docker Hub, tag it, and push it to GCR.

With the container image in place, we are now ready to deploy it as a Cloud Run service. Since the app is coded to find MongoDB by hostname db, we don’t need to change anything. It “automagically” gets wired to the MongoDB ClusterIP service exposed as db.

Instead of CLI, we will use GCP console to deploy the service. This will help us understand all the options involved.

We chose the GKE cluster from the location dropdown.

The green tick mark confirms that the service is healthy and accessible.

Step 5: Accessing the Web App

Accessing the web application is not as straightforward as the Kubernetes service. We need to first get the Istio Ingress Gateway IP address and then modify the host header to see the frontend in the browser.

The below screenshot shows that the IP address of Istio Ingress Gateway as Before we can hit this URL, we also need to modify the HTTP header to reflect the hostname

We will use a Chrome extension, ModHeader, to manipulate the headers. Add a new header as per the below screenshot:

Now you can enter the Ingress IP address to see the web page.

Unlike Kubernetes, Cloud Run doesn’t keep the service running forever. The pods associated with Cloud Run service come up only when there is a request and automatically shut down after an idle timeout period.

As soon as we hit the address through the browser, Cloud Run instantiates the pod.

Behind the scenes, the lifecycle of the deployment is handled by Knative Serving.

This scenario demonstrates how to run highly available stateful services powered by Portworx and elastic stateless services managed by Cloud Run on Google Kubernetes Engine.

Janakiram MSV’s Webinar series, “Machine Intelligence and Modern Infrastructure (MI2)” offers informative and insightful sessions covering cutting-edge technologies. Sign up for the upcoming MI2 webinar to learn how to run applications at the edge with AWS Greengrass.

Feature image by Randy Fath on Unsplash.

The New Stack is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.