WO2019134222A1

WO2019134222A1 - Docker mirror image library file storage method, terminal, device and storage medium

Info

Publication number: WO2019134222A1
Application number: PCT/CN2018/077126
Authority: WO
Inventors: 刘俊杰
Original assignee: 平安科技（深圳）有限公司
Priority date: 2018-01-08
Filing date: 2018-02-24
Publication date: 2019-07-11
Also published as: CN108228842B; CN108228842A

Abstract

Disclosed are a Docker mirror image library file storage method, a terminal, a device and a storage medium. The method comprises: abstracting several mirror image files into objects (S101); determining objects having the same logical path, and abstracting the objects in the same logical path into buckets (S102); allocating the abstracted buckets to different object containers (S103); and if an access instruction of a user is received, reading an abstracted bucket from a corresponding object container according to the access instruction, and sending same to the user (S104). The self-control of a mirror image is realized, and the storage cost of a mirror image file is reduced.

Description

Docker image library file storage method, terminal, device, and storage medium

This application claims the priority of the Chinese patent application filed on January 8, 2018, the Chinese Patent Office, the application number is CN 201810016146.3, and the application name is "Docker image library file storage method, terminal, device and storage medium". This is incorporated herein by reference.

Technical field

The present application relates to the field of computer technologies, and in particular, to a Docker image library file storage method, a terminal, a device, and a storage medium.

Background technique

In the prior art, a traditional storage method is used to store an image file of a mirrored warehouse, such as a memory storage mode or a file system storage mode, etc., because the image file is generally large, and is stored in a memory or file system manner. The migration of image files is inefficient, and the storage process consumes a large amount of storage devices, resulting in excessive storage costs for image files.

Summary of the invention

In view of this, the embodiment of the present application provides a Docker image library file storage method, a terminal, a device, and a storage medium, which implement self-management of the image and save the storage cost of the image file.

In one aspect, the embodiment of the present application provides a Docker image library file storage method, the method includes: abstracting a plurality of image files into objects; determining objects of the same logical path, and abstracting objects in the same logical path into buckets; The abstracted bucket is allocated to a different object container; if the user's access instruction is received, the abstracted bucket is read from the corresponding object container according to the access instruction and sent to the user.

On the other hand, the embodiment of the present application provides a Docker image library file storage terminal, the terminal includes: an abstracting unit for abstracting a plurality of image files into objects; and a first determining unit, configured to determine the same logical path. An object, and abstracting an object under the same logical path into a bucket; an allocating unit for allocating the abstracted bucket to a different object container; and a reading unit for receiving an access instruction of the user according to the access The instruction reads the abstracted bucket from the corresponding object container and sends it to the user.

In another aspect, the embodiment of the present application further provides a Docker image library file storage device, including: a memory for storing a program for implementing a Docker image library file storage method; and a processor for running the storage in the memory A program that implements the Docker image library file storage method to perform the following operations: abstracting several image files into objects; determining objects of the same logical path, and abstracting objects under the same logical path into buckets; allocating abstract buckets And to the different object container; if the user's access instruction is received, the abstracted bucket is read from the corresponding object container according to the access instruction and sent to the user.

In still another aspect, the embodiment of the present application further provides a computer readable storage medium, where the one or more computer programs are stored, and the one or more computer programs may be one or more The processor executes to implement the steps of: abstracting a plurality of image files into objects; determining objects of the same logical path, and abstracting objects under the same logical path into buckets; and allocating the abstracted buckets into different object containers; If the user's access instruction is received, the abstracted bucket is read from the corresponding object container according to the access instruction and sent to the user.

The embodiment of the present application abstracts several image files into objects, determines objects of the same logical path, and abstracts objects under the same logical path into buckets; assigns the abstract buckets to different object containers; if the user is received The access instruction reads the abstracted bucket from the corresponding object container according to the access instruction and sends it to the user. The embodiment of the present application implements self-management of the image, and saves the storage cost of the image file.

DRAWINGS

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings used in the description of the embodiments will be briefly described below. Obviously, the drawings in the following description are some embodiments of the present application, For the ordinary technicians, other drawings can be obtained based on these drawings without any creative work.

1 is a schematic flow chart of a Docker image library file storage method provided by an embodiment of the present application;

2 is a schematic flowchart of a Docker image library file storage method provided by an embodiment of the present application;

3 is a schematic flow chart of a Docker image library file storage method provided by an embodiment of the present application;

4 is a schematic flowchart of a method for storing a Docker image library file according to another embodiment of the present application;

FIG. 5 is a schematic flowchart of a Docker image library file storage method according to another embodiment of the present application; FIG.

6 is a schematic block diagram of a Docker image library file storage terminal provided by an embodiment of the present application;

FIG. 7 is another schematic block diagram of a Docker image library file storage terminal according to an embodiment of the present application; FIG.

FIG. 8 is another schematic block diagram of a Docker image library file storage terminal according to an embodiment of the present application; FIG.

FIG. 9 is another schematic block diagram of a Docker image library file storage terminal according to an embodiment of the present application; FIG.

FIG. 10 is another schematic block diagram of a Docker image library file storage terminal according to an embodiment of the present application; FIG.

FIG. 11 is a schematic structural diagram of a Docker image library file storage device according to an embodiment of the present application.

Detailed ways

The technical solutions in the embodiments of the present application are clearly and completely described in the following with reference to the drawings in the embodiments of the present application. It is obvious that the described embodiments are a part of the embodiments of the present application, and not all of the embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present application without departing from the inventive scope are the scope of the present application.

The use of the terms "comprising", "comprising", "","," The presence or addition of a plurality of other features, integers, steps, operations, elements, components, and/or collections thereof.

It is also to be understood that the terminology of the present invention is to be construed as a The singular forms "a", "the", and "the"

Please refer to FIG. 1. FIG. 1 is a schematic flowchart of a method for storing a Docker image library file according to an embodiment of the present application. The method can be run on terminals such as smart phones (such as Android phones, IOS phones, etc.), tablets, laptops, and smart devices. The Docker image library file storage method described in the embodiment of the present invention can realize self-management of the image and save the storage cost of the image file. FIG. 1 is a schematic flowchart of a Docker image library file storage method provided by an embodiment of the present application. The method includes steps S101 to S104.

S101, abstracting a plurality of image files into objects.

In the embodiment of the present application, different image files are stored in the Docker image library, wherein the Docker image library includes a location where the image file and the image file are stored. Specifically, the Docker image library provides a registration server, and the registration server uses the registration server. For saving multiple warehouses, each warehouse can contain multiple image files with different labels; in actual use, the default repository used in the Docker image library runtime is the Docker Hub public repository; for the image files in the Docker image library Storage, there are many ways to store the storage, for example, it can be memory storage, storage in the form of file system, and so on.

It should be noted that, in consideration of the structural characteristics of the image file, the embodiment of the present application uses the object storage method to store the image file, and abstracts several image files into objects, such as abstracting the image file 1 into Object1 and abstracting the image file 2. In Object2 and so on, the abstract process can be abstracted through the programming language, and the specific abstraction process is not limited here.

Let's take the tomcat image in the Docker image library as an example to illustrate the abstraction process:

The tomcat image in the Docker image library can be queried to get the version of the image as 8. The memory of the tomcat image in the Docker image library can be divided into three layers, that is, the image has three image files, which are respectively used as image files. , image file 2, image file 3, obtain the hash value of the three image files, and read the ID number of the hash value, find the save path of the image file by the ID number of the hash value, different image files The save path is different, and the image file is abstracted by using the different save paths corresponding to different image files as the object name.

Further, as shown in FIG. 2, step S101 includes steps S201 to S203.

S201. Determine a hash value corresponding to the image file, and determine a corresponding ID number according to the hash value.

In the embodiment of the present application, in the Docker image library, each image file corresponds to a hash value, and the hash value is obtained by the FileHash() function. Specifically, the file name corresponding to the hash value is obtained by FileName. The corresponding hash value is obtained by Type_, and after the function is successfully executed, the corresponding hash value is returned. Determining a corresponding ID number according to the hash value. Since each hash value corresponds to a unique ID number or a corresponding code, after determining the hash value, the hashID function may be used to obtain a hash value corresponding to the hash value. ID field, which takes the obtained ID field as the ID number of the hash value.

S202. Search for a save path corresponding to the image file according to the ID number.

In the embodiment of the present application, the format of the save path found by each image file is: the image name - the image version number - the hash number corresponding to the hash value is, for example, the storage of the tomcat image in the Docker image library is divided into a total of The third layer, that is, the image has three image files, which are mirror file 1, image file 2, and image file 3, respectively, obtain the hash values of the three image files, and read the ID number of the hash value. The ID numbers read are aaa111, bbb222, and ccc333, respectively. The path to find the image file by the ID number can be /myimage/tomcat/8/aaa111, /myimage/tomcat/8/bbb222, /myimage/tomcat/ 8/ccc333.

S203. Abstract the image files into objects according to the saved path.

In the embodiment of the present application, the save path corresponding to each image file is abstracted as an object name, and the abstract process may be abstracted by a programming language. The specific abstract process is not limited herein.

S102. Determine an object of the same logical path, and abstract the object under the same logical path into a bucket.

In the embodiment of the present application, in the embodiment of the present application, each image warehouse includes multiple image files, and objects that are abstracted into image files of the same mirror warehouse are referred to as objects in the same logical path, and the same logic is used. The object under the path is abstracted into a bucket. For example, three objects with the same logical path can be abstracted into bucket 1, or four objects with the same logical path can be abstracted into bucket 2, etc. The abstract process can be through a program. The design language is abstracted, and the specific abstraction process is not limited here.

The following is an example of abstracting three objects with the same logical path into bucket 1. The abstract process can be: save it as /myimage/tomcat/8/aaa111/myimage/tomcat/8/bbb222,/ The three objects of myimage/tomcat/8/ccc333 belong to the same /myimage path, so abstract /myimage as a bucket name into a bucket, and /myimage/tomcat/8/aaa111, /myimage/tomcat/8 /bbb22, /myimage/tomcat/8/ccc333 is used as an object in the bucket/myimage. Since the same logical path stores the object abstracted from the image file of the same repository, abstracting the objects in the same logical path into a bucket ensures the integrity of the image file.

S103, assigning the abstract bucket to a different object container.

In the embodiment of the present application, the object container may be a disk, and the number of the disks may be one or more according to storage requirements. When the abstracted buckets are allocated to different disks, the allocation manner is randomly distributed. The so-called random distributed allocation refers to randomly assigning different objects in the bucket to the disk. It should be noted that, when the object is allocated to the storage mode of the disk, an object can be repeatedly stored in different disks, and the object is For distributed storage on different disks, for example, assigning Object1 in Bucker1 to Disk 1, you can also assign Object1 in Bucket1 to Disk 2; Assign Object1 in Bucket2 to Disk 2, or both. Assign Object1 in Bucket2 to Disk 3; assign Object1 in Bucket3 to Disk 3, or assign Object1 in Bucket 3 to Disk 4 at the same time, and so on.

It should be noted that the disk in this embodiment belongs to a storage medium for storing files and data in the self-developed storage system, and the self-developed storage system can save the processed files/data to the disk or from the disk. The saved file/data is read. The mirrored warehouse belongs to the external device for the self-developed storage system. The mirrored warehouse can call the interface of the storage system (the interface is the port set to the external device in the self-developed storage system), and the image is mirrored. The object files in the warehouse are saved by the self-developed storage system, or the corresponding object files are read from the self-developed storage system according to the object name.

S104. If an access instruction of the user is received, the abstracted bucket is read from the corresponding object container according to the access instruction and sent to the user.

In the embodiment of the present application, the object container is storage hardware in the object storage system, and the storage hardware may be a disk. An object storage system may include an API Gateway, a storage system, and a disk. If an access instruction of the user is received, the access instruction is required. Through the backend storage driver supported by the mirror repository, the driver can be AWS S3, Openstack Swift, Alibaba Cloud Object Storage, etc., and the disk in the object storage system is required to read the abstract bucket.

It should be noted that the specific access process is: pre-connecting the driver of the mirror warehouse with the object storage system, and sending the access instruction to the disk in the object storage system through the driver, and reading the corresponding disk in the disk The bucket sends the acquired bucket to the user according to the docking relationship between the mirrored warehouse and the object storage system.

Optionally, the user access instruction may be a logical path and an object name of the object to be read, such as Bucket1 and Object1, where Bucket1 is the logical path of the object, and Object1 is the object name, and the logical path and the object name are sent to the disk. After that, you don't need to care about which disk you need to access data from, but traverse all the disks in the object storage system to read the corresponding data.

Further, as shown in FIG. 3, step S104 includes steps S301 to S304.

S301. Connect the driver of the mirror warehouse to the object storage system according to the access instruction.

In the embodiment of the present application, the object storage system may be a self-developed object storage system, and the mirrored warehouse and the object storage system may be connected through a compatible API of the storage drive-storage system.

S302. Send the access instruction to an object container in the object storage system.

In the embodiment of the present application, for the mirror warehouse, only the storage driver needs to be configured normally, and it is not necessary to understand how the data is processed behind the storage driver; for the self-developed storage system, the mirrored warehouse accesses the instruction through the storage driver. After being sent to the compatible API, the storage system only needs to read and write the relevant files normally according to the information of the access instruction, and does not need to know the specific situation of the requesting party.

S303. Read a corresponding bucket in the object container.

In the embodiment of the present application, if the access instruction reaches the storage system, a normal read and write operation is performed in the object container according to the access instruction to read the corresponding bucket.

S304: Send the acquired bucket to the user according to the docking relationship between the mirrored warehouse and the object storage system.

It can be seen from the above that the embodiment of the present application abstracts several image files into objects, determines objects of the same logical path, and abstracts objects under the same logical path into buckets; assigns the abstract buckets to different object containers; If the user's access instruction is received, the abstracted bucket is read from the corresponding object container according to the access instruction and sent to the user. The embodiment of the present application implements self-management of the image, and saves the storage cost of the image file.

Please refer to FIG. 4. FIG. 4 is a schematic flowchart of a method for storing a Docker image library file according to an embodiment of the present application. The method can be run on terminals such as smart phones (such as Android phones, IOS phones, etc.), tablets, laptops, and smart devices. As shown in FIG. 4, the method includes steps S401 to S407.

S401, abstracting a plurality of image files into objects.

S402. Determine an object of the same logical path, and abstract the object under the same logical path into a bucket.

The following is an example of abstracting three objects with the same logical path into bucket 1. The abstract process can be: save it as /myimage/tomcat/8/aaa111/myimage/tomcat/8/bbb222,/ The three objects of myimage/tomcat/8/ccc333 belong to the same /myimage path, so abstract /myimage as a bucket name into a bucket, and /myimage/tomcat/8/aaa111, /myimage/tomcat/8 /bbb22, /myimage/tomcat/8/ccc333 is used as an object in the bucket/myimage. Because the same logical path stores the object abstracted from the image file of the same repository, abstracting the objects in the same logical path into a bucket ensures the integrity of the image file.

S403. Scan the object name of the object in all the buckets.

In the embodiment of the present application, by connecting to the database, the objects in all the buckets are scanned and obtained by using a Structured Query Language (SQL). Specifically, all the buckets are obtained by using a SELECT statement, and the WHERE statement is used to obtain The name of the object in the bucket to achieve the effect of scanning the object name.

S404. Identify a naming specification corresponding to the currently scanned object name.

In the embodiment of the present application, the identifying the naming specification corresponding to the currently scanned object name may be to identify whether there is a numerical order rule between the object names, for example, the first object name is “xx111”, The second object name is "xx222". Since there is a rule of increasing the number of digits between "111" and "222", it is possible to recognize that there is a numerical order between the object names, thereby judging the The object names have the same naming convention. The identifying the naming specification corresponding to the currently scanned object name may be to identify whether there is an alphabetic order between the object names, for example, the first object name is “aaa”, and the second object name is “ Bbb", since "a" and "b" have an alphabetical order, it is possible to recognize that there is an alphabetic order between the object names, thereby judging that the object names have the same naming convention.

S405. Determine an object of the same naming convention.

S406. Assign the determined objects of the same naming convention to the same object container.

In the embodiment of the present application, the object container may be a disk, and the number of the disks may be one or more according to storage requirements. The principle of allocating different objects in the bucket to the disk may be the same naming convention. The objects are allocated to the same object container. For example, the Object1 in Bucket1 is assigned to Disk 1, and Object2 in Bucket2 of the same naming convention can also be assigned to Disk 1. In addition, objects of different naming conventions can be randomly assigned to different object containers, and objects of different naming conventions can also be assigned to the same object container.

S407. If an access instruction of the user is received, the abstracted bucket is read from the corresponding object container according to the access instruction and sent to the user.

Optionally, the user access instruction may be a logical path and an object name of the object to be read, such as Bucker1, Object1, where Bucker1 is the logical path of the object, and Object1 is the object name, and the logical path and the object name are sent to the disk. After that, you don't need to care about which disk you need to access data from, but traverse all the disks in the object storage system to read the corresponding data.

Please refer to FIG. 5. FIG. 5 is a schematic flowchart of a method for storing a Docker image library file according to an embodiment of the present application. The method can be run on terminals such as smart phones (such as Android phones, IOS phones, etc.), tablets, laptops, and smart devices. As shown in FIG. 5, the method includes steps S501 to S505.

S501, abstracting several image files into objects.

S502. Determine an object of the same logical path and abstract the object under the same logical path into a bucket.

S503. Determine an amount of storage that the object container performs storage.

In the embodiment of the present application, the object container may be a disk, and the number of the disks may be one or more according to storage requirements, and different disks have different storage capacities, and the storage capacity of the disks is determined in advance. When an abstract bucket is allocated to a disk, it can be replaced/added to other storage by judging whether the disk storage is full.

S504. Allocate objects in the bucket according to the determined storage amount according to a preset order.

In the embodiment of the present application, according to the storage capacity of the disk, the objects in the bucket may be allocated and stored in a planned manner, and the preset sequence may be stored according to the size of the object, from large to small rules. It can be stored according to the rules of the date when the object is abstracted, and so on.

S505. If an access instruction of the user is received, the abstracted bucket is read from the corresponding object container according to the access instruction and sent to the user.

Referring to FIG. 6 , corresponding to the Docker image library file storage method, the embodiment of the present application further provides a Docker image library file storage terminal, the terminal 100 includes: an abstraction unit 101, a first determining unit 102, an allocating unit 103, The unit 104 is read.

The abstracting unit 101 is configured to abstract several image files into objects. a first determining unit 102, configured to determine an object of the same logical path, and abstract an object under the same logical path into a bucket; an allocating unit 103, configured to allocate the abstracted bucket into a different object container; the reading unit 104 And if the access instruction of the user is received, the abstracted bucket is read from the corresponding object container according to the access instruction and sent to the user.

As shown in FIG. 7, the abstracting unit 101 includes: a second determining unit 1011, configured to determine a hash value corresponding to the image file, and determine a corresponding ID number according to the hash value; the searching unit 1012 And searching for the save path corresponding to the image file according to the ID number; the abstract subunit 1013 is configured to abstract the plurality of image files into objects according to the saved save path.

As shown in FIG. 8, the reading unit 104 includes: a docking unit 1041, configured to interface the driver of the mirror warehouse with the object storage system according to the access instruction; and the first sending unit 1042 is configured to: The object is sent to the object container in the object storage system; the reading subunit 1043 is configured to read the corresponding bucket in the object container; and the second sending unit 1044 is configured to perform the docking relationship between the mirrored warehouse and the object storage system. Send the acquired bucket to the user.

Please refer to FIG. 9 , which corresponds to a Docker image library file storage method. The embodiment of the present application further provides a Docker image library file storage terminal. The terminal 200 includes an abstracting unit 201, a first determining unit 202, and a scanning unit 203. The identification unit 204, the third determination unit 205, the first distribution subunit 206, and the reading unit 207.

The abstracting unit 201 is configured to abstract a plurality of image files into objects; the first determining unit 202 is configured to determine objects of the same logical path, and abstract objects in the same logical path into buckets; the scanning unit 203, An object name for scanning objects in all the buckets; an identifying unit 204, configured to identify a naming specification corresponding to the currently scanned object name; a third determining unit 205, configured to determine an object of the same naming convention; the first assigning subunit 206, configured to allocate the determined object of the same naming convention to the same object container; the reading unit 207 is configured to: when receiving the access instruction of the user, read from the corresponding object container according to the access instruction Abstract bucket.

Referring to FIG. 10, corresponding to the Docker image library file storage method, the embodiment of the present application further provides a Docker image library file storage terminal, the terminal 300 includes: an abstraction unit 301, a first determining unit 302, and a fourth determining unit. 303. The second allocation subunit 304 and the reading unit 305.

The abstracting unit 301 is configured to abstract a plurality of image files into objects; the first determining unit 302 is configured to determine objects of the same logical path, and abstract objects in the same logical path into buckets; 303. The second allocation subunit 304 is configured to allocate an object in the bucket according to the determined storage quantity according to the determined storage quantity. The reading unit 305 is configured to use the storage unit. If the user's access instruction is received, the abstracted bucket is read from the corresponding object container according to the access instruction.

In the hardware implementation, the above abstract unit 101, the first determining unit 102, the allocating unit 103, the reading unit 104, and the like may be embedded in the hardware processing device in hardware or in the form of software. In the memory of the device, so that the processor calls to perform the operations corresponding to the above respective units. The processor can be a central processing unit (CPU), a microprocessor, a microcontroller, or the like.

The above Docker image library file storage terminal can be implemented in the form of a computer program that can be run on a computer device as shown in FIG.

FIG. 11 is a schematic structural diagram of a Docker image library file storage device according to the present application. The device may be a terminal or a server, wherein the terminal may be a communication device such as a smart phone, a tablet computer, a notebook computer, a desktop computer, a personal digital assistant, and a wearable device. The server can be a standalone server or a server cluster consisting of multiple servers. Referring to FIG. 11, the computer device 500 includes a processor 502, a non-volatile storage medium 503, an internal memory 504, and a network interface 505 connected by a system bus 501. The non-volatile storage medium 503 of the computer device 500 can store an operating system 5031 and a computer program 5032. When the computer program 5032 is executed, the processor 502 can be caused to execute a Docker image library file storage method. The processor 502 of the computer device 500 is used to provide computing and control capabilities to support the operation of the entire computer device 500. The internal memory 504 provides an environment for the operation of the computer program 5032 in the non-volatile storage medium 503, which when executed by the processor, causes the processor 502 to execute a Docker image library file storage method. The network interface 505 of the computer device 500 is used to perform network communications, such as sending assigned tasks and the like. It will be understood by those skilled in the art that the structure shown in FIG. 11 is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation of the computer device to which the solution of the present application is applied. The specific computer device may It includes more or fewer components than those shown in the figures, or some components are combined, or have different component arrangements.

The processor 502 performs the following operations: abstracting a plurality of image files into objects; determining objects of the same logical path, and abstracting objects under the same logical path into buckets; assigning the abstract buckets to different object containers If the access instruction of the user is received, the abstracted bucket is read from the corresponding object container according to the access instruction and sent to the user.

In an embodiment, the abstracting the image file into the object includes: determining a hash value corresponding to the image file, and determining a corresponding ID number according to the hash value; searching according to the ID number The save path corresponding to the image file; abstracting several image files into objects according to the saved save path.

In one embodiment, the allocating the abstracted buckets to different object containers includes: scanning object names of objects in all buckets; identifying a naming specification corresponding to the currently scanned object name; determining the same naming convention Object; assigns objects of the same naming convention that are determined to the same object container.

In one embodiment, the allocating the abstracted buckets to different object containers comprises: determining an amount of storage by which the object containers are stored; and in the preset order according to the determined storage amount The object is allocated.

In one embodiment, the reading the abstracted bucket from the corresponding object container according to the access instruction and sending it to the user includes: docking the driver of the mirrored warehouse with the object storage system according to the access instruction; The access instruction is sent to the object container in the object storage system; the corresponding bucket is read in the object container; and the acquired bucket is sent to the user according to the docking relationship between the mirrored warehouse and the object storage system.

It can be understood by those skilled in the art that the embodiment of the Docker image library file storage device shown in FIG. 11 does not constitute a limitation on the specific configuration of the Docker image library file storage device. In other embodiments, the Docker image library file storage device may Includes more or fewer components than shown, or combines some components, or different component arrangements. For example, in some embodiments, the Docker image library file storage device includes only the memory and the processor. In such an embodiment, the structure and function of the memory and the processor are the same as those in the embodiment shown in FIG. .

The application provides a computer readable storage medium storing one or more computer programs executable by one or more processors to implement the Docker image described above Library file storage method.

The foregoing storage medium of the present application includes: a magnetic disk, an optical disk, a read-only memory (ROM), and the like, which can store various program codes.

The units in all the embodiments of the present application may be implemented by a general-purpose integrated circuit, such as a CPU (Central Processing Unit), or by an ASIC (Application Specific Integrated Circuit).

The steps in the Docker image library file storage method of the embodiment of the present application may be sequentially adjusted, merged, and deleted according to actual needs.

The units in the Docker image library file storage terminal of the embodiment of the present application can be merged, divided, and deleted according to actual needs.

The foregoing is only a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto, and any equivalents can be easily conceived by those skilled in the art within the technical scope disclosed in the present application. Modifications or substitutions are intended to be included within the scope of the present application. Therefore, the scope of protection of this application should be determined by the scope of protection of the claims.

Claims

A Docker image library file storage method, characterized in that the method comprises:

Abstracting several image files into objects;

Identify objects of the same logical path and abstract objects under the same logical path into buckets;

Assign the abstracted buckets to different object containers;

If the user's access instruction is received, the abstracted bucket is read from the corresponding object container according to the access instruction and sent to the user.
The method of claim 1 wherein said abstracting a plurality of image files into objects comprises:

Determining a hash value corresponding to the image file, and determining a corresponding ID number according to the hash value;

Finding, according to the ID number, a save path corresponding to the image file;

Several image files are abstracted into objects based on the saved save path.
The method of claim 1 wherein said assigning said abstracted buckets to different object containers comprises:

Scan the object names of objects in all buckets;

Identify the naming convention corresponding to the name of the currently scanned object;

Identify objects of the same naming convention;

Assign the objects of the same naming convention that are determined to the same object container.
The method of claim 1 wherein said assigning said abstracted buckets to different object containers comprises:

Determining a storage amount of the object container to store;

The objects in the bucket are allocated in a preset order according to the determined storage amount.
The method of claim 1, wherein the reading the abstracted bucket from the corresponding object container according to the access instruction and transmitting to the user comprises:

Interfacing the driver of the mirrored warehouse with the object storage system according to the access instruction;

Transmitting the access instruction to an object container in the object storage system;

Reading a corresponding bucket in the object container;

The acquired bucket is sent to the user according to the docking relationship between the mirrored warehouse and the object storage system.
A Docker image library file storage terminal, wherein the terminal comprises:

An abstract unit for abstracting several image files into objects;

a first determining unit, configured to determine an object of the same logical path, and abstract the object under the same logical path into a bucket;

An allocation unit for allocating abstract buckets into different object containers;

The reading unit is configured to: when receiving the access instruction of the user, read the abstract bucket from the corresponding object container according to the access instruction and send the abstract bucket to the user.
The terminal according to claim 6, wherein the abstracting unit comprises:

a second determining unit, configured to determine a hash value corresponding to the image file, and determine a corresponding ID number according to the hash value;

a searching unit, configured to search, according to the ID number, a save path corresponding to the image file;

An abstract subunit for abstracting several image files into objects based on the saved save path.
The terminal according to claim 6, wherein the allocating unit comprises:

A scanning unit that scans the object names of objects in all buckets;

a identifying unit, configured to identify a naming specification corresponding to the currently scanned object name;

a third determining unit, configured to determine an object of the same naming convention;

The first allocation subunit is configured to allocate the determined objects of the same naming convention to the same object container.
The terminal according to claim 6, wherein the allocating unit comprises:

a fourth determining unit, configured to determine a storage amount of the object container to store;

And a second allocation subunit, configured to allocate objects in the bucket according to the determined storage amount in a preset order.
The terminal according to claim 6, wherein the reading unit comprises:

a docking unit, configured to interface the driver of the mirror warehouse with the object storage system according to the access instruction;

a first sending unit, configured to send the access instruction to an object container in an object storage system;

Reading a subunit for reading a corresponding bucket in the object container;

The second sending unit is configured to send the acquired bucket to the user according to the docking relationship between the mirrored warehouse and the object storage system.
A Docker image library file storage device, comprising:

a memory for storing a program that implements a Docker image library file storage method;

And a processor, configured to run a program stored in the memory to implement a Docker image library file storage method, to perform the following operations:

Abstracting several image files into objects;

Identify objects of the same logical path and abstract objects under the same logical path into buckets;

Assign the abstracted buckets to different object containers;

If the user's access instruction is received, the abstracted bucket is read from the corresponding object container according to the access instruction and sent to the user.
The device of claim 11, wherein the abstracting the plurality of image files into objects comprises:

Determining a hash value corresponding to the image file, and determining a corresponding ID number according to the hash value;

Finding, according to the ID number, a save path corresponding to the image file;

Several image files are abstracted into objects based on the saved save path.
The device of claim 11, wherein the allocating the abstracted buckets to different object containers comprises:

Scan the object names of objects in all buckets;

Identify the naming convention corresponding to the name of the currently scanned object;

Identify objects of the same naming convention;

Assign the objects of the same naming convention that are determined to the same object container.
The device of claim 11, wherein the allocating the abstracted buckets to different object containers comprises:

Determining a storage amount of the object container to store;

The objects in the bucket are allocated in a preset order according to the determined storage amount.
The device according to claim 11, wherein the reading the abstracted bucket from the corresponding object container according to the access instruction and transmitting it to the user comprises:

Interfacing the driver of the mirrored warehouse with the object storage system according to the access instruction;

Transmitting the access instruction to an object container in the object storage system;

Reading a corresponding bucket in the object container;

The acquired bucket is sent to the user according to the docking relationship between the mirrored warehouse and the object storage system.
A computer readable storage medium, characterized in that the computer readable storage medium stores one or more computer programs, the one or more computer programs being executable by one or more processors to implement the following step:

Abstracting several image files into objects;

Identify objects of the same logical path and abstract objects under the same logical path into buckets;

Assign the abstracted buckets to different object containers;

If the user's access instruction is received, the abstracted bucket is read from the corresponding object container according to the access instruction and sent to the user.
The computer readable storage medium of claim 16, wherein the abstracting the plurality of image files into objects comprises:

Determining a hash value corresponding to the image file, and determining a corresponding ID number according to the hash value;

Finding, according to the ID number, a save path corresponding to the image file;

Several image files are abstracted into objects based on the saved save path.
The computer readable storage medium of claim 16, wherein the allocating the abstracted buckets to different object containers comprises:

Scan the object names of objects in all buckets;

Identify the naming convention corresponding to the name of the currently scanned object;

Identify objects of the same naming convention;

Assign the objects of the same naming convention that are determined to the same object container.
The computer readable storage medium of claim 16, wherein the allocating the abstracted buckets to different object containers comprises:

Determining a storage amount of the object container to store;

The objects in the bucket are allocated in a preset order according to the determined storage amount.
The computer readable storage medium of claim 16, wherein the reading the abstracted bucket from the corresponding object container according to the access instruction and transmitting to the user comprises:

Interfacing the driver of the mirrored warehouse with the object storage system according to the access instruction;

Transmitting the access instruction to an object container in the object storage system;

Reading a corresponding bucket in the object container;

The acquired bucket is sent to the user according to the docking relationship between the mirrored warehouse and the object storage system.