Container
Containers enable you to launch an application in a Docker image in Yandex Cloud. 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 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 needed to run the container.
Possible revision statuses include:
Active: ActiveObsolete: 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.
Note
To ensure the integrity of version links, you cannot update or delete container revisions.
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 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 the 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 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 container instances. This ensures concurrent request processing.
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 instances
A provisioned instance is a container instance that, when started, is guaranteed not to have a cold start. In the provisioned instance before the container is invoked:
- Serverless Containers runtime environment components are initialized.
- The user application is loaded and initialized.
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.