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

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.

Permisos necesarios para realizar una implementación

Debes tener UNA de las siguientes funciones:

Propietario
Editor
Las funciones de administrador de Cloud Run y usuario de cuenta de servicio
Cualquier función personalizada que incluya esta lista específica de permisos

Imágenes y registros de contenedores compatibles

Puedes usar imágenes de contenedor almacenadas en Artifact Registry, Container Registry (obsoleto o Docker Hub. Google recomienda el uso de Artifact Registry.

Solo puedes usar los siguientes tipos de imágenes de contenedor:

Imágenes de contenedor almacenadas en el mismo proyecto en el que creas el trabajo o el servicio.
Imágenes de contenedor de otros proyectos de Google Cloud (siempre que se establezcan los permisos de IAM correctos)
Imágenes de contenedor públicas de Artifact Registry, Container Registry o Docker Hub.

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.

Si almacenas imágenes de contenedor en otro tipo de Container Registry, sigue las instrucciones en implementar imágenes de registros no compatibles.

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.

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

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

Consola

Para implementar una imagen de contenedor, sigue estos pasos:

Ir a Cloud Run
Haz clic en Crear servicio para mostrar el formulario Crear servicio (Create service).
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.

Línea de comandos

En la consola de Google Cloud, activa Cloud Shell.

Activar Cloud Shell

En la parte inferior de la consola de Google Cloud, se inicia una sesión de Cloud Shell en la que se muestra una ventana de línea de comandos. Cloud Shell es un entorno de shell con Google Cloud CLI ya instalada y con valores ya establecidos para el proyecto actual. La sesión puede tardar unos segundos en inicializarse.
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 REGION-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
```
Reemplaza
- 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 REGION-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 REGION-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)
europe-north1 (Finlandia) Bajo nivel de CO₂
europe-southwest1 (Madrid)
europe-west1 (Bélgica) Bajo nivel de CO₂
europe-west4 (Países Bajos)
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)
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-south1 (Bombay, India)
asia-south2 Delhi (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) 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.

Cuando se implementa, el agente de servicio de Cloud Run debe poder acceder al contenedor implementado, que es el caso de forma predeterminada.

Cada servicio tiene una URL única y permanente que no cambiará con el tiempo a medida que implementes revisiones nuevas.

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.

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:

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.

Línea de comandos

En la consola de Google Cloud, activa Cloud Shell.

Activar Cloud Shell

En la parte inferior de la consola de Google Cloud, se inicia una sesión de Cloud Shell en la que se muestra una ventana de línea de comandos. Cloud Shell es un entorno de shell con Google Cloud CLI ya instalada y con valores ya establecidos para el proyecto actual. La sesión puede tardar unos segundos en inicializarse.
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 REGION-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 REGION-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)
europe-north1 (Finlandia) Bajo nivel de CO₂
europe-southwest1 (Madrid)
europe-west1 (Bélgica) Bajo nivel de CO₂
europe-west4 (Países Bajos)
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)
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-south1 (Bombay, India)
asia-south2 Delhi (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) 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 registros no compatibles

Si almacenas imágenes de contenedor en un registro de contenedores público o privado no compatible, envíalas de forma temporal a 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 sidecars 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 localhost usado 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.

Casos de uso

Los casos de uso de sidecars 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

Cómo implementar 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 o YAML.

Consola

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.
- Para implementar en un servicio nuevo, haz clic en 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.

Línea de comandos

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

En la consola de Google Cloud, activa Cloud Shell.

Activar Cloud Shell

En la parte inferior de la consola de Google Cloud, se inicia una sesión de Cloud Shell en la que se muestra una ventana de línea de comandos. Cloud Shell es un entorno de shell con Google Cloud CLI ya instalada y con valores ya establecidos para el proyecto actual. La sesión puede tardar unos segundos en inicializarse.
Para implementar varios contenedores en un servicio, ejecuta el siguiente comando:
```
gcloud beta run deploy SERVICE \
 --container INGRESS_CONTAINER_NAME
 --image='INGRESS_IMAGE' \
 --port='CONTAINER_PORT' \
 --container SIDECAR_CONTAINER_NAME \
 --image='SIDECAR_IMAGE'
```
- 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 INGRESS_CONTAINER_NAME por un nombre para el contenedor que recibe solicitudes, por ejemplo, app.
- Reemplaza INGRESS_IMAGE por una referencia a la imagen de contenedor que debe recibir solicitudes, por ejemplo, us-docker.pkg.dev/cloudrun/container/hello:latest.
- Reemplaza SIDECAR_CONTAINER_NAME por un nombre para el contenedor de sidecar, por ejemplo, sidecar.
- Reemplaza 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 beta 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 a 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_NAME
spec:
  template:
    spec:
      containers:
      - image: INGRESS_IMAGE
        ports:
          - containerPort: CONTAINER_PORT
      - image: SIDECAR_IMAGE

Reemplaza

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. Debes especificar un puerto. A diferencia de un servicio de contenedor único, para un servicio que contiene sidecars no hay un puerto predeterminado para el contenedor de entrada.
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

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