For example, the current reference count of the container image can be recorded, that is, the number of times the image is referenced by containers. When the reference is cleared, the current image is considered to be useless. A selection can be made as to whether to delete the image when the last container that references the image exits according to configuration. For example, in some scenarios, a large number of identical short-term tasks, such as some data calculation tasks, may be run, and they may use the same image. In this case, when the current reference count of the image drops to zero, the same tasks may be rerun at a subsequent time. Therefore, in this application scenario, a preset deletion policy can be configured not to delete the image when the current reference count reduces to zero in order to speed up the task startup. In implementations, for another example, the duration for which the current reference count is cleared can be timed, and the image can be deleted when determining that it has not been used for a long time. For another example, in some scenarios, it is generally not often to run a large number of the same short-term tasks, that is, after the tasks of the containers end, the same tasks may not be run immediately. Therefore, a preset deletion policy can be configured as deleting the image when the current reference count reduces to zero to reduce memory consumption.

It needs to be noted that when the methods provided in the embodiments of the present disclosure are applied in an actual scenario, a corresponding interactive interface may be provided according to the requirements of the implementation scenario. For example, an option for a user to select an accelerated startup of a secure container may be provided in the interactive interface, and the methods provided in the embodiments of the specification may be applied to accelerate the startup of the secure container according to the user's selection. For another example, a user may be provided with an input method of configuration information for setting a deletion policy in the interactive interface, which may be various types of input methods such as text or voice. For example, configuration information of deletion polic(ies) of the user can be received through the interactive interface to determine whether a task performed by a secure container is a short-term task, whether an image needs to be deleted when the last container that references the image exits, or an allowable time length of the duration that the reference count is zero, etc.

In the following, in conjunction with FIG. 2, using the method for starting a secure container provided in the present disclosure to quickly start a container in a pod (the smallest scheduling unit in the kubernetes system) of a secure container is used as an example, to further explain the method for starting a secure container. FIG. 2 shows a schematic diagram of a specific framework of a method for starting a secure container provided by an embodiment of the present disclosure.

A block image driver as shown in FIG. 2 is an image driver of a block device and a module in a container engine, which is used to convert a container image into a corresponding block device format. The block image driver can run on a host machine, providing a block device storage method for container images, and being responsible for transferring the container images to a secure container. Data of a container image is stored in the host machine by the block image driver (which can be, for example, any form of a storage driver, regardless of whether the driver has the ability to support snapshots) in a form of a block device and is transmitted to a container in a read-only manner.

An image reference manager as shown in FIG. 2 can be used to record the current reference count of a container image. When the reference is cleared, the corresponding container image is considered to be useless. A selection can be made as to whether to delete the container image when the last container referencing the container image exits.

A merge (aggregation) module as shown in FIG. 2 can be used to select a storage medium in a guest kernel (virtual machine kernel) for a secure container to assign a read-write layer after the container receives a container image, and to provide a filesystem for the container after combining the container image with the read-write layer.

According to the above framework diagram, as shown in FIG. 2, a process of starting a container may include:

- (1) The block image driver (the storage driver of the block device) transfers a file including a path of a container image to a secure container.
- (2) The security container detects the transfer of the file, and an image reference manager updates the current reference count of the corresponding container image to determine whether it is the first reference, adds the container image to the security container as a block device if affirmative, and does not add it again if not.
- (3) When the container image is referenced for the first time, the merge module mounts a block device of the corresponding container image into a directory, records a path of the directory of the image, creates a read-write layer of a container in the storage medium, and then executes an actual aggregation operation. When the container image is not referenced for the first time, the merge module indexes to the path of the corresponding image directory, creates a read-write layer of a container in the storage medium, and then performs an actual aggregation operation.
- (4) After the merge module provides a file system of the container, the startup of the container is completed.

In the following, processing steps of the methods provided by the embodiments of the present disclosure are schematically described by using the startup of a container corresponding to an image A as an example. For example, a starting process of a container corresponding to an image A may include: transferring, by a block image driver, a including a path of the image A to a secure container. An image reference manager updates a current reference count of the image A. When the image A is referenced for the first time, such as when a “container A” as shown in FIG. 2 is started, a block device of the image A is added to a secure container, and the merge module can mount the block device of the image A as a directory and record a path of the directory of the image A. When the image A is not referenced for the first time, such as when a “container B” as shown in FIG. 2 is started, the merge module can directly obtain the path of the directory of the image A. For the container A, the merge module creates a read-write layer of the container A, such as a “containerA rw layer” as shown in FIG. 2, in a storage medium, and performs an aggregation operation of the path of the “containerA rw layer” and the path of the “image A”. For the container B, the merge module creates a read-write layer of the container B, such as a “containerB rw layer” as shown in FIG. 2, in the storage medium, and performs an aggregation operation of the path of the “containerB rw layer” and the path of the “image A”.

Processing of image B as shown in FIG. 2 is similar to that of image A, and will not be repeated herein.

According to the above processing process, it can be seen that different container images represent different tasks to run. After starting a pod of a secure container, a large number of high-performance containers can be quickly started inside the pod to run set tasks. When the pod starts a first container of a container image, no corresponding image layer exists inside the secure container, and the container image is passed into the container through an interface provided by the secure container. After the first container is started, since there is already a corresponding container image in the secure container when subsequent containers are started, and the current reference count of the container image is maintained inside the secure container to represent the container's reference to the image, the process of mounting the container image by the subsequent containers can be skipped when starting the containers corresponding to the container image, thus achieving the purpose of fast startup. For example, hundreds of containers can be started in seconds, which is very friendly to short-task applications.

It can be understood that the methods provided by the embodiments of the present disclosure can be applied to any scenario that needs to start multiple containers concurrently and quickly, such as scenarios of big data computing under systems such as kubernetes and meson, etc. For example, in a scenario where the methods provided by the embodiments of the present disclosure is applied to quickly start a container in a pod, a scheduling system of a kubernetes system can be used to create the container.

Corresponding to the foregoing method embodiments, the present disclosure also provides an exemplary apparatus for starting a secure container. FIG. 3 shows a schematic structural diagram of an apparatus 300 for starting a secure container provided by the embodiments of the present disclosure. As shown in FIG. 3, the apparatus 300 includes: an adding module 302, a first merge module 304, and a second merge module 306.

The adding module 302 may be configured to add a container image to a secure container in a read-only manner when starting a first container corresponding to the container image in the secure container.

The first merge module 304 may be configured to aggregate a read-write layer of the first container with the container image in the secure container to obtain a file system of the first container.

The second merge module 306 may be configured to aggregate a read-write layer of the second container with the added container image in the secure container when starting the second container corresponding to the container image in the secure container to obtain a file system of the second container.

Since the apparatus adds a container image into a secure container in a read-only manner when starting a first container corresponding to the container image in the secure container, aggregates a read-write layer of the first container with the container image in the secure container to obtain a file system of the first container, and aggregates a read-write layer of a second container with the added container image in the secure container when starting the second container corresponding to the container image in the secure container to obtain a file system of the second container, this apparatus therefore reuses resources by sharing read-only images and creating read-write layers of containers inside a secure container, thus avoiding additional processes to assist process 10 forwarding, saving memory consumption, and being more stable, and thereby realizing a quick start of a large number of containers in seconds.

FIG. 4 shows a schematic structural diagram of an apparatus 400 for starting a secure container provided by another embodiment of the present disclosure. As shown in FIG. 4, the apparatus 400 further includes: a read-write layer creation module 308, which can be configured to create a read-write layer from a directory of a storage medium in a virtual machine kernel of the secure container according to a unique identifier of the container when starting the container and assign thereof to the container.

In one or more embodiments of the present disclosure, considering maximally reusing resources, it is possible to detect a transfer of a container image to a secure container. For the same container image, only the first transfer detected is added, and subsequent transfers detected can be shared. Specifically, for example, the apparatus may further include: a detection module 310 and an image determination module 312.

The detection module 310 may be configured to detect a transfer of the container image to the secure container.

The image determination module 312 may be configured to determine whether the container image has been added to the secure container when detecting the transfer of the container image to the secure container.

The adding module 302 may be configured to add the container image to the secure container in the read-only manner if a determination of the image determination module 312 is negative.

The second merge module 306 may be configured to aggregate the read-write layer of the second container with the added container image in the secure container to obtain the file system of the second container if the determination of the image determination module 312 is positive.

In order to facilitate determine whether the container image has been added to the secure container, in one or more embodiments of the present disclosure, such determination is made based on the current number of references to the container image. Specifically, for example, as shown in FIG. 4, the image determination module 312 may include: a reference count determination submodule 3122, a first reference determination module 3124, and a re-referencing determination module 3126.

The reference count determination submodule 3122 may be configured to determine whether a current reference count corresponding to the container image is an initial value.

The first reference determination module 3124 may be configured to determine that the container image has not been added to the secure container if being the initial value.

The re-reference determination module 3126 may be configured to determine that the container image has been added to the secure container if being not the initial value.

The current reference count corresponding to the container image is updated correspondingly when the container image is used by any container or when a task of any container using the container image ends.

In one or more embodiments of the present disclosure, the adding module 302 may be configured to add a block device of the container image to the secure container in a read-only manner through a storage driver of a block device in a host machine. The storage driver of the block device in the host machine stores the container image in a form of a block device according to a block device type defined in a configuration file of the secure container.