Se usó la API de Cloud Translation para traducir esta página.

Implementa imágenes de contenedor en Cloud Run

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

Cloud Run importa la imagen del contenedor cuando se implementa. Cloud Run mantiene esta copia de la imagen del contenedor, siempre que una revisión de publicación la use. Las imágenes de contenedor no se extraen de su repositorio de contenedores cuando se inicia una instancia nueva de Cloud Run.

Para ver una explicación de ejemplo de cómo implementar un servicio nuevo, consulta Implementa una guía de inicio rápido de contenedor de muestra.

Antes de comenzar

Si estás bajo una política de la organización de restricción de dominios que restringe las invocaciones no autenticadas para tu proyecto, deberás acceder al servicio implementado como se describe en Prueba servicios privados.

Roles obligatorios

Para obtener los permisos que necesitas para configurar y, luego, implementar los servicios de Cloud Run, pídele a tu administrador que te otorgue los siguientes roles de IAM:

Desarrollador de Cloud Run (roles/run.developer) en el servicio de Cloud Run
Usuario de la cuenta de servicio (roles/iam.serviceAccountUser) en la identidad del servicio
Lector de Artifact Registry (roles/artifactregistry.reader) en el repositorio de Artifact Registry de la imagen de contenedor implementada (si corresponde)

Para obtener una lista de los roles y los permisos de IAM asociados con Cloud Run, consulta los roles de IAM de Cloud Run y los permisos de IAM de Cloud Run. Si tu servicio de Cloud Run interactúa con las APIs de Google Cloud, como las bibliotecas cliente de Cloud, consulta la guía de configuración de identidades del servicio. Para obtener más información acerca de cómo otorgar roles, consulta Permisos de implementación y Administra el acceso.

Imágenes y registros de contenedores compatibles

Puedes usar directamente imágenes de contenedor almacenadas en Artifact Registry o Docker Hub. Google recomienda el uso de Artifact Registry.

Puedes usar imágenes de contenedor de otros registros públicos o privados (como JFrog Artifactory, Nexus o GitHub Container Registry) a través de la configuración de un repositorio remoto de Artifact Registry.

Solo debes considerar Docker Hub para implementar imágenes de contenedor populares, como las imágenes oficiales de Docker o las imágenes de OSS patrocinadas por Docker. Para obtener una mayor disponibilidad, Google recomienda implementar estas imágenes de Docker Hub mediante un repositorio remoto de Artifact Registry.

Implementa un servicio nuevo

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

Cuando implementas en un servicio por primera vez, se crea su primera revisión. Ten en cuenta que las revisiones son inmutables. Si implementas desde una etiqueta de imagen de contenedor, se resolverá en un resumen y la revisión siempre entregará este resumen en particular.

Haz clic en la pestaña para obtener instrucciones de la herramienta que elijas.

Consola

Para implementar una imagen de contenedor, sigue estos pasos:

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

Ir a Cloud Run
Haz clic en Implementar contenedor y selecciona Servicio para mostrar el formulario Crear servicio.
1. En el formulario, selecciona la opción de implementación:
  1. Si deseas implementar un contenedor de forma manual, selecciona Implementar una revisión desde una imagen de contenedor existente y especifica la imagen de contenedor.
  2. Si deseas automatizar para la implementación continua, selecciona Implementar continuamente revisiones nuevas desde el repositorio de código fuente y sigue las instrucciones correspondientes.
2. Ingresa el nombre del servicio necesario. Los nombres de servicios deben tener 49 caracteres o menos, y deben ser únicos por región y proyecto. Un nombre de servicio no se puede cambiar más adelante y es visible de forma pública.
3. Selecciona la región donde quieres que se ubique el servicio. El selector de región indica el nivel de precio, la disponibilidad de los mapeos de dominios y destaca las regiones con el impacto más bajo de huella de carbono.
4. Configura la asignación de CPU y los precios según sea necesario.
5. En Ajuste de escala automático, especifica las instancias mínimas y máximas.
6. Establece la configuración de Ingress en el formato que necesites.
7. En Autenticación, configura lo siguiente:
  - Si creas una API o un sitio web públicos, selecciona Permitir invocaciones no autenticadas. Si seleccionas esta opción, se asigna la función de invocador de IAM al identificador especial allUser. Puedes usar IAM para editar esta configuración más adelante una vez que hayas creado el servicio.
  - Si quieres tener un servicio seguro protegido por autenticación, selecciona Solicitar autenticación.
Haz clic en Contenedores, volúmenes, herramientas de redes y seguridad para establecer otra configuración opcional en las pestañas correspondientes:
Cuando termines de configurar tu servicio, haz clic en Crear para implementar la imagen en Cloud Run y espera a que termine la implementación.
Haz clic en el vínculo de la URL que se muestra para abrir el extremo único y estable del 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 implementar una imagen de contenedor, sigue estos pasos:
1. Ejecuta el siguiente comando:
```
gcloud run deploy SERVICE --image IMAGE_URL
```
  - Reemplaza SERVICE por el nombre del servicio en el que deseas implementar. Los nombres de servicios deben tener 49 caracteres o menos, y deben ser únicos por región y proyecto. Si aún no existe, con este comando se crea el servicio durante la implementación. Puedes omitir este parámetro por completo, pero se te solicitará el nombre del servicio si lo haces.
  - Reemplaza IMAGE_URL por una referencia a la imagen de contenedor, como us-docker.pkg.dev/cloudrun/container/hello:latest. Si usas Artifact Registry, el repositorio REPO_NAME debe estar creado. La URL tiene 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 creas una API o un sitio web públicos, puedes permitir las invocaciones sin autenticación de tu servicio mediante la marca --allow-unauthenticated. Así asignas la función de IAM de invocador de Cloud Run a allUsers. También puedes especificar --no-allow-unauthenticated para inhabilitar las invocaciones no autenticadas. Si omites cualquiera de estas marcas, se te solicitará que confirmes cuando se ejecute el comando deploy.
2. Espera a que finalice la implementación. Una vez que la compilación se completa de manera correcta, se muestra un mensaje de éxito, además de la URL del servicio implementado.
Ten en cuenta que para implementar en una ubicación diferente a la que estableciste mediante las propiedades de run/region gcloud, usa lo siguiente:
```
gcloud run deploy SERVICE --region REGION
```

YAML

Puedes almacenar la especificación de servicio en un archivo YAML y, luego, implementarla con gcloud CLI

Crea un archivo nuevo service.yaml con el siguiente contenido:
```
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    spec:
      containers:
      - image: IMAGE
```
Reemplazar
- SERVICE por el nombre del servicio de Cloud Run Los nombres de servicios deben tener 49 caracteres o menos, y deben ser únicos por región y proyecto.
- IMAGE por la URL de la imagen de contenedor
También puedes especificar más opciones de configuración, como variables de entorno o límites de memoria.
Implementa el servicio nuevo mediante el siguiente comando:
```
gcloud run services replace service.yaml
```
De manera opcional, haz que tu servicio sea público si deseas permitir el acceso sin autenticación.

Cloud Code

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

Terraform

Si usas Terraform, define tu servicio en una configuración de Terraform con el recurso google_cloud_run_v2_service del proveedor de Google Cloud Platform.

Crea un archivo main.tf nuevo con este contenido:
```
provider "google" {
  project = "PROJECT-ID"
}

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

  template {
    containers {
      image = "IMAGE"
    }
  }
}

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"
}
```
Reemplaza
- PROJECT-ID por el ID del proyecto de Google Cloud
- REGION por la región de Google Cloud
- SERVICE por el nombre del servicio de Cloud Run Los nombres de servicios deben tener 49 caracteres o menos, y deben ser únicos por región y proyecto.
- IMAGE_URL por una referencia a la imagen del contenedor, como us-docker.pkg.dev/cloudrun/container/hello:latest Si usas Artifact Registry, el repositorio REPO_NAME debe estar creado. La URL tiene 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, quita la estrofa google_cloud_run_v2_service_iam_member.
Inicializa Terraform mediante este comando:
```
terraform init
```
Aplica la configuración de Terraform:
```
terraform apply
```
Ingresa yes para confirmar que deseas aplicar las acciones descritas.

Bibliotecas cliente

Para crear un servicio nuevo desde el código, haz lo siguiente:

API de REST

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

Por ejemplo, con 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

Reemplaza lo siguiente:

ACCESS_TOKEN por un token de acceso válido para una cuenta que tenga los permisos de IAM para implementar servicios. Por ejemplo, si accediste a gcloud, puedes recuperar un token de acceso con gcloud auth print-access-token. Desde una instancia de contenedor de Cloud Run, puedes recuperar un token de acceso a través del servidor de metadatos de instancias de contenedor.
IMAGE_URL por una referencia a la imagen del contenedor, como us-docker.pkg.dev/cloudrun/container/hello:latest Si usas Artifact Registry, el repositorio REPO_NAME debe estar creado. La URL tiene el formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
SERVICE por el nombre del servicio en el que deseas implementar. Los nombres de servicios deben tener 49 caracteres o menos, y deben ser únicos por región y proyecto.
REGION por la región de Google Cloud del servicio.
PROJECT-ID por el ID del proyecto de Google Cloud.

Ubicaciones de Cloud Run

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

El cumplimiento de los requisitos de latencia, disponibilidad o durabilidad es el factor principal para seleccionar la región en la que se ejecutan los servicios de Cloud Run. Por lo general, puedes seleccionar la región más cercana a los usuarios, pero debes considerar la ubicación de los otros productos de Google Cloud que usa el servicio de Cloud Run. Si usas productos de Google Cloud en varias ubicaciones, la latencia y el costo del servicio pueden verse afectados.

Cloud Run está disponible en las siguientes regiones:

Sujetas a los Precios del nivel 1

asia-east1 (Taiwán)
asia-northeast1 (Tokio)
asia-northeast2 (Osaka)
asia-south1 (Bombay, India)
europe-north1 (Finlandia) Bajo nivel de CO₂
europe-southwest1 (Madrid) Bajo nivel de CO₂
europe-west1 (Bélgica) Bajo nivel de CO₂
europe-west4 (Países Bajos) Bajo nivel de CO₂
europe-west8 (Milán)
europe-west9 (París) Bajo nivel de CO₂
me-west1 (Tel Aviv)
us-central1 (Iowa) Bajo nivel de CO₂
us-east1 (Carolina del Sur)
us-east4 (Virginia del Norte)
us-east5 (Columbus)
us-south1 (Dallas) Bajo nivel de CO₂
us-west1 (Oregón) Bajo nivel de CO₂

Sujetas 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 (India)
australia-southeast1 (Sídney)
australia-southeast2 (Melbourne)
europe-central2 (Varsovia, Polonia)
europe-west10 (Berlín) Bajo nivel de CO₂
europe-west12 (Turín)
europe-west2 (Londres, Reino Unido) Bajo nivel de CO₂
europe-west3 (Fráncfort, Alemania) Bajo nivel de CO₂
europe-west6 (Zúrich, Suiza) Bajo nivel de CO₂
me-central1 (Doha)
me-central2 (Dammam)
northamerica-northeast1 (Montreal) Bajo nivel de CO₂
northamerica-northeast2 (Toronto) Bajo nivel de CO₂
southamerica-east1 (São Paulo, Brasil) Bajo nivel de CO₂
southamerica-west1 (Santiago, Chile) Bajo nivel de CO₂
us-west2 (Los Ángeles)
us-west3 (Salt Lake City)
us-west4 (Las Vegas)

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

Implementa una revisión nueva de un servicio existente

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

Ten en cuenta que cualquier cambio en la configuración hace que se cree una revisión nueva, incluso si no hay cambios en la imagen de contenedor. Cada revisión creada es inmutable.

Cloud Run importa la imagen del contenedor cuando se implementa. Cloud Run mantiene esta copia de la imagen del contenedor, siempre que una revisión de publicación la use.

Haz clic en la pestaña para obtener instrucciones de la herramienta que elijas.

Consola

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

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

Ir a Cloud Run
Identifica el servicio que deseas actualizar en la lista de servicios y hazle clic para abrir los detalles.
Haz clic en Editar e implementar una revisión nueva para mostrar el formulario de implementación de revisión.
1. Si es necesario, proporciona la URL a la imagen de contenedor nueva que deseas implementar.
2. Configura el contenedor según sea necesario.
3. Configura la asignación de CPU y los precios según sea necesario.
4. En Capacidad, especifica los Límites de memoria y 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 Ajuste de escala automático, especifica las instancias mínimas y máximas.
8. Usa las otras pestañas según sea necesario para configurar lo siguiente de manera opcional:
Para enviar todo el tráfico a la revisión nueva, selecciona Aplicar esta revisión inmediatamente. Para lanzar una nueva revisión de forma gradual, desmarca esa casilla de verificación. Esto da como resultado una implementación en la que no se envía tráfico a la revisión nueva. Sigue las instrucciones para los lanzamientos graduales después de la implementación.
Haz clic en Implementar y espera a que finalice la implementación.

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 implementar una imagen de contenedor, sigue estos pasos:
1. Ejecute el comando:
```
gcloud run deploy SERVICE --image IMAGE_URL
```
  - Reemplaza SERVICE por el nombre del servicio en el que realizas la implementación. Puedes omitir este parámetro por completo, pero se te solicitará el nombre del servicio si lo haces.
  - Reemplaza IMAGE_URL por una referencia a la imagen de contenedor, como us-docker.pkg.dev/cloudrun/container/hello:latest. Si usas Artifact Registry, el repositorio REPO_NAME debe estar creado. La URL tiene el formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
  El sufijo de revisión se asigna de forma automática para las revisiones nuevas. Si deseas proporcionar tu propio sufijo de revisión, usa el parámetro --revision-suffix de la CLI de gcloud.
2. Espera a que finalice la implementación. Una vez que la compilación se completa de manera correcta, se muestra un mensaje de éxito, además de la URL del servicio implementado.

YAML

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

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

Desde un archivo YAML de configuración de servicio, modifica cualquier atributo secundario spec.template como necesites para actualizar la configuración de revisión y, luego, implementa la revisión nueva:

gcloud run services replace service.yaml

Cloud Code

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

Terraform

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

Realiza un cambio en el archivo de configuración.
Aplica la configuración de Terraform:
```
terraform apply
```
Ingresa yes para confirmar que deseas aplicar las acciones descritas.
Nota: A menos que se requiera un cambio de configuración, no se creará una revisión nueva.

Bibliotecas cliente

Para implementar una revisión nueva desde el código, haz lo siguiente:

API de REST

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

Por ejemplo, con 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

Reemplaza lo siguiente:

ACCESS_TOKEN por un token de acceso válido para una cuenta que tenga los permisos de IAM para implementar revisiones. Por ejemplo, si accediste a gcloud, puedes recuperar un token de acceso con gcloud auth print-access-token. Desde una instancia de contenedor de Cloud Run, puedes recuperar un token de acceso a través del servidor de metadatos de instancias de contenedor.
IMAGE_URL por una referencia a la imagen del contenedor, como us-docker.pkg.dev/cloudrun/container/hello:latest Si usas Artifact Registry, el repositorio REPO_NAME debe estar creado. La URL tiene el formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
Reemplaza SERVICE por el nombre del servicio en el que realizas la implementación.
REGION por la región de Google Cloud del servicio.
PROJECT-ID por el ID del proyecto de Google Cloud.

Ubicaciones de Cloud Run

Cloud Run está disponible en las siguientes regiones:

Sujetas a los Precios del nivel 1

asia-east1 (Taiwán)
asia-northeast1 (Tokio)
asia-northeast2 (Osaka)
asia-south1 (Bombay, India)
europe-north1 (Finlandia) Bajo nivel de CO₂
europe-southwest1 (Madrid) Bajo nivel de CO₂
europe-west1 (Bélgica) Bajo nivel de CO₂
europe-west4 (Países Bajos) Bajo nivel de CO₂
europe-west8 (Milán)
europe-west9 (París) Bajo nivel de CO₂
me-west1 (Tel Aviv)
us-central1 (Iowa) Bajo nivel de CO₂
us-east1 (Carolina del Sur)
us-east4 (Virginia del Norte)
us-east5 (Columbus)
us-south1 (Dallas) Bajo nivel de CO₂
us-west1 (Oregón) Bajo nivel de CO₂

Sujetas 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 (India)
australia-southeast1 (Sídney)
australia-southeast2 (Melbourne)
europe-central2 (Varsovia, Polonia)
europe-west10 (Berlín) Bajo nivel de CO₂
europe-west12 (Turín)
europe-west2 (Londres, Reino Unido) Bajo nivel de CO₂
europe-west3 (Fráncfort, Alemania) Bajo nivel de CO₂
europe-west6 (Zúrich, Suiza) Bajo nivel de CO₂
me-central1 (Doha)
me-central2 (Dammam)
northamerica-northeast1 (Montreal) Bajo nivel de CO₂
northamerica-northeast2 (Toronto) Bajo nivel de CO₂
southamerica-east1 (São Paulo, Brasil) Bajo nivel de CO₂
southamerica-west1 (Santiago, Chile) Bajo nivel de CO₂
us-west2 (Los Ángeles)
us-west3 (Salt Lake City)
us-west4 (Las Vegas)

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

Implementa imágenes de otros proyectos de Google Cloud

Puedes implementar imágenes de contenedor de otros proyectos de Google Cloud si estableces los permisos de IAM adecuados:

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

Ve a la página IAM
Selecciona Incluir asignaciones de roles proporcionadas por Google.
Copia el correo electrónico del agente de servicio de Cloud Run. Tiene el sufijo @serverless-robot-prod.iam.gserviceaccount.com.
Abre el proyecto que posee el registro de contenedores que deseas usar.

Ve a la página IAM
Haz clic en Agregar para agregar una principal nueva.
En el campo Principales nuevas, pega el correo electrónico de la cuenta de servicio que copiaste antes.
En el menú desplegable Seleccionar una función, si usas Container Registry, elige la función Almacenamiento -> Visualizador de objetos de Storage. Si usas Artifact Registry, selecciona la función Artifact Registry -> Lector de Artifact Registry.
Implementa la imagen del contenedor en el proyecto que contiene tu servicio de Cloud Run.

Nota: Para obtener mayor seguridad, otorga acceso solo al bucket de Cloud Storage o al repositorio de Artifact Registry que contiene las imágenes de contenedor.

Implementa imágenes de otros registros

Para implementar imágenes de contenedor públicas o privadas que no se almacenan en Artifact Registry ni en Docker Hub, configura un repositorio remoto de Artifact Registry.

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

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

Como alternativa, si no puedes usar un repositorio remoto de Artifact Registry, puedes extraer e insertar imágenes de contenedor de forma temporal en Artifact Registry mediante docker push para implementarlas en Cloud Run. Cloud Run importa la imagen del contenedor cuando se implementa, por lo que, después de la implementación, puedes borrarla de Artifact Registry.

Implementa varios contenedores en un servicio (sidecars)

En una implementación de Cloud Run con sidecars, hay un contenedor de entrada que controla todas las solicitudes HTTPS entrantes en el PORT de contenedor que especifiques y hay una o más contenedores sidecar. Los archivos adicionales no pueden escuchar las solicitudes HTTP entrantes en el puerto del contenedor de entrada, pero pueden comunicarse entre sí y con el contenedor de entrada mediante un puerto localhost. El puerto de localhost que se usa varía según los contenedores que uses.

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

Contenedores múltiples de Cloud Run

Puedes implementar hasta 10 contenedores por instancia, incluido el contenedor de entrada. Todos los contenedores dentro de una instancia comparten el mismo espacio de nombres de red y también pueden compartir archivos a través de volúmenes compartidos en la memoria, como se muestra en el diagrama.

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

De forma predeterminada, solo se asigna CPU a los contenedores secundarios cuando la instancia está procesando al menos una solicitud. Si necesitas que tu sidecar pueda usar la CPU fuera del procesamiento de solicitudes (por ejemplo, para la recopilación de métricas), configura tu servicio para que siempre tenga asignada la CPU. Para obtener más información, consulta Asignación de CPU (servicios).

Puedes exigir que todas las implementaciones usen un sidecar específico si creas políticas de organización personalizadas.

Casos de uso

Los casos de uso de archivos adicionales en un servicio de Cloud Run incluyen los siguientes:

Supervisión, registro y seguimiento de aplicaciones
Uso de Nginx, Envoy o Apache2 como proxy frente al contenedor de tu aplicación
Uso de filtros de autenticación y autorización (por ejemplo, agente de políticas abiertas)
Uso de proxies de conexión saliente, como el proxy de autenticación de la base de datos de Alloy

Implementa un servicio con contenedores de sidecar

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

Haz clic en la pestaña para obtener instrucciones de la herramienta que elijas.

Console

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

Ir a Cloud Run
- Para implementar en un servicio existente, ubícalo en la lista de servicios y haz clic para abrir, luego haz clic en EDITAR E IMPLEMENTAR UNA REVISIÓN NUEVA para mostrar el formulario de implementación de revisión.
- Haz clic en Implementar contenedor y selecciona Servicio para mostrar el formulario Crear servicio.
Para un servicio nuevo, sigue estos pasos:
1. Proporciona el nombre del servicio y la URL a la imagen de contenedor de entrada que deseas implementar.
2. Haz clic en Contenedores, volúmenes, herramientas de redes y seguridad.
En la tarjeta Editar contenedor, configura el contenedor de entrada según sea necesario.
Haz clic en Agregar contenedor y configura un contenedor de archivo adicional que deseas agregar junto con el contenedor de entrada. Si el sidecar depende de otro contenedor en el servicio, indica esto en el menú desplegable Orden de inicio del contenedor. Repite este paso para cada contenedor de archivo adicional que implementes.
Para enviar todo el tráfico a la revisión nueva, selecciona Aplicar esta revisión inmediatamente. Si quieres hacer un lanzamiento gradual, desmarca esa casilla de verificación. Esto da como resultado una implementación en la que no se envía tráfico a la revisión nueva. Sigue las instrucciones para los lanzamientos graduales después de la implementación.
Haz clic en Crear para un servicio nuevo o en Implementar en un servicio existente y espera a que finalice la implementación.

gcloud

Los parámetros container en Google Cloud CLI están en Vista previa.

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 implementar 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'
```
Reemplaza lo siguiente:
- Reemplaza SERVICE por el nombre del servicio en el que realizas la implementación. Puedes omitir este parámetro por completo, pero se te solicitará el nombre del servicio si lo haces.
- INGRESS_CONTAINER_NAME por un nombre para el contenedor que recibe solicitudes, por ejemplo, app.
- INGRESS_IMAGE por una referencia a la imagen de contenedor que debe recibir solicitudes, por ejemplo, us-docker.pkg.dev/cloudrun/container/hello:latest.
- CONTAINER_PORT por el puerto en el que el contenedor de entrada escucha las solicitudes entrantes. A diferencia de un servicio de contenedor único, para un servicio que contiene sidecars no hay un puerto predeterminado para el contenedor de entrada. Debes configurar de forma explícita el puerto del contenedor para el contenedor de entrada, y solo un contenedor puede tener el puerto expuesto.
- SIDECAR_CONTAINER_NAME por un nombre para el contenedor de sidecar, por ejemplo, sidecar.
- SIDECAR_IMAGE por una referencia a la imagen del contenedor del sidecar.
Si deseas configurar cada contenedor en el comando de implementación, proporciona la configuración de cada contenedor después de los parámetros container como en el siguiente 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 son de nivel de contenedor antes de las marcas a nivel de contenedor; de lo contrario, el comando de implementación falla con un mensaje de error a tal efecto. Por ejemplo, en el comando “gcloud run services deploy service --execution-environment=gen2 --container app --memory=1G”, la marca --execution-environment debe pasarse antes de la marca --container.
Espera a que finalice la implementación. Una vez que la compilación se completa de manera correcta, se muestra un mensaje de éxito, además de 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 agrégale 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

Reemplazar

SERVICE por el nombre del servicio de Cloud Run Los nombres de servicios deben tener 49 caracteres o menos.
CONTAINER_PORT por el puerto en el que el contenedor de entrada escucha las solicitudes entrantes. A diferencia de un servicio de contenedor único, para un servicio que contiene sidecars no hay un puerto predeterminado para el contenedor de entrada. Debes configurar de forma explícita el puerto del contenedor para el contenedor de entrada, y solo un contenedor puede tener el puerto expuesto.
INGRESS_IMAGE por una referencia a la imagen de contenedor que debe recibir solicitudes, por ejemplo, us-docker.pkg.dev/cloudrun/container/hello:latest.
SIDECAR_IMAGE por una referencia a la imagen del contenedor del sidecar. Puedes especificar varios archivos adicionales agregando más elementos al array containers en el YAML.

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

gcloud run services replace service.yaml

Terraform

Si deseas obtener más información para aplicar o quitar una configuración de Terraform, consulta los comandos básicos de Terraform.

Agrega lo siguiente a un recurso google_cloud_run_v2_service en la 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"
      }
    }
  }

El CONTAINER_PORT representa el puerto en el que el contenedor de entrada escucha las solicitudes entrantes. A diferencia de un servicio de contenedor único, para un servicio que contiene sidecars no hay un puerto predeterminado para el contenedor de entrada. Debes configurar de forma explícita el puerto del contenedor para el contenedor de entrada, y solo un contenedor puede tener el puerto expuesto.

Funciones destacadas disponibles para implementaciones con sidecars

Puedes especificar el orden de inicio del contenedor dentro de una implementación con varios contenedores si tienes dependencias que requieren que algunos contenedores se inicien antes que otros contenedores en la implementación.

Si tienes contenedores que dependen de otros contenedores, debes usar verificaciones de estado en tu implementación. Si usas verificaciones de estado, Cloud Run sigue el orden de inicio del contenedor y, luego, inspecciona el estado de cada contenedor, y se asegura de que cada uno pase correctamente antes de que Cloud Run ejecute el siguiente contenedor en el orden. Si no usas las verificaciones de estado, se iniciarán los contenedores en buen estado, incluso si los contenedores de los que dependen no están en ejecución.

Varios contenedores dentro de una sola instancia pueden acceder a un volumen en memoria compartido, al que puede acceder cada contenedor con los puntos de activación que creas.

¿Qué sigue?

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

Puedes automatizar las implementaciones y compilaciones de los servicios de Cloud Run mediante el uso de activadores de Cloud Build.

Configura la implementación continua

También puedes usar Cloud Deploy para configurar una canalización de entrega continua a fin de implementar servicios de Cloud Run en varios entornos:

Implementa una app en Cloud Run con Cloud Deploy