Container

A container allows you to run in Yandex Cloud the application contained in a Docker image. After creating a container revision, you can invoke it:

• Over HTTPS.
• Using a trigger.
• Using a Yandex API Gateway extension.

Learn more about invoking a container.

Container revisionContainer revision

You can only create a container revision from a Docker image uploaded to a registry in Yandex Container Registry. No other registries are supported. The revision contains all the information you need to run the container.

Possible revision statuses include:

• Active: Active
• Obsolete: Obsolete

Invoking a container triggers the active revision. By default, it is the latest revision, but you have the option to change the active revision. When you create a new revision, it automatically becomes active.

You need to create a new revision:

• When you upload a new Docker image version to Yandex Container Registry.
• When you modify revision settings.

If a registry or repository containing the Docker image is not public, you need to specify a service account with permission to download the Docker image in the revision settings. For example, the container-registry.images.puller role to the folder or registry containing the Docker image.

If a service account is specified in the revision settings, the user or the service account creating the revision must have the iam.serviceAccounts.user role. It confirms the right to use the service account.

Container instanceContainer instance

A container instance is a virtual machine with:

• A loaded operating system.
• A running bootstrap process.
• Initialized Serverless Containers runtime environment components.
• A loaded and initialized user application.

Serverless Containers uses internal rules to dynamically manage the virtual machine lifecycle. These rules may change as the service evolves.

Creating an instanceCreating an instance

When a container is called, one of these two events takes place:

• A new container instance is started to process the call.
• The call is redirected to an already running container instance, either one that was not terminated after processing the previous calls or one that was created by the service in background before the user's request came in.

When deciding whether to start a new instance, Serverless Containers considers the following:

• Load on already running instances.
• Number of calls awaiting processing.
• Container scaling settings.
• Quota usage.

The process of starting an instanceThe process of starting an instance

1. Serverless Containers selects a service cluster node taking into consideration the resources (CPU, RAM, network), loaded user app images, and other factors affecting the duration of starting an instance. Priority is given to the node that ensures the shortest start. Start duration time may vary. Thus, it will be shorter if the node has cached the user app image from the previous call.
2. On the cluster node thus selected, a virtual machine starts. The service configures the virtual machine's network interfaces, allocates CPU and RAM resources, and connects disk images containing the operating system and user app.
3. The virtual machine starts the Linux core and the bootstrap process.
4. Following initialization, the bootstrap process starts the user app.

Instance operationInstance operation

Once created, the instance can process calls. Calls sent to the instance enter a queue from where they are taken for execution. The result of call processing is forwarded to the sender. When there are no calls left, the instance stays in RAM for a variable time that depends on factors like container execution timeout.

Suspending an instanceSuspending an instance

If the new instance receives no new calls for a certain period of time, it gets suspended. The operating system and the running processes remain in RAM but are not processed by the CPU. The instance resumes operation in the following cases:

• It gets a new call.
• A service cycle is initiated to get the instance up and running again, e.g., to update timers or run maintenance tasks of the guest OS.
• Prior to terminating the instance.

Terminating an instanceTerminating an instance

Serverless Containers decides to terminate a running instance based on a number of factors, for example:

• There are no new calls for an extended period of time.
• Container execution timeout has been reached.
• An unrecoverable runtime error was encountered.

In some cases, the service may forcibly terminate a container instance. In which case the user app will get a notification about the upcoming forced termination.

Container operation modeContainer operation mode

Serverless Containers supports the following container operation modes:

Operation mode	How it works	Result returned when a container is invoked successfully	Data on the HTTP request to a container	Constraints
HTTP server	HTTP requests to the container are received by an HTTP server, which must be running on the port specified in the PORT environment variable. Serverless Containers sets the variable value automatically.	An HTTP response received from the HTTP server. When forwarded to the container, some HTTP response headers get modified	Provided in an HTTP request to the HTTP server	—
Commands	Each HTTP request to the container initiates the ENTRYPOINT instructions from a Dockerfile or the commands set when creating a revision. If the commands are set, they will override the ENTRYPOINT instructions from Dockerfile	Response code 200 and termination code in the X-Task-Exit-Code response header	Specified in the file located at the path from theREQUEST_PATH environment variable	Maximum number of concurrent requests to a single container instance: 1

Scaling a containerScaling a container

A container instance processes one container invocation at a single point in time. If the container is invoked faster than the instance can process the request, the service scales the container by running additional instances of it. This ensures concurrent request processing.

To reduce the number of cold starts, Serverless Containers creates container instances in the background, not for the purpose of processing user requests. The number of instances created this way does not exceed the quota.

In addition, in Serverless Containers, you can change the maximum number of concurrent invocations of a single container instance and specify the number of provisioned container instances.

Scaling settings take effect within five minutes after being configured.

Provisioned instancesProvisioned instances

A provisioned instance is a container instance that is guaranteed not to have a cold start when you run it. In the provisioned instance before the container is invoked:

• Serverless Containers runtime environment components are initialized.
• The user application is loaded and initialized.

The initialization and operation processes of a simple and provisioned container instances are identical. A provisioned instance is remains suspended and does not consume CPU unit it begins processing a call.

Downtime of provisioned instances and runtime of the container in them are charged additionally.

If the number of container invocations exceeds the number of provisioned instances, Serverless Containers scales the container within the quotas, but unprovisioned instances have a cold start when they are first started.

Provisioned instances count towards the following quotas even when they are not running:

• Number of container instances per availability zone.
• Total RAM for all running container instances per availability zone.
• Number of provisioned container instances per cloud.

Use casesUse cases

• Developing CRUD APIs for a movie service
• Setting up a Yandex Managed Service for PostgreSQL connection from a container in Serverless Containers
• Running a containerized app in Yandex Serverless Containers
• Developing functions in Functions Framework and deploying them in Yandex Serverless Containers

See alsoSee also

• Creating a container revision
• Adding scaling settings