Los servicios de Cloud Run no tienen un entorno de ejecución especificado de forma predeterminada, lo que significa que Cloud Run selecciona el entorno de ejecución según las funciones que se usaron. Por lo tanto, a menos que especifiques un entorno de ejecución para el servicio, Cloud Run puede seleccionar el entorno de primera o segunda generación.
Ten en cuenta que los trabajos de Cloud Run usan únicamente el entorno de ejecución de segunda generación y no se puede cambiar para los trabajos.
El entorno de ejecución de primera generación cuenta con tiempos de inicio en frío rápidos y emulación de la mayoría de las llamadas al sistema operativo, pero no todas. En un principio, este era el único entorno de ejecución disponible para los servicios en Cloud Run.
El entorno de ejecución de segunda generación proporciona compatibilidad total con Linux en lugar de la emulación de llamadas al sistema. Este entorno de ejecución proporciona lo siguiente:
- Rendimiento de CPU más rápido
- Rendimiento más rápido de la red, especialmente en pérdida de paquetes
- Compatibilidad total con Linux, incluida la compatibilidad con todas las llamadas al sistema, los espacios de nombres y los cgroups
- Compatibilidad con el sistema de archivos de red
Si bien el entorno de ejecución de segunda generación generalmente funciona más rápido con una carga sostenida, tiene horas de inicio en frío más largos que el de primera generación para la mayoría de los servicios.
Puedes seleccionar el entorno de ejecución de tu servicio de Cloud Run cuando implementes un servicio nuevo o una revisión nueva del servicio. Si no especificas un entorno de ejecución, se usa la primera generación de forma predeterminada.
Cómo elegir un entorno de ejecución
Debes usar la primera generación si se cumple alguna de las siguientes condiciones:
- Tu servicio de Cloud Run tiene tráfico inestable y necesita escalar horizontalmente a muchas instancias, o tu servicio es sensible a los tiempos de inicio en frío.
- El servicio de Cloud Run tiene tráfico poco frecuente que causa un escalamiento horizontal frecuente desde cero.
- Quieres usar menos de 512 MiB de memoria. El entorno de ejecución de segunda generación requiere al menos 512 MiB de memoria.
Debes usar la segunda generación si se aplica alguna de las siguientes opciones a tu servicio de Cloud Run:
- El servicio debe usar un sistema de archivos de red, que solo es compatible con la segunda generación.
- Tu servicio tiene tráfico bastante estable y tolera los inicios en frío más lentos.
- El servicio tiene cargas de trabajo de uso intensivo de CPU.
- Tu servicio podría beneficiarse de un rendimiento de red más rápido.
- El servicio debe usar un software que tenga problemas para ejecutarse en la primera generación debido a llamadas al sistema no implementadas.
- Tu servicio necesita la funcionalidad cgroup de Linux.
- Tu servicio usa infraestructura de terceros para proteger los contenedores.
Prácticas recomendadas para usar el entorno de ejecución de segunda generación
Recomendamos que tu contenedor instale un controlador SIGTERM, en especial si usas el modelo de facturación a pedido de CPU.
El manejo de SIGTERM le da a tu contenedor la oportunidad de realizar cualquier tarea de limpieza necesaria, como vaciar los registros antes de salir. Si el contenedor no detecta SIGTERM, aún tendrá 10 segundos para realizar estas tareas. Esos 10 segundos son facturables.
Cómo verificar si el contenedor controla SIGTERM
Para determinar si el contenedor tiene un controlador SIGTERM instalado, haz lo siguiente:
Inicie Cloud Shell. Puedes encontrar Activar Cloud Shell en el encabezado de la página de documentación en la que te encuentras. Es posible que debas autorizarlo y esperar a que se aprovisione. También puedes iniciar una sesión independiente.
Ejecuta el contenedor de forma local en Cloud Shell:
docker run IMAGE_URL
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 formatoLOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
.Abre otra pestaña en Cloud Shell y obtén una lista de los contenedores que se ejecutan en la sesión actual de Cloud Shell:
docker container ls
Debes ubicar el ID del contenedor que muestra el comando.
Con el ID del contenedor, envía a tu contenedor una señal SIGTERM
docker kill -s SIGTERM CONTAINER_ID
Regresa a la pestaña en la que invocaste
docker run
para comprobar si el contenedor se cerró (detuvo). Si la señal SIGTERM hizo que el contenedor se salir, el contenedor controla SIGTERM.
Cómo controlar SIGTERM
Si el contenedor no controla SIGTERM, la forma más sencilla de agregar un controlador SIGTERM es unir el servicio con tini
. Esto hace que tu servicio se ejecute como un subproceso de tini
, que toma el rol del proceso init del contenedor.
Consulta las instrucciones de Docker para obtener instrucciones.
Como alternativa, puedes cambiar la aplicación para controlar directamente SIGTERM.
¿Qué sigue?
- A fin de especificar un entorno de ejecución para los servicios de Cloud Run, consulta Selecciona un entorno de ejecución.
- A fin de especificar la memoria para los servicios de Cloud Run, consulta Límites de memoria.
- Para usar Filestore con Cloud Run, consulta Usa Filestore con Cloud Run.
- Para usar Cloud Storage FUSE con Cloud Run, consulta Usa Cloud Storage FUSE con Cloud Run.
- Para usar sistemas de archivos de red, como NFS, NDB, 9P, CIFS/Samba y Ceph con Cloud Run, consulta Usa sistemas de archivos de red.