Deploy an Elastic Web App with Portworx and Google Cloud Run
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.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
PROJECT_ID='[your_project_id]' ZONE_ID='us-central1-a' GKE_CLUSTER='gke-px-cloud-run' gcloud config set project $PROJECT_ID gcloud config set compute/zone $ZONE_ID gcloud services enable container.googleapis.com containerregistry.googleapis.com cloudbuild.googleapis.com gcloud components update gcloud components install beta gcloud components install kubectl gcloud beta container clusters create $GKE_CLUSTER \ --addons=HorizontalPodAutoscaling,HttpLoadBalancing,Istio,CloudRun \ --machine-type=n1-standard-4 \ --cluster-version="1.11.8-gke.6" \ --zone=$ZONE_ID \ --image-type "UBUNTU" \ --disk-type "pd-ssd" \ --disk-size "50" \ --enable-stackdriver-kubernetes \ --enable-ip-alias \ --scopes cloud-platform |
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.
|
1 |
kubectl apply -f 'https://install.portworx.com/?mc=false&kbver=1.11.8-gke.6&b=true&s=%22type%3Dpd-standard%2Csize%3D50%22&md=type%3Dpd-standard%2Csize%3D150&c=px-cluster-1fee88cb-6efe-4d5d-af6e-578caeac812c&gke=true&stork=true&lh=true&st=k8s' |
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.
|
1 2 3 4 5 6 7 |
kind: StorageClass apiVersion: storage.k8s.io/v1beta1 metadata: name: px-sc provisioner: kubernetes.io/portworx-volume parameters: repl: "3" |
|
1 |
kubectl create -f px-sc.yaml |
Taking advantage of dynamic provisioning, we will create a persistent volume control (PVC) based on the above storage class.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: px-mongo-pvc annotations: volume.beta.kubernetes.io/storage-class: px-sc spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi |
|
1 |
kubectl create -f px-mongo-pvc.yaml |
Now, we are ready to deploy the MongoDB pod.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: db labels: name: mongo app: todoapp spec: strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 1 type: RollingUpdate replicas: 1 template: metadata: labels: name: mongo app: todoapp spec: schedulerName: stork containers: - name: mongo image: mongo imagePullPolicy: "Always" ports: - containerPort: 27017 volumeMounts: - mountPath: /data/db name: mongodb volumes: - name: mongodb persistentVolumeClaim: claimName: px-mongo-pvc |
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
|
1 |
$ kubectl get pods |
Finally, it’s time to expose the pod internally through a ClusterIP. Create the below service with the name db.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
apiVersion: v1 kind: Service metadata: name: db labels: name: mongo app: todoapp spec: selector: name: mongo type: ClusterIP ports: - name: db port: 27017 targetPort: 27017 |
|
1 |
kubectl create -f db-svc.yaml |
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.
|
1 2 3 |
docker pull janakiramm/todo:latest docker tag janakiramm/todo gcr.io/$PROJECT_ID/cr-todo docker push gcr.io/$PROJECT_ID/cr-todo |
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 35.226.12.138. Before we can hit this URL, we also need to modify the HTTP header to reflect the hostname todo.default.example.com.
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.