Google Cloud Run is responsible for creating and deploying highly scalable containerized applications on a completely managed serverless platform. This service allows you to write code your way using your favorite languages (Go, Python, Java, Ruby, Node.js, and more). Moreover, here, you can summarize all infrastructure management for a simple developer experience and can create the container and Knative open standards, enabling the portability of your applications. 

Benefits of Cloud Run:
  • In Google Cloud Run, you can write code accordion to your way by creating any code or container that listens for requests or events. This allows to use anylanguage, with favorite dependencies and tools, and deploy them in seconds.
  • Secondly, you can abstract all infrastructure management by automatically scaling up and down from zero almost directly based on traffic. You only have to pay for the resources you use.
  • Lastly, Cloud RUn offers a developer experience in which you can create app development and deployment simpler and faster. Moreover, this is combined with Cloud Code, Cloud Build, Cloud Monitoring, and Cloud Logging for an enhanced end-to-end developer experience.

What are the features of Cloud Run?

Google Cloud Run comes with various in-built features that make it the best in the market.

1. Leverage container workflows and standards

Containers are now a standard for packaging and deploying code and its dependencies. However, Cloud Run pairs well with the container ecosystem like Cloud Build, Cloud Code, Artifact Registry, and Docker.

2. Pay‐per‐use

In Cloud Run, you only have to pay when your code is running, charged to the nearest 100 milliseconds.

3. Enhanced developer experience

Cloud Run comes with a command‐line and user interface for deploying and managing your services. For continuous deployments, this is used with Cloud Code and Cloud Build.

4. Completely Managed

In this, you do not have to worry about managing infrastructure. After deploying, Cloud Run automatically manages your services.

5. Quick autoscaling

Cloud Run takes care of scaling up or down from zero to N depending on the amount of traffic.

6. Redundancy

Cloud Run services are regional, with various zones automatically duplicated.

7. Security

Cloud Run prepares secrets from Secret Manager. Moreover, it only deploys trusted container images with Binary Authorization with have support for bringing your own encryption keys. Further, in this, the container instances run in a secure sandbox isolated from other resources, with dedicated identities and permissions.

8. Integrated logging and monitoring

Cloud Run offers integration with Cloud Monitoring, Cloud Logging, Cloud Trace, and Error Reporting for ensuring the health of an application.

9. Process asynchronous events

In this, you can set up triggers for receiving events from 60+ Google Cloud sources through Cloud Audit Logs or Custom sources via Cloud Pub/Sub

10. Portability

Cloud Run accepts standard container images and is created on the Knative open-source project, thus allowing the portability of your workloads over platforms.

11. HTTPS URLs

Every Cloud Run service comes with a secure HTTPS endpoint that handles TLS termination for you. You may also map your services to your own domains like this.

12. HTTP/2, WebSockets, and gRPC

You can request and connect Cloud Run services with HTTP/1.*, HTTP/2, WebSockets, or gRPC (unary and streaming).

Use cases for Google Cloud Run:

1. Web services: Websites

In Google Cloud Run, you can create your website using a mature technology stack like Nginx, ExpressJS, and Django. Moreover, you can access your SQL database on Cloud SQL, and display dynamic HTML pages.

Icon for Google Chrome flows to rectangle with programming languages Node.js, django, and Ruby on Rails, all which flow into Cloud SQL Relational
Image Source: Google Cloud
2. Web services: REST APIs backend

You should know that modern mobile apps usually depend on RESTful backend APIs for providing current views of application data and separation for frontend and backend development teams. However, the API services running on Cloud Run provide developers access for continuing data reliably on managed databases like Cloud SQL or Firestore (NoSQL). 

Example
Image Source: Google Cloud
3. Web services: Back‐office administration

Back‐office administration mostly needs documents, spreadsheets, and other custom integrations, and running a vendor‐supplied web application. Hosting the containerized internal web application on Cloud Run, on the other hand, ensures that it is always available and that you are only billed when it is utilized.

example
Image Source: Google Cloud
4. Data processing: Lightweight data transformation

In Cloud Run, you can create data processing applications that convert lightweight data as it arrives and store it as structured data. Transformations can trigger from Google Cloud sources.

However, when a .csv file is built, an event is fired and delivered to a Cloud Run service. Then, the data is extracted, structured, and stored in a BigQuery table.

GCP exam course
5. Automation: Scheduled document generation

In Cloud Run, you can schedule a monthly job with Cloud Scheduler for creating invoices using a Cloud Run service. This is because containers containing custom binaries can be deployed to Cloud Run. Moreover, it is able to run in a PDF generation tool such as LibreOffice in a serverless way. This means that you only pay when you are creating invoices.

Use case diagram for scheduled document generation: Flow from Cloud Scheduler box on left, arrow labeled Every month moves right, to middle in stack of 3 boxes labeled PDF generation / Cloud Run. Arrow pointing up labeled Get customer data leads to Cloud SQL Relational. Arrow down, labeled Store invoices, leads to Cloud Storage
Image Source: Google Cloud
6. Automation: Business workflow with webhooks

Using Cloud Run, you connect your operations together with an event‐driven approach. Moreover, Cloud Run scales on demand while implementing a webhook target, pushing events in the form of requests and only charging you when you receive and process the event.

Further, you can also react to events from GitHub or Slack, or send webhooks when

  • a purchase is made
  • a job is ready
  • an alert is fired with a service that can react on a just‐in‐time basis for triggering a microservice in your infrastructure.
Box on left labeled Developer leads to right with arrow labeled Push code to Git Repository box, flows right with POST request arrow to 2nd in stack of 3 boxes, labeled Webhook Receiver/Cloud Run. Arrow labeled Triggering points up to Other services box, another label, Relay, leads down to Google Chat.
Image Source: Google Cloud

Above we have covered the basic features and use cases of the Cloud Run. Now, it’s time to get started with the service.

Getting Started with Cloud Run

1. Deploying a Prebuilt Sample Container 

In this, we will learn the process of deploying a sample container that has already been uploaded to the Container Registry repository to Cloud Run.

Deploying the sample container

For deploying a container:

  1. Firstly, go to Cloud Run
  2. Secondly, click Create service for displaying the Create service form:
image
Image Source: Google Cloud

Then, in the form,

  • Firstly, select the region where you want your service located.
  • Secondly, define the name you want to give to your service.
  • Then, click Next to continue to the Configure the service’s first revision page:
Example google cloud run
Image Source: Google Cloud

Next, in the form,

  • Firstly, select Deploy one revision from an existing container image.
  • Secondly, use us-docker.pkg.dev/cloudrun/container/hello as the container image.
  • Then, click Next to continue to the Configure how this service is triggered page:
image google cloud run
Image Source: Google Cloud
  • After that, select Allow unauthenticated invocations to be able to open the result in your web browser
  • Next, click Create for deploying the image to Cloud Run and wait for the deployment to finish.

3. Lastly, click the displayed URL link for running the deployed container.

2. Building and Deploying

Here, you can build a simple application and package it into a container. After that, you can deploy the container image to Cloud Run. For this, you can use any of the provided languages:

  • Go
  • Node.js service
  • Python service
  • Java service
  • C# service
  • C++ service
  • PHP service
  • Ruby service
  • Shell service
  • Other languages

For Example: 

Building and deploying a Python service: 

For writing an application in Python:

  • Firstly, create a new directory named helloworld and modify the directory into it:

mkdir helloworld

cd helloworld

  • Secondly, create a file named main.py. After that, paste the following code into it:

run/helloworld/main.py

google cloud run example
Image Source: Google Cloud

However, this code responds to requests with our “Hello World” greeting. Gunicorn web server in the container handles the HTTP. When directly requested for local use, this code builds a basic web server that listens on the port specified by the PORT environment variable.

Containerizing an app and uploading it to Container Registry

Create a new file named Dockerfile in the same directory as the source files to containerize the sample app. Then, copy the following content:

The Python Dockerfile begins a Gunicorn web server that listens on the port specified by the PORT environment variable:

run/helloworld/Dockerfile

example
Image Source: Google Cloud
  • After that, add a .dockerignore file to exclude files from your container image.

run/helloworld/.dockerignore

example
Image Source: Google Cloud
  • Now, create a container image using Cloud Build, by running the command given below from the directory containing the Dockerfile:

gcloud builds submit –tag gcr.io/PROJECT-ID/helloworld

In this, the PROJECT-ID is your GCP project ID. You can obtain it by running gcloud config get-value project.

  • Lastly, you will see a SUCCESS message containing the image name (gcr.io/PROJECT-ID/helloworld). Further, the image can be re-used and is stored in Container Registry.
Deploying to Cloud Run

For deploying the container image:

  • Use the following command:
    • gcloud run deploy –image gcr.io/PROJECT-ID/helloworld
    • However, if reminded for enabling the API, Reply y to enable.
    • Then, replace PROJECT-ID with your GCP project ID. Moreover, you can view your project ID by running the command gcloud config get-value project.
      • Here, you will get a reminder for the service name: press Enter to accept the default name, helloworld.
      • Then, you will get a reminder for the region: select the region of your choice.
      • Then, you will get reminder to allow unauthenticated invocations: respond y.
  • Secondly, go on the deployed container by opening the service URL in a web browser. And, after finishing the deployment, you can successfully deploy an application packaged in a container image to Cloud Run. 
    • Further, Cloud Run has the ability for automatically and horizontally scaling out your container image for handling the received requests, then scales in when demand decreases. 
Cleaning up

You can delete your image or delete your Cloud project for avoiding incurring charges. Furthermore, removing your Cloud project cancels any charges for the resources utilised in that project. For deleting:

  • Firstly, go to the Manage resources page in the Cloud Console.
  • Then, select the project that you want to delete from the project list, and then click Delete.
  • Lastly, type the project ID in the dialog, and then click Shut down for deleting the project.

What is Cloud Run pricing?

In Cloud Run, you only have to pay for the resources you use. This gets rounded up to the nearest 100 milliseconds. However, the total Cloud Run bill will be the cost of the resources in the pricing table. While setting concurrency higher than one request at a time, multiple requests can share the assigned CPU and memory.

Billable time:

You only have to pay for the CPU and memory used during billable time, which is rounded up to the closest 100 milliseconds. However, for a given container instance, active billable time occurs when:

  • Firstly, the container instance is beginning.
  • Secondly, the container instance is shutting down (handling the SIGTERM signal).
  • Lastly, at least one request is being processed by the container instance. Active billable time starts at the beginning of the first request and ends at the end of the last request.

Final Words

Above we have understood the concepts of Google Cloud Run by covering the benefits, features, use cases, and how to get started with it. Many major firms are benefiting from this service, which allows them to quickly interact with a wide range of partner technologies. So, if you have an interest in learning more about Cloud Run then, go through the blog and use Google Documentation as a reference for getting more clarity.

professional cloud architect practice tests
Menu