Google Cloud Run Explained: Deploy Containers Without Managing Servers

#!/bin/bash
# ─────────────────────────────────────────────────────────────
# GOAL: Build a Docker image, push it to Artifact Registry,
#       and deploy it as a Cloud Run service in one script.
#
# PREREQUISITES:
#   - gcloud CLI installed and authenticated
#   - Docker installed and running
#   - A GCP project with billing enabled
# ─────────────────────────────────────────────────────────────

# Replace these with your actual values
GCP_PROJECT_ID="my-production-project"
GCP_REGION="us-central1"
SERVICE_NAME="product-api"
IMAGE_NAME="us-central1-docker.pkg.dev/${GCP_PROJECT_ID}/cloud-run-services/${SERVICE_NAME}"

# Step 1: Authenticate Docker to push to Artifact Registry
# gcloud configures Docker credentials automatically — no manual login needed
gcloud auth configure-docker us-central1-docker.pkg.dev --quiet

# Step 2: Build the Docker image and tag it for Artifact Registry
# The tag format must match your Artifact Registry repository path exactly
docker build \
  --tag "${IMAGE_NAME}:latest" \
  --platform linux/amd64 \
  . # <── build context is the current directory (where Dockerfile lives)

# Step 3: Push the image to Artifact Registry
# Cloud Run pulls from here at deploy time — it never touches Docker Hub by default
docker push "${IMAGE_NAME}:latest"

# Step 4: Deploy to Cloud Run
gcloud run deploy "${SERVICE_NAME}" \
  --image "${IMAGE_NAME}:latest" \
  --platform managed \
  --region "${GCP_REGION}" \
  --allow-unauthenticated \
  --port 8080 \
  --memory 512Mi \
  --cpu 1 \
  --min-instances 0 \
  --max-instances 100 \
  --concurrency 80
  # --allow-unauthenticated: makes the service publicly accessible
  # --concurrency 80: each instance handles up to 80 simultaneous requests
  # --min-instances 0: scale to zero when idle (cheapest option)
  # --max-instances 100: hard cap to prevent runaway billing

# ── Stage 1: Install dependencies ──────────────────────────────
# We use a full Node image here because we need npm to install packages
FROM node:20-alpine AS dependency-installer
WORKDIR /build

# Copy package files first — Docker layer caching means if these
# haven't changed, npm install is skipped entirely on rebuild
COPY package.json package-lock.json ./
RUN npm ci --omit=dev
# npm ci is stricter than npm install — it respects package-lock.json exactly
# --omit=dev drops devDependencies so they don't bloat the final image

# ── Stage 2: Runtime image ──────────────────────────────────────
# Start fresh from a minimal Alpine image — no build tools, no npm cache
FROM node:20-alpine AS runtime
WORKDIR /app

# Create a non-root user — Cloud Run doesn't need root and neither does your app
RUN addgroup --system api-group && adduser --system --ingroup api-group api-user

# Copy only what we need: the installed node_modules and the app source
COPY --from=dependency-installer /build/node_modules ./node_modules
COPY src/ ./src/
COPY package.json ./

# Switch to non-root user before the app starts
USER api-user

# Cloud Run injects PORT at runtime — we expose 8080 as a documentation hint
# but the app itself must read process.env.PORT, not hardcode this number
EXPOSE 8080

CMD ["node", "src/server.js"]

#!/bin/bash
# ─────────────────────────────────────────────────────────────
# GOAL: Create a dedicated service account for the product-api,
#       store secrets in Secret Manager, and deploy Cloud Run
#       with proper IAM bindings — no plaintext secrets anywhere.
# ─────────────────────────────────────────────────────────────

GCP_PROJECT_ID="my-production-project"
GCP_REGION="us-central1"
SERVICE_NAME="product-api"
SERVICE_ACCOUNT_NAME="product-api-runner"
SERVICE_ACCOUNT_EMAIL="${SERVICE_ACCOUNT_NAME}@${GCP_PROJECT_ID}.iam.gserviceaccount.com"
IMAGE_NAME="us-central1-docker.pkg.dev/${GCP_PROJECT_ID}/cloud-run-services/${SERVICE_NAME}:latest"

# Step 1: Create a dedicated service account for this Cloud Run service
# Never use the default Compute SA — it has far too many permissions
gcloud iam service-accounts create "${SERVICE_ACCOUNT_NAME}" \
  --display-name "Service Account for product-api Cloud Run service" \
  --project "${GCP_PROJECT_ID}"

# Step 2: Store the database password in Secret Manager
# Read the secret from stdin so it never appears in your shell history
echo -n "super-secret-db-password" | \
  gcloud secrets create DB_PASSWORD \
    --data-file=- \
    --replication-policy="automatic" \
    --project "${GCP_PROJECT_ID}"
# The -n flag on echo prevents a trailing newline — important for passwords!

# Step 3: Grant the service account permission to READ this specific secret
# Note: secretAccessor only allows reading — not creating or deleting secrets
gcloud secrets add-iam-policy-binding DB_PASSWORD \
  --member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \
  --role="roles/secretmanager.secretAccessor" \
  --project "${GCP_PROJECT_ID}"

# Step 4: Deploy Cloud Run with the dedicated service account
# and mount the secret as an environment variable at runtime
gcloud run deploy "${SERVICE_NAME}" \
  --image "${IMAGE_NAME}" \
  --platform managed \
  --region "${GCP_REGION}" \
  --service-account "${SERVICE_ACCOUNT_EMAIL}" \
  --update-secrets="DB_PASSWORD=DB_PASSWORD:latest" \
  # ↑ Format: ENV_VAR_NAME=SECRET_NAME:VERSION
  # Cloud Run fetches the secret at startup and injects it as an env var
  # Your app reads it with: process.env.DB_PASSWORD — same as any env var
  --set-env-vars="NODE_ENV=production,DB_HOST=10.0.0.5,DB_NAME=products_db" \
  --allow-unauthenticated

# Step 5: Verify the deployment and check the service account is correct
gcloud run services describe "${SERVICE_NAME}" \
  --region "${GCP_REGION}" \
  --format="value(spec.template.spec.serviceAccountName)"