Entorno de ejecución de Cloud Functions

Cloud Run Functions se ejecuta en un entorno sin servidores y completamente administrado en el que Google administra 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

Cloud Run Functions admite varios entornos de ejecución de lenguajes. Cada uno incluye un conjunto estándar de paquetes de sistemas, así como las herramientas y bibliotecas necesarias para ese lenguaje. Necesitarás el valor del ID del entorno de ejecución si implementas funciones desde la línea de comandos o con Terraform.

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 su configuración. Para obtener más información sobre las actualizaciones del entorno de ejecución, consulta Protege tu función de Cloud Run.

Node.js

Entorno de ejecución	Generación	Entorno	ID del entorno de ejecución	Imagen del entorno de ejecución
Node.js 24 (versión preliminar)	2ª gen.	Ubuntu 24.04	nodejs24	us-central1-docker.pkg.dev/serverless-runtimes/google-24-full/runtimes/nodejs24
Node.js 22	1ª y 2ª gen.	Ubuntu 22.04	nodejs22	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/nodejs22
Node.js 20	1ª y 2ª gen.	Ubuntu 22.04	nodejs20	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/nodejs20
Node.js 18	1ª y 2ª gen.	Ubuntu 22.04	nodejs18	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/nodejs18
Node.js 16	1ª y 2ª gen.	Ubuntu 18.04	nodejs16	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/nodejs16
Node.js 14	1ª y 2ª gen.	Ubuntu 18.04	nodejs14	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/nodejs14
Node.js 12	1ª y 2ª gen.	Ubuntu 18.04	nodejs12	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/nodejs12
Node.js 10	1ª y 2ª gen.	Ubuntu 18.04	nodejs10	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/nodejs10
Node.js 8	1ª y 2ª gen.	Ubuntu 18.04	nodejs8	Retirada
Node.js 6	1ª y 2ª gen.	Ubuntu 18.04	nodejs6	Retirada

Python

Entorno de ejecución	Generación	Entorno	ID del entorno de ejecución	Imagen del entorno de ejecución
Python 3.13	2ª gen.	Ubuntu 22.04	python313	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/python313
Python 3.12	1ª y 2ª gen.	Ubuntu 22.04	python312	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/python312
Python 3.11	1ª y 2ª gen.	Ubuntu 22.04	python311	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/python311
Python 3.10	1ª y 2ª gen.	Ubuntu 22.04	python310	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/python310
Python 3.9	1ª y 2ª gen.	Ubuntu 18.04	python39	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/python39
Python 3.8	1ª y 2ª 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 del entorno de ejecución	Imagen del entorno de ejecución
Go 1.25	2ª gen.	Ubuntu 22.04	go125	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/go125
Go 1.24	2ª gen.	Ubuntu 22.04	go124	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/go124
Go 1.23	2ª gen.	Ubuntu 22.04	go123	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/go123
Go 1.22	2ª gen.	Ubuntu 22.04	go122	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/go122
Go 1.21	1ª y 2ª gen.	Ubuntu 22.04	go121	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/go121
Go 1.20	1ª y 2ª gen.	Ubuntu 22.04	go120	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/go120
Go 1.19	1ª y 2ª gen.	Ubuntu 22.04	go119	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/go119
Go 1.18	1ª y 2ª gen.	Ubuntu 22.04	go118	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/go118
Go 1.16	1ª y 2ª gen.	Ubuntu 18.04	go116	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/go116
Go 1.13	1ª y 2ª gen.	Ubuntu 18.04	go113	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/go113
Go 1.11	1ª y 2ª gen.	Ubuntu 18.04	go111	Retirada

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 clave 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 del entorno de ejecución	Imagen del entorno de ejecución
Java 25 (versión preliminar)	2ª gen.	Ubuntu 24.04	java25	us-central1-docker.pkg.dev/serverless-runtimes/google-24-full/runtimes/java25
Java 21	2ª gen.	Ubuntu 22.04	java21	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/java21
Java 17	1ª y 2ª gen.	Ubuntu 22.04	java17	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/java17
Java 11	1ª y 2ª 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 del entorno de ejecución	Imagen del entorno de ejecución
Ruby 3.4	2ª gen.	Ubuntu 22.04	ruby34	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/ruby34
Ruby 3.3	1ª y 2ª gen.	Ubuntu 22.04	ruby33	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/ruby33
Ruby 3.2	1ª y 2ª gen.	Ubuntu 22.04	ruby32	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/ruby32
Ruby 3.0	1ª y 2ª gen.	Ubuntu 18.04	ruby30	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/ruby30
Ruby 2.7	1ª y 2ª gen.	Ubuntu 18.04	ruby27	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/ruby27
Ruby 2.6	1ª y 2ª 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 del entorno de ejecución	Imagen del entorno de ejecución
PHP 8.4	2ª gen.	Ubuntu 22.04	php84	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/php84
PHP 8.3	2ª gen.	Ubuntu 22.04	php83	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/php83
PHP 8.2	1ª y 2ª gen.	Ubuntu 22.04	php82	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/php82
PHP 8.1	1ª y 2ª gen.	Ubuntu 18.04	php81	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/php81
PHP 7.4	1ª y 2ª 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 del 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	1ª y 2ª gen.	Ubuntu 22.04	dotnet6	us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/dotnet6
.NET Core 3	1ª y 2ª gen.	Ubuntu 18.04	dotnet3	us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/dotnet3

Comportamiento del escalado automático

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

Cloud Run Functions administra las solicitudes entrantes asignándolas a las instancias de tu función. Según el volumen de solicitudes, así como la cantidad de instancias de funciones existentes, Cloud Run Functions puede asignar una solicitud a una instancia existente o crear una nueva.

En los casos en que el volumen de solicitudes entrantes exceda la cantidad de instancias existentes, Cloud Run Functions puede iniciar varias instancias nuevas para administrarlas. Este comportamiento del escalado automático permite que Cloud Run Functions administre muchas solicitudes en paralelo, cada una con una instancia diferente de la función.

Nota: Un aumento muy rápido del tráfico entrante puede provocar 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 fila de pendientes mientras se crean instancias nuevas. Configurar la 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 Soluciona problemas de Cloud Functions para obtener más información.

En algunos casos, no se recomienda el escalamiento ilimitado. Para solucionar esto, Cloud Run Functions permite establecer 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 las funciones, estas deben ser sin estado. La invocación de una función no debe depender del estado de la memoria configurado por una invocación anterior. Las invocaciones pueden controlarse con 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 entre las invocaciones, la función debe usar un servicio como Memorystore, Datastore, Firestore o Cloud Storage para conservar los datos. Consulta las bases de datos deGoogle Cloud y los productos de almacenamiento deGoogle 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 la administración 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.

Cloud Run Functions (1ª gen.)

En Cloud Run Functions (1ª gen.), cada instancia de una función administra 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 asignes.

Dado que diferentes instancias de funciones procesan solicitudes simultáneas en Cloud Run Functions (1ª gen.), no comparten variables ni memoria local. Consulta Sin estado y Vida útil de las instancias de funciones 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 escalarse 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 el código. Las solicitudes que incluyen el inicio de instancias de funciones, llamadas inicios en frío, pueden ser más lentas que las que se enrutan a instancias de funciones existentes. Sin embargo, si la 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 reiniciar el entorno de la función.

Si el código de la 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 más inicios en frío, lo que da como resultado una latencia más alta, por lo que recomendamos capturar excepciones y, en lo posible, evitar la finalización del proceso actual.

Nota: En la 1ª gen., la cantidad de memoria otorgada a una función afecta la asignación de CPU, lo que, a su vez, puede afectar la hora del inicio en frío (consulta precios). Si bien esto también ocurre de forma predeterminada en la 2ª gen., tienes la opción de configurar la asignación de CPU por separado de la memoria.

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

Vida útil de las instancias de funciones

Por lo general, las instancias de funciones son resilientes y se reutilizan en invocaciones de funciones posteriores, a menos que se reduzca verticalmente su escala debido a la falta de tráfico en curso o a la falla de la función. Esto significa que, cuando la ejecución de una función finaliza, la misma instancia de función puede controlar otra invocación.

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

Alcance de la función en comparación con el alcance global

La invocación de una sola función hace que se ejecute solo el cuerpo de la función declarada como el punto de entrada. El alcance global del código fuente de la 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 con el objetivo de optimizar el rendimiento, pero no debes depender del estado establecido en el alcance global por 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 ni de su tiempo, ya que pueden variar según la actividad del escalado automático.

Cronograma de ejecución de funciones

Las funciones tienen acceso a los recursos que tienen asignados (como la memoria y CPU) solo durante su período de ejecució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 la función de forma correcta y evitar ejecutar cualquier otro código. Consulta Funciones de HTTP, Funciones en segundo plano y Funciones de CloudEvent para obtener orientación.

La ejecución de la función también está sujeta al tiempo de espera de esta última. Consulta Tiempo de espera de las funciones 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 alcance global durante la inicialización, ya que se ejecutarían 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, Cloud Run Functions 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 la función puede invocarse para un único evento depende del tipo de función:

• Las funciones de HTTP se invocan una vez como máximo. Esto se debe al carácter síncrono de las llamadas HTTP, lo que implica que se mostrará cualquier error que ocurra durante la invocación de la función sin reintentos. 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 basadas en eventos se invocan una vez como mínimo. Esto se debe al carácter asíncrono de los eventos, en los que no hay ningún emisor que espere por la respuesta. En extrañas circunstancias, el sistema podría invocar una función basada en eventos más de una vez para garantizar la entrega 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 los reintentos en caso de error para esa función.

Para asegurarte de que la función se comporte de forma correcta en los reintentos de ejecución, debes implementarla, lo que la vuelve idempotente y permite que se produzcan los resultados esperados (y sus 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 esperado incluso si el emisor vuelve a intentar las llamadas al extremo de la función de HTTP. Consulta Reintenta las funciones basadas en eventos para obtener más información sobre cómo hacer que la función se vuelva idempotente.

Memoria y sistema de archivos

Cada función tiene una cierta cantidad de memoria asignada para su uso, la cual se puede configurar durante la implementación. Consulta Configura la memoria para obtener más información.

El entorno de ejecución de la función incluye un sistema de archivos en la memoria que contiene los archivos de origen y los directorios implementados con la función (consulta Estructura el código fuente). El directorio que contiene los archivos de origen solo se puede leer, pero el resto del sistema de archivos se puede escribir (excepto los archivos que usa el sistema operativo). El uso del sistema de archivos se tiene en cuenta para el uso de memoria de una función.

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

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

Red

La función puede acceder al Internet público con métodos estándar en cada lenguaje de programación, ya sea a través de las bibliotecas integradas que ofrece el entorno de ejecución o de bibliotecas externas que incluyas como dependencias.

Intenta reutilizar las conexiones de red en las invocaciones de funciones. Sin embargo, ten en cuenta que el sistema podría cerrar una conexión que no se usa durante 10 minutos y que los intentos posteriores de usar una conexión cerrada podrían generar un error de “restablecimiento de la conexión”. El código debe usar una biblioteca que administre bien las conexiones cerradas o que lo haga de manera explícita si usa constructos de redes de nivel inferior.

Aislamiento de funciones

Cada función implementada se aísla del resto, 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. Como alternativa, puedes invocar una función desde otra con los activadores apropiados y pasando 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.