Esto es Cloud Run: Nueve formas de implementar (y cuándo usar cada uno) Para Windows 7,8,10,11

Esta es la parte 2 de la serie “Esto es Cloud Run”. En Parte 1, cubrimos qué es Cloud Run, ¿Qué hay detrás de la cortina?, lo que obtienes gratis, Funciones de ejecución en la nube, los límites de la plataforma, y el camino de la migración a Kubernetes. Ahora seamos prácticos.

En parte 1, la pregunta era "¿debería usar Cloud Run?"?" Aquí, el caso es "¿Cómo puedo ingresar mi código?"?"

Este no es un tutorial paso a paso.. Este artículo es el por qué detrás de cada opción, para que puedas tomar decisiones informadas en lugar de copiar comandos.

Opciones de implementación

Una de las fortalezas subestimadas de Cloud Run es la cantidad de formas en que puede ingresar su código en la plataforma.. Entre la CLI, la consola, YAML, Terraformar, Construcción de nube, Acciones de GitHub, Implementación en la nube, bibliotecas cliente, y más, no faltan opciones. No voy a cubrirlos todos.. En cambio, Me centraré en los que encuentro más útiles en los proyectos en los que trabajo., desde prototipos rápidos hasta implementaciones de producción.

Del código fuente

gcloud ejecutar implementar mi-servicio --source . --región us-central1

Este es el comando "Solo quiero que esto se ejecute". Apuntas gcloud a tu directorio de código fuente, y Cloud Run se encarga de todo lo demás. But "everything else" hides a multi-step pipeline that's worth understanding:

Subir. gcloud comprime tu directorio de origen y lo sube a Construcción de nube.
Detectar. Ejecuciones de compilación en la nube Paquetes de compilación de Google Cloud, que inspeccionan su código para determinar el lenguaje y el marco. Encontré un archivo de requisitos.txt? Pitón. Encontrado gunicorn en las dependencias.? That's your server.
Construir. Los paquetes de compilación crean una imagen de contenedor: imagen base segura, dependencias instaladas, punto de entrada configurado. Si un Dockerfile está presente en su directorio, Cloud Build usa eso en lugar de paquetes de compilación.
Empujar. La imagen construida se empuja a Registro de artefactos, Registro de contenedores de Google Cloud.
Desplegar. Cloud Run extrae la imagen y la implementa como nueva revisión.

Todo desde un comando. No necesitas conocer Docker, no es necesario comprender los registros de contenedores, y ni siquiera necesitas un Dockerfile.

La compensación es el control.. No puede personalizar la imagen base ni ejecutar compilaciones de varias etapas. Si no necesitas nada de eso, La implementación de código fuente funciona perfectamente bien en producción.. Muchos de mis servicios se ejecutan de esta manera.. Pero si necesita un control preciso sobre lo que hay en el contenedor, la siguiente opción te da eso.

Lo mejor para: Iteraciones rápidas durante el desarrollo., creación de prototipos, desarrolladores nuevos en contenedores, y los momentos de "solo quiero que esto funcione".

Desde una imagen de contenedor prediseñada

gcloud ejecutar implementar mi servicio \
  --imagen us-docker.pkg.dev/my-project/repo/my-image:v1.2.3 \
  --región us-central1

Este es el camino de producción.. Creas tu imagen de Docker como quieras (en la zona, en CI, en Construcción de nube), empujarlo a Registro de artefactos, e implementar por URL de imagen. Note la bandera: –imagen en lugar de –fuente. No build step happens on Google's side. Cloud Run extrae la imagen y comienza a ejecutarla, lo que hace que la implementación en sí sea mucho más rápida.

La ventaja clave es el control total sobre el proceso de construcción.. Construcciones de varias etapas para mantener las imágenes pequeñas. Imágenes base personalizadas ajustadas para su tiempo de ejecución. Secretos de tiempo de compilación para registros de paquetes privados. Cualquiera que sea su Dockerfile necesita. Si te importan las imágenes mínimas, versiones de imagen base fijadas, y una pequeña superficie de ataque, aquí es donde obtienes eso.

Lo mejor para: Implementaciones de producción, equipos con canales de construcción existentes, cargas de trabajo que necesitan pasos de compilación personalizados.

Funciones de ejecución en la nube

gcloud ejecutar implementar mi función \
  --fuente . \
  --función mipunto de entrada \
  --imagen base python312 \
  --región us-central1

Cubrimos Funciones de ejecución en la nube en profundidad en la parte 1, Así que aquí nos centraremos en la mecánica de implementación.. Dos indicadores distinguen una implementación de función de una implementación de servicio:

–función mipunto de entrada selecciona qué función en su código fuente usar como punto de entrada HTTP. Su fuente puede definir múltiples funciones; cada implementación sirve a uno.
–imagen base python312 selecciona un imagen base administrada para el tiempo de ejecución. Google gestiona estas imágenes base, incluyendo parches de seguridad, so you don't maintain a Dockerfile.

Los tiempos de ejecución compatibles incluyen Node.js, Pitón, Ir, Java, .NETO, Rubí, y PHP. También puede implementar funciones de Cloud Run desde Interfaz de usuario de la consola con un editor de código en línea, lo cual es útil para experimentos rápidos.

Lo mejor para: Puntos finales de propósito único, ganchos web, controladores de eventos, y el patrón de proxy API LLM que describí en la Parte 1.

Interfaz de usuario de la consola

El Consola de Google Cloud proporciona una interfaz de apuntar y hacer clic para implementar servicios de Cloud Run. Selecciona una imagen de contenedor de Artifact Registry, configurar los ajustes a través de un formulario guiado (UPC, memoria, escalada, variables de entorno, redes), y desplegar sin tocar la línea de comando.

Una cosa para la que la consola es sorprendentemente buena: descubrimiento. Antes de memorizar los indicadores CLI, Al hacer clic en el formulario de la consola, se muestran todas las opciones de configuración que ofrece Cloud Run.. Lo he usado más de una vez para descubrir una configuración que no sabía que existía., Luego lo repliqué en mis scripts de implementación..

Pero la Consola tiene una limitación obvia: no es programable. Cada implementación es manual, lo que significa que no es repetible, no controlable por versión, e imposible codificar la revisión. No puedes obtener diferencias con un clic.

Lo mejor para: Exploración, implementaciones únicas, revisar y ajustar las configuraciones visualmente, y aprender qué opciones existen antes de escribir la automatización.

CLI de gcloud con configuración completa

Ya has visto la implementación de gcloud run con indicadores mínimos.. Pero el mismo comando es también una herramienta de implementación con todas las funciones docenas de opciones de configuración. Cada configuración de Cloud Run es una bandera:

gcloud ejecutar implementar mi servicio \
  --imagen us-docker.pkg.dev/my-project/repo/my-image:v1.2.3 \
  --región us-central1 \
  --memoria 512Mi \
  --UPC 1 \
  --instancias mínimas 0 \
  --instancias máximas 10 \
  --concurrencia 80 \
  --set-env-vars "DB_HOST=10.0.0.1,ENV=production" \
  --set-secrets "API_KEY=my-secret:el último" \
  --cuenta-servicio [email protected] \
  --sufijo de revisión v1-2-3

Memoria? una bandera. Secretos de Gerente secreto? una bandera. Conectividad VPC? una bandera. Esto hace que los comandos de gcloud se puedan programar, repetible, y fácil de incluir en scripts de shell o canalizaciones de CI/CD.

Una cosa que lo mantiene práctico.: la configuración es pegajosa. Una vez que estableces una bandera, permanece en el servicio hasta que lo cambie explícitamente. Por lo tanto, su primera implementación podría ser la más larga con –memoria, –UPC, –instancias máximas, y todo lo demás. Pero las implementaciones posteriores pueden volver a la simple ejecución de gcloud, implementar mi servicio. –imagen mi-imagen:v2 –región us-central1 y todas sus configuraciones anteriores se transfieren. Sólo especificas lo que quieres cambiar.

Lo mejor para: Implementaciones con script, scripts de shell, Integración CI/CD, y cuando necesitas preciso, control repetible sobre cada configuración.

YAML declarativo

Los servicios de ejecución de gcloud reemplazan service.yaml --region us-central1

Las banderas CLI son imperativas: “cambiar estas cosas”. YAML es declarativo: “Esto es lo que quiero”. Usted define toda la configuración de su servicio en un archivo., y Cloud Run hace que la realidad coincida. Si algo se desvió (alguien modificó una configuración en la consola), el YAML lo corrige. si nada cambio, no pasa nada.

El YAML sigue el Esquema de Knative Serving API v1:

versión api: sirviendo.knative.dev/v1
amable: Servicio
metadatos:
  nombre: mi-servicio
  etiquetas:
    cloud.googleapis.com/ubicación: us-central1
  anotaciones:
    run.googleapis.com/ingress: todo
especulación:
  plantilla:
    metadatos:
      anotaciones:
        autoscaling.knative.dev/minScale: '0'
        autoscaling.knative.dev/maxScale: '10'
    especulación:
      contenedorConcurrencia: 80
      contenedores:
        - imagen: us-docker.pkg.dev/my-project/repo/my-image:v1.2.3
          puertos:
            - contenedorPuerto: 8080
          recursos:
            límites:
              memoria: 512Mi
              UPC: '1'
          ambiente:
            - nombre: ENV
              valor: "production"

Este es el mismo modelo que Kubernetes y Terraformar: usted describe Lo que quieras, no cómo llegar allí. Y porque el esquema es compatible con Knative, estos archivos YAML son portátiles entre Cloud Run y autohospedados Bribón es kubernetes.

Un consejo práctico: puedes exportar la configuración de un servicio existente con los servicios de ejecución de gcloud describe SERVICIO –exportar formato > servicio.yaml, modificarlo, y volver a aplicar. Esta es una excelente manera de llevar un servicio que se implementó originalmente a través de la consola o CLI al control de versiones..

Un matiz importante: Políticas de IAM (¿Quién puede invocar su servicio?) se gestionan por separado de la definición del servicio. El YAML define la configuración del servicio.; Acceso a controles de enlace de políticas add-iam de servicios de ejecución de gcloud. Esta es realmente una buena práctica., Dado que el control de acceso a menudo lo gestiona un equipo diferente..

Lo mejor para: Flujos de trabajo de GitOps, infraestructura como código, equipos que quieren configuración en control de versiones, y equipos que migran desde Kubernetes o Knative.

Despliegue continuo desde Git

Conecte un GitHub, GitLab, o Bitbucket repositorio a Cloud Run a través Desencadenantes de Cloud Build. Cada envío a una rama específica crea automáticamente su contenedor e implementa una nueva revisión. Lo configuras una vez y lo olvidas..

Puedes configurar esto desde la interfaz de usuario de la consola de Cloud Run en "Configurar la implementación continua,”o manualmente creando activadores de Cloud Build. De cualquier manera, el resultado es el mismo: empujar a principal, espera un par de minutos, y tus cambios están en vivo. Debajo del capó, utiliza la misma canalización de paquete de compilación que –implementaciones de origen: tu código se detecta automáticamente, construido en una imagen, empujado al Registro de artefactos, y desplegado como una nueva revisión.

La diferencia entre esta y las siguientes dos opciones. (Acciones de GitHub y compilación en la nube) es simplicidad. La implementación continua desde Git es un proceso prediseñado. No escribe pasos de compilación ni archivos de flujo de trabajo. La compensación es la flexibilidad: no puedes ejecutar pruebas antes de implementar, no se puede implementar primero en la etapa de preparación, y no puede personalizar la compilación más allá de lo que proporciona la detección automática de Cloud Build. Si necesitas alguna de esas cosas, sigue leyendo.

Lo mejor para: Equipos que desean una implementación automatizada en cada impulso sin crear ni mantener CI/CD personalizado.

Construcción de nube

Construcción de nube es la plataforma CI/CD sin servidor de Google Cloud. Donde la opción anterior le brinda una tubería prediseñada, Cloud Build te ofrece los elementos básicos para montar el tuyo propio.

Usted define su canalización en un archivo cloudbuild.yaml en la raíz de su repositorio.:

pasos:
  - nombre: 'gcr.io/cloud-builders/docker'
    argumentos: ['build', '-t', 'us-docker.pkg.dev/$PROJECT_ID/repo/my-image:$COMMIT_SHA', '.']
  - nombre: 'gcr.io/cloud-builders/docker'
    argumentos: ['push', 'us-docker.pkg.dev/$PROJECT_ID/repo/my-image:$COMMIT_SHA']
  - nombre: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    punto de entrada: nube de gcloud
    argumentos: ['run', 'deploy', 'my-service',
           '--image', 'us-docker.pkg.dev/$PROJECT_ID/repo/my-image:$COMMIT_SHA',
           '--region', 'us-central1']

Cada paso se ejecuta en su propio contenedor.. El primer paso crea la imagen de Docker., etiquetándolo con el SHA de confirmación para su trazabilidad. El segundo lo lleva al Registro de artefactos.. El tercero lo implementa en Cloud Run.. Puedes encadenar tantos pasos como necesites: ejecutar pruebas, código de pelusa, escanear en busca de vulnerabilidades, implementar en la puesta en escena, ejecutar pruebas de integración contra la puesta en escena, luego implementar en producción. Los $PROJECT_ID y $COMMIT_SHA son variables de sustitución incorporadas que Cloud Build se completa automáticamente.

Activar este canal en cada empujón a una rama, en solicitudes de extracción, o bajo demanda con envío de compilaciones de gcloud. Esa flexibilidad es el punto: Cloud Build es el camino a seguir, y tu decides lo que contiene.

Lo mejor para: Tuberías de construcción complejas, implementaciones multiservicio, equipos que necesitan flujos de trabajo de prueba antes de la implementación, y los equipos ya han invertido en el ecosistema CI/CD de Google Cloud.

Acciones de GitHub

Si su código se encuentra en GitHub y su CI/CD ya se ejecuta en Acciones de GitHub, Google proporciona una acción oficial para la implementación en Cloud Run:

- usos: acciones-github-google/auth@v2
  con:
    proveedor_identidad_carga_de_trabajo: 'projects/123/locations/global/workloadIdentityPools/my-pool/providers/my-provider'
    cuenta_servicio: '[email protected]'

- usos: google-github-actions/deploy-cloudrun@v2
  con:
    servicio: mi-servicio
    imagen: us-docker.pkg.dev/my-project/repo/my-image:${{ github.sha }}
    región: us-central1

La autenticación se maneja a través de Federación de identidades de cargas de trabajo, que permite a GitHub Actions autenticarse en Google Cloud sin claves de cuenta de servicio. En lugar de almacenar un archivo de clave JSON como un secreto de GitHub (un secreto que nunca caduca y se puede copiar en cualquier lugar), Workload Identity Federation utiliza tokens de corta duración otorgados a través de una asignación de identidad. No hay llaves para guardar, no hay llaves para rotar, No hay claves que se filtren accidentalmente en un registro..

El google-github-acciones/deploy-cloudrun La acción admite implementaciones basadas en imágenes y en fuentes., y la URL del servicio resultante está disponible como salida del flujo de trabajo para los pasos posteriores. (útil para publicar enlaces de vista previa en solicitudes de extracción).

Lo mejor para: Equipos con flujos de trabajo centrados en GitHub que desean integrar la implementación en su CI/CD existente.

Elegir el método de implementación adecuado

Aquí hay una referencia rápida de los métodos que cubrimos.:

MétodoVelocidad de implementaciónControl de construcciónRepetibleMejor escenarioDesde el origenMedioBajoSí (CLI)Creación de prototipos, iteraciones rápidasImagen prediseñadaRápidoAltoSí (CI/CD)Producción, compilaciones personalizadasFunciones de ejecución en la nubeMedioBajoSí (CLI)Puntos finales de propósito únicoConsola UIManualMedioSinExploración, CLI de aprendizaje en la nube (lleno)RápidoAltoSí (guiones)Implementaciones con script, CI/CDDeclarativo YAMLFápidoAltoSí (GitOps)Infraestructura como código Git Implementación continua Media Baja Sí (auto)Implementación automática simple en pushCloud BuildMediumHighSí (tubería)Canalizaciones complejas de CI/CDAcciones de GitHubMediaAltaSí (tubería)Equipos centrados en GitHub

En la práctica, la mayoría de los equipos siguen una progresión natural. empiezas con implementación de fuente para la creación de prototipos: un comando, retroalimentación instantánea. A medida que el proyecto madura, te mudas a imágenes prediseñadas para reproducibilidad y control. Cuando el equipo crece, tu agregas CI/CD (Construcción de nube, Acciones de GitHub, o implementación continua desde Git) para que las implementaciones se realicen de forma automática y consistente.

No es necesario elegir uno y seguir con él.. Utilice la implementación de origen para su entorno de desarrollo y las implementaciones basadas en imágenes para producción. Utilice la consola para explorar, luego codifica lo que aprendiste en YAML. El método de implementación es una herramienta., no es un compromiso.

Estas no son las únicas opciones. Cloud Run también admite la implementación a través de Terraformar, Implementación en la nube para canales de entrega continua gestionados, Código de nube para integración IDE, bibliotecas cliente, y la API REST directamente. El Documentación de implementación de Cloud Run cubre la lista completa.

Revisiones y Gestión del Tráfico

Cada vez que implementas en Cloud Run, crea un nuevo revisión: una instantánea inmutable de la configuración de su servicio y la imagen del contenedor. Piense en las revisiones como el control de versiones integrado de Cloud Run.. Su servicio puede acumular docenas de revisiones a lo largo de su vida, cada uno representa una implementación específica. Las revisiones anteriores se mantienen y pueden volver a atender el tráfico en cualquier momento.. No se elimina nada a menos que lo elimines explícitamente.

Por defecto, Cloud Run genera automáticamente nombres de revisión como my-service-00001-abecedario. eso funciona, but it's not helpful when you're staring at a list of revisions trying to figure out which one introduced a bug. Puede establecer nombres significativos con el –bandera de sufijo de revisión:

gcloud ejecutar implementar mi servicio \
  --imagen us-docker.pkg.dev/my-project/repo/my-image:v1.2.3 \
  --sufijo de revisión v1-2-3 \
  --región us-central1

Ahora la revisión se llama my-service-v1-2-3.. En un proceso de CI/CD, puedes usar Git commit SHA: –sufijo-revisión=$(git rev-parse –CABEZA CORTA). Cuando algo sale mal, puedes saber inmediatamente qué confirmación se está ejecutando.

División del tráfico

Pero el verdadero poder de las revisiones es división del tráfico. Porque las revisiones son inmutables y permanecen, puedes dividir el tráfico entre ellos:

Servicios de ejecución de gcloud tráfico de actualización mi servicio \
  --a-revisiones mi-servicio-v1-2-3=95,mi-servicio-v1-3-0=5 \
  --región us-central1

esto envía 95% del tráfico a la antigua revisión y 5% al nuevo. Mira las métricas en Monitoreo de la nube. Si la tasa de error y la latencia de la nueva revisión se ven bien, desplazar más tráfico. si algo esta mal, un comando te devuelve:

Servicios de ejecución de gcloud tráfico de actualización mi servicio \
  --a-revisiones mi-servicio-v1-2-3=100 \
  --región us-central1

Reversión instantánea. Sin redistribución, sin reconstrucción, sin tiempo de inactividad. La antigua revisión todavía está ahí., ya corriendo, listo para tomar 100% de tráfico otra vez. Este es el verdadero poder de las revisiones inmutables..

Si bien la CLI funciona bien para implementaciones con script, La división del tráfico es una de esas cosas que a menudo es más fácil de hacer desde la Consola de ejecución en la nube. Puedes ver todas tus revisiones., arrastre los controles deslizantes para ajustar los porcentajes, y observa cómo los cambios surten efecto.

También puede utilizar la división del tráfico para:

Pruebas A/B en diferentes versiones de su servicio
Implementaciones graduales donde cambias el tráfico de forma incremental (5% → 25% → 50% → 100%)
Implementaciones azul/verde implementando la nueva revisión con 0% tráfico, probándolo a través de una etiqueta de revisión (vea abajo), luego cambiar el tráfico de una vez

Etiquetas de revisión

Etiquetas de revisión Dar a las revisiones individuales sus propias URL estables sin dirigirles ningún tráfico de producción.:

Servicios de ejecución de gcloud tráfico de actualización mi servicio \
  --set-tags staging=mi-servicio-v1-3-0 \
  --región us-central1

Esto crea una URL como https://puesta en escena—my-service-abc123-uc.a.run.app que apunta directamente a esa revisión. Su equipo de control de calidad puede probar la nueva versión en esa URL mientras el tráfico de producción continúa llegando a la revisión actual sin cambios.. When you're satisfied, cambiar el tráfico. No se necesita un entorno de preparación separado.

Puedes tener varias etiquetas activas a la vez: puesta en escena, canario, pr-42. Cada uno tiene su propia URL. Esto es particularmente útil en canalizaciones de CI/CD donde desea ejecutar pruebas automatizadas en una revisión implementada antes de dirigir a usuarios reales a ella..

Conclusión

Cloud Run le ofrece muchas formas de implementación, cada uno diseñado para una etapa diferente de su proyecto. No es necesario utilizarlos todos..

El patrón que veo con más frecuencia: los equipos comienzan con la implementación de ejecución de gcloud –fuente . y la configuración por defecto. Eso los pone en funcionamiento en minutos. A medida que el proyecto madura, se mueven a imágenes prediseñadas para mayor reproducibilidad, agregue CI/CD para la automatización, y utilice revisiones y división del tráfico para implementaciones seguras. Cada cambio entra en vigor en la siguiente implementación., sin tiempo de inactividad.

Parte 3 viene pronto. Profundizaremos en las opciones de configuración que le permiten ajustar Cloud Run para su carga de trabajo específica.: UPC, memoria, escalada, redes, misterios, y seguridad. Sigue para no perdértelo.

Recursos

Esto es Cloud Run: Nueve formas de implementar (y cuándo usar cada uno) se publicó originalmente en Google Developer Experts en Medium, donde las personas continúan la conversación resaltando y respondiendo a esta historia.