Deploy Aplikasi Container ke Google Cloud Run: dari Docker Image sampai Production URL

Mengapa Google Cloud Run?

Deploy aplikasi ke server tradisional membutuhkan provisioning, konfigurasi, dan pemeliharaan infrastruktur yang berkelanjutan. Google Cloud Run menghilangkan kompleksitas tersebut dengan model serverless: kita cukup mengirim Docker image, dan Cloud Run menangani scaling, load balancing, dan TLS secara otomatis.

Cloud Run cocok untuk aplikasi containerized yang menerima HTTP request. Platform ini menskalakan container dari nol ke ribuan instance berdasarkan traffic, dan menurunkan kembali ketika traffic berkurang. Kita hanya membayar waktu komputasi yang benar-benar digunakan — tidak ada biaya untuk instance yang idle.

Membuat Dockerfile yang Optimal

Langkah pertama adalah membuat Dockerfile yang menghasilkan image kecil dan aman. Multi-stage build memisahkan tahap build dari tahap runtime, mengurangi ukuran image final secara signifikan.

# Build stage
FROM node:20-slim AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

# Runtime stage
FROM node:20-slim
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY . .

ENV NODE_ENV=production
EXPOSE 8080

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

Dockerfile di atas menggunakan node:20-slim sebagai base image yang hanya berisi komponen minimal. Multi-stage build memastikan hanya node_modules production dan source code yang masuk ke image final — tanpa dev dependencies atau build tools. Cloud Run secara default mendengarkan port 8080, jadi kita ekspos port tersebut dan pastikan aplikasi menggunakan PORT environment variable.

Build dan Push Docker Image

Setelah Dockerfile siap, kita build image secara lokal, tag dengan registry Google Cloud, dan push ke Artifact Registry. Proses ini membutuhkan Google Cloud SDK terinstal dan project yang sudah dikonfigurasi.

# Set project ID
export PROJECT_ID="my-project-123"

# Build the image
docker build -t gcr.io/${PROJECT_ID}/my-app:latest .

# Push to Artifact Registry
docker push gcr.io/${PROJECT_ID}/my-app:latest

Output:

latest: Pushed
digest: sha256:a1b2c3d4e5f6789012345678901234567890abcdef1234567890 size: 2847

Penamaan image menggunakan format gcr.io/PROJECT_ID/IMAGE_NAME sesuai konvensi Google Cloud. Tag latest memudahkan testing awal, tetapi untuk production sebaiknya gunakan version tag spesifik seperti v1.2.3 untuk memudahkan rollback dan audit trail.

Deploy ke Cloud Run

Dengan image yang sudah di-push, kita bisa deploy ke Cloud Run menggunakan perintah gcloud run deploy. Perintah ini membuat service baru atau mengupdate service yang sudah ada dengan revision terbaru.

gcloud run deploy my-app \
  --image gcr.io/${PROJECT_ID}/my-app:latest \
  --platform managed \
  --region asia-southeast1 \
  --allow-unauthenticated \
  --port 8080 \
  --memory 256Mi \
  --cpu 1 \
  --max-instances 10

Output:

Deploying container to Cloud Run service [my-app] in project [my-project-123] region [asia-southeast1]
✓ Deploying... Done.
  ✓ Creating Revision... Done.
  ✓ Routing traffic... Done.

Service URL: https://my-app-abc123.asia-southeast1.run.app

Beberapa parameter penting yang perlu diperhatikan:

• --allow-unauthenticated membolehkan akses publik tanpa autentikasi. Jika aplikasi membutuhkan autentikasi, hilangkan flag ini dan konfigurasi IAM policy terpisah.
• --memory 256Mi mengalokasikan memori per container. Cloud Run mendukung hingga 32GiB, tetapi alokasi yang berlebihan meningkatkan biaya.
• --max-instances 10 membatasi jumlah maksimum instance untuk mengontrol biaya. Tanpa batas ini, Cloud Run bisa menskala ke ratusan instance pada traffic spike.

Mengonfigurasi Environment Variable dan Secrets

Aplikasi production membutuhkan konfigurasi dinamis — database URL, API keys, dan parameter lain yang berbeda antara staging dan production. Cloud Run mendukung environment variable langsung dan integrasi dengan Secret Manager untuk data sensitif.

gcloud run services update my-app \
  --region asia-southeast1 \
  --set-env-vars="NODE_ENV=production,PORT=8080" \
  --update-secrets="DB_PASSWORD=db-password:latest"

Output:

✓ Updating Service [my-app]... Done.
  ✓ Updating Revision... Done.
  ✓ Routing traffic... Done.

Service [my-app] revision [my-app-00003-xiz] has been deployed.

Untuk secrets yang dirujuk via --update-secrets, Cloud Run akan mengambil nilai terbaru dari Secret Manager setiap kali container dimulai. Pola ini memastikan rotasi password atau API key tidak membutuhkan re-deploy — cukup update secret di Secret Manager dan container baru akan menggunakan nilai terbaru.

Monitoring dan Logging

Setelah deploy, observabilitas menjadi kunci untuk memastikan aplikasi berjalan normal. Cloud Run terintegrasi langsung dengan Cloud Logging dan Cloud Monitoring tanpa konfigurasi tambahan.

# View recent logs
gcloud run services logs read my-app \
  --region asia-southeast1 \
  --limit 20

Output:

2026-04-15 08:23:41.123 PST  GET / 200 12ms
2026-04-15 08:23:42.456 PST  GET /api/health 200 3ms
2026-04-15 08:24:01.789 PST  POST /api/data 201 45ms

Semua stdout dan stderr dari container secara otomatis muncul di Cloud Logging. Untuk monitoring, Cloud Run menyediakan metrik bawaan seperti request count, latency percentiles, container memory, dan instance count. Kita bisa membuat dashboard di Cloud Monitoring atau mengatur alert berdasarkan threshold — misalnya, mengirim notifikasi ketika error rate melebihi 1% dalam window 5 menit.

Deployment Workflow yang Direkomendasikan

Untuk tim yang menggunakan CI/CD, Google menawarkan gcloud run deploy yang bisa diintegrasikan ke dalam pipeline. Workflow yang optimal mencakup build di CI, push ke Artifact Registry dengan version tag, deploy ke staging environment terlebih dahulu untuk smoke test, kemudian promote ke production jika semua tes lolos.

# Staging deploy with canary testing
gcloud run deploy my-app-staging \
  --image gcr.io/${PROJECT_ID}/my-app:v1.2.3 \
  --platform managed \
  --region asia-southeast1 \
  --no-traffic

# Route traffic gradually
gcloud run services update-traffic my-app \
  --region asia-southeast1 \
  --to-revisions=my-app-v123=25,my-app-v122=75

Pendekatan canary deployment memastikan hanya sebagian kecil traffic yang mengarah ke revision baru sebelum full rollout. Jika terjadi error pada revision baru, rollback bisa dilakukan dengan satu perintah tanpa downtime.

Siap menguasai cloud computing dan containerization secara praktis? Kunjungi kursus dan bootcamp di Rumah Coding untuk belajar langsung dari praktisi dan membangun portfolio project yang relevan dengan kebutuhan industri.