Patrones de GCP Cloud Run y AWS Fargate

Las plataformas de contenedores permiten a los equipos de Go ejecutar un main normal con net/http o gRPC mientras la nube gestiona el escalado, el parcheo y el balanceo de carga.

Cloud Run optimiza para HTTP impulsado por solicitudes con escalado a cero; AWS Fargate ejecuta tareas de ECS sin gestionar EC2, a menudo para servicios estables en lugar de economías de inactivo a cero.

Resumen

Envía una imagen OCI mínima con un binario Go estático, escucha en $PORT y configura las comprobaciones de salud de la plataforma.

Cloud Run establece solicitudes concurrentes máximas por instancia, ajústalo según la latencia del manejador y el tamaño del grupo de bases de datos.

Las tareas de Fargate necesitan CPU/memoria en la definición de la tarea, red awsvpc y Service Connect opcional para el descubrimiento estilo service mesh.

Ambas plataformas se benefician del apagado elegante consciente de SIGTERM en Go.

Receta

Tarjeta de receta de referencia rápida, lista para copiar y pegar.

srv := &http.Server{
    Addr:              ":" + port,
    Handler:           mux,
    ReadHeaderTimeout: 5 * time.Second,
    ReadTimeout:       30 * time.Second,
    WriteTimeout:      30 * time.Second,
    IdleTimeout:       120 * time.Second,
}
go func() {
    <-shutdown
    ctx, cancel := context.WithTimeout(context.Background(), 15*time.Second)
    defer cancel()
    _ = srv.Shutdown(ctx)
}()
log.Fatal(srv.ListenAndServe())

# Esquema de despliegue de Cloud Run
gcloud run deploy api --image IMAGE --region REGION --concurrency 80 --cpu 1 --memory 512Mi

Cuándo usar esto:

• APIs REST públicas con tráfico variable que deberían permanecer inactivas de forma económica (Cloud Run).
• Trabajadores en segundo plano o APIs internas siempre activas en AWS sin los límites de Lambda (Fargate).
• Equipos que ya están contenerizando Go en CI y desean paridad con docker run local.

Ejemplo de Trabajo

package main
 
import (
    "context"
    "log/slog"
    "net/http"
    "os"
    "os/signal"
    "syscall"
    "time"
)
 
func main() {
    port := os.Getenv("PORT")
    if port == "" {
        port = "8080"
    }
    mux := http.NewServeMux()
    mux.HandleFunc("GET /healthz", func(w http.ResponseWriter, r *http.Request) {
        w.WriteHeader(http.StatusNoContent)
    })
    mux.HandleFunc("GET /readyz", func(w http.ResponseWriter, r *http.Request) {
        // opcional: hacer ping a la base de datos con un tiempo de espera corto
        w.WriteHeader(http.StatusNoContent)
    })
    mux.HandleFunc("GET /api/status", func(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("Content-Type", "application/json")
        _, _ = w.Write([]byte(`{"status":"ok"}`))
    })
 
    srv := &http.Server{
        Addr:              ":" + port,
        Handler:           mux,
        ReadHeaderTimeout: 5 * time.Second,
    }
 
    stop := make(chan os.Signal, 1)
    signal.Notify(stop, syscall.SIGTERM, syscall.SIGINT)
    go func() {
        <-stop
        slog.Info("inicio de apagado")
        ctx, cancel := context.WithTimeout(context.Background(), 20*time.Second)
        defer cancel()
        if err := srv.Shutdown(ctx); err != nil {
            slog.Error("error de apagado", "err", err)
        }
    }()
 
    slog.Info("escuchando", "addr", srv.Addr)
    if err := srv.ListenAndServe(); err != http.ErrServerClosed {
        slog.Error("error del servidor", "err", err)
        os.Exit(1)
    }
}

Lo que esto demuestra:

• Liveness (/healthz) y readiness (/readyz) separadas para orquestadores.
• ReadHeaderTimeout en el servidor para protección contra clientes lentos.
• Manejador SIGTERM con Shutdown limitado: Cloud Run envía SIGTERM antes de matar el contenedor.

Análisis Profundo

Cómo Funciona

• Cloud Run antepone un proxy gestionado por Google a tu contenedor, dirige HTTP al puerto del contenedor y escala las instancias basándose en la tasa de solicitudes y la configuración de concurrencia.
• Cuando el tráfico cae a cero, Cloud Run puede escalar a cero instancias: no pagas nada por cómputo hasta la siguiente solicitud (se aplica el arranque en frío).
• Fargate programa tareas en capacidad gestionada por AWS; los servicios ECS mantienen las tareas con recuento deseado en ejecución, sin escalado a cero por defecto.

Perillas de Cloud Run para Go

Patrón de Tarea Fargate

{
  "family": "go-api",
  "cpu": "512",
  "memory": "1024",
  "networkMode": "awsvpc",
  "containerDefinitions": [{
    "name": "api",
    "image": "ACCOUNT.dkr.ecr.REGION.amazonaws.com/go-api:latest",
    "portMappings": [{"containerPort": 8080}],
    "healthCheck": {
      "command": ["CMD-SHELL", "wget -q -O- http://127.0.0.1:8080/healthz || exit 1"],
      "interval": 30,
      "timeout": 5,
      "retries": 3
    },
    "stopTimeout": 30
  }]
}

Haz coincidir stopTimeout del contenedor con el presupuesto de Shutdown de tu Go para que ECS no haga SIGKILL a mitad del vaciado.

Compensaciones del Escalado a Cero

Errores Comunes

• :8080 codificado ignorando PORT: Cloud Run inyecta PORT; enlazar el puerto incorrecto falla las comprobaciones de salud del despliegue. Solución: Leer os.Getenv("PORT") con un respaldo.
• Sin manejo de SIGTERM: La plataforma mata el proceso después de un breve período de gracia. Solución: signal.Notify + srv.Shutdown.
• Concurrencia demasiado alta para grupos de bases de datos: 80 solicitudes concurrentes con MaxOpenConns=10 causan esperas o tiempos de espera. Solución: Alinear la concurrencia de Cloud Run con las matemáticas del grupo.
• Imágenes de contenedor grandes: Arranques en frío lentos en Cloud Run. Solución: Imágenes distroless o scratch; compilaciones multi-etapa.
• Rol de tarea Fargate faltante: Las llamadas al SDK de AWS fallan con acceso denegado. Solución: Adjuntar un rol de tarea IAM en paralelo a los roles de ejecución de Lambda.
• Readiness igual a liveness: Las interrupciones de la base de datos reinician toda la tarea en lugar de detener el tráfico. Solución: Fallar solo /readyz, mantener /healthz económico.

Alternativas

Preguntas Frecuentes

Relacionados

• Conceptos básicos de Cloud Deploy - Dockerfile y gcloud run deploy
• Go en la Nube: Lambda, Cloud Run y Más Allá - modelos de contenedor vs función
• Secretos, IAM y Workload Identity - Cuentas de servicio de Cloud Run y roles de tarea de Fargate
• HTTP/2, Tiempos de espera y ReverseProxy - ajuste de http.Server en producción
• Guía de Decisión de Arquitectura Serverless de Go - selección de plataforma
• Mejores Prácticas de Cloud y Serverless - costo y observabilidad

Versiones de Stack: Esta página fue escrita para Go 1.26.x (predeterminado GC Green Tea, go fix modernizers - verifica el parche en la compilación), chi (última versión - verifica en la compilación), gin (última versión - verifica en la compilación), echo (última versión - verifica en la compilación), google.golang.org/grpc (última versión - verifica en la compilación), sigs.k8s.io/controller-runtime (última versión - verifica en la compilación), kubebuilder (última versión - verifica en la compilación), tinygo (última versión - verifica los objetivos de la placa en la compilación), wazero (última versión - verifica en la compilación) y golangci-lint (última versión - verifica el conjunto de linters en la compilación).