Entorno de ejecución de Cloud Functions

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

Cloud Run Functions 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 1ª y 2ª 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 Cloud Run Functions.

Node.js

Entorno de ejecución	Generación	Entorno	ID de entorno de ejecución	Imagen del entorno de ejecución
Node.js 22 (solo vista previa)	2ª gen.	Ubuntu 22.04	nodejs22	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/nodejs22
Node.js 20	1st gen, 2nd gen	Ubuntu 22.04	nodejs20	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/nodejs20
Node.js 18	1st gen, 2nd gen	Ubuntu 22.04	nodejs18	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/nodejs18
Node.js 16	1st gen, 2nd gen	Ubuntu 18.04	nodejs16	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/nodejs16
Node.js 14	1st gen, 2nd gen	Ubuntu 18.04	nodejs14	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/nodejs14
Node.js 12	1st gen, 2nd gen	Ubuntu 18.04	nodejs12	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/nodejs12
Node.js 10	1st gen, 2nd gen	Ubuntu 18.04	nodejs10	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/nodejs10
Node.js 8	1st gen, 2nd gen	Ubuntu 18.04	nodejs8	Fuera de servicio
Node.js 6	1st gen, 2nd gen	Ubuntu 18.04	nodejs6	Fuera de servicio

Python

Entorno de ejecución	Generación	Entorno	ID de entorno de ejecución	Imagen del entorno de ejecución
Python 3.12	1st gen, 2nd gen	Ubuntu 22.04	python312	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/python312
Python 3.11	1st gen, 2nd gen	Ubuntu 22.04	python311	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/python311
Python 3.10	1st gen, 2nd gen	Ubuntu 22.04	python310	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/python310
Python 3.9	1st gen, 2nd gen	Ubuntu 18.04	python39	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/python39
Python 3.8	1st gen, 2nd gen	Ubuntu 18.04	python38	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/python38
Python 3.7	1ª gen.	Ubuntu 18.04	python37	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/python37

Go

Entorno de ejecución	Generación	Entorno	ID de entorno de ejecución	Imagen del entorno de ejecución
Go 1.22	2ª gen.	Ubuntu 22.04	go122	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/go122
Go 1.21	1st gen, 2nd gen	Ubuntu 22.04	go121	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/go121
Go 1.20	1st gen, 2nd gen	Ubuntu 22.04	go120	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/go120
Go 1.19	1st gen, 2nd gen	Ubuntu 22.04	go119	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/go119
Go 1.18	1st gen, 2nd gen	Ubuntu 22.04	go118	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/go118
Go 1.16	1st gen, 2nd gen	Ubuntu 18.04	go116	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/go116
Go 1.13	1st gen, 2nd gen	Ubuntu 18.04	go113	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/go113
Go 1.11	1st gen, 2nd gen	Ubuntu 18.04	go111	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	Generación	Entorno	ID de entorno de ejecución	Imagen del entorno de ejecución
Java 21	2ª gen.	Ubuntu 22.04	java21	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/java21
Java 17	1st gen, 2nd gen	Ubuntu 22.04	java17	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/java17
Java 11	1st gen, 2nd gen	Ubuntu 18.04	java11	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/java11

Ruby

Entorno de ejecución	Generación	Entorno	ID de entorno de ejecución	Imagen del entorno de ejecución
Ruby 3.3	1st gen, 2nd gen	Ubuntu 22.04	ruby33	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/ruby32
Ruby 3.2	1st gen, 2nd gen	Ubuntu 22.04	ruby32	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/ruby32
Ruby 3.0	1st gen, 2nd gen	Ubuntu 18.04	ruby30	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/ruby30
Ruby 2.7	1st gen, 2nd gen	Ubuntu 18.04	ruby27	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/ruby27
Ruby 2.6	1st gen, 2nd gen	Ubuntu 18.04	ruby26	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/ruby26

PHP

Entorno de ejecución	Entorno	Generación	ID de entorno de ejecución	Imagen del entorno de ejecución
PHP 8.3	2ª gen.	Ubuntu 22.04	php83	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/php83
PHP 8.2	1st gen, 2nd gen	Ubuntu 22.04	php82	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/php82
PHP 8.1	1st gen, 2nd gen	Ubuntu 18.04	php81	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/php81
PHP 7.4	1st gen, 2nd gen	Ubuntu 18.04	php74	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/php74

.NET Core

Entorno de ejecución	Generación	Entorno	ID de entorno de ejecución	Imagen del entorno de ejecución
.NET Core 8	2ª gen.	Ubuntu 22.04	dotnet8	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/dotnet8
.NET Core 6	1st gen, 2nd gen	Ubuntu 22.04	dotnet6	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/dotnet6
.NET Core 3	1st gen, 2nd gen	Ubuntu 18.04	dotnet3	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/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 Cloud Functions 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

Cloud Run Functions (2ª gen.)

Cloud Run Functions (2ª gen.) admite 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 Cloud Run Functions.

Nota: En la 1ª gen., la cantidad de memoria otorgada a una función afecta la asignación de CPU, que, a su vez, puede afectar la hora de inicio en frío (consulta precios). Si bien esto también es así en la 2nd gen de forma predeterminada, en la 2nd gen, 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 controlada por 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.