A Docker image management method, device, equipment and medium for product storage system

Abstract

The present application proposes a Docker image management method, device, equipment and medium for a product storage system, the method comprising: receiving and parsing resource query, upload and download requests from a Docker client, and obtaining corresponding Docker warehouse configuration information; a product information parser obtains the namespace of the image corresponding to the current request; when a request points to a Docker virtual warehouse, obtains the namespace settings of the local warehouse and remote warehouse aggregated by it, and generates new resource request data for the corresponding warehouse according to the settings; dynamically modifies the namespace of the image name of the Docker product information and the remote warehouse proxy URL according to the namespace settings of the Docker local warehouse and remote warehouse; uses the new namespace for local resource acquisition and external requests, and generates product information using the new namespace after adding cached or uploaded products. The present application enables the Docker product warehouse to correctly interact with the Docker client in the form of a Docker Hub image source, expanding the use scenarios of the Docker product warehouse.

Description

Technical Field

[0001] The present application relates to the technical field of product storage and management, and in particular to a Docker image management method, device, equipment and medium for a product storage system. Background Art

[0002] With the popularization of informatization, the use of Docker images is becoming more and more widespread, and the demand for the use of Docker private product repositories is also increasing. However, for multi-project and multi-warehouse product management systems, it is difficult to configure a specified Docker private warehouse as the registry-mirror image source of the Docker client and simulate the operating mechanism of the Docker Hub for use; the usability of many Docker proxy repositories also needs to be improved. For example, the compatibility of the proxy source address pointing to the Docker Hub or the Docker Hub image source is insufficient, and users are often required to know the default namespace mechanism of the Docker Hub. The pull instructions and name display of the images in different namespaces cached from the Docker Hub or the Docker Hub image source to the local are also difficult to be consistent with the Docker Hub. The present application provides a Docker image management method for solving the above problems. While improving the user experience, it can also achieve the effect of shielding the private warehouse address and domain name from the outside, reduce information exposure and improve the security of the Docker private warehouse. Summary of the invention

[0003] The embodiments of the present application provide a Docker image management method, device, equipment and medium for a product storage system to solve the problems of interaction with the Docker client and product data display when a private Docker product repository is used as an image source of Docker Hub. The technical solution is as follows:

[0004] The present application embodiment provides a Docker image management method for a product storage system, including:

[0005] When the Docker artifact repository provides namespace settings, change the artifact information creation logic of the Docker image and the logic of interacting with the Docker client;

[0006] There are three types of Docker product warehouses, including local warehouses, remote warehouses, and virtual warehouses; the local warehouse is used to receive image push requests from Docker clients and store image files uploaded by users; the remote warehouse is used to make proxy requests for image query or download to the remote image source set by the user, and cache the data of the image source to speed up the response to client requests; the virtual warehouse is used to organize multiple local and remote warehouse relationships and aggregate them into a single warehouse address, so that users can access all other warehouse product data associated with the virtual warehouse address;

[0007] The namespace setting is a setting option associated with a Docker artifact repository. The setting option will affect the creation and processing of artifact information. The namespace option can be set through the page, or the change of the specified repository namespace setting can be completed through HTTP request;

[0008] The product information of the Docker image is a detailed data description of each complete image stored in the product management system, mainly including the image name, version list, version number, image size, metadata, file list, applicable operating system and architecture, pull instructions, etc. This information is automatically analyzed, created and stored in the database when the new image product data is first stored;

[0009] The logic of interacting with the Docker client is that when the product management system receives a query or download request for product data in a specified Docker repository sent by the Docker client, it analyzes the image name, version number, acceptable resource types and other information specified in the request, retrieves resources through the product storage system, builds and returns the response data required by the Docker client, and repeats this step to complete all HTTP interaction requests of a single Docker client command.

[0010] In a possible implementation, the product management system analyzes the request from the Docker client, determines whether the image corresponding to the request belongs to a certain namespace, and extracts it as the first namespace;

[0011] If yes, determine whether the first namespace is consistent with the second namespace configured in the repository to which the requested target resource belongs, or whether the first namespace is subordinate to the second namespace;

[0012] If so, the first namespace and the second namespace will participate in the subsequent processing of the artifact data.

[0013] In one possible implementation, when uploading a Docker image to a local repository for storage, the image namespace will be modified:

[0014] If the first namespace is consistent with the second namespace, the namespace of the image is removed, and when the image is reflected in the product information, the image is an image without a namespace;

[0015] If the first namespace is subordinate to the second namespace, a sub-namespace of the first namespace relative to the second namespace is extracted as a new namespace of the mirror.

[0016] In one possible implementation, when requesting cached data from a remote repository or retrieving it from a proxy source, the namespace of the target image will be modified:

[0017] If the first namespace and the second namespace are consistent, the namespace of the image is removed. If the product is added as a cache of the remote warehouse, product information is created for the cache and displayed on the page. The corresponding image name does not contain the namespace.

[0018] If the first namespace is subordinate to the second namespace, a sub-namespace of the first namespace relative to the second namespace is extracted as a new third namespace of the mirror.

[0019] In a possible implementation, when a proxy request is made from a remote repository, the set proxy source address is dynamically modified: if the third namespace exists, ensure that the set proxy source address has the third namespace as a suffix.

[0020] In one possible implementation, when a Docker artifact resource request is made from a virtual warehouse, the namespace settings of each member warehouse associated with the virtual warehouse are queried, and new artifact resource request data is generated for use by the corresponding member warehouse based on these namespace settings.

[0021] In one possible implementation, the Docker repository settings page provides a check option with the same meaning as "Use library as default namespace". When the check option is enabled, the value of the repository namespace setting is "library".

[0022] The embodiment of the present application also provides a Docker image management device for a product storage system, including:

[0023] A parsing module is used to determine the specific information of the resource and its associated image based on the Docker resource request;

[0024] The conversion module is used to convert the namespace of the image to which the resource belongs and the URL of the Docker remote repository proxy;

[0025] The acquisition module is used to obtain the required resource files from local storage and external networks;

[0026] The storage module is used to store resource files uploaded by users or obtained from the external network into the product storage system.

[0027] The present application also provides an electronic device, including: a memory and a processor. The memory stores instructions, and the instructions are loaded and executed by the processor to implement the method in any of the above-mentioned embodiments. The memory and the processor communicate with each other through an internal connection path.

[0028] The embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a computer, the method in any one of the above-mentioned embodiments is implemented.

[0029] The advantages or beneficial effects of the above technical solution include at least:

[0030] This application dynamically changes the processing logic of the product management system for Docker type products through the namespace setting in the Docker private warehouse setting, including data response to the Docker client, generation of Docker product information and page display, and expands the use of Docker private warehouses, mainly allowing local type, remote proxy type and virtual type Docker private warehouses to interact with the Docker client as Docker Hub image sources. At this time, the user can associate any warehouse to a new domain name and configure it as one of the values ​​of the registry-mirrors of the Docker client. The Docker client will consider the Docker product source to be Docker Hub or Docker Hub mirror source. When obtaining products through different methods of the Docker client, there is no need to fill in the warehouse address or its associated domain name. The pull can be completed by directly entering a simple image name, which not only improves the user experience, but also improves the security of the use of Docker private warehouses, that is, the warehouse address or domain name is not exposed to users who obtain Docker image products. Considering that when users use Docker private remote proxy repositories, if they specify the mainstream Docker Hub or Docker Hub proxy source, it is difficult to detect the existence of hidden library namespaces. Therefore, when the option "Use library as default namespace" is enabled for the remote proxy type repository, regardless of whether the proxy address is filled in with "library" as the address suffix, the remote proxy repository can also interact correctly with the remote Docker Hub or Docker Hub image source, reducing the possibility of errors in this usage scenario and improving the user experience.

[0031] The above summary is for illustrative purposes only and is not intended to be limiting in any way. In addition to the illustrative aspects, embodiments and features described above, further aspects, embodiments and features of the present application will be readily apparent by reference to the accompanying drawings and the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the accompanying drawings required for use in the embodiments will be briefly introduced below. In the accompanying drawings, unless otherwise specified, the same reference numerals throughout multiple drawings represent the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that the following drawings only illustrate certain embodiments of the present application and are therefore not to be regarded as limiting the scope. For those of ordinary skill in the art, other relevant drawings can also be obtained based on these drawings without paying creative work.

[0033] Figure 1 This is a schematic diagram of the steps of the Docker image management method according to an embodiment of the present application;

[0034] Figure 2 This is a flow chart of a Docker image management method according to an embodiment of the present application;

[0035] Figure 3 This is a schematic diagram of a Docker remote proxy repository settings page according to an embodiment of the present application;

[0036] Figure 4 This is a schematic diagram of a Docker image list page according to an embodiment of the present application;

[0037] Figure 5 This is a schematic diagram showing the details of a Docker image according to an embodiment of the present application;

[0038] Figure 6 This is a structural block diagram of a Docker image management device according to an embodiment of the present application;

[0039] Figure 7 This is a structural block diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0040] To make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the technical scheme in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. It should be understood that the drawings in the present application only serve the purpose of explanation and description and are not used to limit the scope of protection of the present application. In addition, it should be understood that the schematic drawings are not drawn in real proportion. The flowchart used in this application shows the operations implemented according to some embodiments of the present application. It should be understood that the operations of the flowchart can be implemented out of sequence, and the steps without logical context can be reversed in order or implemented simultaneously. In addition, those skilled in the art, under the guidance of the content of the present application, can add one or more other operations to the flowchart, or remove one or more operations from the flowchart.

[0041] In addition, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. The components of the embodiments of the present application described and shown in the drawings here can be arranged and designed in various configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the application claimed for protection, but merely represents the selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without making creative work belong to the scope of protection of the present application.

[0042] In the following, only some exemplary embodiments are briefly described. As those skilled in the art will appreciate, the described embodiments may be modified in various ways without departing from the spirit or scope of the present application. Therefore, the drawings and descriptions are considered to be exemplary and non-restrictive in nature.

[0043] In the related art, it is difficult to configure the Docker private artifact repository in the multi-warehouse artifact storage system as the registry-mirrors of the Docker client and use it interactively with simplified commands, or when used in this way, the proxy URL of the Docker remote proxy repository is not compatible with both the form of including and excluding the namespace, and the naming display rules of the image artifact cannot be restored when proxying the image source of DockerHub or Docker Hub.

[0044] Reference Figure 1 , a flowchart of a Docker image management method for a multi-warehouse product storage system according to an embodiment of the present application is shown. The Docker image management method may at least include steps S100-S600:

[0045] S100, receiving and parsing a request from a Docker client, and querying configuration information of a Docker private warehouse corresponding to the request;

[0046] S200, parsing specific Docker product information corresponding to the request;

[0047] S300, if the request points to a Docker virtual warehouse, the namespace settings of the local and remote warehouses aggregated by the Docker virtual warehouse will be queried, and new resource request data will be generated according to the respective namespace settings, and then handed over to the corresponding local or remote warehouse for processing;

[0048] S400, dynamically converting the namespace of the image product according to the namespace of the image product and the namespace configured in the warehouse; if the corresponding Docker warehouse is a remote warehouse type, dynamically converting the URL address configured in the warehouse;

[0049] S500: Use the new image namespace to obtain or save local resources. For remote repositories, the converted URL is also used to make proxy requests for remote resources.

[0050] S600: For a newly uploaded or newly cached product, new product information is generated using a new namespace.

[0051] The technical solution of the embodiment of the present application uses the namespace setting of the Docker product repository configuration to dynamically change the product information creation logic of the Docker image and the logic of interacting with the Docker client.

[0052] like Figure 3 As shown, the Docker remote agent repository provides a setting option of "Use library as the default namespace". After the user checks this option, the namespace setting of the repository is "library", which is also applicable to the local repository. In addition, the user can also customize the namespace by calling the repository setting interface. The customized namespace is still applicable to all namespace conversion mechanisms described below, but in this embodiment, "library" is the best setting value and is used as an example.

[0053] like Figure 2 As shown, in a possible implementation, the product management system will analyze the request from the Docker client to determine the image slave namespace corresponding to the request and whether it needs to be converted.

[0054] When uploading an image to a local repository that uses the library namespace, if the image does not have a namespace or the namespace is not "library", the image is stored and artifact information is created using the original namespace, which is the same as when the library namespace is not enabled; if the namespace of the image is "library", the namespace will be converted to no namespace for subsequent artifact information creation and storage. On the image list page, the image does not display the "library" namespace specified when uploading, which is consistent with the image display rules of Docker Hub, reflecting that the local repository is suitable for the registry-mirror format and can be used as a Docker Hub image source.

[0055] When retrieving or pulling image artifacts from a local repository that uses the library namespace, there is no need to specify the repository address, and the namespace of the image name specified in the pull command is exactly the same as that displayed on the page. For example, for the image "namespace 1 / image name 1" displayed on the page, you can use "docker pull namespace 1 / image name 1: tag" to pull it, and for the image "image name 2" displayed on the page, you can use "docker pull image name 2: tag" to pull it. When the repository is used in the form of registry-mirror, the Docker client will automatically add the "library" namespace to the pull request sent to the corresponding repository, and the namespace conversion mechanism of the artifact management system correctly handles this situation, so that the artifact is successfully retrieved and returned to the client, and the page display of the artifact information and the image name namespace consistency of the corresponding pull command are maintained. In addition, the Docker image usage instructions also provide simplified pull commands that can be used when the repository is used as a registry-mirror. Whether it is the display of the image name and its namespace, or the usage instructions, it reflects the high applicability of the local repository as a Docker Hub image source.

[0056] The use of the repository in the form of registry-mirror means configuring a separate domain name corresponding to the repository as one of the registry-mirrors of the Docker client. At this time, the Docker client regards it as a DockerHub image source. When pulling products from Docker Hub or the user wants to regard private products as coming from DockerHub, there is no need to fill in the domain name, project, warehouse and other information to which these images belong. Instead, the image name can be directly specified to successfully pull it.

[0057] When retrieving or pulling image artifacts that are not cached locally from a remote proxy repository that uses the library namespace, the remote proxy repository will be fully compatible with the proxy address containing or not containing the namespace; for example Figure 3 As shown in the figure, the remote proxy warehouse is configured with the official Docker source address "https: / / registry***docker.io", which is the case without namespace. When the Docker client pulls an image without namespace in the form of registry-mirror (for example, "docker pull image name 1", the client automatically adds the library namespace) or explicitly specifies the library namespace (for example, "docker pull library / image name 1"), or pulls an image without namespace or with the namespace "library" in a non-registry-mirror form (for example, docker pull private warehouse address / image name 1), the namespace conversion mechanism will automatically add the "library" namespace to the proxy address, so that the proxy address is dynamically converted to "https: / / registry***docker.io / library" when requested; and when the Docker client pulls an image with a namespace and the namespace is not "library" in the form of registry-mirror (for example, "dockerpull namespace1 / image name2") or pulls such an image in a non-registry-mirror form (for example, "dockerpull private warehouse address / image name 1"), the namespace conversion mechanism will automatically add the "library" namespace to the proxy address, so that the proxy address is dynamically converted to "https: / / registry***docker.io / library" when requested. The namespace conversion mechanism will not transform the proxy URL of the repository configuration when the proxy URL is "repository address / namespace1 / image name2").

[0058] In another embodiment, the remote proxy repository proxy URL pointing to Docker Hub or Docker Hub image source can also be added with the "library" namespace, for example, the remote proxy address is configured as https: / / registry***docker.io / library. In this case, if the proxy address needs to be converted to the "library" namespace according to the above rules, the address will no longer be converted. Obviously, in this case, only images under the "library" namespace will be supported, because the user explicitly fills in library as the suffix of the proxy URL, which means that the user only wants to pull the image products under this namespace.

[0059] When the above-mentioned remote repository proxy URL conversion mechanism is in operation, the namespace conversion mechanism of Docker request artifact information is also effective at the same time. When the Docker client pulls an image without a namespace in the form of registry-mirror (for example, "docker pull image name 1", the client automatically adds the library namespace) or explicitly specifies the library namespace (for example, "docker pull library / image name 1"), or pulls an image with the namespace "library" in a non-registry-mirror form (for example, docker pull private repository address / library / image name 1), the "library" namespace of the image name will be converted to no namespace; when the Docker client pulls an image with a namespace and the namespace is not "library" in the form of registry-mirror (for example, "dockerpull namespace1 / image name2") or pulls an image without a namespace or with a namespace not "library" in a non-registry-mirror form (for example, "docker pull repository address / namespace1 / image name2"), the namespace of the image will not be converted;

[0060] The above two conversion rules act on the Docker remote proxy repository at the same time, which will produce the following effects:

[0061] The remote proxy address is compatible with both the library namespace as the suffix and the library namespace as the suffix. Both forms support the user to correctly interact with the Docker Hub image source through the remote proxy repository. The image product name and namespace displayed on the page are also consistent with Docker Hub.

[0062] like Figure 4 As shown in the figure, for images belonging to the library namespace in Docker Hub, no matter how they are pulled, the image names are consistent with Docker Hub. For example, node images and python images are all nameless (Docker Hub displays images belonging to the library namespace as nameless. In other words, all images without namespace actually belong to the library namespace). For images with non-library namespaces, such as aquasec / trivy, their namespace "aquasec" is also displayed correctly.

[0063] like Figure 5As shown in the figure, in the instructions for using the image product, a simplified pull command consistent with Docker Hub is provided, and the same is true for images belonging to non-library namespaces.

[0064] In one possible implementation, Figure 2 As shown in the figure, when retrieving or pulling image products from the Docker virtual warehouse, the namespace settings of each member warehouse associated with the virtual warehouse will be queried, and new product resource request data will be generated for the corresponding member warehouse according to these namespace settings, and the namespace conversion rules of the corresponding warehouse will be applied. Therefore, even if warehouses with different settings are aggregated into the same virtual warehouse, the corresponding namespace conversion rules and URL conversion rules will be correctly applied to the processing flow of these member warehouses.

[0065] When viewing image artifacts on the Docker virtual repository page, these images will also display the image name and its namespace according to the rules applicable to each repository, and mark the actual repository source. When the user clicks on the artifact, it will jump to the corresponding image artifact details, and have the same information display and usage instructions as when entering the artifact details from the local or remote repository.

[0066] In one possible implementation, the processing logic of the gateway is used to process the independent domain name corresponding to the specified private Docker warehouse filled in the registry-mirrors setting of the Docker client. Since this setting of the Docker client does not support filling in the domain name with the URL of the subordinate path, it is necessary to use a separate domain name to establish a mapping relationship with the specific private warehouse. When the gateway receives a GET access request for "domain name / v2 / ", the gateway can seek authentication from the product management system and participate in the subsequent authentication process, or it can directly return a 200 status to inform the Docker client that the domain name does not need to be authenticated; when the gateway receives a query or download request for a Docker product resource file, the gateway will re-forward the request to the mapped warehouse address, thereby completing the connection between the registry-mirror domain name and the private Docker warehouse address.

[0067] Reference Figure 6 , shows a structural block diagram of a Docker image management device according to an embodiment of the present application, the device may include:

[0068] The parsing module is used to parse the specific information of the request from the Docker client, such as the corresponding project, private repository, image name and its namespace, label or reference, resource type, etc.

[0069] The conversion module is used to convert the image namespace according to certain rules, including the conversion of the remote repository proxy URL;

[0070] The acquisition module is used to obtain artifacts from the local repository or remote repository cache, and is also used by remote repositories to request artifacts from proxy URLs;

[0071] The storage module is used to store image artifacts uploaded by the Docker client and also to cache artifacts requested from the proxy URL from the remote repository.

[0072] In one embodiment, the Docker image management device further includes a gateway module, and the gateway module is used to:

[0073] Process the "domain name / v2 / " probe interface sent by the Docker client;

[0074] Handle the authentication process, or forward the authentication process to the product management system, and participate in the conversion of authentication information;

[0075] Forwards query, upload, and download requests for specific Docker resources to the corresponding private warehouse address.

[0076] The functions of each module in each device in the embodiments of the present application can be found in the corresponding description in the above method, and will not be repeated here.

[0077] Reference Figure 7 , shows a structural block diagram of an electronic device according to an embodiment of the present application, the electronic device includes: a memory 310 and a processor 320, the memory 310 stores instructions that can be run on the processor 320, and the processor 320 loads and executes the instructions to implement the Docker image management method in the above embodiment. The number of the memory 310 and the processor 320 can be one or more.

[0078] In one embodiment, the electronic device further includes a communication interface 330 for communicating with external devices and performing data exchange transmission. If the memory 310, the processor 320 and the communication interface 330 are implemented independently, the memory 310, the processor 320 and the communication interface 330 can be interconnected through a bus and communicate with each other. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 7Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0079] Optionally, in a specific implementation, if the memory 310, the processor 320 and the communication interface 330 are integrated on a chip, the memory 310, the processor 320 and the communication interface 330 can communicate with each other through an internal interface.

[0080] An embodiment of the present application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the Docker image management method provided in the above embodiment.

[0081] An embodiment of the present application also provides a chip, which includes a processor for calling and executing instructions stored in the memory from the memory, so that a communication device equipped with the chip executes the method provided by the embodiment of the present application.

[0082] An embodiment of the present application also provides a chip, including: an input interface, an output interface, a processor and a memory, wherein the input interface, the output interface, the processor and the memory are connected via an internal connection path, and the processor is used to execute the code in the memory. When the code is executed, the processor is used to execute the method provided in the embodiment of the application.

[0083] It should be understood that the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc. It is worth noting that the processor may be a processor supporting the advanced RISC machines (ARM) architecture.

[0084] Further, optionally, the above-mentioned memory may include a read-only memory and a random access memory, and may also include a non-volatile random access memory. The memory may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may include a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may include a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available. For example, static RAM (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM) and direct rambus RAM (DR RAM).

[0085] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium.

[0086] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example" or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. Moreover, the described specific features, structures, materials or characteristics may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine different embodiments or examples described in this specification and the features of different embodiments or examples, unless they are contradictory.

[0087] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of the features. In the description of this application, the meaning of "plurality" is two or more, unless otherwise clearly and specifically defined.

[0088] Any process or method description in the flow chart or otherwise described herein can be understood to represent a module, fragment or portion of a code including one or more executable instructions for implementing the steps of a specific logical function or process. And the scope of the preferred embodiment of the present application includes other implementations, in which the functions may not be performed in the order shown or discussed, including in a substantially simultaneous manner or in a reverse order according to the functions involved.

[0089] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing logical functions, which can be embodied in any computer-readable medium for use by an instruction execution system, apparatus or device (such as a computer-based system, a system including a processor or other system that can fetch instructions from an instruction execution system, apparatus or device and execute instructions), or used in combination with these instruction execution systems, apparatuses or devices.

[0090] It should be understood that the various parts of the present application can be implemented with hardware, software, firmware or a combination thereof. In the above embodiments, multiple steps or methods can be implemented with software or firmware stored in a memory and executed by a suitable instruction execution system. All or part of the steps of the above embodiment method can be completed by instructing the relevant hardware through a program, which can be stored in a computer-readable storage medium, and when the program is executed, it includes one of the steps of the method embodiment or a combination thereof.

[0091] In addition, each functional unit in each embodiment of the present application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into one module. The above-mentioned integrated module can be implemented in the form of hardware or in the form of a software functional module. If the above-mentioned integrated module is implemented in the form of a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. The storage medium can be a read-only memory, a disk or an optical disk, etc.

[0092] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of various changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0093] Finally, it should be noted that the above-described embodiments are only specific implementation methods of the present application, which are used to illustrate the technical solutions of the present application, rather than to limit them. The protection scope of the present application is not limited thereto. Although the present application is described in detail with reference to the above-mentioned embodiments, ordinary technicians in the field should understand that any technician familiar with the technical field can still modify the technical solutions recorded in the above-mentioned embodiments within the technical scope disclosed in the present application, or can easily think of changes, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be based on the protection scope of the claims.

Claims

1. A Docker image management method for a product storage system, characterized in that: include: When the Docker artifact repository provides namespace settings, change the artifact information creation logic of the Docker image and the logic of interacting with the Docker client; There are three types of Docker product warehouses, including local warehouses, remote warehouses, and virtual warehouses; The local warehouse is used to receive the image push request from the Docker client and store the image files uploaded by the user; The remote warehouse is used to make proxy requests for image query or download to the remote image source set by the user, and cache the data of the image source to speed up the response of the client request; The virtual warehouse is used to organize multiple local and remote warehouse relationships and aggregate them into a single warehouse address, so as to access all other warehouse product data associated with the virtual warehouse address; The namespace setting is a setting option associated with a Docker artifact repository. The setting option will affect the creation and processing of artifact information. The namespace option can be set through the page, and the change of the specified repository namespace setting can also be completed through HTTP request. The namespace setting analyzes the request from the Docker client, determines whether the image corresponding to the request belongs to a certain namespace, and extracts it as the first namespace; If so, determine whether the first namespace is consistent with the second namespace configured in the repository to which the requested target resource belongs, or whether the first namespace is subordinate to the second namespace; If so, the first namespace and the second namespace will participate in the subsequent processing of the product data; The namespace mentioned above will be modified when uploading a Docker image to a local repository for storage: If the first namespace is consistent with the second namespace, the namespace of the image is removed, and the image is a namespace-free image when reflected in the product information; If the first namespace is subordinate to the second namespace, extracting a sub-namespace of the first namespace relative to the second namespace as a new namespace of the image; The product information of the Docker image is a detailed data description of each complete image stored in the product management system, including the image name, version list, version number, image size, metadata, file list, applicable operating system and architecture, and pull instructions; The product information of the Docker image is automatically analyzed, created and stored in the database when new image product data is stored for the first time; The logic of interacting with the Docker client is that when the product management system receives a query or download request for product data in a specified Docker repository sent by the Docker client, it analyzes the image name, version number, and acceptable resource type information specified in the request, retrieves resources through the product storage system, builds and returns the response data required by the Docker client, and repeats this step to complete all HTTP interaction requests of a single Docker client command.

2. The method according to claim 1, characterized in that The namespace includes: When requesting cached data from a remote repository or retrieving it from a proxy source, the namespace of the target image will be modified: If the first namespace and the second namespace are consistent, the namespace of the image is removed. If the product is added as a cache of the remote warehouse, product information is created for the cache and displayed on the page. The corresponding image name does not contain the namespace. If the first namespace is subordinate to the second namespace, a sub-namespace of the first namespace relative to the second namespace is extracted as a new third namespace of the mirror.

3. The method according to claim 2, characterized in that The namespace also includes: When proxying requests from a remote repository, the set proxy source address will be dynamically modified: If the third namespace exists, ensure that the configured proxy source address has the third namespace as a suffix.

4. The method according to claim 1, characterized in that The namespace includes: when making a Docker product resource request from a virtual warehouse, querying the namespace settings of each member warehouse based on each member warehouse associated with the virtual warehouse, and generating new product resource request data for use by the corresponding member warehouse according to the namespace settings.

5. The method according to claim 1, characterized in that The namespace setting also includes: the Docker repository setting page provides a check option with the same meaning as "Use library as the default namespace". When the check option is enabled, the value of the repository namespace setting is "library".

6. A Docker image management device for a product storage system, characterized in that: A Docker image management method for implementing a product storage system according to any one of claims 1 to 5, comprising: A parsing module is used to determine the specific information of the resource and its associated image based on the Docker resource request; The conversion module is used to convert the namespace of the image to which the resource belongs and the URL of the Docker remote repository proxy; The acquisition module is used to obtain the required resource files from local storage and external networks; The storage module is used to store resource files uploaded by users or obtained from the external network into the product storage system.

7. An electronic device, characterized in that: include: A processor and a memory, wherein the memory stores instructions, and the instructions are loaded and executed by the processor to implement the method according to any one of claims 1 to 5.

8. A computer-readable storage medium, wherein a computer program is stored in the computer-readable storage medium, and when the computer program is executed, the method according to any one of claims 1 to 5 is implemented.

Images