|
| 1 | +# Cloud Run Worker |
| 2 | + |
| 3 | +This sample demonstrates how to run a Temporal Worker inside a |
| 4 | +[Google Cloud Run](https://cloud.google.com/run) container. It shows: |
| 5 | + |
| 6 | +- Reading Temporal connection config from environment variables. |
| 7 | +- Handling **SIGTERM gracefully** — Cloud Run sends SIGTERM and allows 10 seconds |
| 8 | + for the container to exit; the worker drains in-progress tasks before stopping. |
| 9 | +- Optional **mTLS** authentication for [Temporal Cloud](https://temporal.io/cloud) |
| 10 | + via base64-encoded certificate/key env vars. |
| 11 | + |
| 12 | +The sample registers a simple greeting Workflow and Activity. The same pattern |
| 13 | +applies to any Workflow/Activity definitions. |
| 14 | + |
| 15 | +## Prerequisites |
| 16 | + |
| 17 | +- A [Temporal Cloud](https://temporal.io/cloud) namespace **or** a self-hosted |
| 18 | + Temporal server reachable from Cloud Run (e.g. via VPC connector or Cloud Run |
| 19 | + direct VPC egress). |
| 20 | +- [Docker](https://www.docker.com/) for local testing. |
| 21 | +- [Google Cloud SDK (`gcloud`)](https://cloud.google.com/sdk) for deployment. |
| 22 | +- Python 3.10+ |
| 23 | + |
| 24 | +## Files |
| 25 | + |
| 26 | +| File | Description | |
| 27 | +|------|-------------| |
| 28 | +| `worker.py` | Entry point — connects to Temporal, registers Workflows/Activities, and handles SIGTERM | |
| 29 | +| `workflows.py` | Sample Workflow that executes a greeting Activity | |
| 30 | +| `activities.py` | Sample Activity that returns a greeting string | |
| 31 | +| `starter.py` | Helper script to start a Workflow execution from a local machine | |
| 32 | +| `Dockerfile` | Container definition for Cloud Run | |
| 33 | +| `deploy.sh` | Builds the image with Cloud Build and deploys to Cloud Run | |
| 34 | +| `pyproject.toml` | Standalone project manifest for this sample | |
| 35 | + |
| 36 | +## Environment Variables |
| 37 | + |
| 38 | +| Variable | Required | Description | |
| 39 | +|----------|----------|-------------| |
| 40 | +| `TEMPORAL_ADDRESS` | Yes | `host:port` of the Temporal frontend (e.g. `<ns>.<acct>.tmprl.cloud:7233`) | |
| 41 | +| `TEMPORAL_NAMESPACE` | Yes | Temporal namespace (e.g. `<ns>.<acct>`) | |
| 42 | +| `TEMPORAL_TASK_QUEUE` | No | Task queue name (default: `cloud-run-task-queue`) | |
| 43 | +| `TEMPORAL_TLS_CERT` | For Temporal Cloud | Base64-encoded mTLS client certificate | |
| 44 | +| `TEMPORAL_TLS_KEY` | For Temporal Cloud | Base64-encoded mTLS client private key | |
| 45 | + |
| 46 | +For Temporal Cloud, encode your credentials: |
| 47 | + |
| 48 | +```bash |
| 49 | +export TEMPORAL_TLS_CERT=$(base64 -i client.pem) |
| 50 | +export TEMPORAL_TLS_KEY=$(base64 -i client.key) |
| 51 | +``` |
| 52 | + |
| 53 | +## Local Development |
| 54 | + |
| 55 | +### 1. Start a local Temporal dev server |
| 56 | + |
| 57 | +```bash |
| 58 | +temporal server start-dev |
| 59 | +``` |
| 60 | + |
| 61 | +### 2. Run the worker |
| 62 | + |
| 63 | +```bash |
| 64 | +TEMPORAL_ADDRESS=localhost:7233 TEMPORAL_NAMESPACE=default uv run python worker.py |
| 65 | +``` |
| 66 | + |
| 67 | +### 3. Start a workflow |
| 68 | + |
| 69 | +In a separate terminal, from inside this directory: |
| 70 | + |
| 71 | +```bash |
| 72 | +TEMPORAL_ADDRESS=localhost:7233 TEMPORAL_NAMESPACE=default uv run python starter.py |
| 73 | +``` |
| 74 | + |
| 75 | +## Docker |
| 76 | + |
| 77 | +### Build |
| 78 | + |
| 79 | +```bash |
| 80 | +docker build -t cloud-run-worker . |
| 81 | +``` |
| 82 | + |
| 83 | +### Run locally (against local dev server) |
| 84 | + |
| 85 | +```bash |
| 86 | +docker run --rm \ |
| 87 | + -e TEMPORAL_ADDRESS=host.docker.internal:7233 \ |
| 88 | + -e TEMPORAL_NAMESPACE=default \ |
| 89 | + cloud-run-worker |
| 90 | +``` |
| 91 | + |
| 92 | +### Run locally (against Temporal Cloud) |
| 93 | + |
| 94 | +```bash |
| 95 | +docker run --rm \ |
| 96 | + -e TEMPORAL_ADDRESS=<ns>.<acct>.tmprl.cloud:7233 \ |
| 97 | + -e TEMPORAL_NAMESPACE=<ns>.<acct> \ |
| 98 | + -e TEMPORAL_TLS_CERT="$(base64 -i client.pem)" \ |
| 99 | + -e TEMPORAL_TLS_KEY="$(base64 -i client.key)" \ |
| 100 | + cloud-run-worker |
| 101 | +``` |
| 102 | + |
| 103 | +## Deploy to Cloud Run |
| 104 | + |
| 105 | +Use the provided `deploy.sh` script (requires `gcloud` and appropriate IAM |
| 106 | +permissions to push to Container Registry and deploy Cloud Run services): |
| 107 | + |
| 108 | +```bash |
| 109 | +export TEMPORAL_ADDRESS=<ns>.<acct>.tmprl.cloud:7233 |
| 110 | +export TEMPORAL_NAMESPACE=<ns>.<acct> |
| 111 | + |
| 112 | +./deploy.sh my-temporal-worker us-central1 my-gcp-project |
| 113 | +``` |
| 114 | + |
| 115 | +The script: |
| 116 | +1. Builds the container image with Cloud Build and pushes to Container Registry. |
| 117 | +2. Deploys the Cloud Run service with the necessary env vars. |
| 118 | +3. Reads `TEMPORAL_TLS_CERT` and `TEMPORAL_TLS_KEY` from Secret Manager secrets |
| 119 | + named `<service>-tls-cert` and `<service>-tls-key`. |
| 120 | + |
| 121 | +Or run `gcloud run deploy` directly: |
| 122 | + |
| 123 | +```bash |
| 124 | +gcloud run deploy my-temporal-worker \ |
| 125 | + --image gcr.io/my-gcp-project/my-temporal-worker:latest \ |
| 126 | + --region us-central1 \ |
| 127 | + --platform managed \ |
| 128 | + --no-allow-unauthenticated \ |
| 129 | + --set-env-vars "TEMPORAL_ADDRESS=<ns>.<acct>.tmprl.cloud:7233,TEMPORAL_NAMESPACE=<ns>.<acct>" \ |
| 130 | + --set-secrets "TEMPORAL_TLS_CERT=my-temporal-worker-tls-cert:latest,TEMPORAL_TLS_KEY=my-temporal-worker-tls-key:latest" \ |
| 131 | + --min-instances 1 \ |
| 132 | + --no-cpu-throttling |
| 133 | +``` |
| 134 | + |
| 135 | +Setting `--min-instances 1` ensures the worker is always polling; without it |
| 136 | +Cloud Run may scale to zero and leave no worker available for task execution. |
| 137 | + |
| 138 | +### Why a health server? |
| 139 | + |
| 140 | +Cloud Run services must listen on the port named by `$PORT` (default 8080) or the |
| 141 | +deploy's startup probe fails and the service never goes healthy. A Temporal worker |
| 142 | +only polls Temporal, so `worker.py` runs a tiny HTTP health endpoint in a background |
| 143 | +thread purely to satisfy that contract. The `--no-cpu-throttling` flag keeps CPU |
| 144 | +allocated between requests so the worker keeps polling, since Cloud Run otherwise |
| 145 | +throttles CPU to near zero when no HTTP request is in flight. |
| 146 | + |
| 147 | +## Further Reading |
| 148 | + |
| 149 | +- [Temporal Python SDK documentation](https://python.temporal.io) |
| 150 | +- [Temporal Cloud — production worker deployment](https://docs.temporal.io/production-deployment) |
| 151 | +- [Cloud Run — container contract](https://cloud.google.com/run/docs/container-contract) |
| 152 | +- [Cloud Run — handling signals (SIGTERM)](https://cloud.google.com/run/docs/reference/container-contract#lifecycle) |
0 commit comments