GCP Cloud Run

Cloud Run is GCP's serverless platform for running containerized applications. A container is a packaged application that includes all its code, libraries, and dependencies — it runs the same way in any environment. Cloud Run takes that container, runs it on demand, and scales it automatically from zero to thousands of instances.

Think of Cloud Run like a vending machine. The container is the pre-packaged item. When someone places an order (HTTP request), the vending machine instantly delivers the product (response). When no one is buying, the machine sits idle and costs nothing.

Cloud Run vs App Engine vs Compute Engine

Understanding Containers

A container is created from a Dockerfile — a script that defines the environment. The container image is then stored in a container registry and pulled by Cloud Run to execute requests.

Dockerfile
    │
    │ docker build
    ▼
Container Image
    │
    │ Push to Artifact Registry
    ▼
Google Artifact Registry
    │
    │ Cloud Run pulls image
    ▼
Cloud Run Service (running container)
    │
    │ Responds to HTTP requests
    ▼
User receives response

Building and Deploying to Cloud Run

Step 1 – Write the Application

# app.py (Python Flask)
from flask import Flask
import os

app = Flask(__name__)

@app.route('/')
def hello():
    name = os.environ.get('NAME', 'World')
    return f'Hello, {name}! Running on Cloud Run.'

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=int(os.environ.get('PORT', 8080)))

Step 2 – Create the Dockerfile

# Dockerfile
FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install -r requirements.txt

COPY . .

CMD ["python", "app.py"]

Step 3 – Deploy Directly to Cloud Run

Cloud Run can build and deploy in one step using the source deploy method (no separate Docker build required):

# Deploy directly from source code
gcloud run deploy my-app \
  --source . \
  --region us-central1 \
  --allow-unauthenticated

After deployment, Cloud Run provides a URL like:

https://my-app-abcd1234-uc.a.run.app

Cloud Run Service Configuration

Cloud Run Service: my-app
┌────────────────────────────────────────────────┐
│  Container Image: gcr.io/my-project/my-app     │
│  Region: us-central1                           │
│  Min Instances: 0  (scales to zero when idle)  │
│  Max Instances: 100                            │
│  Memory: 512 MiB                               │
│  CPU: 1 vCPU                                   │
│  Timeout: 300 seconds                          │
│  Concurrency: 80 requests per instance         │
└────────────────────────────────────────────────┘

Key configuration options:

Authentication in Cloud Run

Cloud Run services can be public or private:

• Allow unauthenticated requests: Anyone on the internet can call the service. Used for public APIs and websites.
• Require authentication: Only principals with the roles/run.invoker IAM role can call the service. Used for internal microservices.

# Allow a service account to call a private Cloud Run service
gcloud run services add-iam-policy-binding my-private-service \
  --region=us-central1 \
  --member="serviceAccount:my-app-sa@my-project.iam.gserviceaccount.com" \
  --role="roles/run.invoker"

Cloud Run Jobs

Cloud Run also supports Jobs — tasks that run to completion instead of serving HTTP requests. Jobs are ideal for data processing, batch operations, and scheduled scripts.

# Create and run a Cloud Run Job
gcloud run jobs create my-batch-job \
  --image gcr.io/my-project/batch-processor \
  --region us-central1 \
  --tasks 10 \
  --max-retries 3

# Execute the job
gcloud run jobs execute my-batch-job --region us-central1

Connecting Cloud Run to Cloud SQL

Cloud Run Service
        │
        │ Uses Cloud SQL connection name
        ▼
Cloud SQL Auth Proxy (built into Cloud Run)
        │
        ▼
Cloud SQL Instance

gcloud run deploy my-app \
  --source . \
  --region us-central1 \
  --add-cloudsql-instances my-project:us-central1:my-db \
  --set-env-vars DB_NAME=mydb,DB_USER=app \
  --set-secrets DB_PASS=db-password:latest

Key Takeaways

• Cloud Run runs containerized applications without managing servers.
• It scales automatically from zero to thousands of instances based on traffic.
• Billing is based on request processing time — idle services cost nothing.
• A Dockerfile defines the container environment.
• Source deploy (--source .) builds and deploys in one command.
• Cloud Run Jobs handle one-time or scheduled batch tasks.
• Private services require IAM authentication using the invoker role.