Desplegar imágenes de contenedor en Cloud Run

En esta página se describe cómo desplegar imágenes de contenedor en un nuevo servicio de Cloud Run o en una nueva revisión de un servicio de Cloud Run.

Cloud Run importa la imagen de contenedor cuando se despliega. Cloud Run conserva esta copia de la imagen de contenedor mientras la utilice una revisión de servicio. Las imágenes de contenedor no se extraen de su repositorio de contenedores cuando se inicia una nueva instancia de Cloud Run.

Para ver un ejemplo de cómo desplegar un nuevo servicio, consulta la guía de inicio rápido para desplegar un contenedor de ejemplo.

Antes de empezar

Si tu proyecto está sujeto a una política de organización de restricción de dominio que restringe las invocaciones no autenticadas, tendrás que acceder al servicio desplegado tal como se describe en la sección Probar servicios privados.

Roles obligatorios

Para obtener los permisos que necesitas para desplegar servicios de Cloud Run, pide a tu administrador que te conceda los siguientes roles de gestión de identidades y accesos:

Para ver una lista de los roles y permisos de gestión de identidades y accesos asociados a Cloud Run, consulta los artículos sobre roles de gestión de identidades y accesos de Cloud Run y permisos de gestión de identidades y accesos de Cloud Run. Si tu servicio de Cloud Run interactúa con APIs, como las bibliotecas de cliente de Cloud, consulta la guía de configuración de la identidad del servicio.Google Cloud Para obtener más información sobre cómo conceder roles, consulta los artículos sobre permisos de implementación y gestión del acceso.

Registros e imágenes de contenedores admitidos

Puedes usar directamente imágenes de contenedor almacenadas en Artifact Registry o Docker Hub. Google recomienda usar Artifact Registry. Las imágenes de Docker Hub se almacenan en caché durante un máximo de una hora.

Puedes usar imágenes de contenedor de otros registros públicos o privados (como JFrog Artifactory, Nexus o GitHub Container Registry) configurando un repositorio remoto de Artifact Registry.

Solo deberías usar Docker Hub para desplegar imágenes de contenedor populares, como las imágenes oficiales de Docker o las imágenes de OSS patrocinadas por Docker. Para aumentar la disponibilidad, Google recomienda implementar estas imágenes de Docker Hub mediante un repositorio remoto de Artifact Registry.

Cloud Run no admite capas de imágenes de contenedor de más de 9,9 GB al implementar desde Docker Hub o un repositorio remoto de Artifact Registry con un registro externo.

Desplegar un nuevo servicio

Puedes especificar una imagen de contenedor con una etiqueta (por ejemplo, us-docker.pkg.dev/my-project/container/my-image:latest) o con un digest exacto (por ejemplo, us-docker.pkg.dev/my-project/container/my-image@sha256:41f34ab970ee...).

Al implementar un servicio por primera vez, se crea su primera revisión. Ten en cuenta que las revisiones son inmutables. Si despliega desde una etiqueta de imagen de contenedor, se resolverá en un digest y la revisión siempre usará ese digest concreto.

Haga clic en la pestaña para ver las instrucciones sobre cómo usar la herramienta que prefiera.

Consola

Para desplegar una imagen de contenedor, sigue estos pasos:

  1. En la Google Cloud consola, ve a la página Cloud Run:

    Ir a Cloud Run

  2. Selecciona Servicios en el menú y haz clic en Implementar contenedor para que se muestre el formulario Crear servicio.

    1. En el formulario, selecciona la opción de implementación:

      1. Si quieres desplegar un contenedor manualmente, selecciona Desplegar una revisión desde una imagen de contenedor que ya existe y especifica la imagen del contenedor.

      2. Si quieres automatizar el despliegue continuo, selecciona Desplegar continuamente nuevas revisiones desde el repositorio de origen y sigue las instrucciones para los despliegues continuos.

    2. Introduce el nombre del servicio necesario. Los nombres de los servicios deben tener 49 caracteres o menos y ser únicos por región y proyecto. El nombre del servicio no se puede cambiar más adelante y es público.

    3. Selecciona la región en la que quieras que se encuentre tu servicio. El selector de regiones indica el nivel de precios, la disponibilidad de asignaciones de dominio y destaca las regiones con el menor impacto de carbono.

    4. Configura la facturación según sea necesario.

    5. En Escalado de servicio, si usas el autoescalado predeterminado de Cloud Run, puedes especificar las instancias mínimas. Si usas el escalado manual, especifica el número de instancias del servicio.

    6. Define los ajustes de Ingress en el formulario según sea necesario.

    7. En Autenticación, configura lo siguiente:

      • Si vas a crear una API o un sitio web públicos, selecciona Permitir acceso público. Al seleccionar esta opción, se asigna el rol de invocador de gestión de identidades y accesos al identificador especial allUser. Puedes usar la gestión de identidades y accesos para editar esta opción más adelante, después de crear el servicio.
      • Si quieres que el servicio esté protegido por autenticación, selecciona Requerir autenticación.

  3. Haga clic en Contenedores, Volúmenes, Redes y Seguridad para definir otros ajustes opcionales en las pestañas correspondientes:

  4. Cuando hayas terminado de configurar el servicio, haz clic en Crear para desplegar la imagen en Cloud Run y espera a que se complete el despliegue.

  5. Haz clic en el enlace de la URL que se muestra para abrir el endpoint único y estable de tu servicio implementado.

gcloud

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. Para desplegar una imagen de contenedor, sigue estos pasos:

    1. Ejecuta el siguiente comando: 

      gcloud run deploy SERVICE --image IMAGE_URL

      Haz los cambios siguientes:

      • SERVICE: el nombre del servicio en el que quieras implementar la aplicación. Los nombres de los servicios deben tener 49 caracteres o menos y ser únicos por región y proyecto. Si el servicio aún no existe, este comando lo crea durante la implementación. Puedes omitir este parámetro por completo, pero se te pedirá el nombre del servicio si lo haces.
      • IMAGE_URL: una referencia a la imagen del contenedor, por ejemplo, us-docker.pkg.dev/cloudrun/container/hello:latest. Si usas Artifact Registry, el repositorio REPO_NAME ya debe estar creado. La URL sigue el formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG . Ten en cuenta que, si no proporcionas la marca --image , el comando de implementación intentará implementar desde el código fuente.

      Si vas a crear una API o un sitio web públicos, permite el acceso público a tu servicio mediante la marca --allow-unauthenticated. De esta forma, se asigna el rol de gestión de identidades y accesos Invocador de Cloud Run a allUsers. También puedes especificar --no-allow-unauthenticated para denegar el acceso público. Si omites alguna de estas marcas, se te pedirá que confirmes cuando se ejecute el comando deploy.

    2. Espera a que finalice la implementación. Si se completa correctamente, se mostrará un mensaje de confirmación junto con la URL del servicio implementado.

    Ten en cuenta que, para desplegar en una ubicación diferente a la que hayas definido con las propiedades run/region gcloud, debes usar lo siguiente:

    gcloud run deploy SERVICE --region REGION

    3. YAML

    Puedes almacenar la especificación de tu servicio en un archivo YAML y, a continuación, implementarlo con la CLI de gcloud.

    1. Crea un archivo service.yaml con el siguiente contenido:

      apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    spec:
      containers:
      - image: IMAGE

      Haz los cambios siguientes:

      • SERVICE: el nombre de tu servicio de Cloud Run. Los nombres de los servicios deben tener 49 caracteres o menos y ser únicos por región y proyecto.
      • IMAGE: la URL de la imagen del contenedor.

      También puede especificar más configuraciones, como variables de entorno o límites de memoria.

    2. Implementa el nuevo servicio con el siguiente comando:

      gcloud run services replace service.yaml

    3. Si quieres permitir el acceso al servicio sin autenticación, puedes hacerlo público.

    Cloud Code

    Para desplegar con Cloud Code, consulta las guías de IntelliJ y Visual Studio Code.

    Terraform

    Para saber cómo aplicar o quitar una configuración de Terraform, consulta Comandos básicos de Terraform.

    Añade lo siguiente a un recurso google_cloud_run_v2_service en tu configuración de Terraform:
      provider "google" {
    project = "PROJECT-ID"
  }

  resource "google_cloud_run_v2_service" "default" {
    name     = "SERVICE"
    location = "REGION"
    client   = "terraform"

    template {
      containers {
        image = "IMAGE_URL"
      }
    }
  }

  resource "google_cloud_run_v2_service_iam_member" "noauth" {
    location = google_cloud_run_v2_service.default.location
    name     = google_cloud_run_v2_service.default.name
    role     = "roles/run.invoker"
    member   = "allUsers"
  }

    Haz los cambios siguientes:

    • PROJECT-ID: el ID del proyecto Google Cloud
    • REGION: la Google Cloud región
    • SERVICE: el nombre de tu servicio de Cloud Run. Los nombres de los servicios deben tener 49 caracteres como máximo y ser únicos por región y proyecto.
    • IMAGE_URL: una referencia a la imagen del contenedor, por ejemplo, us-docker.pkg.dev/cloudrun/container/hello:latest. Si usas Artifact Registry, el repositorio REPO_NAME ya debe estar creado. La URL sigue el formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG

    Esta configuración permite el acceso público (el equivalente a --allow-unauthenticated). Para que el servicio sea privado, elimina la estrofa google_cloud_run_v2_service_iam_member.

    Bibliotecas de cliente

    Para implementar un nuevo servicio a partir de código, sigue estos pasos:

    API REST

    Para desplegar un nuevo servicio, envía una solicitud HTTP POST al endpoint service de la API Cloud Run Admin.

    Por ejemplo, si usas curl:

    curl -H "Content-Type: application/json" \
  -H "Authorization: Bearer ACCESS_TOKEN" \
  -X POST \
  -d '{template: {containers: [{image: "IMAGE_URL"}]}}' \
  https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services?serviceId=SERVICE

    Haz los cambios siguientes:

    • ACCESS_TOKEN: un token de acceso válido para una cuenta que tenga los permisos de gestión de identidades y accesos para implementar servicios. Por ejemplo, si has iniciado sesión en gcloud, puedes obtener un token de acceso con gcloud auth print-access-token. Desde una instancia de contenedor de Cloud Run, puedes obtener un token de acceso mediante el servidor de metadatos de la instancia de contenedor.
    • IMAGE_URL: una referencia a la imagen del contenedor, por ejemplo, us-docker.pkg.dev/cloudrun/container/hello:latest. Si usas Artifact Registry, el repositorio REPO_NAME ya debe estar creado. La URL sigue el formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG .
    • SERVICE: el nombre del servicio en el que quieres implementar. Los nombres de servicio deben tener 49 caracteres como máximo y ser únicos por región y proyecto.
    • REGION: la Google Cloud región del servicio.
    • PROJECT-ID: el ID del proyecto. Google Cloud

Ubicaciones de Cloud Run

Cloud Run es regional, lo que significa que la infraestructura que ejecuta tus servicios de Cloud Run se encuentra en una región específica y Google la gestiona para que esté disponible de forma redundante en todas las zonas de esa región.

Cumplir tus requisitos de latencia, disponibilidad o durabilidad son factores primordiales para seleccionar la región en la que se ejecutan tus servicios de Cloud Run. Por lo general, puedes seleccionar la región más cercana a tus usuarios, pero debes tener en cuenta la ubicación de los otros Google Cloudproductos que utiliza tu servicio de Cloud Run. Usar Google Cloud productos juntos en varias ubicaciones puede afectar a la latencia y al coste de tu servicio.

Cloud Run está disponible en las siguientes regiones:

Con sujeción a los precios del nivel 1

  • asia-east1 (Taiwán)
  • asia-northeast1 (Tokio)
  • asia-northeast2 (Osaka)
  • asia-south1 (Bombay, la India)
  • europe-north1 (Finlandia) icono de una hoja CO2 bajo
  • europe-north2 (Estocolmo) icono de una hoja CO2 bajo
  • europe-southwest1 (Madrid) icono de una hoja CO2 bajo
  • europe-west1 (Bélgica) icono de una hoja CO2 bajo
  • europe-west4 (Países Bajos) icono de una hoja CO2 bajo
  • europe-west8 (Milán)
  • europe-west9 (París) icono de una hoja CO2 bajo
  • me-west1 (Tel Aviv)
  • northamerica-south1 (México)
  • us-central1 (Iowa) icono de una hoja CO2 bajo
  • us-east1 (Carolina del Sur)
  • us-east4 (Norte de Virginia)
  • us-east5 (Columbus)
  • us-south1 (Dallas) icono de una hoja CO2 bajo
  • us-west1 (Oregón) icono de una hoja CO2 bajo

Con sujeción a los precios del nivel 2

  • africa-south1 (Johannesburgo)
  • asia-east2 (Hong Kong)
  • asia-northeast3 (Seúl, Corea del Sur)
  • asia-southeast1 (Singapur)
  • asia-southeast2 (Yakarta)
  • asia-south2 (Delhi, la India)
  • australia-southeast1 (Sídney)
  • australia-southeast2 (Melbourne)
  • europe-central2 Varsovia (Polonia)
  • europe-west10 (Berlín) icono de una hoja CO2 bajo
  • europe-west12 (Turín)
  • europe-west2 (Londres, Reino Unido) icono de una hoja CO2 bajo
  • europe-west3 (Fráncfort, Alemania)
  • europe-west6 (Zúrich, Suiza) icono de una hoja CO2 bajo
  • me-central1 (Doha)
  • me-central2 (Dammam)
  • northamerica-northeast1 (Montreal) icono de una hoja CO2 bajo
  • northamerica-northeast2 (Toronto) icono de una hoja CO2 bajo
  • southamerica-east1 (São Paulo, Brasil) icono de una hoja CO2 bajo
  • southamerica-west1 (Santiago, Chile) icono de una hoja CO2 bajo
  • us-west2 (Los Ángeles)
  • us-west3 (Salt Lake City)
  • us-west4 (Las Vegas)

Si ya has creado un servicio de Cloud Run, puedes ver la región en el panel de control de Cloud Run de la Google Cloud consola.

Desplegar una nueva revisión de un servicio

Puedes desplegar una revisión nueva con la consola Google Cloud , la línea de comandos gcloud o un archivo de configuración YAML.

Ten en cuenta que, si cambias cualquier ajuste de configuración, se creará una revisión nueva, aunque no se modifique la imagen del contenedor. Cada revisión creada es inmutable.

Cloud Run importa la imagen de contenedor cuando se despliega. Cloud Run conserva esta copia de la imagen de contenedor mientras la utilice una revisión de servicio.

Haga clic en la pestaña para ver las instrucciones sobre cómo usar la herramienta que prefiera.

Consola

Para desplegar una nueva revisión de un servicio, sigue estos pasos:

  1. En la Google Cloud consola, ve a la página Cloud Run:

    Ir a Cloud Run

  2. Busca el servicio que quieras actualizar en la lista de servicios y haz clic en él para abrir sus detalles.

  3. Haz clic en Editar y desplegar nueva revisión para mostrar el formulario de despliegue de la revisión.

    1. Si es necesario, proporcione la URL de la nueva imagen de contenedor que quiera desplegar.

    2. Configure el contenedor según sea necesario.

    3. Configura la facturación según sea necesario.

    4. En Capacidad, especifica los límites de memoria y los límites de CPU.

    5. Especifica el tiempo de espera de la solicitud y la simultaneidad según sea necesario.

    6. Especifica el entorno de ejecución según sea necesario.

    7. En Auto escalado, especifica el número mínimo y máximo de instancias.

    8. Usa las otras pestañas según sea necesario para configurar opcionalmente lo siguiente:

  4. Para enviar todo el tráfico a la nueva revisión, selecciona Servir esta revisión de inmediato. Para implementar gradualmente una nueva revisión, desmarca esa casilla. De este modo, se realiza una implementación en la que no se envía tráfico a la nueva revisión. Sigue las instrucciones para hacer lanzamientos graduales después de la implementación.

  5. Haz clic en Desplegar y espera a que se complete el despliegue.

gcloud

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. Para desplegar una imagen de contenedor, sigue estos pasos:

    1. Ejecuta el comando: 

      gcloud run deploy SERVICE --image IMAGE_URL

      Haz los cambios siguientes:

      • SERVICE: el nombre del servicio en el que vas a implementar la aplicación. Puedes omitir este parámetro por completo, pero se te pedirá el nombre del servicio si lo haces.
      • IMAGE_URL: una referencia a la imagen del contenedor, por ejemplo, us-docker.pkg.dev/cloudrun/container/hello:latest. Si usas Artifact Registry, el repositorio REPO_NAME ya debe estar creado. La URL sigue el formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG .

      El sufijo de revisión se asigna automáticamente a las revisiones nuevas. Si quieres proporcionar tu propio sufijo de revisión, usa el parámetro --revision-suffix de la interfaz de línea de comandos de gcloud.

    2. Espera a que finalice la implementación. Si se completa correctamente, se mostrará un mensaje de confirmación junto con la URL del servicio implementado.

    3. YAML

    Si necesitas descargar o ver la configuración de un servicio, usa el siguiente comando para guardar los resultados en un archivo YAML:

    gcloud run services describe SERVICE --format export > service.yaml

    En un archivo YAML de configuración de servicio, modifique los spec.template atributos secundarios que necesite para actualizar la configuración de la revisión y, a continuación, implemente la nueva revisión:

    gcloud run services replace service.yaml

    Cloud Code

    Para desplegar una nueva revisión de un servicio con Cloud Code, consulta las guías de IntelliJ y Visual Studio Code.

    Terraform

    Asegúrate de haber configurado Terraform tal como se describe en el ejemplo Implementar un nuevo servicio.

    1. Cambia el archivo de configuración.

    2. Aplica la configuración de Terraform:

      terraform apply

      Para confirmar que quieres aplicar las acciones descritas, escribe yes.

    Bibliotecas de cliente

    Para desplegar una nueva revisión a partir del código, sigue estos pasos:

    API REST

    Para desplegar una revisión, envía una solicitud HTTP PATCH al endpoint service de la API Admin de Cloud Run.

    Por ejemplo, si usas curl:

    curl -H "Content-Type: application/json" \
  -H "Authorization: Bearer ACCESS_TOKEN" \
  -X PATCH \
  -d '{template: {containers: [{image: "IMAGE_URL"}]}}' \
  https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services/SERVICE

    Haz los cambios siguientes:

    • ACCESS_TOKEN: un token de acceso válido para una cuenta que tenga los permisos de gestión de identidades y accesos para implementar revisiones. Por ejemplo, si has iniciado sesión en gcloud, puedes obtener un token de acceso con gcloud auth print-access-token. Desde una instancia de contenedor de Cloud Run, puedes obtener un token de acceso mediante el servidor de metadatos de la instancia de contenedor.
    • IMAGE_URL: una referencia a la imagen del contenedor, por ejemplo, us-docker.pkg.dev/cloudrun/container/hello:latest. Si usas Artifact Registry, el repositorio REPO_NAME ya debe estar creado. La URL sigue el formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG .
    • SERVICE: el nombre del servicio en el que vas a implementar la aplicación.
    • REGION: la Google Cloud región del servicio.
    • PROJECT-ID: el ID del proyecto. Google Cloud

Ubicaciones de Cloud Run

Cloud Run es regional, lo que significa que la infraestructura que ejecuta tus servicios de Cloud Run se encuentra en una región específica y Google la gestiona para que esté disponible de forma redundante en todas las zonas de esa región.

Cumplir tus requisitos de latencia, disponibilidad o durabilidad son factores primordiales para seleccionar la región en la que se ejecutan tus servicios de Cloud Run. Por lo general, puedes seleccionar la región más cercana a tus usuarios, pero debes tener en cuenta la ubicación de los otros Google Cloudproductos que utiliza tu servicio de Cloud Run. Usar Google Cloud productos juntos en varias ubicaciones puede afectar a la latencia y al coste de tu servicio.

Cloud Run está disponible en las siguientes regiones:

Con sujeción a los precios del nivel 1

  • asia-east1 (Taiwán)
  • asia-northeast1 (Tokio)
  • asia-northeast2 (Osaka)
  • asia-south1 (Bombay, la India)
  • europe-north1 (Finlandia) icono de una hoja CO2 bajo
  • europe-north2 (Estocolmo) icono de una hoja CO2 bajo
  • europe-southwest1 (Madrid) icono de una hoja CO2 bajo
  • europe-west1 (Bélgica) icono de una hoja CO2 bajo
  • europe-west4 (Países Bajos) icono de una hoja CO2 bajo
  • europe-west8 (Milán)
  • europe-west9 (París) icono de una hoja CO2 bajo
  • me-west1 (Tel Aviv)
  • northamerica-south1 (México)
  • us-central1 (Iowa) icono de una hoja CO2 bajo
  • us-east1 (Carolina del Sur)
  • us-east4 (Norte de Virginia)
  • us-east5 (Columbus)
  • us-south1 (Dallas) icono de una hoja CO2 bajo
  • us-west1 (Oregón) icono de una hoja CO2 bajo

Con sujeción a los precios del nivel 2

  • africa-south1 (Johannesburgo)
  • asia-east2 (Hong Kong)
  • asia-northeast3 (Seúl, Corea del Sur)
  • asia-southeast1 (Singapur)
  • asia-southeast2 (Yakarta)
  • asia-south2 (Delhi, la India)
  • australia-southeast1 (Sídney)
  • australia-southeast2 (Melbourne)
  • europe-central2 Varsovia (Polonia)
  • europe-west10 (Berlín) icono de una hoja CO2 bajo
  • europe-west12 (Turín)
  • europe-west2 (Londres, Reino Unido) icono de una hoja CO2 bajo
  • europe-west3 (Fráncfort, Alemania)
  • europe-west6 (Zúrich, Suiza) icono de una hoja CO2 bajo
  • me-central1 (Doha)
  • me-central2 (Dammam)
  • northamerica-northeast1 (Montreal) icono de una hoja CO2 bajo
  • northamerica-northeast2 (Toronto) icono de una hoja CO2 bajo
  • southamerica-east1 (São Paulo, Brasil) icono de una hoja CO2 bajo
  • southamerica-west1 (Santiago, Chile) icono de una hoja CO2 bajo
  • us-west2 (Los Ángeles)
  • us-west3 (Salt Lake City)
  • us-west4 (Las Vegas)

Si ya has creado un servicio de Cloud Run, puedes ver la región en el panel de control de Cloud Run de la Google Cloud consola.

Desplegar imágenes de otros proyectos Google Cloud

Para desplegar imágenes de otros Google Cloud proyectos, tú o tu administrador debéis conceder los roles de gestión de identidades y accesos necesarios a la cuenta de implementación y al agente de servicio de Cloud Run.

Para consultar los roles necesarios de la cuenta de implementador, consulta Roles necesarios.

Para conceder los roles necesarios al agente de servicio de Cloud Run, consulta las siguientes instrucciones:

  1. En la Google Cloud consola, abre el proyecto de tu servicio de Cloud Run.

    Ir a la página de gestión de identidades y accesos

  2. Selecciona Incluir concesiones de roles proporcionadas por Google.

  3. Copia el correo del agente de servicio de Cloud Run. Tiene el sufijo @serverless-robot-prod.iam.gserviceaccount.com

  4. Abre el proyecto propietario del registro de contenedores que quieras usar.

    Ir a la página de gestión de identidades y accesos

  5. Haga clic en Añadir para añadir un nuevo principal.

  6. En el campo Nuevos principales, pega el correo de la cuenta de servicio que has copiado anteriormente.

  7. En el menú desplegable Select a role (Seleccionar un rol), haz clic en Artifact Registry -> Artifact Registry Reader (Artifact Registry > Lector de Artifact Registry).

  8. Despliega la imagen de contenedor en el proyecto que contiene tu servicio de Cloud Run.

Desplegar imágenes de otros registros

Para desplegar imágenes de contenedor públicas o privadas que no estén almacenadas en Artifact Registry o Docker Hub, configura un repositorio remoto de Artifact Registry.

Los repositorios remotos de Artifact Registry te permiten hacer lo siguiente:

  • Despliega cualquier imagen de contenedor pública, como GitHub Container Registry (ghcr.io).
  • Despliega imágenes de contenedor de repositorios privados que requieran autenticación, como JFrog Artifactory o Nexus.

Si no puedes usar un repositorio remoto de Artifact Registry, puedes extraer e insertar imágenes de contenedor en Artifact Registry temporalmente con docker push para desplegarlas en Cloud Run. Cloud Run importa la imagen de contenedor cuando se despliega, por lo que, después del despliegue, puedes eliminar la imagen de Artifact Registry.

Implementar varios contenedores en un servicio (sidecars)

En una implementación de Cloud Run con sidecars, hay un contenedor de entrada que gestiona todas las solicitudes HTTPS entrantes en el puerto del contenedor que especifiques, y hay uno o varios contenedores sidecar. Los sidecars no pueden escuchar las solicitudes HTTP entrantes en el puerto del contenedor de entrada, pero sí pueden comunicarse entre sí y con el contenedor de entrada mediante un puerto localhost. El puerto localhost utilizado varía en función de los contenedores que utilices.

En el siguiente diagrama, el contenedor de entrada se comunica con el sidecar mediante localhost:5000.

Multicontenedor de Cloud Run

Puedes implementar hasta 10 contenedores por instancia, incluido el contenedor de entrada. Todos los contenedores de una instancia comparten el mismo espacio de nombres de red y también pueden compartir archivos mediante un volumen compartido en memoria, como se muestra en el diagrama.

Puedes desplegar varios contenedores en el entorno de ejecución de primera o de segunda generación.

Si usas la facturación basada en solicitudes (el valor predeterminado de Cloud Run), se asigna CPU a los sidecars solo en estos casos:

  • La instancia está procesando al menos una solicitud.
  • El contenedor de entrada se está iniciando.

Si tu sidecar debe usar la CPU fuera del procesamiento de solicitudes (por ejemplo, para la recogida de métricas), configura la facturación de tu servicio como facturación basada en instancias. Para obtener más información, consulta Configuración de facturación (servicios).

Si usas la facturación basada en solicitudes, configura una prueba de inicio para asegurarte de que tu sidecar no se limite por la CPU al iniciarse.

Puedes requerir que todas las implementaciones usen un sidecar específico creando políticas de organización personalizadas.

Casos prácticos

Entre los casos prácticos de los sidecars en un servicio de Cloud Run se incluyen los siguientes:

  • Monitorización, registro y trazado de aplicaciones
  • Usar Nginx, Envoy o Apache2 como proxy delante del contenedor de tu aplicación
  • Añadir filtros de autenticación y autorización (por ejemplo, Open Policy Agent)
  • Ejecutar proxies de conexión saliente, como el proxy de autenticación de AlloyDB

Desplegar un servicio con contenedores sidecar

Puedes desplegar varios sidecars en un servicio de Cloud Run mediante laGoogle Cloud consola, la CLI de Google Cloud, YAML o Terraform.

Haga clic en la pestaña para ver las instrucciones sobre cómo usar la herramienta que prefiera.

Consola

  1. En la Google Cloud consola, ve a la página Cloud Run:

    Ir a Cloud Run

    • Para implementar una versión en un servicio, localízalo en la lista de servicios, haz clic en él para abrirlo y, a continuación, haz clic en Editar e implementar una nueva revisión para que se muestre el formulario de implementación de la revisión.
    • Selecciona Servicios en el menú y haz clic en Desplegar contenedor para mostrar el formulario Crear servicio.

  2. Para un servicio nuevo,

    1. Proporciona el nombre del servicio y la URL de la imagen del contenedor de entrada que quieras desplegar.
    2. Haz clic en Contenedores, volúmenes, redes y seguridad.

  3. En la tarjeta Editar contenedor, configure el contenedor de entrada según sea necesario.

  4. Haz clic en Añadir contenedor y configura un contenedor sidecar que quieras añadir junto al contenedor de entrada. Si el sidecar depende de otro contenedor del servicio, indícalo en el menú desplegable Orden de inicio de los contenedores. Repite este paso con cada contenedor sidecar que vayas a implementar.

  5. Para enviar todo el tráfico a la nueva revisión, selecciona Servir esta revisión de inmediato. Para hacer un lanzamiento gradual, desmarque esa casilla. De este modo, se realiza una implementación en la que no se envía tráfico a la nueva revisión. Sigue las instrucciones para hacer lanzamientos graduales después de la implementación.

  6. Haz clic en Crear para crear un servicio o en Desplegar para desplegar un servicio que ya tengas y, a continuación, espera a que se complete el despliegue.

gcloud

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. Para desplegar varios contenedores en un servicio, ejecuta el siguiente comando:

    gcloud run deploy SERVICE \
 --container INGRESS_CONTAINER_NAME \
 --image='INGRESS_IMAGE' \
 --port='CONTAINER_PORT' \
 --container SIDECAR_CONTAINER_NAME \
 --image='SIDECAR_IMAGE'

    Haz los cambios siguientes:

    • SERVICE: el nombre del servicio en el que vas a implementar la aplicación. Puedes omitir este parámetro por completo, pero se te pedirá el nombre del servicio si lo haces.
    • INGRESS_CONTAINER_NAME: el nombre del contenedor que recibe las solicitudes (por ejemplo, app).
    • INGRESS_IMAGE: una referencia a la imagen del contenedor que debe recibir solicitudes (por ejemplo, us-docker.pkg.dev/cloudrun/container/hello:latest).
    • CONTAINER_PORT: el puerto en el que el contenedor de entrada escucha las solicitudes entrantes. A diferencia de un servicio de un solo contenedor, en el caso de un servicio que contiene sidecars, no hay ningún puerto predeterminado para el contenedor de entrada. Debe configurar explícitamente el puerto del contenedor de entrada y solo un contenedor puede tener el puerto expuesto.
    • SIDECAR_CONTAINER_NAME: el nombre del contenedor sidecar, por ejemplo, sidecar.
    • SIDECAR_IMAGE: una referencia a la imagen del contenedor secundario

    Si quiere configurar cada contenedor en el comando de implementación, proporcione la configuración de cada contenedor después de los parámetros container. Por ejemplo:

    gcloud run deploy SERVICE \
  --container CONTAINER_1_NAME \
  --image='INGRESS_IMAGE' \
  --set-env-vars=KEY=VALUE \
  --port='CONTAINER_PORT' \
  --container SIDECAR_CONTAINER_NAME \
  --image='SIDECAR_IMAGE' \
  --set-env-vars=KEY_N=VALUE_N

  3. Espera a que finalice la implementación. Si se completa correctamente, se mostrará un mensaje de éxito junto con la URL del servicio implementado.

    4. YAML

    En estas instrucciones se muestra un archivo YAML básico para tu servicio de Cloud Run con sidecars. Crea un archivo llamado service.yaml y añade lo siguiente:

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  annotations:
  name: SERVICE
spec:
  template:
    spec:
      containers:
      - image: INGRESS_IMAGE
        ports:
          - containerPort: CONTAINER_PORT
      - image: SIDECAR_IMAGE

    Haz los cambios siguientes:

    • SERVICE: el nombre de tu servicio de Cloud Run. Los nombres de los servicios deben tener 49 caracteres como máximo.
    • CONTAINER_PORT: el puerto en el que el contenedor de entrada escucha las solicitudes entrantes. A diferencia de un servicio de un solo contenedor, en el caso de un servicio que contiene sidecars, no hay ningún puerto predeterminado para el contenedor de entrada. Debe configurar explícitamente el puerto del contenedor de entrada y solo un contenedor puede tener el puerto expuesto.
    • INGRESS_IMAGE: una referencia a la imagen del contenedor que debe recibir solicitudes (por ejemplo, us-docker.pkg.dev/cloudrun/container/hello:latest).
    • SIDECAR_IMAGE: una referencia a la imagen del contenedor secundario. Puedes especificar varios sidecars añadiendo más elementos al array containers en el archivo YAML.

    Después de actualizar el archivo YAML para incluir los contenedores de entrada y sidecar, despliega el archivo en Cloud Run con el siguiente comando:

    gcloud run services replace service.yaml

    Terraform

    Para saber cómo aplicar o quitar una configuración de Terraform, consulta Comandos básicos de Terraform.

    Añade lo siguiente a un recurso google_cloud_run_v2_service en tu configuración de Terraform:
    resource "google_cloud_run_v2_service" "default" {
  name     = "SERVICE"
  location = "REGION"
  ingress = "INGRESS_TRAFFIC_ALL"
  template {
    containers {
      name = "INGRESS_CONTAINER_NAME"
      ports {
        container_port = CONTAINER_PORT
      }
      image = "INGRESS_IMAGE"
      depends_on = ["SIDECAR_CONTAINER_NAME"]
    }
    containers {
      name = "SIDECAR_CONTAINER_NAME"
      image = "SIDECAR_IMAGE"
      }
    }
  }

    CONTAINER_PORT representa el puerto en el que el contenedor de entrada escucha las solicitudes entrantes. A diferencia de un servicio de un solo contenedor, en el caso de un servicio que contiene sidecars, no hay ningún puerto predeterminado para el contenedor de entrada. Debe configurar explícitamente el puerto del contenedor de entrada y solo un contenedor puede tener el puerto expuesto.

Funciones destacadas disponibles para las implementaciones con sidecars

Puede especificar el orden de inicio de los contenedores en una implementación con varios contenedores si tiene dependencias que requieren que algunos contenedores se inicien antes que otros en la implementación.

Si tienes contenedores que dependen de otros contenedores, debes usar comprobaciones de estado en tu implementación. Si usas comprobaciones de estado, Cloud Run sigue el orden de inicio de los contenedores e inspecciona el estado de cada uno de ellos. De esta forma, se asegura de que cada contenedor se complete correctamente antes de que Cloud Run inicie el siguiente contenedor en el orden. Si no usas comprobaciones del estado, los contenedores en buen estado se iniciarán aunque los contenedores de los que dependen no estén en ejecución.

Varios contenedores de una misma instancia pueden acceder a un volumen en memoria compartido, al que puede acceder cada contenedor mediante los puntos de montaje que crees.

Siguientes pasos

Después de implementar un nuevo servicio, puedes hacer lo siguiente:

Puedes automatizar las compilaciones y los despliegues de tus servicios de Cloud Run con los activadores de Cloud Build:

También puedes usar Cloud Deploy para configurar un flujo de procesamiento de entrega continua con el que desplegar servicios de Cloud Run en varios entornos: