Esta página se ha traducido con Cloud Translation API.

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 ya creado.

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:

Desarrollador de Cloud Run (roles/run.developer) en el servicio Cloud Run
Usuario de cuenta de servicio (roles/iam.serviceAccountUser) en la identidad de servicio
Lector de Artifact Registry (roles/artifactregistry.reader) en el repositorio de Artifact Registry de la imagen de contenedor implementada
Si utilizas una cuenta de servicio entre proyectos para desplegar un servicio: Creador de tokens de cuenta de servicio (roles/iam.serviceAccountTokenCreator) en la identidad del servicio

Para ver una lista de los roles y permisos de gestión de identidades y accesos asociados a Cloud Run, consulta los artículos 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 permisos de implementación y el artículo sobre cómo gestionar el 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 debes usar Docker Hub para desplegar imágenes de contenedores 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:

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

Ir a Cloud Run
Haga 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 proceso para 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 quieres 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 utilizas 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, configure 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.
Haga clic en Contenedores, Volúmenes, Redes y Seguridad para definir otros ajustes opcionales en las pestañas correspondientes:
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.
Haz clic en el enlace de la URL que se muestra para abrir el endpoint único y estable de tu servicio implementado.

gcloud

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.
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, usa lo siguiente:
```
gcloud run deploy SERVICE --region REGION
```

YAML

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

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 de tu contenedor.
También puedes especificar más opciones de configuración, como variables de entorno o límites de memoria.
Implementa el nuevo servicio con el siguiente comando:
```
gcloud run services replace service.yaml
```
Si quieres permitir el acceso al servicio sin autenticación, puedes hacerlo público.

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 servicio 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.

Redactar

Puedes almacenar tu especificación de Compose en un archivo YAML y, a continuación, desplegarlo como un servicio de Cloud Run con un solo comando de gcloud.

Para desplegar un archivo compose.yaml como servicio de Cloud Run, sigue estos pasos:

En el directorio de tu proyecto, crea un archivo compose.yaml con tus definiciones de servicio.
```
services:
  web:
    image: IMAGE
    ports:
      - "8080:8080"
```
Sustituye IMAGE por la URL de tu imagen de contenedor.

También puedes especificar más opciones de configuración, como variables de entorno, secretos y montajes de volúmenes.
Para desplegar los servicios, ejecuta el comando gcloud beta run compose up:
```
gcloud beta run compose up compose.yaml
```
Responde y a las peticiones para instalar los componentes necesarios o habilitar las APIs.
Opcional: Haz público tu servicio si quieres permitir el acceso sin autenticación al servicio.

Después de la implementación, se muestra la URL del servicio de Cloud Run. Copia esta URL y pégala en el navegador para ver el contenedor en ejecución. Puedes inhabilitar la autenticación predeterminada desde la consola Google Cloud .

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 Admin de Cloud Run.

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 los servicios 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 los requisitos de latencia, disponibilidad o durabilidad es el factor principal a la hora de 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) CO₂ bajo
europe-north2 (Estocolmo) CO₂ bajo
europe-southwest1 (Madrid) CO₂ bajo
europe-west1 (Bélgica) CO₂ bajo
europe-west4 (Países Bajos) CO₂ bajo
europe-west8 (Milán)
europe-west9 (París) CO₂ bajo
me-west1 (Tel Aviv)
northamerica-south1 (México)
us-central1 (Iowa) CO₂ bajo
us-east1 (Carolina del Sur)
us-east4 (Norte de Virginia)
us-east5 (Columbus)
us-south1 (Dallas) CO₂ bajo
us-west1 (Oregón) CO₂ 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)
europe-west12 (Turín)
europe-west2 (Londres, Reino Unido) CO₂ bajo
europe-west3 (Fráncfort, Alemania)
europe-west6 (Zúrich, Suiza) Bajas emisiones de CO₂
me-central1 (Doha)
me-central2 (Dammam)
northamerica-northeast1 (Montreal) CO₂ bajo
northamerica-northeast2 (Toronto) CO₂ bajo
southamerica-east1 (São Paulo, Brasil) CO₂ bajo
southamerica-west1 (Santiago, Chile) CO₂ 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 nueva revisión mediante 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:

En la Google Cloud consola, ve a la página Servicios de Cloud Run:

Ir a Cloud Run
Busca el servicio que quieras actualizar en la lista de servicios y haz clic en él para abrir sus detalles.
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:
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.
Haz clic en Desplegar y espera a que se complete el despliegue.

gcloud

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.
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.

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.

Cambia el archivo de configuración.
Aplica la configuración de Terraform:
```
terraform apply
```
Para confirmar que quieres aplicar las acciones descritas, escribe yes.

Nota: A menos que sea necesario cambiar la configuración, no se creará ninguna revisión nueva.

Redactar

Puedes almacenar tu especificación de Compose en un archivo YAML y, a continuación, desplegarlo como una revisión de servicio de Cloud Run con un solo comando de gcloud.

Para desplegar un archivo compose.yaml como revisión de un servicio de Cloud Run, sigue estos pasos:

En el directorio de tu proyecto, crea un archivo compose.yaml con tus definiciones de servicio.
```
services:
  web:
    image: IMAGE
    ports:
      - "8080:8080"
```
Sustituye IMAGE por la URL de tu imagen de contenedor.

También puedes especificar más opciones de configuración, como variables de entorno, secretos y montajes de volúmenes.
Para desplegar los servicios, ejecuta el comando gcloud beta run compose up:
```
gcloud beta run compose up compose.yaml
```
Responde y a las peticiones para instalar los componentes necesarios o habilitar las APIs.
Opcional: Haz público tu servicio si quieres permitir el acceso sin autenticación al servicio.

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 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) CO₂ bajo
europe-north2 (Estocolmo) CO₂ bajo
europe-southwest1 (Madrid) CO₂ bajo
europe-west1 (Bélgica) CO₂ bajo
europe-west4 (Países Bajos) CO₂ bajo
europe-west8 (Milán)
europe-west9 (París) CO₂ bajo
me-west1 (Tel Aviv)
northamerica-south1 (México)
us-central1 (Iowa) CO₂ bajo
us-east1 (Carolina del Sur)
us-east4 (Norte de Virginia)
us-east5 (Columbus)
us-south1 (Dallas) CO₂ bajo
us-west1 (Oregón) CO₂ 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)
europe-west12 (Turín)
europe-west2 (Londres, Reino Unido) CO₂ bajo
europe-west3 (Fráncfort, Alemania)
europe-west6 (Zúrich, Suiza) Bajas emisiones de CO₂
me-central1 (Doha)
me-central2 (Dammam)
northamerica-northeast1 (Montreal) CO₂ bajo
northamerica-northeast2 (Toronto) CO₂ bajo
southamerica-east1 (São Paulo, Brasil) CO₂ bajo
southamerica-west1 (Santiago, Chile) CO₂ 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.

Implementar imágenes de otros Google Cloud proyectos

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 ver los roles necesarios de la cuenta de implementación, consulta los roles necesarios.

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

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
Selecciona Incluir concesiones de roles proporcionadas por Google.
Copia el correo del agente de servicio de Cloud Run. Tiene el sufijo @serverless-robot-prod.iam.gserviceaccount.com.
Abre el proyecto propietario del registro de contenedores que quieras usar.

Ir a la página de gestión de identidades y accesos
Haga clic en Añadir para añadir un nuevo principal.
En el campo Nuevos principales, pega el correo de la cuenta de servicio que has copiado anteriormente.
En el menú Seleccionar un rol, haz clic en Artifact Registry > Lector de Artifact Registry.
Despliega la imagen de contenedor en el proyecto que contiene tu servicio de Cloud Run.

Nota: Para aumentar la seguridad, concede acceso al repositorio de Artifact Registry que contiene tus imágenes de contenedor.

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 le 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 desplegar 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 (la opción predeterminada 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 exigir que todas las implementaciones usen un sidecar específico creando políticas de organización personalizadas.

Casos prácticos

Estos son algunos de los casos prácticos de los sidecars en un servicio de Cloud Run:

Monitorización, registro y seguimiento 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

En la Google Cloud consola, ve a la página Servicios de 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.
- Para implementar un nuevo servicio, haz clic en Implementar contenedor para mostrar el formulario Crear servicio.
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.
En la tarjeta Editar contenedor, configure el contenedor de entrada según sea necesario.
Haga clic en Añadir contenedor y configure un contenedor sidecar que quiera añadir junto al contenedor de entrada. Si el sidecar depende de otro contenedor del servicio, indícalo en el menú Orden de inicio de los contenedores. Repite este paso con cada contenedor sidecar que vayas a implementar.
Para enviar todo el tráfico a la nueva revisión, selecciona Servir esta revisión de inmediato. Para hacer un lanzamiento gradual, 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.
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

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.
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. Debes configurar explícitamente el puerto del contenedor de entrada y solo un contenedor puede tener el puerto expuesto.
- SIDECAR_CONTAINER_NAME: un nombre para el 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
```
Importante: Cuando usas la marca --container, debes especificar todas las marcas que no sean de nivel de contenedor antes de las marcas de nivel de contenedor. De lo contrario, el comando de implementación fallará y se mostrará un mensaje de error. Por ejemplo, en el comando "gcloud run services deploy service --execution-environment=gen2 --container app --memory=1G", la marca --execution-environment debe incluirse antes de la marca --container.
Espera a que finalice la implementación. Si se completa correctamente, se mostrará un mensaje de éxito junto con la URL del servicio implementado.

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. Debes 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, despliégalo 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. Debes 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

Orden de inicio

Puede especificar el orden de inicio de los contenedores en una implementación con varios contenedores si tiene dependencias que requieran 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 todos se completen correctamente antes de iniciar 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.

Intercambiar datos de archivos entre sidecars

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. Se suele usar para compartir archivos entre contenedores. Por ejemplo, un contenedor auxiliar de telemetría puede recoger registros de un contenedor de aplicaciones.

Comunicación entre sidecars

Dos contenedores de la misma instancia pueden comunicarse entre sí en la red local.

Considera este servicio de ejemplo:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example
spec:
  template:
    spec:
      containers:
      - name: ingress
        image: ...
        ports:
          - containerPort: 8080
      - name: sidecar
        image: ...

Cada instancia de este servicio ejecutará dos contenedores: uno llamado ingress y otro llamado sidecar.

Las solicitudes que llegan al servicio se envían al contenedor ingress en el puerto 8080. En un servicio con varios contenedores, solo se puede configurar un contenedor como contenedor de entrada que gestione todas las solicitudes entrantes. Este debe ser el contenedor para el que se haya configurado un containerPort.

Los contenedores ingress y sidecar pueden comunicarse entre sí en http://localhost. Por ejemplo, si el contenedor sidecar escucha las solicitudes en el puerto 5000, el contenedor ingress puede comunicarse con él en http://localhost:5000.

Como los contenedores tienen nombre, pueden comunicarse entre sí usando el nombre del contenedor. Por ejemplo, si el contenedor sidecar escucha las solicitudes en el puerto 5000, el contenedor ingress puede comunicarse con sidecar mediante http://sidecar:5000.

Adaptar los contenedores para Cloud Run

La mayoría de los contenedores que crees o encuentres serán compatibles con el contrato de tiempo de ejecución de contenedores de Cloud Run. Sin embargo, es posible que tengas que modificar algunos contenedores creados para facilitar el desarrollo local o que esperen tener el control total de la máquina para que sean compatibles con los entornos de ejecución de Cloud Run.

Mover los montajes a la configuración de Cloud Run

Los scripts de inicialización de tu contenedor deben asumir que los montajes ya se han completado antes de llamar a tu contenedor. Debes mover todas las operaciones de montaje a la configuración de recursos de Cloud Run.

Cambia a un usuario que no sea root cuando sea posible

Prefiere los contenedores que no usen ni dependan del usuario raíz. Esta práctica reduce el riesgo de vulnerabilidad de tu servicio de Cloud Run, disminuye la superficie de ataque del contenedor, limita el acceso de los atacantes a tus sistemas de archivos y se ajusta al principio de mínimos accesos.

Usa la instrucción USER en tu Dockerfile para cambiar a una identidad con menos privilegios, ya que el valor predeterminado es ejecutar como root. Cloud Run usa el usuario especificado en tu archivo Dockerfile para ejecutar el contenedor.

Auditoría del uso de binarios de `setuid`

La ejecución de archivos binarios setuid fallará cuando se ejecuten desde tus contenedores en Cloud Run.

Si usas Docker o Podman de forma local, utiliza el argumento --cap-drop=setuid. También puedes validar que los archivos binarios de los que dependes no tengan el bit setuid definido.

Verificar que los contenedores raíz son compatibles con los espacios de nombres de usuario

Prueba los cambios de forma local o en una máquina virtual evaluando el código cuando se ejecute en espacios de nombres de usuario, como cuando se usa la función userns-remap de Docker, se ejecuta el contenedor en Podman sin root o se implementan los cambios en máquinas virtuales que ejecutan el sistema operativo optimizado para contenedores de Google con el argumento --userns-remap=default en el comando docker run.

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 activadores de Cloud Build:

Configurar despliegue continuo

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

Desplegar una aplicación en Cloud Run con Cloud Deploy

Desplegar imágenes de contenedor en Cloud Run Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Antes de empezar

Roles obligatorios

Registros e imágenes de contenedores admitidos

Desplegar un nuevo servicio

Consola

gcloud

YAML

Terraform

Redactar

Bibliotecas de cliente

API REST

Ubicaciones de Cloud Run

Con sujeción a los precios del nivel 1

Con sujeción a los precios del nivel 2

Desplegar una nueva revisión de un servicio

Consola

gcloud

YAML

Cloud Code

Terraform

Redactar

Bibliotecas de cliente

API REST

Ubicaciones de Cloud Run

Con sujeción a los precios del nivel 1

Con sujeción a los precios del nivel 2

Implementar imágenes de otros Google Cloud proyectos

Desplegar imágenes de otros registros

Implementar varios contenedores en un servicio (sidecars)

Casos prácticos

Desplegar un servicio con contenedores sidecar

Consola

gcloud

YAML

Terraform

Funciones destacadas disponibles para las implementaciones con sidecars

Orden de inicio

Intercambiar datos de archivos entre sidecars

Comunicación entre sidecars

Adaptar los contenedores para Cloud Run

Mover los montajes a la configuración de Cloud Run

Cambia a un usuario que no sea root cuando sea posible

Auditoría del uso de binarios de setuid

Verificar que los contenedores raíz son compatibles con los espacios de nombres de usuario

Siguientes pasos

Desplegar imágenes de contenedor en Cloud Run

Auditoría del uso de binarios de `setuid`