Entorno de ejecución de funciones de Cloud Run

Nota: Por lo general, la información de este documento se aplica a las funciones de Cloud Run (1ª gen.) y a las funciones de Cloud Run (antes Cloud Functions (2nd gen)). , excepto cuando se indique lo contrario. Para ver las funciones adicionales compatibles con las funciones de Cloud Run, consulta la comparación de versiones de funciones de Cloud Run.

Funciones de Cloud Run se ejecuta en un entorno sin servidores y completamente administrado en el que Google se encarga de la infraestructura, los sistemas operativos y los entornos de ejecución. Cada función se ejecuta en un contexto propio, seguro y aislado, se escala automáticamente y cuenta con un ciclo de vida independiente de otras funciones.

Entornos de ejecución

Funciones de Cloud Run admite varios entornos de ejecución de lenguajes. Cada uno contiene un conjunto estándar de paquetes del sistema, así como las herramientas y bibliotecas necesarias para ese lenguaje. Necesitarás el valor del ID del entorno de ejecución si implementas funcionesdesde la línea de comandos o medianteTerraform.

Las actualizaciones de seguridad y mantenimiento están disponibles para todos los entornos de ejecución de funciones de Cloud Run (1ª gen.). Estas actualizaciones se aplican de forma automática o manual, según el entorno y la configuración. Para obtener más información sobre las actualizaciones del entorno de ejecución, consulta Protege tu función de Cloud Run.

Las imágenes del entorno de ejecución se alojan en todas las regiones en las que Artifact Registry está disponible. Puedes personalizar la ruta de acceso de la imagen del entorno de ejecución; para ello, reemplaza la primera parte del URI por la región que elijas:

REGION-docker.pkg.dev/serverless-runtimes/STACK/runtimes/RUNTIME_ID

Reemplaza lo siguiente:

• REGION por la región preferida, por ejemplo, us-central1
• STACK por la pila preferida del sistema operativo, por ejemplo, google-22-full
• RUNTIME_ID por el ID del entorno de ejecución que usa la función, por ejemplo, python310.

Por ejemplo, se hará referencia a la imagen base más reciente de Node.js 20 que usa la pila google-22-full, alojada en us-central1, con esta URL: us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/nodejs22

Node.js

Entorno de ejecución	ID de entorno de ejecución	Pilas	Imagen base del entorno de ejecución
Node.js 22 (solo vista previa)	nodejs22	google-22 (predeterminada) google-22-full	google-22/nodejs22 google-22-full/nodejs22
Node.js 20	nodejs20	google-22 (predeterminada) google-22-full	google-22/nodejs20 google-22-full/nodejs20
Node.js 18	nodejs18	google-22 (predeterminada) google-22-full	google-22/nodejs18 google-22-full/nodejs18
Node.js 16	nodejs16	google-18-full	google-18-full/nodjes16
Node.js 14	nodejs14	google-18-full	google-18-full/nodjes14
Node.js 12	nodejs12	google-18-full	google-18-full/nodjes14
Node.js 10	nodejs10	google-18-full	google-18-full/nodjes10
Node.js 8	nodejs8	Fuera de servicio	Fuera de servicio
Node.js 6	nodejs6	Fuera de servicio	Fuera de servicio

Python

Entorno de ejecución	ID de entorno de ejecución	Pilas	Imagen base del entorno de ejecución
Python 3.12	python312	google-22 (predeterminada) google-22-full	google-22/python312 google-22-full/python312
Python 3.11	python311	google-22 (predeterminada) google-22-full	google-22/python311 google-22-full/python311
Python 3.10	python310	google-22 (predeterminada) google-22-full	google-22/python310 google-22-full/python311
Python 3.9	python39	google-18-full	google-18-full/python39
Python 3.8	python38	google-18-full	google-18-full/python38
Python 3.7	python37	google-18-full	google-18-full/python37

Go

Entorno de ejecución	ID de entorno de ejecución	Pilas	Imagen base del entorno de ejecución
Go 1.22	go122	google-22 (predeterminada) google-22-full	google-22/go122 google-22-full/go122
Go 1.21	go121	google-22 (predeterminada) google-22-full	google-22/go121 google-22-full/go121
Go 1.20	go120	google-22 (predeterminada) google-22-full	google-22/go120 google-22-full/go120
Go 1.19	go119	google-22 (predeterminada) google-22-full	google-22/go119 google-22-full/go119
Go 1.18	go118	google-22 (predeterminada) google-22-full	google-22/go118 google-22-full/go120
Go 1.16	go116	google-18-full	google-18-full/go116
Go 1.13	go113	google-18-full	google-18-full/go113
Go 1.11	go111	Fuera de servicio	Fuera de servicio

Nota: En la política de versiones de Go, se indica que cada versión principal de Go es compatible hasta que haya dos versiones principales más recientes. Es posible que las fechas de claves no estén disponibles hasta que las versiones más recientes de Go estén disponibles de forma pública.

Java

Entorno de ejecución	ID de entorno de ejecución	Pilas	Imagen base del entorno de ejecución
Java 21	java21	google-22 (predeterminada) google-22-full	google-22/java21 google-22-full/java21
Java 17	java17	google-22 (predeterminada) google-22-full	google-22/java17 google-22-full/java17
Java 11	java11	google-18	google-18/java11

Ruby

Entorno de ejecución	ID de entorno de ejecución	Pilas	Imagen base del entorno de ejecución
Ruby 3.3	ruby33	google-22 (predeterminada) google-22-full	google-22/ruby33 google-22-full/ruby33
Ruby 3.2	ruby32	google-22 (predeterminada) google-22-full	google-22/ruby32 google-22-full/ruby32
Ruby 3.0	ruby30	google-18-full	google-18-full/ruby30
Ruby 2.7	ruby27	google-18-full	google-18-full/ruby27
Ruby 2.6	ruby26	google-18-full	google-18-full/ruby26

PHP

Entorno de ejecución	ID de entorno de ejecución	Pilas	Imagen base del entorno de ejecución
PHP 8.3	php83	google-22 (predeterminada) google-22-full	google-22/php83 google-22-full/php83
PHP 8.2	php82	google-22 (predeterminada) google-22-full	google-22/php82 google-22-full/php82
PHP 8.1	php81	google-18-full	google-18-full/php81
PHP 7.4	php74	google-18-full	google-18-full/php74

.NET Core

Entorno de ejecución	ID de entorno de ejecución	Pilas	Imagen base del entorno de ejecución
.NET Core 8	dotnet8	google-22 (predeterminada) google-22-full	google-22/dotnet8 google-22-full/dotnet8
.NET Core 6	dotnet6	google-22 (predeterminada) google-22-full	google-22/dotnet6 google-22-full/dotnet6
.NET Core 3	dotnet3	google-18-full	google-18-full/dotnet3

Comportamiento del ajuste de escala automático

Funciones de Cloud Run implementa el paradigma sin servidores, en el que solo ejecutas el código sin preocuparte por la infraestructura subyacente, como los servidores o las máquinas virtuales. Una vez implementadas, las funciones se administran y escalan de forma automática.

Funciones de Cloud Run maneja las solicitudes entrantes asignándolas a las instancias de tu función. Dependiendo del volumen de solicitudes, así como de la cantidad de instancias de funciones existentes, funciones de Cloud Run puede asignar una solicitud a una instancia existente o crear una nueva.

En los casos en los que el volumen de solicitudes entrantes exceda la cantidad de instancias existentes, funciones de Cloud Run puede iniciar varias instancias nuevas para manejar las solicitudes. Este comportamiento de ajuste de escala automático permite que funciones de Cloud Run maneje muchas solicitudes en paralelo, cada una a través de una instancia diferente de la función.

Nota: Un aumento muy rápido en el tráfico entrante puede hacer que algunas solicitudes fallen de forma intermitente con un código HTTP de 500. Esto se debe a que las solicitudes agotan el tiempo de espera en la lista de pendientes mientras esperan que se creen las instancias nuevas. Configurar tu carga de trabajo de modo que aumente el tráfico de manera gradual durante el transcurso de un minuto puede ayudar con este problema. Consulta también Solución de problemas de funciones de Cloud Run para obtener más información.

En algunos casos, no se recomienda el escalamiento ilimitado. Para solucionar esto, funciones de Cloud Run te permite configurar una cantidad máxima de instancias que pueden coexistir en un momento determinado para una función en particular.

Sin estado

Para habilitar la administración automática y el escalamiento de tus funciones, las funciones deben ser sin estado: una invocación de función no debe basarse en un estado de la memoria configurado por una invocación previa. Las invocaciones pueden controlarse mediante diferentes instancias de funciones, que no comparten variables globales, memoria, sistemas de archivos ni otro estado.

Nota: Aunque no se puede confiar en él, el estado en la memoria a menudo puede volver a utilizarse como una optimización del rendimiento; consulta la recomendación en Sugerencias y trucos para obtener más detalles.

Si necesitas compartir estados en las invocaciones de función, la función debe usar un servicio como Memorystore, Datastore, Firestore o Cloud Storage para conservar los datos. Consulta las bases de datos de Google Cloud y los productos de almacenamiento de Google Cloud para obtener más información sobre las opciones de bases de datos y almacenamiento que proporciona Google Cloud.

Simultaneidad

Funciones de Cloud Run

Las funciones de Cloud Run admiten el manejo de varias solicitudes simultáneas en una sola instancia de función. Esto puede ser útil para prevenir inicios en frío, ya que una instancia ya preparada puede procesar varias solicitudes de forma simultánea, lo que reduce la latencia general. Para obtener más información, consulta Simultaneidad.

Funciones de Cloud Run (1ª gen.)

En funciones de Cloud Run (1ª gen.), cada instancia de una función maneja solo una solicitud simultánea a la vez. Esto significa que mientras tu código procesa una solicitud, no hay posibilidad de que una segunda solicitud se enrute a la misma instancia. Por lo tanto, la solicitud original puede usar la cantidad total de recursos (memoria y CPU) que asignas.

Dado que diferentes instancias de función procesan solicitudes simultáneas en funciones de Cloud Run (1ª gen.), no comparten variables ni memoria local. Consulta Sin estado y Ciclo de vida de la instancia de función para obtener más información.

Inicios en frío

Una instancia de función nueva se inicia en dos casos:

• Cuando implementas la función.

• Cuando una instancia de función nueva se crea automáticamente para escalar verticalmente hasta la carga o, de manera ocasional, a fin de reemplazar una instancia existente.

Iniciar una instancia de función nueva implica cargar el entorno de ejecución y tu código. Las solicitudes que incluyen el inicio de instancias de función, llamadas inicios en frío, pueden ser más lentas que las que se enrutan a instancias de función existentes. Sin embargo, si tu función recibe una carga constante, la cantidad de inicios en frío suele ser insignificante, a menos que la función falle con frecuencia y requiera el reinicio del entorno de la función.

Si el código de tu función genera una excepción no detectada o hace que falle el proceso actual, la instancia de función puede reiniciarse. Esto puede generar inicios más en frío, lo que da como resultado una latencia más alta, por lo que recomendamos capturar excepciones y, de lo contrario, evitar la finalización del proceso actual. Consulta Informa errores para obtener una explicación sobre cómo manejar y, luego, informar errores en funciones de Cloud Run.

Nota: En funciones de Cloud Run (1ª gen.), la cantidad de memoria otorgada a una función afecta la asignación de CPU, que, a su vez, puede afectar el tiempo de inicio en frío (consulta precios). Si bien esto también es así en las funciones de Cloud Run de forma predeterminada, en las funciones de Cloud Run, tienes la opción de configurar la asignación de CPU por separado de la memoria.

Si tu función es sensible a la latencia, considera establecer una cantidad mínima de instancias para evitar inicios en frío.

Vida útil de la instancia de función

Por lo general, las instancias de función son resilientes y se vuelven a usar en invocaciones de funciones posteriores, a menos que se reduzca la cantidad de instancias verticalmente debido a la falta de tráfico en curso o a que tu función falle. Esto significa que, cuando la ejecución de una función termina, la misma instancia de función puede controlar otra invocación de función.

Nota: Como optimización del rendimiento, puedes almacenar en caché el estado en todas las invocaciones de alcance global cuando sea posible. Sin embargo, tu función no debe depender de este estado de caché, ya que no hay garantía de que la siguiente invocación alcance la misma instancia de función. Consulta Sin estado.

Alcance de la función vs. alcance global

La invocación de una sola función da como resultado la ejecución del cuerpo de la función declarada solamente como el punto de entrada. El alcance global del código fuente de tu función solo se ejecuta en inicios en frío y no en instancias que ya se inicializaron.

Node.js

const functions = require('@google-cloud/functions-framework');

// TODO(developer): Define your own computations
const {lightComputation, heavyComputation} = require('./computations');

// Global (instance-wide) scope
// This computation runs once (at instance cold-start)
const instanceVar = heavyComputation();

/**
 * HTTP function that declares a variable.
 *
 * @param {Object} req request context.
 * @param {Object} res response context.
 */
functions.http('scopeDemo', (req, res) => {
  // Per-function scope
  // This computation runs every time this function is called
  const functionVar = lightComputation();

  res.send(`Per instance: ${instanceVar}, per function: ${functionVar}`);
});

Python

import time

import functions_framework


# Placeholder
def heavy_computation():
    return time.time()


# Placeholder
def light_computation():
    return time.time()


# Global (instance-wide) scope
# This computation runs at instance cold-start
instance_var = heavy_computation()


@functions_framework.http
def scope_demo(request):
    """
    HTTP Cloud Function that declares a variable.
    Args:
        request (flask.Request): The request object.
        <http://flask.pocoo.org/docs/1.0/api/#flask.Request>
    Returns:
        The response text, or any set of values that can be turned into a
        Response object using `make_response`
        <http://flask.pocoo.org/docs/1.0/api/#flask.Flask.make_response>.
    """

    # Per-function scope
    # This computation runs every time this function is called
    function_var = light_computation()
    return f"Instance: {instance_var}; function: {function_var}"

Go

// h is in the global (instance-wide) scope.
var h string

// init runs during package initialization. So, this will only run during an
// an instance's cold start.
func init() {
	h = heavyComputation()
	functions.HTTP("ScopeDemo", ScopeDemo)
}

// ScopeDemo is an example of using globally and locally
// scoped variables in a function.
func ScopeDemo(w http.ResponseWriter, r *http.Request) {
	l := lightComputation()
	fmt.Fprintf(w, "Global: %q, Local: %q", h, l)
}

Java

import com.google.cloud.functions.HttpFunction;
import com.google.cloud.functions.HttpRequest;
import com.google.cloud.functions.HttpResponse;
import java.io.IOException;
import java.io.PrintWriter;
import java.util.Arrays;

public class Scopes implements HttpFunction {
  // Global (instance-wide) scope
  // This computation runs at instance cold-start.
  // Warning: Class variables used in functions code must be thread-safe.
  private static final int INSTANCE_VAR = heavyComputation();

  @Override
  public void service(HttpRequest request, HttpResponse response)
      throws IOException {
    // Per-function scope
    // This computation runs every time this function is called
    int functionVar = lightComputation();

    var writer = new PrintWriter(response.getWriter());
    writer.printf("Instance: %s; function: %s", INSTANCE_VAR, functionVar);
  }

  private static int lightComputation() {
    int[] numbers = new int[] { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
    return Arrays.stream(numbers).sum();
  }

  private static int heavyComputation() {
    int[] numbers = new int[] { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
    return Arrays.stream(numbers).reduce((t, x) -> t * x).getAsInt();
  }
}

Ruby

# Global (instance-wide) scope.
# This block runs on cold start, before any function is invoked.
#
# Note: It is usually best to run global initialization in an on_startup block
# instead at the top level of the Ruby file. This is because top-level code
# could be executed to verify the function during deployment, whereas an
# on_startup block is run only when an actual function instance is starting up.
FunctionsFramework.on_startup do
  instance_data = perform_heavy_computation

  # To pass data into function invocations, the best practice is to set a
  # key-value pair using the Ruby Function Framework's built-in "set_global"
  # method. Functions can call the "global" method to retrieve the data by key.
  # (You can also use Ruby global variables or "toplevel" local variables, but
  # they can make it difficult to isolate global data for testing.)
  set_global :my_instance_data, instance_data
end

FunctionsFramework.http "tips_scopes" do |_request|
  # Per-function scope.
  # This method is called every time this function is called.
  invocation_data = perform_light_computation

  # Retrieve the data computed by the on_startup block.
  instance_data = global :my_instance_data

  "instance: #{instance_data}; function: #{invocation_data}"
end

Puedes usar variables globales como una optimización del rendimiento, pero no debes confiar en el estado establecido en el alcance global mediante invocaciones de funciones anteriores. Consulta Sin estado para obtener más información.

Puedes suponer que, para cada instancia de función, el alcance global se ejecutó solo una vez antes de que se invocara el código de la función. Sin embargo, no debes depender de la cantidad total de ejecuciones de alcance global o de su tiempo, ya que pueden variar según la actividad de ajuste de escala automático.

Cronograma de ejecución de funciones

Una función tiene acceso a sus recursos asignados (memoria y CPU) solo por el tiempo que dura la ejecución de la función. El código que se ejecuta fuera del período de ejecución no tiene garantía de ejecutarse y puede detenerse en cualquier momento. Por lo tanto, siempre debes indicar el final de la ejecución de tu función de forma correcta y evitar ejecutar cualquier otro código. Consulta las funciones de HTTP, las funciones en segundo plano y las funciones de CloudEvent para obtener asesoramiento.

La ejecución de la función también está sujeta a la duración de tiempo de espera de la función. Consulta Tiempo de espera de la función para obtener más información.

Ten en cuenta el cronograma de ejecución cuando inicialices la aplicación. Las tareas en segundo plano no deben crearse en el alcance global durante la inicialización, ya que se ejecutan fuera de la duración de una solicitud.

Garantías de ejecución

Por lo general, las funciones se invocan una vez por cada evento entrante. Sin embargo, funciones de Cloud Run no garantiza una sola invocación en todos los casos debido a las diferencias en las situaciones de error.

La cantidad máxima o mínima de veces que tu función puede invocarse para un solo evento depende del tipo de función.

• Las funciones de HTTP se invocan máximo una vez. Esto se debe a la naturaleza síncrona de las llamadas a HTTP y quiere decir que se mostrará cualquier error que ocurra durante la invocación de función sin reintentar el proceso. Se espera que el emisor de una función de HTTP corrija los errores y vuelva a intentar el proceso si es necesario.

• Las funciones controladas por eventos se invocan mínimo una vez. Esto se debe a su naturaleza asíncrona del manejo de eventos, en la que no hay ningún emisor que espere por la respuesta. En extrañas circunstancias, el sistema podría invocar una función controlada por eventos más de una vez con el fin de asegurar el envío del evento. Si la invocación de una función basada en eventos falla con un error, no se invocará de nuevo, a menos que se habiliten opciones para esa función que permitan reintentar el proceso en caso de error.

Para asegurarte de que tu función se comporta correctamente en los demás intentos de ejecución, debes hacerla idempotente mediante su implementación, de manera que se produzcan los resultados deseados (y efectos secundarios) incluso si un evento se entrega varias veces. En el caso de las funciones de HTTP, esto también implica mostrar el valor deseado, incluso si el emisor vuelve a intentar las llamadas al extremo de la función de HTTP. Consulta Reintenta las funciones controladas por eventos para obtener más información sobre cómo hacer que tu función sea idempotente.

Memoria y sistema de archivos

Cada función tiene una cierta cantidad de memoria asignada para su uso. Puedes configurar la cantidad de memoria en la implementación; consulta Límites de memoria para obtener más información.

El entorno de ejecución de funciones incluye un sistema de archivos en la memoria que contiene los archivos de origen y los directorios implementados con la función (consulta Estructura código fuente). El directorio que contiene tus archivos de origen es de solo lectura, pero el resto del sistema de archivos puede escribirse (excepto los archivos que usa el sistema operativo). El uso del sistema de archivos se considera dentro del uso de memoria de una función.

Tu función puede interactuar con el sistema de archivos mediante métodos estándar en cada lenguaje de programación.

Nota: En el entorno de ejecución de funciones de Cloud Run, el directorio raíz del código fuente de tu función es el directorio de trabajo actual (.), con la excepción de los entornos de ejecución de Go, en los que el directorio raíz del código fuente de la función está por debajo del directorio de trabajo actual en ./serverless_function_source_code.

Red

Tu función puede acceder a la red pública de Internet con métodos estándar en cada lenguaje de programación, ya sea a través de bibliotecas integradas que ofrece el entorno de ejecución o bibliotecas de terceros que incluyas como dependencias.

Vuelve a usar las conexiones de red en las invocaciones de funciones, como se describe en Optimiza las Herramientas de redes. Sin embargo, ten en cuenta que el sistema podría cerrar una conexión que permanece 10 minutos sin usarse y que los intentos adicionales para usar una conexión cerrada podrían dar como resultado un error de “restablecimiento de la conexión”. El código debe usar una biblioteca que administre bien las conexiones cerradas o que las administre de manera explícita si usa construcciones de herramientas de redes de nivel inferior.

Aislamiento de funciones

Cada función implementada se aísla de todas las demás funciones, incluso de aquellas implementadas desde el mismo archivo fuente. En particular, no comparten memoria, variables globales, sistemas de archivos ni otros estados.

Para compartir datos entre las funciones implementadas, puedes usar servicios como Memorystore, Datastore, Firestore o Cloud Storage. De manera alternativa, puedes invocar una función desde otra con los activadores apropiados y pasar los datos necesarios. Por ejemplo, realiza una solicitud HTTP al extremo de una función de HTTP o publica un mensaje en un tema de Pub/Sub para activar una función de Pub/Sub.