A container image management method, device, equipment and storage medium

By creating virtual disk files on cluster file systems such as ocfs2 and decompressing container images onto them, and then using reflink to create snapshots, the problem of frequent locking in container image storage is solved, improving read and write efficiency and high availability.

CN115586872BActive Publication Date: 2026-01-27LANGCHAO ELECTRONIC INFORMATION IND CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202211412172.0
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-11-11
Publication Date
2026-01-27
Estimated Expiration
2042-11-11

AI Technical Summary

Technical Problem

Existing technologies involve numerous locking operations when storing container images on cluster file systems such as OCFS2, resulting in low read/write performance of image files/directories. Furthermore, the devmapper method is not suitable for file system storage.

Method used

By creating a virtual disk file as the carrier of the container image, decompressing the container image file to the virtual disk, and creating a snapshot using reflink, frequent locking operations are avoided, and the multi-node concurrent access characteristics of the cluster file system are utilized.

Benefits of technology

It improves the read and write efficiency of container image files and enhances the high availability of containers, avoiding the frequent locking issues of traditional methods.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115586872B_ABST
    Figure CN115586872B_ABST
Patent Text Reader

Abstract

The application discloses a container image management method and device, equipment and storage medium, and relates to the technical field of cloud computing. The method comprises the following steps: creating a virtual disk file according to container information of a container; obtaining a target container image file and analyzing the target container image file to obtain compressed files of each layer in the target container image file; decompressing the compressed file of the current layer in the target container image file to the virtual disk file and performing corresponding processing, then creating a snapshot of the virtual disk file obtained after processing in a ref link mode, and determining a target virtual disk file when the compressed files of each layer in the target container image file are all decompressed; and mounting the target virtual disk file according to the container type of the container, so that the target virtual disk file is used as the root directory of the target container. Through the technical scheme, the image reading and writing efficiency can be improved, and the high availability of the container can be improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, and in particular to a container image management method, apparatus, device, and storage medium. Background Technology

[0002] With the development of cloud computing technology, Kubernetes (K8s) and related container technologies have been widely used. For container image storage, the open-source community provides various implementation methods, such as OverlayFS and devmapper. However, these image management methods are not perfectly suitable for certain user scenarios. For example, when container images are stored on cluster file systems like OCFS2, the OverlayFS management method results in a large number of small files and directories. When stored on the OCFS2 file system, this leads to numerous locking operations, causing slow container startup and low read / write performance of image files / directories. The devmapper method, on the other hand, requires underlying creation based on raw devices and is not suitable for storing container images on a file system.

[0003] In summary, how to avoid generating a large number of locking operations when storing container images on cluster file systems such as ocfs2 is a problem that needs to be solved. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a container image management method, apparatus, device, and storage medium that can avoid generating a large number of locking operations when storing container images on cluster file systems such as OCFS2. The specific solution is as follows:

[0005] Firstly, this application discloses a container image management method, including:

[0006] Create a virtual disk file based on the container's container information;

[0007] Obtain the target container image file and parse the target container image file to obtain the compressed files of each layer in the target container image file;

[0008] The compressed file of the current layer in the target container image file is decompressed to the virtual disk file and processed accordingly. Then, a snapshot is created on the processed virtual disk file using the reflink method. After all the compressed files of each layer in the target container image file are decompressed, the target virtual disk file is determined.

[0009] The target virtual disk file is mounted according to the container type of the container, so that the target virtual disk file is used as the root directory of the target container.

[0010] Optionally, creating a virtual disk file based on the container's container information includes:

[0011] Get the root directory space size information of the container;

[0012] Based on the root directory space size information, a virtual disk file in RAW format of the corresponding size is created using preset disk creation instructions.

[0013] Optionally, after creating the virtual disk file based on the container's container information, the method further includes:

[0014] The virtual disk file is formatted, and a file system is created on the formatted virtual disk file.

[0015] Optionally, the step of decompressing the compressed file of the current layer in the target container image file to the virtual disk file and performing corresponding processing, and then creating a snapshot of the processed virtual disk file using the reflink method, and determining the target virtual disk file after all the compressed files of each layer in the target container image file have been decompressed, includes:

[0016] The virtual disk file is mounted in loop mode, and the compressed file of the current layer in the target container image file is decompressed to the file system to obtain the first virtual disk file;

[0017] The file system is unloaded, and then a snapshot of the first virtual disk file is created using the reflink method to obtain the second virtual disk file;

[0018] Determine whether the data in the second disk file is the data of all layers in the target image file. If so, the second disk file is identified as the target virtual disk file. Otherwise, the second disk file is used as the current virtual disk file. Then, repeat the steps of mounting the virtual disk file in loop mode and decompressing the compressed file of the current layer in the target container image file to the file system until the data in the second disk file includes the data of all layers in the target image file. Then, the second disk file is identified as the target virtual disk file.

[0019] Optionally, mounting the target virtual disk file according to the container type of the container, so as to use the target virtual disk file as the root directory of the target container, includes:

[0020] If the container type is a traditional Docker container or a runc container, the target virtual disk file is mounted in loop mode so that the target virtual disk file is used as the root directory of the target container.

[0021] Optionally, mounting the target virtual disk file according to the container type of the container, so as to use the target virtual disk file as the root directory of the target container, includes:

[0022] If the container type is a Kata container based on lightweight virtualization, the target virtual disk file is added to the Kata container via virio-blk or virtio-scsi so that the target virtual disk file is used as the root directory of the target container.

[0023] Optionally, mounting the target virtual disk file according to the container type of the container, so as to use the target virtual disk file as the root directory of the target container, includes:

[0024] Once the container starts, the corresponding target virtual disk file is located based on the target container image file, and a snapshot is created on the target virtual disk file using the reflink method to obtain a temporary snapshot file;

[0025] The temporary snapshot file is mounted according to the container type of the container so that the temporary snapshot file is used as the root directory of the target container.

[0026] Secondly, this application discloses a container image management device, comprising:

[0027] The virtual disk file creation module is used to create virtual disk files based on the container information of the container;

[0028] The target container image file acquisition module is used to acquire the target container image file and parse the target container image file to obtain the compressed files of each layer in the target container image file;

[0029] The target virtual disk file determination module is used to decompress the compressed file of the current layer in the target container image file to the virtual disk file and perform corresponding processing. Then, a snapshot is created on the processed virtual disk file using the reflink method. After all the compressed files of each layer in the target container image file are decompressed, the target virtual disk file is determined.

[0030] The target virtual disk file mounting module is used to mount the target virtual disk file according to the container type of the container, so as to use the target virtual disk file as the root directory of the target container.

[0031] Thirdly, this application discloses an electronic device including a processor and a memory; wherein the memory is used to store a computer program, which is loaded and executed by the processor to implement the container image management method as described above.

[0032] Fourthly, this application discloses a computer-readable storage medium for storing a computer program; wherein the computer program, when executed by a processor, implements the container image management method as described above.

[0033] This application provides a container image management method. First, a virtual disk file is created based on the container information. Then, a target container image file is obtained and parsed to obtain the compressed files of each layer within the target container image file. The compressed file of the current layer in the target container image file is decompressed to the virtual disk file and processed accordingly. A snapshot is then created on the processed virtual disk file using reflink. Once all compressed files in the target container image file have been decompressed, the target virtual disk file is determined. The target virtual disk file is mounted according to the container type of the container, so that it serves as the root directory of the target container. As can be seen, by creating a virtual disk file as the carrier of the container image, and then decompressing the compressed files of each layer of the target container image to be used to the virtual disk file, the container image is transferred to the virtual disk file. Subsequent file and directory creation, reading, and writing under the container's root directory are all performed within the virtual disk file. Furthermore, this method improves upon traditional container image storage methods based on reflink, ultimately forming the container's root directory. Compared to traditional container image storage methods, it avoids the frequent locking issues caused by file / directory operations when using traditional overlay image management on the OCFS2 file system, improves the efficiency of container image file reading and writing, and can leverage the concurrent access characteristics of multiple nodes in the cluster file system to improve container high availability.

[0034] In addition, the container image management device, equipment and storage medium provided in this application correspond to the above-mentioned container image management method and have the same effect. Attached Figure Description

[0035] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0036] Figure 1This is a flowchart of a container image management method disclosed in this application;

[0037] Figure 2 This is a schematic diagram of a container image management method disclosed in this application;

[0038] Figure 3 This application discloses a specific container image management method flowchart;

[0039] Figure 4 This is a schematic diagram of the structure of a container image management device disclosed in this application;

[0040] Figure 5 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0041] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0042] Currently, existing container image management methods are not suitable for cluster file systems such as ocfs2. For example, the OverlayFS management method has a large number of small files and directories, which will generate a lot of locking operations when stored on the ocfs2 file system, resulting in low image file read and write performance. The devmapper method requires the underlying creation based on raw devices and is not suitable for storing container images on the file system.

[0043] To address this, this application provides a container image management solution that avoids generating a large number of locking operations when storing container images on cluster file systems such as ocfs2.

[0044] This invention discloses a container image management method, see [link to relevant documentation]. Figure 1 As shown, the method includes:

[0045] Step S11: Create a virtual disk file based on the container information of the container.

[0046] In this embodiment, a virtual disk file is used as the carrier of the container image. Therefore, it is necessary to create a corresponding virtual disk file based on the container information. Specifically, the root directory space size information of the container is obtained; and a RAW format virtual disk file of the corresponding size is created according to the root directory space size information using a preset disk creation instruction.

[0047] In this embodiment, the default container root directory space size is first set, for example, 50G. Then, the qemu-img command is used to create a raw format virtual disk file of the corresponding size, assuming its name is image_layer0.raw.

[0048] Step S12: Obtain the target container image file and parse the target container image file to obtain the compressed files of each layer in the target container image file.

[0049] In this embodiment, after creating the virtual disk file, the virtual disk file is formatted, and a file system, such as an OCFS2 file system, is created on the formatted virtual disk file to facilitate subsequent writing of data to the file system corresponding to the virtual disk file. It should be noted that when the virtual disk file corresponding to the target container image file is stored on a cluster file system such as OCFS2, since OCFS2 and similar file systems can be accessed by multiple host nodes simultaneously, high availability features for the container can be further developed.

[0050] In this embodiment, the container image file to be used is determined, and it is used as the target container image file and parsed to obtain the compressed files of each layer in the target container image file. For example, suppose a container image file is divided into two layers, layer0 and layer1, where layer0 is the bottom layer of the container image and can be the basic system of the container; layer1 is the layer above layer0 and mainly stores the user's application or related executable files.

[0051] Step S13: Decompress the compressed file of the current layer in the target container image file to the virtual disk file and perform corresponding processing. Then, create a snapshot of the processed virtual disk file using the reflink method. After all the compressed files of each layer in the target container image file are decompressed, the target virtual disk file is determined.

[0052] In this embodiment, the created virtual disk file is mounted in loop mode, then the compressed file of the current layer of the container image is decompressed to the corresponding mount point in the file system, then the file system corresponding to the virtual disk is unmounted, and a snapshot of the virtual disk file is taken using reflink mode to generate a new image file.

[0053] As is understandable, reflink is a fast file copying method provided by the file system. Compared to traditional hard links, the newly copied file no longer shares metadata with the original file, but corresponds to different inodes. However, the file data is shared with the original file when the new file is created; data is only written to the new location via copy-on-write (COW) when the data in the new file changes. Reflink technology enables file snapshot functionality. It's important to note that when a file system is mounted on an existing directory, the files on the mounted file system become subdirectories and files of the mount point. If the mount point directory already contains files or subdirectories, they are not lost, but they become unusable until the mounted file system is unmounted. Therefore, after the current layer's compressed file is decompressed to the corresponding mount point in the file system, the file system corresponding to the virtual disk is unmounted, and then a snapshot is taken using reflink to generate a new virtual disk file. This new image file includes the data of the current layer of the target container image file.

[0054] In this embodiment of the application, after all the compressed files of each layer in the target container image file are decompressed, the target virtual disk file containing the data of each previous layer is determined, and finally the root directory of the container is formed.

[0055] Step S14: Mount the target virtual disk file according to the container type of the container, so that the target virtual disk file is used as the root directory of the target container.

[0056] In this embodiment, after the container starts, the corresponding target virtual disk file is located based on the container image, and a temporary reflink snapshot file is created based on the corresponding target virtual disk file. If multiple containers use the same container image, multiple reflink snapshots are created based on the same virtual disk file and provided to the containers for use. In this way, when a container uses this target virtual disk file, a temporary snapshot of the original target virtual disk file generated through reflink can be provided to multiple containers for use.

[0057] In this embodiment, for traditional Docker or Runc containers, the snapshot is mounted as the root directory of the container via a loop; while for Kata and other containers based on lightweight virtualization, the snapshot file is added to the Kata container via virtio-blk or virtio-scsi, recognized as a disk inside the Kata container, and mounted as the root directory of the container.

[0058] like Figure 2The diagram illustrates container image management. A raw format virtual disk file is created using the `qemu-img` command and then formatted and mounted. The compressed files of each layer of the container image are decompressed layer by layer into the corresponding mount directory of the virtual disk file, and a new reflink virtual disk snapshot is created for each layer. The virtual disk file `image_layerN.raw` contains the data from each previous layer. When a container needs to use the container image, the corresponding virtual disk file `image_layerN.raw` is located, and a temporary virtual disk file `image_container0_uuid.raw` is created based on `image_layerN.raw` using reflink. If the container is running on a lightweight virtualization-based Kata runtime, `image_container0_uuid.raw` is added to the Kata container using `virio-blk` or `virtio-scsi`, where it is mounted as a system disk. Alternatively, the virtual disk file can be made available to traditional Docker / Runc containers using loop mount.

[0059] This application provides a container image management method. First, a virtual disk file is created based on the container information. Then, a target container image file is obtained and parsed to obtain the compressed files of each layer within the target container image file. The compressed file of the current layer in the target container image file is decompressed to the virtual disk file and processed accordingly. A snapshot is then created on the processed virtual disk file using reflink. Once all compressed files in the target container image file have been decompressed, the target virtual disk file is determined. The target virtual disk file is mounted according to the container type of the container, so that it serves as the root directory of the target container. As can be seen, by creating a virtual disk file as the carrier of the container image, and then decompressing the compressed files of each layer of the target container image to be used to the virtual disk file, the container image is transferred to the virtual disk file. Subsequent file and directory creation, reading, and writing under the container's root directory are all performed within the virtual disk file. Furthermore, this method improves upon traditional container image storage methods based on reflink, ultimately forming the container's root directory. Compared to traditional container image storage methods, it avoids the frequent locking issues caused by file / directory operations when using traditional overlay image management on the OCFS2 file system, improves the efficiency of container image file reading and writing, and can leverage the concurrent access characteristics of multiple nodes in the cluster file system to improve container high availability.

[0060] This application discloses a specific container image management method. (See also...) Figure 3 As shown, the method includes:

[0061] Step S21: Create a virtual disk file based on the container information of the container.

[0062] For a more detailed description of the process of step S21, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0063] Step S22: Format the virtual disk file and create a file system on the formatted virtual disk file.

[0064] In this embodiment, a raw virtual disk file is created as the carrier of the container image. Then, the virtual disk file is formatted, and the compressed files of each layer of the container image are decompressed onto the file system created in the raw virtual disk file, ultimately forming the root directory of the container.

[0065] Step S23: Obtain the target container image file and parse the target container image file to obtain the compressed files of each layer in the target container image file.

[0066] For a more detailed explanation of step S23, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0067] Step S24: Mount the virtual disk file in loop mode, and decompress the compressed file of the current layer in the target container image file to the file system to obtain the first virtual disk file.

[0068] In this embodiment, a raw format virtual disk file is created using the `qemu-img` command, and then formatted and mounted. The compressed files of each layer of the container image are decompressed layer by layer into the mount directory corresponding to the virtual disk file. A new reflink virtual disk file snapshot is created for each layer of the image file. For example, suppose the `qemu-img` command is used to create a raw format virtual disk file of the same size as the container's root directory space, and its name is `image_layer0.raw`. If a container image file is divided into two layers, layer0 and layer1, after mounting the created virtual disk file in loop mode, the compressed file of container image layer0 is decompressed into the file system to obtain the first virtual disk file.

[0069] Step S25: Unmount the file system and then create a snapshot of the first virtual disk file using the reflink method to obtain the second virtual disk file.

[0070] In this embodiment of the application, after obtaining the first virtual disk file, the file system corresponding to the virtual disk is unloaded, and a snapshot of the virtual disk file image_layer0.raw is taken using the reflink method to generate a new image file image_layer1.raw, which is the second virtual disk file.

[0071] Step S26: Determine whether the data in the second disk file is the data of all layers in the target image file. If so, determine the second disk file as the target virtual disk file; otherwise, use the second disk file as the current virtual disk file, and then repeat the steps of mounting the virtual disk file in loop mode and decompressing the compressed file of the current layer in the target container image file to the file system until the data in the second disk file includes the data of all layers in the target image file, then determine the second disk file as the target virtual disk file.

[0072] In this embodiment, since it is assumed that the image file has two layers, image_layer1.raw, that is, the second virtual disk file, currently contains the data of layer0. image_layer1.raw is mounted using a loop, and then the container image layer1 compressed file is decompressed to the corresponding mount point. After decompression and copying are complete, the image file image_layer1.raw is unmounted. It can be understood that the above assumes the original container image file has only two layers. If the container image has multiple layers, it is necessary to further create a snapshot of the virtual disk file image_layer1.raw obtained in the previous step using reflink, and decompress and copy the subsequent container image layers into it. Finally, the container image layer N corresponds to the virtual disk file image_layerN.raw, which contains the data of the previous layers.

[0073] Step S27: Mount the target virtual disk file according to the container type of the container, so that the target virtual disk file is used as the root directory of the target container.

[0074] For a more detailed explanation of step S27, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0075] This application provides a container image management method. First, a virtual disk file is created based on the container information. The virtual disk file is then formatted, and a file system is created on the formatted virtual disk file. Next, a target container image file is obtained, and the target container image file is parsed to obtain the compressed files of each layer within the target container image file. The virtual disk file is mounted in loop mode, and the compressed file of the current layer in the target container image file is decompressed to the file system to obtain a first virtual disk file. The file system is then unmounted, and a snapshot of the first virtual disk file is created using reflink mode to obtain a second virtual disk file. Finally, the second virtual disk file is determined... If the data in the second disk file is the data of all layers in the target image file, then the second disk file is identified as the target virtual disk file; otherwise, the second disk file is used as the current virtual disk file. The steps of mounting the virtual disk file in loop mode and decompressing the compressed file of the current layer in the target container image file to the file system are repeated until the data in the second disk file includes the data of all layers in the target image file. Then, the second disk file is identified as the target virtual disk file. The target virtual disk file is mounted according to the container type so that it serves as the root directory of the target container. Thus, by creating a virtual disk file as the carrier of the container image, decompressing the compressed files of each layer of the target container image to be used into the virtual disk file, and transferring the container image to the virtual disk file, the subsequent creation, reading, and writing of files and directories under the container root directory are all performed within the virtual disk file. Furthermore, this method improves upon the traditional container image storage method based on reflink, ultimately forming the root directory of the container. Compared to traditional container image storage methods, it avoids the frequent locking issues caused by file / directory operations when using traditional overlay image management on the OCFS2 file system, improves the efficiency of container image file reading and writing, and can leverage the concurrent access characteristics of multiple nodes in the cluster file system to improve container high availability.

[0076] Accordingly, this application also discloses a container image management device, see [link to relevant documentation]. Figure 4 As shown, the device includes:

[0077] Virtual disk file creation module 11 is used to create virtual disk files based on the container information of the container;

[0078] The target container image file acquisition module 12 is used to acquire the target container image file and parse the target container image file to obtain the compressed files of each layer in the target container image file;

[0079] The target virtual disk file determination module 13 is used to decompress the compressed file of the current layer in the target container image file to the virtual disk file and perform corresponding processing. Then, a snapshot is created on the processed virtual disk file through the reflink method. After all the compressed files of each layer in the target container image file are decompressed, the target virtual disk file is determined.

[0080] The target virtual disk file mounting module 14 is used to mount the target virtual disk file according to the container type of the container, so as to use the target virtual disk file as the root directory of the target container.

[0081] For more detailed information on the working process of each of the above modules, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0082] Therefore, the above-described scheme in this embodiment first creates a virtual disk file based on the container information; then, it obtains the target container image file and parses it to obtain the compressed files of each layer; it decompresses the compressed file of the current layer in the target container image file to the virtual disk file and performs corresponding processing; then, it creates a snapshot of the processed virtual disk file using reflink; after all the compressed files of each layer in the target container image file are decompressed, the target virtual disk file is determined; and it is mounted according to the container type of the container so that it serves as the root directory of the target container. Thus, by creating a virtual disk file as the carrier of the container image, and then decompressing the compressed files of each layer of the target container image to be used to the virtual disk file, the container image is transferred to the virtual disk file. Subsequent file and directory creation, reading, and writing under the container's root directory are all performed within the virtual disk file. Furthermore, this improves upon the traditional container image storage method based on reflink, ultimately forming the root directory of the container. Compared to traditional container image storage methods, it avoids the frequent locking issues caused by file / directory operations when using traditional overlay image management on the OCFS2 file system, improves the efficiency of container image file reading and writing, and can leverage the concurrent access characteristics of multiple nodes in the cluster file system to improve container high availability.

[0083] Furthermore, embodiments of this application also disclose an electronic device, Figure 5 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0084] Figure 5This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the container image management method disclosed in any of the foregoing embodiments. Furthermore, the electronic device 20 in this embodiment may specifically be a server.

[0085] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0086] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk, or optical disk, etc. The resources stored on it can include an operating system 221, computer programs 222, and data 223, etc. The data 223 can include various types of data. The storage method can be temporary storage or permanent storage.

[0087] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the container image management method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include a computer program capable of performing other specific tasks.

[0088] Furthermore, this application also discloses a computer-readable storage medium, which includes random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, magnetic disks, optical disks, or any other form of storage medium known in the art. The computer program, when executed by a processor, implements the aforementioned container image management method. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0089] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0090] The steps of container image management or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, or any other form of storage medium known in the art.

[0091] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0092] The above provides a detailed description of the container image management method, apparatus, device, and storage medium provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A container image management method, characterized in that, include: Create a virtual disk file based on the container's container information; Obtain the target container image file and parse the target container image file to obtain the compressed files of each layer in the target container image file; The process involves decompressing the compressed file of the current layer in the target container image file to the virtual disk file and performing corresponding processing. Then, a snapshot of the processed virtual disk file is created using the reflink method. Once all the compressed files of each layer in the target container image file have been decompressed, the target virtual disk file is determined. The processing of the target container image file includes: mounting the created virtual disk file in loop mode, decompressing the compressed file of the current layer of the container image to the corresponding mount point in the file system, unmounting the file system corresponding to the virtual disk, creating a snapshot of the virtual disk file using the reflink method, and determining the target virtual disk file containing the data of each previous layer after all the compressed files of each layer in the target container image file have been decompressed. The target virtual disk file is mounted according to the container type of the container, so that the target virtual disk file is used as the root directory of the target container; wherein, when the container starts, the corresponding target virtual disk file is found according to the target container image file, and a snapshot is created on the target virtual disk file using the reflink method to obtain a temporary snapshot file; the temporary snapshot file is mounted according to the container type of the container, so that the temporary snapshot file is used as the root directory of the target container.

2. The container image management method according to claim 1, characterized in that, The step of creating a virtual disk file based on the container information includes: Get the root directory space size information of the container; Based on the root directory space size information, a virtual disk file in RAW format of the corresponding size is created using preset disk creation instructions.

3. The container image management method according to claim 1, characterized in that, After creating the virtual disk file based on the container information, the process also includes: The virtual disk file is formatted, and a file system is created on the formatted virtual disk file.

4. The container image management method according to claim 3, characterized in that, The process involves decompressing the compressed file of the current layer in the target container image file to the virtual disk file and performing corresponding processing. Then, a snapshot is created on the processed virtual disk file using reflink. Once all compressed files in each layer of the target container image file have been decompressed, the target virtual disk file is determined, including: The virtual disk file is mounted in loop mode, and the compressed file of the current layer in the target container image file is decompressed to the file system to obtain the first virtual disk file; The file system is unloaded, and then a snapshot of the first virtual disk file is created using the reflink method to obtain the second virtual disk file; Determine whether the data in the second virtual disk file is the data of all layers in the target container image file. If so, the second virtual disk file is identified as the target virtual disk file. Otherwise, the second virtual disk file is used as the current virtual disk file. Then, repeat the steps of mounting the virtual disk file in loop mode and decompressing the compressed file of the current layer in the target container image file to the file system until the data in the second virtual disk file includes the data of all layers in the target container image file. At this point, the second virtual disk file is identified as the target virtual disk file.

5. The container image management method according to claim 1, characterized in that, The step of mounting the target virtual disk file according to the container type of the container, so as to use the target virtual disk file as the root directory of the target container, includes: If the container type is a traditional Docker container or a runc container, the target virtual disk file is mounted in loop mode so that the target virtual disk file is used as the root directory of the target container.

6. The container image management method according to claim 1, characterized in that, The step of mounting the target virtual disk file according to the container type of the container, so as to use the target virtual disk file as the root directory of the target container, includes: If the container type is a Kata container based on lightweight virtualization, the target virtual disk file is added to the Kata container via virio-blk or virtio-scsi so that the target virtual disk file is used as the root directory of the target container.

7. A container image management device, characterized in that, include: The virtual disk file creation module is used to create virtual disk files based on the container information of the container; The target container image file acquisition module is used to acquire the target container image file and parse the target container image file to obtain the compressed files of each layer in the target container image file; The target virtual disk file determination module is used to decompress the compressed file of the current layer in the target container image file to the virtual disk file and perform corresponding processing. Then, a snapshot is created on the processed virtual disk file using the reflink method. After all the compressed files of each layer in the target container image file are decompressed, the target virtual disk file is determined. The processing of the target container image file includes: mounting the created virtual disk file in loop mode, decompressing the compressed file of the current layer of the container image to the corresponding mount point in the file system, unmounting the file system corresponding to the virtual disk, creating a snapshot on the virtual disk file using the reflink method, and determining the target virtual disk file containing the data of each previous layer after all the compressed files of each layer in the target container image file are decompressed. The target virtual disk file mounting module is used to mount the target virtual disk file according to the container type of the container, so as to use the target virtual disk file as the root directory of the target container; wherein, when the container starts, the corresponding target virtual disk file is found according to the target container image file, and a snapshot is created on the target virtual disk file using the reflink method to obtain a temporary snapshot file; the temporary snapshot file is mounted according to the container type of the container, so as to use the temporary snapshot file as the root directory of the target container.

8. An electronic device, characterized in that, The electronic device includes a processor and a memory; wherein the memory is used to store a computer program, which is loaded and executed by the processor to implement the container image management method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, Used to store computer programs; wherein the computer programs, when executed by a processor, implement the container image management method as described in any one of claims 1 to 6.

Citation Information

Patent Citations

  • Container mirror hierarchical encryption storage method based on Device Mapper

    CN109190386A

  • Method and apparatus for managing container image

    CN110308972A