WO2017113374A1 - 镜像部署方法和装置 - Google Patents
镜像部署方法和装置 Download PDFInfo
- Publication number
- WO2017113374A1 WO2017113374A1 PCT/CN2015/100291 CN2015100291W WO2017113374A1 WO 2017113374 A1 WO2017113374 A1 WO 2017113374A1 CN 2015100291 W CN2015100291 W CN 2015100291W WO 2017113374 A1 WO2017113374 A1 WO 2017113374A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- image
- deployed
- host
- layer
- mirroring
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
- G06F8/63—Image based installation; Cloning; Build to order
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
Definitions
- the present application relates to the field of computer technologies, and in particular, to a mirror deployment method, a mirror deployment device, a mirrored deployment computing device, and a container system.
- Container technology is a lightweight virtual technology based on operating system.
- the container runs in the user space above the operating system.
- the container on one host shares the operating system kernel.
- container technology has gradually become a hot spot in cloud computing research.
- One of the core of container technology is the use of layered mirroring.
- the image used in container technology consists of mirror layers, each of which includes various modifications based on the parent image layer of the mirror layer, so a complete image must include its required All mirror layers. You can create and publish your own image, or you can download the required image from the image library. After downloading the image to the host, you can start the container corresponding to the image according to the downloaded image.
- the container system generally runs a plurality of hosts for running the container.
- the container system first needs to select one of the multiple hosts to run the container, and the host subsequently detects the selected one. Whether the mirrored layer stored by the host can support the startup of the container. If it is not supported, the host needs to request a mirror layer from the mirror library. Therefore, the time taken for the container to be deployed includes the download time of the required image of the container and the startup time of the container after the image is downloaded.
- the startup time of the container after the image download is short, and the speed of restricting the deployment of the container is often that it takes a long time to download the image.
- This application provides a mirroring deployment method.
- the mirroring deployment speed is improved by selecting the deployment host of the mirror to be deployed and the deployed image of each host.
- the first aspect of the present application provides a mirroring deployment method, in which the management node obtains the mirrored label of the deployed image on each host.
- This step can be implemented before the image deployment method. It is executed when the image is deployed, for example, it can be executed periodically or when the trigger timing is met.
- the management node obtains the mirroring label of the mirror image of the mirror to be deployed, and compares the mirrored labels of the mirrors that have been deployed on the hosts. Which of the mirrors belong to the parent image of the mirror to be deployed, that is, you can know which parts of the host are missing from the mirror to be deployed. Deploying the to-be-deployed image by using a comparison result of each host and a predetermined policy to select a host that requires less downloading to improve the speed of image deployment.
- the triggering time of the management node to obtain the mirrored label of the deployed image on each host includes: a preset period of arrival, receiving an instruction to deploy the container, or receiving the instruction The collection instruction sent by the user.
- the management node further acquires resource usage information of each host, and the host that is compared by the management node may be The management node determines, according to the resource usage information of each host, the host that meets the resource usage requirements of the image to be deployed, that is, the host to be selected. Through the determination of the host to be selected, the workload of the subsequent comparison of the management node is reduced, and the working efficiency of the management node is improved.
- the deployment node selected by the management node may be the host with the largest number of parent images of the mirror to be deployed.
- the host with the largest number of parent images deployed on the mirror to be deployed requires the least amount of downloads, which further improves the speed of deploying the image to be deployed.
- the management node may not compare the mirrored label of the parent image of the mirror to be mirrored with the mirrored label of the mirror deployed on each host.
- the mirroring label of the parent image of the mirror to be deployed is compared with the mirroring label of the mirrored image of each host. This saves the comparison time of the management node and improves the working efficiency of the management node.
- a method for image deployment where a management node acquires each host The layer ID of the deployed mirroring layer.
- This step can be implemented before the mirroring deployment method. It can be executed every time the mirror is deployed. For example, it can be executed periodically or when the trigger timing is met.
- the management node After obtaining the mirroring label of the mirror to be deployed, the management node obtains the layer identifier of the mirroring layer of the mirror to be deployed, and compares it with the layer identifier of the mirroring layer deployed on each host. Which mirroring layers belong to the mirror to be deployed, that is, you can know which mirroring layers are missing from each host relative to the mirror to be deployed. Deploying the to-be-deployed image by using a comparison result and a predetermined policy of each host to select a host that requires less downloading to improve the speed of image deployment.
- the triggering time for the management node to obtain the layer identifier of the mirror layer that has been deployed on each host includes: receiving a preset period, receiving an instruction to receive the container, or receiving A collection instruction sent to the user.
- the management node further acquires resource usage information of each host, and the host that is compared by the management node may be The management node determines, according to the resource usage information of each host, the host that meets the resource usage requirements of the image to be deployed, that is, the host to be selected. Through the determination of the host to be selected, the workload of the subsequent comparison of the management node is reduced, and the working efficiency of the management node is improved.
- the deployment node selected by the management node may be the host with the largest number of mirroring layers of the image to be deployed.
- the host with the largest number of mirroring layers in the mirror to be deployed requires the least amount of downloads, which further improves the speed of deploying the image to be deployed.
- the management node may not compare the layer identifier of the mirroring layer of the mirror to be mirrored with the layer identifier of the mirrored image of each host.
- the layer identifier of the top-level mirroring layer of the deployment image starts and is compared downwards, which saves the comparison time of the management node and improves the working efficiency of the management node.
- a mirror deployment apparatus is provided, the image deployment apparatus being used for A mirror is deployed in the system, the image deployment apparatus including at least one unit for performing the image deployment method provided by the first aspect.
- an image deployment apparatus for deploying a mirror in a container system, the image deployment apparatus comprising at least one unit for performing the image deployment method provided by the second aspect.
- a computing device for deploying a mirror in a container system, the computing device being a management node in a container system, the computing device executing the image provided by the first aspect Deployment method.
- a computing device for deploying a mirror in a container system, the computing device being a management node in a container system, the computing device executing the image provided by the second aspect Deployment method.
- a seventh aspect of the present application provides a mirroring deployment method, which is applied to a host and a management node in a container system, where the host sends a locally deployed image to the management node when the trigger timing is met.
- the image label, in which the management node executes, refers to the image deployment method provided by the first aspect.
- An eighth aspect of the present application provides a mirroring deployment method, where the image deployment method is applied to a host and a management node in a container system, wherein the host sends a locally deployed mirror layer to the management node when the trigger timing is met.
- the layer identification, in which the management node performs the part, refers to the image deployment method provided by the second aspect.
- a ninth aspect of the present application provides a host that sends a mirrored label of a locally deployed image to a management node when the trigger timing is met, and the trigger timing includes: a preset period arrives, or receives The collection instruction sent by the management node, the collection instruction indicates to send the mirrored label of the deployed image to the management node, or detects that the locally deployed image changes.
- a tenth aspect of the present application provides a host that sends a layer identifier of a locally deployed mirror layer to a management node when the trigger timing is met, and the trigger timing includes: a preset period of arrival, or receiving The collection instruction sent by the management node, the collection instruction indicates to send the layer identifier of the deployed mirror layer to the management node, or detects that the locally deployed mirror layer changes.
- a mirror label sending module is provided, where the module runs on a host The host sends the mirrored label of the locally deployed image to the management node when the trigger timing is met.
- a twelfth aspect of the present application provides a mirroring label sending module, where the module runs on a host, so that the host sends the layer identifier of the locally deployed mirroring layer to the management node when the triggering timing is met.
- a container system comprising at least two hosts provided by the ninth aspect, and management by the image deployment apparatus provided by the third aspect or the computing apparatus provided by the fifth aspect node.
- the mirroring label of the parent image of the mirror to be deployed is sent to each host, and each host determines the parent of the deployed image to be deployed.
- each host returns the mirrored label of the parent image of the deployed mirror to the management node for the management node to determine the deployment node.
- a fourteenth aspect of the present invention provides a container system, comprising a container system comprising at least two hosts provided by the tenth aspect, and the image deployment device or the sixth aspect provided by the fourth aspect A management node implemented by a computing device.
- the layer identifier of the mirroring layer of the image to be deployed is sent to each host, and each host determines the mirror of the deployed image to be deployed. Layers, each host returns the layer ID of the mirror layer of the deployed image to be deployed to the management node, so that the management node determines the deployment node.
- This container system distributes part of the management node's work to each host in a distributed manner, further improving the efficiency of the management node.
- FIG. 1 is a schematic diagram of an architecture of a container system according to an embodiment of the present application.
- FIG. 2 is a schematic diagram of a physical architecture of a container system according to an embodiment of the present application.
- FIG. 3 is a schematic diagram of a mirrored organization relationship provided by an embodiment of the present application.
- FIG. 4 is a schematic structural diagram of a computing device provided by an embodiment of the present application.
- FIG. 5 is a schematic flowchart of a mirroring deployment method according to an embodiment of the present disclosure
- FIG. 6 is a schematic diagram of a storage structure of a mirrored label according to an embodiment of the present disclosure
- FIG. 7(a) to 7(d) are schematic diagrams showing a matching process of a mirrored label according to an embodiment of the present application.
- FIG. 8 is a schematic flowchart diagram of another image deployment method according to an embodiment of the present disclosure.
- FIG. 9 is a schematic diagram of a storage structure of a layer identifier of a mirroring layer according to an embodiment of the present disclosure.
- 10(a) to 10(c) are schematic diagrams showing a matching process of layer identifiers of a mirroring layer according to an embodiment of the present application
- FIG. 11 is a schematic structural diagram of an image deployment apparatus according to an embodiment of the present disclosure.
- FIG. 12 is a schematic structural diagram of another image deployment apparatus according to an embodiment of the present disclosure.
- an image is a modification of the root file system (English: root filesystem) and an ordered collection of corresponding container runtime parameters.
- the image is a read-only (English: read only) file.
- the image consists of a mirror layer.
- the mirroring layer includes at least one of metadata corresponding to the mirroring layer (metadata) and file system modifications described by the mirroring layer.
- the metadata corresponding to the mirror layer is described by the json format, and may also be referred to as layer metadata (English: layer metadata); or the file system modification described by the mirror layer may also be referred to as an image file system modification set ( English: image filesystem changeset).
- layer metadata English: layer metadata
- image file system modification set English: image filesystem changeset
- the metadata describes the basic information of the mirroring layer, such as the creation date, the author, the layer identifier of the mirror layer, the layer identifier of the parent mirror layer, and the size of the mirror layer.
- Image file system modification of the mirror layer The set records an archive of the modified files in the parent mirror layer relative to the mirror layer.
- Each mirror layer is represented by a layer identifier, and each mirror is represented by a mirrored label.
- the layer identifier of the mirror layer refers to the identifier that the mirror layer is assigned at the time of creation.
- the layer identifier of each mirror layer is unique, and a 256-bit hexadecimal code expression is commonly used.
- a mirrored label (English: tag) refers to a descriptive, user-provided name that has a mapping relationship with a layer identifier of a mirroring layer.
- the image tag consists of two parts, the application name and version number of the image, such as Mysql: 5.4, where Mysql is the application name and 5.4 is the version number of Mysql.
- An image other than the base image consists of at least two mirror layers, each with a unique parent mirror layer.
- the image label of Mysql: 5.4 includes the layer identifiers of layer identifier 1, layer identifier 2, layer identifier 3, layer identifier 4, layer identifier 5, mirror layer and layer mirror of layer identifier 10, and The Mirror layer between Mysql:5.3 and Ubuntu:12.10 omitted in 3, and the mirror layer between Ubuntu:12.10 and the base image omitted in Figure 3.
- the image other than the base image includes at least one parent image.
- the parent image of Mysql: 5.4 includes Mysql: 5.3, Ubuntu: 12.10, and the base image, while the parent image of Mongo: 2.2 includes Ubuntu: 12.10, and The base image. Therefore, two images may have the same parent image, and if the parent image shared by the two images is not the base image, the two images also include the same mirror layer.
- the base image (English: base image) has no parent image.
- the base image generally includes the part of the operating system release that removes the operating system kernel.
- the image corresponds to the container, and the container corresponding to the image includes the image and the read-write layer superimposed on the image. For example, if you need to run a container corresponding to the Mysql application version 5.4, running the container requires mirroring the image as Mysql: 5.4. Multiple containers can be run on a single host. These containers can include different base images, but containers running on the same host share the operating system kernel.
- the mirror library refers to the mirror layer information included in each image, the parent image information included in each mirror, and the database of multiple mirror layers.
- the image library can be public, and users can access public image libraries via the Internet, such as Docker Hub. Users can also create private image libraries in private data centers.
- the mirror library includes at least one mirror family, each mirror group includes n mirrors, each of the two mirror images has a parent-child relationship, the first layer mirror is a base image, and the parent image of the n-th mirror includes a layer 1.
- n is a natural number greater than or equal to 2.
- Figure 3 includes two mirror families, including Mysql: 5.4, Mysql: 5.3, Ubuntu: 12.10, the mirror image of the base image 1, and includes Mongo: 2.2, Ubuntu: 12.10, mirroring family 2 of the base image.
- the base image in mirror family 1 is the first layer mirror
- Mysql: 5.4 is the nth layer mirror
- Mysql: 5.3 is the n-1 layer mirror.
- Mysql: 5.3 is its top-level parent image, that is, for the m-th layer image, the m-1 is mirrored as its top-level parent image, and the m-2 layer mirror is its next-level parent image.
- the layer identifier of the top mirror layer is 1, and the layer identifier of the next layer mirror layer is 2.
- the parent image of Mysql:5.3 and Mysql:5.3 can also constitute a mirroring group 3.
- the number of mirrors included in mirroring group 3 is one less than the number of mirrors included in mirroring group 1.
- the container system includes a management node and a plurality of hosts that run containers.
- the container system scheduling module and the container system management module are run on the management node.
- the container system management module is used to manage the resource usage information of each host, including the central processing unit (English: central processing unit, abbreviated: CPU) utilization, total memory, memory utilization, and hard disk (English: hard disk drive, abbreviation : HDD) or solid state drive (English: solid state drive, abbreviation: SSD) utilization.
- the container system management module is also used to manage the information of the mirror layer that has been deployed on the host, and the information of the image that has been deployed on the host.
- the container system scheduling module is configured to deploy the image according to the resource usage information of the host, the information of the mirror that has been deployed on the host, and the information of the mirror layer that has been deployed on the host.
- the container system scheduling module can also perform the container on the host according to the scaling policy. management.
- the host image management module is running on the host to manage the deployed image on the host.
- the container system management module and the host image management module on each host can collect the mirror information of each host to the container system management module in the master slave mode.
- the container system scheduling module determines, according to the mirror information of each host collected by the container system management module and the resource usage information of each host, that an image is deployed by a host, and the host image management module on the host is notified to interact with the image library. Obtain the mirror layer that is lacking on the host to deploy the image.
- One or more images can be deployed on each host.
- one type of image is deployed on multiple hosts, so that the corresponding container of the image does not stop running because of a host failure.
- the host can be a virtual machine or a physical machine
- the management node can be a physical machine or a virtual machine.
- Management nodes are typically deployed with different hosts on different physical machines.
- the container system scheduling module and the container system management module and each host access the image library through the network.
- FIG. 2 A schematic diagram of a physical architecture of the container system is shown in FIG. 2.
- the host and the management node are virtual machines, and one physical machine can run multiple hosts, and the management node and each host run on different physical machines.
- the working efficiency and stability of the container system are improved.
- the management node in FIG. 1 or FIG. 2 can be implemented by computing device 200 in FIG.
- the schematic diagram of the organizational structure of the computing device 200 includes a processor 202 and a memory 204, and may further include a bus 208 and a communication interface 206.
- the processor 202, the memory 204, and the communication interface 206 can implement communication connection with each other through the bus 208, and can also implement communication by other means such as wireless transmission.
- the memory 204 may include a volatile memory (English: volatile memory), such as random-access memory (English: random-access memory, abbreviation: RAM); the memory may also include non-volatile memory (English: non-volatile memory) For example, read-only memory (English: read-only memory, abbreviation: ROM), flash memory (English: flash memory), hard disk (English: hard disk drive, abbreviation: HDD) or solid state drive (English: solid state drive, Abbreviation: SSD); the memory 204 may also include a combination of the above types of memory.
- the program code for implementing the image deployment method provided in FIG. 5 of the present application is saved in the memory 204 and executed by the processor 202.
- Computing device 200 communicates with each host of the mirror library and container system via communication interface 206.
- the processor 202 can be a central processing unit (English: central processing unit, abbreviated: CPU).
- the processor 202 obtains the mirrored label of the image to be deployed, and obtains the mirrored label of the parent image of the image to be deployed from the mirror library according to the mirrored label of the image to be deployed. Then, at least two to-be-selected hosts are determined from the hosts in the container system, that is, the resource usage information of each host and the resource usage requirements of the to-be-deployed image are selected, and the resource usage requirements that can meet the requirements of the image to be deployed are selected from the hosts. Select the host. By selecting the host to be selected, the subsequent processing only needs to be directed to each candidate host, and it is not necessary to analyze all the hosts of the container system, thereby improving the processing efficiency.
- the processor 202 determines, according to the mirroring label of the parent image of the mirror to be deployed, the mirrored label of the mirror that has been deployed on each candidate host, and determines the parent image of the mirror to be deployed that is deployed on each candidate host.
- the parent image of the deployed image to be deployed on the candidate host based on the comparison result and the predetermined policy.
- the predetermined policy can be used as the deployment host for selecting the host with the largest parent image of the mirror to be deployed, or can be selected according to other parameters such as the resource usage of each candidate host.
- the deployment host can be the host with the largest number of parent mirrors to be deployed. You can also configure the host mirrors of the at least two hosts to be deployed. The process of selecting a host to enable the deployment host to download the image to be deployed requires less data to be downloaded, which improves the speed of image deployment.
- the processor 202 can also acquire and save the mirrored label of the deployed image on each host in the container system if the trigger timing is met.
- the triggering time of the triggering includes: presetting the period of obtaining the mirrored label of the deployed image on each host.
- the management node needs to obtain the mirrored label of the deployed image on each host to refresh each storage node of the management node.
- the mirroring situation on the host; the instructions for receiving the deployment container, for example, the user sends a request to deploy the container.
- the management node needs to obtain the mirrored label of the deployed image on each host to select the deployment host of the container. It also includes receiving a collection instruction sent by the user to the management node, instructing the management node to collect and save the mirrored label of the deployed image on each host.
- the present application also provides a method for image deployment.
- the management node in FIG. 1 and FIG. 2 and the computing device 200 in FIG. 4 execute the method during operation, and a schematic flowchart thereof is shown in FIG. 5.
- Step 402 The management node acquires a mirrored label of the image to be deployed.
- the management node When the container system needs to deploy a container, the management node obtains the mirrored label of the image to be deployed corresponding to the container to be deployed. In a common scenario, the container system needs to start the container according to the preset scaling policy of the container system or the request sent by the user. The management node receives the mirrored label of the mirror corresponding to the container, that is, the mirrored label of the image to be deployed.
- step 400 is also performed. Steps 400 and 402 may be performed discontinuously, and step 400 should be performed at least once before execution of step 402.
- Step 400 The management node acquires and saves the mirrored label of the deployed image on each host in the container system when the triggering timing is met.
- the management node obtains a mirrored label of all deployed images on each host, to Make the selection process of subsequent deployment hosts more accurate.
- the triggering time is met: the preset period arrives, or receives an instruction to deploy the container, or receives a collection instruction sent by the user, and the collection instruction indicates collecting and saving the mirror of the deployed image on the host in the container system. label.
- the management node obtains the mirrored label of the deployed image on each host to update the mirrored label of the deployed image on each host stored on the management node.
- the management node may also send an instruction to each host to receive an image of the mirror of each deployed image. After receiving the collection command sent by the user, the management node may send an instruction to each host, and each host is required to report the mirrored label of the mirror that has been deployed.
- the management node when the management node selects the deployment host to be deployed in the image deployment process, the management node can only use the mirrored labels of the partial mirrors deployed on each host. Therefore, in step 400, the deployed portions of the hosts can be obtained.
- the mirrored image label for example, does not obtain the mirrored label of the base image that has been deployed on each host.
- the management node when the management node selects the deployment host to be deployed in the mirroring process, the deployment host can be selected only from some hosts in the container system. Therefore, in step 400, the management node can only obtain and Saves the mirrored label of the deployed image on some hosts in the container system. In a common manner, it is possible to preset that some hosts in the container system do not participate in the deployment of the currently deployed image. In the step 400, the management node does not need to obtain the mirrored label of the deployed image on the host.
- the mirrored label of the deployed image on each host obtained by the management node can be dependent or non-dependent.
- the mirroring of the mirrored image of the mirrored host on the host 1 includes the following methods:
- Mode 1 the mirrored label of the mirror image included in each mirror family obtained by the management node, such as mirror family 1, Mysql: 5.4-Mysql: 5.3-Ubuntu: 12.10-base mirror; mirror family 2, Mongo: 2.2 -Ubuntu: 12.10 - Base image, where "-" indicates that the next image is the parent image of the previous image.
- Mode 2 The mirrorless non-dependent mirrored label obtained by the management node for each mirror family, such as mirroring group 1, Mysql: 5.4, Ubuntu: 12.10, Mysql: 5.3, base image; mirroring group 2, Ubuntu: 12.10 , Mongo: 2.2, the base image.
- the host 1 only needs to report the mirroring labels included in each mirroring group, and may not indicate the dependencies between the mirroring groups in each mirroring group.
- the Ubuntu: 12.10 and the base mirror are duplicated, and the host 1 only needs to report the mirrored label of the deployed mirror on the host 1.
- Host 1 merges the mirrored labels of the deployed images before reporting, which reduces the amount of data uploaded to the management node and improves the working efficiency of the management node.
- the image label of the mirrored image of each host is processed and then stored as mode 3.
- the application may be indexed according to the application name included in the mirrored label of the mirrored image of each host.
- mode 3 if the management node needs to query which hosts have the mirror corresponding to the Mysql application, it is not necessary to filter all the hosts. Only the application name Mysql can be used to obtain the host 1 and the host 2, and the management node is determined. The efficiency of the host where the image to be deployed is deployed.
- Step 404 The management node obtains the mirrored label of the parent image of the to-be-deployed image from the mirroring library according to the mirroring label of the image to be deployed.
- the management node obtains the mirrored label of all the parent images of the image to be deployed from the mirroring library, so that the selection process of the subsequent deployment host is more accurate.
- the management node may locally store the mirrored label of the parent image of the mirrored image. If the mirror to be deployed belongs to one of the mirrored nodes, the management node does not need to request the mirrored label of the parent image of the mirror to be deployed.
- step 400 the mirrored label of the partial mirror that has been deployed on each host can be obtained.
- the management node can also obtain the mirrored label of the partial mirror image of the image to be deployed.
- the mirrored label of the parent image of the mirror to be deployed may be a dependency.
- the mirrored label of the mirror to be deployed is MySQL. : Mysql: 5.4-Mysql: 5.3-Ubuntu: 12.10-based image; the mirrored label of the parent image of the mirror to be deployed can also be non-dependent.
- the mirror image of the parent image of the mirror is obtained, such as: Mysql: 5.4 , Ubuntu: 12.10, Mysql: 5.3, the base image.
- Step 406 The management node determines at least two candidate hosts from the hosts in the container system.
- the management node before the step 406, the management node further obtains the resource usage information of each host in the container system, and the step 406 includes determining, according to the resource usage information of the host in the container system, at least two requirements that meet the resource usage requirements of the image to be deployed. Host to be selected. The selection of the host to be selected makes the management node only need to select the deployment node from the host to be selected in the subsequent steps, which improves the working efficiency of the management node. Therefore, the candidate host needs to meet the resource usage requirements of the image to be deployed. The deployment node selected from the selected hosts can meet the requirements of the to-be-deployed image.
- the resource usage requirement of the image to be deployed expected by the user may be sent at the same time, for example, the CPU usage, memory usage, and total memory of the host deploying the image.
- the management node can query the resource usage request of the historically deployed image and invoke the resource usage requirement of the to-be-deployed image stored therein. The management node then combines the resource usage information of each host with the resource usage requirements of the to-be-deployed image to determine at least two candidate hosts that can meet the resource usage requirements of the to-be-deployed image.
- steps 404 and 406 are not limited. In particular, if step 406 is performed first, the management node can determine only one candidate host that can meet the resource usage requirements of the image to be deployed from the host in the container system, and the steps after step 404 and step 406 need not be performed. Select the host as the deployment host to be deployed.
- step 408 the management node determines the mirrored label of the deployed image on each candidate host.
- step 400 the management node has obtained the mirrored label of the deployed image on each host in the container system, and the management node obtains the mirrored label of the deployed image on each candidate host.
- Step 410 The management node allocates a deployment host to the image to be deployed according to the mirrored label of the parent image of the image to be deployed, and the mirrored label of the image to be deployed on the host to be deployed.
- the parent image of the to-be-deployed image that has been deployed meets the predetermined policy.
- the step 410 may include: matching the mirrored label of the parent image of the to-be-deployed image with the mirrored label of the mirrored image of each candidate host, and determining the parent image of the mirror to be deployed deployed on each candidate host; And compare the parent images of the deployed images to be deployed on each candidate host, according to The comparison result and the predetermined policy specify the deployment host, wherein the predetermined policy is to select the candidate host with the largest number of parent images of the to-be-deployed mirrors that have been deployed in the at least two candidate hosts as the deployment host.
- the size of the mirror layer that is not available on the host to be deployed is obtained. Selecting the resource usage on the host selects the host to be deployed. Therefore, in the actual application, with the design of the predetermined policy, the last selected deployment host may not be the candidate host with the largest number of parent images to be deployed.
- the mirrored label of the mirrored image of the mirrored image is stored on the host, and the mirrored label of the parent image of the mirror to be deployed is obtained from the mirroring library.
- the way the node determines the parent image of the mirror to be deployed that has been deployed on each candidate host is also different.
- the mirroring label of the mirror to be deployed is Mysql: 5.4.
- the mirrored label of the parent image of the image to be deployed obtained by the management node can be Mysql:5.4-Mysql:5.3-Ubuntu:12.10-base mirror with dependencies. Or no dependencies Mysql: 5.4, Ubuntu: 12.10, Mysql: 5.3, the base image.
- the mirrored label of the parent image of the mirror to be deployed is not related to the mirror image of the mirror to be deployed, the mirrored label of the parent image of the mirror to be deployed and the mirror image of the mirror of the mirror to be deployed on each candidate host are mirrored.
- the tags are matched one by one to determine the parent image of the deployed image to be deployed on each candidate host.
- Step 1 Match the mirrored label of the image to be deployed with the mirrored label of the deployed image on the currently selected host. On the host, all the parent images of the to-be-deployed image and the image to be deployed are deployed.
- Step 2 mirror the top-level parent image of the mirror to be deployed. If the mirroring label of the mirrored image is matched, the mirroring label of the mirror image is configured. If the matching mirror is configured, the mirror image of the current mirroring mirror is configured. The mirroring label of the mirror that has been deployed on the host to be selected is matched. The current mirror is the parent mirror of the parent mirror of the mirror to be deployed in the previous step. If it matches, the current host is deployed. If all the parent images of the mirror are not matched, go back to step 3 until they match each parent image of the mirror to be deployed. In any step, if the currently selected host matches the mirrored label, the next step is not performed.
- Another candidate host is designated to perform the foregoing steps until all the selected hosts perform the above steps, that is, each candidate host is determined to have been selected.
- the to-be-deployed image is deployed on the candidate host that matches the mirrored label of the image to be deployed. That is, Mysql: 5.4 has been deployed on the host 1 to be selected, and all parent images of Mysql: 5.4 have been deployed.
- the mirrored label of the top-level parent image of the to-be-deployed image is matched with the mirrored label of the deployed image on the candidate host other than the host 1 of the candidate host, and the top-level parent image of the mirror to be deployed is matched.
- the parent image of the mirror to be deployed is deployed on the candidate host of the mirrored label.
- MySQL and 5.3 are used to match each candidate host.
- the host to be selected in the previous step does not need to be matched again.
- the specific matching process is as follows 508 to 513.
- the matching process of the candidate host 4 is omitted in the figure. All the parent images of the mirrors to be deployed are deployed on the host to be mirrored.
- the parent mirrors of Mysql: 5.4 are deployed on the host 2 to be deployed.
- the mirrored label of the mirror of the next-level parent image of the image to be deployed is matched with the mirrored label of the mirror that has been deployed on the candidate host that is not matched with the previous step in the at least two hosts.
- the parent image other than the top-level parent image of the image to be deployed is deployed on the candidate host of the mirror image of the parent image.
- Ubuntu:12.10 is used to match each candidate host.
- the host to be selected on which the previous step has been matched does not need to be matched again.
- the specific matching process is as follows 514 to 517.
- a parent image other than the top-level parent image of the mirror to be deployed is deployed on the candidate host that matches the mirrored label of the parent image of the mirror to be deployed.
- the method for obtaining the parent image of the to-be-deployed image is configured on each of the to-be-selected hosts, and the parent image of the to-be-deployed image to be deployed is compared with each other. Improved matching efficiency.
- the unselected mirrored label of the mirror image included in each mirroring group is reported to the management node by the candidate host. Therefore, the parent image of the mirror to be deployed that has been deployed on the candidate host is determined.
- the mirroring labels of the mirrors of the mirrors to be deployed are compared with the mirrored labels of the mirrors of the mirrors that have been saved.
- the difference from the mode 1 is that the mirrored label of the deployed image on each host stored in the management node is first searched according to the application in the mirrored label of the image to be deployed.
- Figure 7(d) it can be seen from 518 that only Mysql: 5.4 is deployed on the host 1 to be selected.
- only Mysql:5.3 is deployed on the host 3 to be selected, and the hosts 1 to 4 are selected through the 520. Ubuntu is deployed: 12.10.
- the management node can obtain the parent image of the deployed image to be deployed on each candidate host.
- the method for obtaining the parent image of the to-be-deployed image is configured on each of the to-be-selected hosts, and the parent image of the to-be-deployed image to be deployed is compared with each other. Improved matching efficiency.
- Steps 400 to 410 may be performed by the container system management module of the management node. After determining that the host is deployed, the container system management module sends the identifier of the deployment host to the container system scheduling module, and the container system scheduling module is configured according to the deployment host. The identifier indicates that the deployment host deploys the image to be deployed.
- the image mirroring method corresponding to Figure 5 is used to determine the overlap of the mirrors that have been deployed on the hosts and the mirrors that are to be deployed. The deployment speed of the image to be deployed.
- the management node of FIG. 1 or FIG. 2 can also be implemented by the same computing device as the computing device 200 of FIG.
- the computing device includes a processor, a memory, and may also include a bus, a communication interface.
- the processor, the memory and the communication interface can realize communication connection with each other through a bus, and can also realize communication by other means such as wireless transmission.
- the memory may include volatile memory, such as RAM; it may also include non-volatile memory, such as ROM, flash memory, HDD or SSD; the memory may also include a combination of the above types of memory.
- volatile memory such as RAM
- non-volatile memory such as ROM, flash memory, HDD or SSD
- the program code for implementing the image deployment method provided in FIG. 8 of the present application may be saved in a memory and executed by a processor.
- the computing device communicates with each host of the mirror library and the container system via a communication interface.
- the processor can be a CPU.
- the processor obtains the mirroring label of the image to be deployed, and obtains the layer identifier of the mirroring layer of the image to be deployed from the mirroring library according to the mirroring label of the image to be deployed. Then, at least two to-be-selected hosts are determined from the hosts in the container system, that is, the resource usage information of each host and the resource usage requirements of the to-be-deployed image are selected, and the resource usage requirements that can meet the requirements of the image to be deployed are selected from the hosts. Select the host. By selecting the host to be selected, the subsequent processing only needs to be directed to each candidate host, and it is not necessary to analyze all the hosts of the container system, thereby improving the processing efficiency.
- the processor determines the mirror layer of the to-be-deployed image that is deployed on each candidate host, and compares the layer ID of the mirroring layer of the image to be deployed with the layer identifier of the mirroring layer of each to-be-selected host.
- the layer ID of the mirroring layer of the mirror to be deployed is configured on the host to be deployed.
- the deployment host is configured to deploy the mirror to be deployed according to the comparison result and the predetermined policy.
- the predetermined policy can be selected as the deployment host with the most selected mirroring layer of the mirrored layer to be deployed, or can be selected in combination with other parameters, such as the resource usage of each candidate host.
- the processor can also acquire and save the layer identifiers of the mirror layers that have been deployed on each host in the container system, while satisfying the trigger timing.
- the triggering timing includes: presetting the period of obtaining the layer identifier of the mirrored layer deployed on each host. When the period arrives, the management node needs to obtain the layer identifier of the mirrored layer deployed on each host, so as to refresh each storage node of the management node.
- the management node needs to obtain the layer identifier of the deployed mirror layer on each host to select the deployment host of the container. And receiving a collection instruction sent by the user to the management node, instructing the management node to receive Set and save the layer ID of the deployed mirror layer on the host.
- the process of selecting a host to enable the deployment host to download the image to be deployed requires less data to be downloaded, which improves the speed of image deployment.
- the present application also provides a method for image deployment.
- the management node in FIG. 1 and FIG. 2 and the foregoing computing device execute the method during operation, and the flow chart is shown in FIG. 8 .
- Step 602 The management node acquires a mirrored label of the image to be deployed.
- the management node When the container system needs to deploy a container, the management node obtains the mirrored label of the image to be deployed corresponding to the container to be deployed. In a common scenario, the container system needs to start the container according to the preset scaling policy of the container system or the request sent by the user. The management node receives the mirrored label of the mirror corresponding to the container, that is, the mirrored label of the image to be deployed.
- step 600 is also performed. Steps 600 and 602 may be performed discontinuously, and step 600 should be performed at least once before execution of step 602.
- Step 600 The management node acquires and saves the layer identifier of the deployed mirror layer on the host in the container system, when the trigger timing is met.
- the management node obtains, from each host, a layer identifier of all deployed mirror layers on each host, so that the selection process of the subsequent deployment host is more accurate.
- the triggering time is met: the preset period arrives, or receives an instruction to deploy the container, or receives a collection instruction sent by the user, and the collection instruction indicates collecting and saving the deployed mirror layer on the host in the container system.
- Layer identification The management node obtains the layer identifier of the deployed mirroring layer on each host to update the layer identifier of the deployed mirroring layer on each host stored on the management node. The management node may also send an instruction to each host, and each host is required to report the layer identifier of the mirror layer that has been deployed. After receiving the collection command sent by the user, the management node may send an instruction to each host, and each host is required to report the layer identifier of the mirror layer that has been deployed.
- the management layer can only use the layer identifier of the part of the mirroring layer deployed on each host. Therefore, in step 600, the deployed host can be obtained.
- the management node when the management node selects the deployment host to be deployed in the mirroring process, the deployment host of the image to be deployed can be selected only from some hosts in the container system. Therefore, in step 600, the management node can only obtain and Saves the layer ID of the deployed mirror layer on some hosts in the container system. In a common manner, it is possible to preset that some hosts in the container system do not participate in the deployment of the currently deployed image. In the step 600, the management node does not need to obtain the layer identifier of the mirrored layer deployed on the host.
- the layer identifier of the deployed mirroring layer on each host acquired by the management node may be dependent or non-dependent.
- the layer ID of the mirroring layer deployed on the host 5 of the management node includes the following methods:
- Mode 4 The dependent layer identifier of the mirroring layer of each mirroring group reported by the host 5 to the management node, such as the mirroring group 1, the layer identifier 1 layer identifier 2 layer identifier 3 layer identifier 4 layer identifier 5 - Layer identification 10; mirror family 2, layer identification 7-layer identification 8-layer identification 10, where "-" indicates that the latter mirror layer is the parent mirror layer of the previous mirror layer.
- Mode 5 The non-dependent layer identifier of the mirroring layer of each mirroring group reported by the host 5 to the management node, such as the mirroring group 1, the layer identifier 1, the layer identifier 3, the layer identifier 2, the layer identifier 5, and the layer identifier 4 , layer identifier 10; mirror family 2, layer identifier 8, layer identifier 7, layer identifier 10.
- the host 5 only needs to report the layer ID of each mirroring group including the mirroring layer, and may not indicate the dependency relationship between the mirroring layers in each mirroring group. Further, in the mode 5, the layer IDs of the same mirroring layer of different mirroring groups may be merged.
- the layer identifier 10 is repeated, and the host 5 only needs to be reported to be deployed on the host 5.
- the mirrored image label includes: layer identifier 1 to layer identifier 10.
- the host 5 merges the layer identifiers of the deployed mirroring layers before reporting, which can reduce the amount of data uploaded to the management node and improve the working efficiency of the management node.
- the layer ID of the mirroring layer deployed on each host is processed and then stored as mode 6.
- the application name may be used according to the application name included in the layer identifier of the mirrored layer deployed on each host. , record the layer ID of the deployed mirror layer on each host.
- mode 6 if the management node needs to query which hosts have the mirror layer corresponding to the Mysql application, it is not necessary to filter all the hosts. Only the application name Mysql can be used to obtain the host 5 and the host 6, and the management node is improved. Determine the efficiency of the host where the image to be deployed is deployed.
- step 604 the management node obtains the layer identifier of the mirroring layer of the to-be-deployed image from the mirroring library according to the mirroring label of the image to be deployed.
- the management node obtains the layer identifiers of all the mirroring layers of the mirror to be deployed from the mirroring library, so that the selection process of the subsequent deployment hosts is more accurate.
- the management node may locally store the layer identifier of the mirroring layer of the mirrored image. If the mirror to be deployed belongs to one of the mirroring layers, the management node does not need to request the layer identifier of the mirroring layer of the mirror to be deployed.
- step 600 the layer identifier of the partial mirroring layer that has been deployed on each host may be obtained.
- the management node may also obtain the layer identifier of the partial mirroring layer of the image to be deployed.
- the layer identifier of the mirroring layer of the image to be deployed obtained from the mirroring library may be a dependency.
- the mirroring label of the mirroring layer of the image to be deployed is exemplified by Mysql: 5.4.
- the layer identifier of the mirror layer of the mirror to be deployed may also be non-dependent, and the mirror image of the mirror image is obtained.
- the layer identifiers of the layer are: layer identifier 1, layer identifier 2, layer identifier 5, layer identifier 4, layer identifier 3, and layer identifier 10.
- Step 606 The management node determines at least two candidate hosts from the hosts in the container system.
- the management node before the step 606, the management node further acquires the resource usage information of each host in the container system, and the step 606 includes determining, according to the resource usage information of the host in the container system, at least two requirements that meet the resource usage requirements of the image to be deployed. Host to be selected. The selection of the host to be selected makes the management node only need to select the deployment node from the host to be selected in the subsequent steps, which improves the working efficiency of the management node. Therefore, the candidate host needs to meet the resource usage requirements of the image to be deployed. The deployment node selected from the selected hosts can meet the requirements of the to-be-deployed image.
- the resource usage requirement of the image to be deployed such as CPU usage and memory usage
- the resource usage requirement of the mirrored resource is used.
- the management node also queries the resource usage request of the historically deployed image and invokes the resource usage requirements of the image to be deployed stored therein.
- the management node then combines the resource usage information of each host with the resource usage of the image to be deployed. And determining, at least two candidate hosts that can meet the resource usage requirements of the image to be deployed.
- step 604 and step 606 are not limited. In particular, if step 606 is performed first, the management node can determine only one candidate host that can meet the resource usage requirements of the image to be deployed from the host in the container system, and the steps after step 604 and step 606 need not be performed. Select the host as the deployment host to be deployed.
- Step 608 The management node determines a layer identifier of the mirror layer that has been deployed on each candidate host.
- step 600 the management node has obtained the layer identifier of the deployed mirror layer on each host in the container system, and the management node obtains the layer identifier of the mirror layer that has been deployed on each candidate host.
- Step 610 According to the layer identifier of the mirroring layer of the image to be deployed, and the layer identifier of the mirroring layer deployed on each candidate host, the deployment host is configured for the to-be-deployed image, and the deployment host is used to deploy the to-be-deployed image.
- the mirroring layer of the deployed image to be deployed meets the predetermined policy.
- the step 610 may include: matching the layer identifier of the mirroring layer of the mirror to be mirrored with the layer identifier of the mirroring layer that is deployed on each candidate host, and determining the mirror layer of the mirror to be deployed deployed on each candidate host. And the mirroring layer of the to-be-deployed image that is deployed on each candidate host is compared, and the deployment host is specified according to the comparison result and the predetermined policy.
- the predetermined policy is to select the deployed image to be deployed in at least two selected hosts. The host to be selected with the largest number of mirroring layers is the deployment host.
- the size of the mirroring layer that is not available on the host to be deployed is obtained. Selecting the resource usage on the host selects the host to be deployed. Therefore, in the actual application, with the design of the predetermined policy, the last selected deployment host may not be the host with the largest number of mirroring layers.
- the layer identifier of the mirroring layer of the mirrored layer is saved on the host, and the layer identifier of the mirroring layer of the mirror to be deployed is obtained from the mirroring library.
- the way in which the management node determines the mirroring layer of the deployed image to be deployed on each candidate host is also different.
- the mirroring label of the image to be deployed is Mysql: 5.4.
- the layer identifier of the mirroring layer of the image to be deployed obtained by the management node can be the layer ID of the layer that has the dependency. - Layer identification 5-layer identification 10, or non-dependent layer identification 1, layer identification 2, layer identification 5, layer Identification 4, layer identification 3, layer identification 10.
- the layer identifier of the mirroring layer of the mirror to be deployed is not related to the mirroring layer, the layer identifier of the mirroring layer of the mirror to be deployed and the layer of the mirroring layer of the mirror to be deployed are deployed on each candidate host. The identifiers are matched one by one to determine the mirror layer of the deployed image to be deployed on each candidate host.
- the layer identifier of the mirror layer of the image to be deployed is obtained from the mirror library in step 604, there is a dependency.
- the first selection is made. The host to be selected determines the currently selected host, and then matches the layer identifier of the mirrored layer deployed on the currently selected host according to the layer identifier of the mirroring layer of the image to be deployed.
- the matching sequence can be matched from the top mirroring layer, including the following steps: Step 1: Match the layer identifier of the top mirroring layer of the mirror to be mirrored with the layer identifier of the mirrored layer currently deployed on the host to be selected. If yes, determine that all mirroring layers of the mirror to be deployed are deployed on the host to be selected. If the mapping is not matched, go to step 2. In step 2, set the layer ID of the current mirroring layer to the mirroring layer of the currently deployed host. The layer ID is matched. The current mirroring layer is the parent mirroring layer of the mirroring layer of the mirror to be deployed in the previous step. If the mirroring layer is matched, the mirroring layer below the current mirroring layer is deployed on the currently selected host.
- the mirroring layer below the current mirroring layer includes the parent mirroring layer of the current mirroring layer and the parent mirroring layer of the parent mirroring layer of the current mirroring layer. If it does not match, return to step 2 until it matches each mirror of the mirror to be deployed. Floor. In any step, if the currently selected host matches the layer identifier of the mirror layer, the next step is not performed. After a candidate host is designated as the currently selected host and the foregoing steps are performed, another candidate host is designated to perform the foregoing steps until all the selected hosts perform the above steps, that is, each candidate host is determined to have been selected. The mirroring layer of the deployed image to be deployed.
- the layer identifier 1 is matched with the layer identifier of the mirror layer that has been deployed on each candidate host. If a layer identifier 1 is matched on a candidate host, it is deployed on the candidate host. If the layer identifier of the mirroring layer already has a dependency, there is no need to continue matching on the candidate host, such as 701. If the matching of the selected host has not been matched to the layer ID 1, the layer ID of the mirroring layer that has been deployed on the host is matched until the matching of all the layers is completed, such as 702 and 703. 704, 705. The matching process of the candidate host 7 and the candidate host 8 is omitted in the figure. Match the top mirror layer of the image to be deployed The mirror to be deployed is deployed on the host to be selected. The mirroring layer of Mysql: 5.4 is deployed on the host 5 to be selected.
- the layer identifier of the mirror layer of the next-layer mirroring layer of the to-be-deployed image is matched with the layer identifier of the mirrored layer that has been deployed on the candidate host that is not matched with the previous step in the at least two selected hosts, and the mirror to be deployed is matched. All the mirroring layers except the top mirroring layer of the mirror to be deployed are deployed on the candidate host of the layer of the mirror layer.
- the layer identifier 2 is matched with each candidate host, and the candidate host that has been matched in the previous step does not need to be matched again.
- the specific matching process is as 706 to 709.
- the matching process of the candidate host 7 and the candidate host 8 is omitted in the figure. Repeat this step.
- the parent mirroring layer of the mirroring layer matches the remaining candidate hosts until it is matched on each candidate host.
- the method for obtaining the parent image of the to-be-deployed image is configured on each of the to-be-selected hosts, and the parent image of the to-be-deployed image to be deployed is compared with each other. Improved matching efficiency.
- the non-dependent layer identifier of the mirroring layer included in each mirroring group is reported to the management node by the candidate host. Therefore, the mirroring layer of the to-be-deployed image that has been deployed on the candidate host is determined. The layer ID of the mirroring layer of the mirror to be deployed is compared with the layer ID of the mirroring layer of the saved mirrors. .
- the difference from the mode 5 is that the layer identifier of the mirrored layer deployed on each host stored in the management node is queried according to the application in the mirrored label of the image to be deployed.
- the layer identifiers 1 to 5 are all mirrored by Mysql. Therefore, only the candidate host 5 and the candidate host 6 are matched. Therefore, only the host 5 to be selected is known by 710 to 714.
- the layer identifier 1 corresponds to the mirror layer and the lower layer mirror layer, and the layer identifier 4 corresponding to the mirror layer and the lower layer mirror layer are deployed on the host 6 to be selected.
- the mirror layer corresponding to the layer identifier 10 belongs to the Ubuntu.
- the mirror layer corresponding to the layer identifier 10 is deployed on the host 5 to the host 8 to be selected.
- the management node can obtain the mirrored layer of the deployed image to be deployed on each candidate host.
- the layer identifiers of the layer are compared one by one, which improves the matching efficiency.
- Steps 600 to 610 may be performed by the container system management module of the management node. After the container system management module determines that the host is deployed in step 610, the identifier of the deployment host is sent to the container system scheduling module, and the container system scheduling module is configured according to the deployment host. The identifier indicates that the deployment host deploys the image to be deployed.
- the mirroring method corresponding to Figure 8 is to determine the degree of overlap between the mirroring layer and the mirroring layer included in the image to be deployed on each host, and select the host with fewer mirroring layers to be deployed in the deployment process. The deployment speed of the image to be deployed is effectively improved.
- the image deployment method corresponding to FIG. 8 and the image deployment method corresponding to FIG. 5 have their own characteristics.
- the image deployment method corresponding to FIG. 8 determines the deployment host by comparing the mirror layer of the image to be deployed with the deployed mirror layer, and is more accurate.
- the corresponding image deployment method determines the deployment host by comparing the parent image of the image to be deployed with the deployed image, which is faster than the comparison of the mirror layer. In practice, these two image deployment methods can also be combined.
- the embodiment of the present invention further provides a mirror deployment device 800, which may be implemented by the computing device 200 shown in FIG. 4, or may be implemented by an application-specific integrated circuit (ASIC) or programmable.
- Logic device (English: programmable logic device, abbreviation: PLD) implementation.
- the PLD may be a complex programmable logic device (CPLD), an FPGA, a general array logic (GAL), or any combination thereof.
- the image deployment device 800 is configured to implement the image deployment method shown in FIG. 5. When the image deployment method shown in FIG. 5 is implemented by software, the image deployment device 800 can also be a software module.
- the schematic diagram of the organization of the image deployment apparatus 800 includes an acquisition unit 802 and a processing unit 804.
- the steps 400 and 402 in the image deployment method shown in FIG. 5 and the part of the resource usage information of each host in the container system are performed in the step 406.
- the processing unit 804 is in operation, the method shown in FIG. 5 is performed. Step 404 to step 410 and its alternatives in the image deployment method.
- the image deployment device can determine the overlap of the mirrors that have been deployed on each host and the parent image included in the image to be deployed, and select the hosts that need to be downloaded during the deployment process to deploy the mirrors to be deployed. The deployment speed of the deployment image.
- the embodiment of the present invention further provides a mirror deployment device 1000, which may be implemented by the computing device 200 shown in FIG. 4, and may also be implemented by an ASIC or a PLD.
- the above PLD may be a complex programmable CPLD, an FPGA, a GAL, or any combination thereof.
- the image deployment device 1000 is configured to implement the image deployment method shown in FIG. 8. When the image deployment method shown in FIG. 8 is implemented by software, the image deployment device 1000 may also be a software module.
- the schematic diagram of the organization of the image deployment apparatus 1000 includes an acquisition unit 1002 and a processing unit 1004.
- the steps 600 and 602 and the step 606 in the image deployment method shown in FIG. 8 are performed to acquire the resource usage information of each host in the container system.
- the processing unit 1004 is in operation, the execution shown in FIG. 8 is performed. Step 604 to step 610 and its alternatives in the image deployment method.
- the image deployment device can determine the overlap between the mirroring layer and the mirroring layer included in the image to be deployed on each host, and select the host with fewer mirroring layers to be deployed in the deployment process. The deployment speed of the image to be deployed.
- the embodiment of the present invention further provides a first image deployment method applied to the container system shown in FIG. 1 or FIG. 2, including:
- the host in the container system sends the mirrored label of the locally deployed image to the management node when the trigger timing is met.
- the triggering time is met: the preset period arrives, or the collection instruction sent by the management node is received, the collection instruction indicates that the mirrored label of the deployed image is sent to the management node, or the locally deployed image is detected to be changed. .
- the host image management module is deployed on the host of the container system.
- the host image management module of each host monitors the image deployed on the host, that is, the locally deployed image. Mirroring, whether the user deletes the mirror, etc. If the change occurs, the host image management module sends the mirrored label of the deployed image on the host to the management node to update the information on the management node.
- the host can also report the mirrored label of the deployed image when the preset period arrives.
- the host can also report the collection command sent by the management node.
- This image is deployed in the mirroring mode to determine the overlap of the mirrors that have been deployed on the hosts of the container system and the parent images that are to be deployed. The speed at which the container system deploys the image to be deployed.
- the embodiment of the present invention further provides a second image deployment method applied to the container system shown in FIG. 1 or FIG. 2, including:
- the host in the container system sends the layer identifier of the locally deployed mirror layer to the management node when the trigger timing is met.
- the triggering time is met: the preset period arrives, or the collection instruction sent by the management node is received, the collection instruction indicates that the mirrored label of the deployed image is sent to the management node, or the locally deployed image is detected to be changed. .
- the host image management module is deployed on the host of the container system.
- the host image management module of each host monitors the mirrored layer deployed on the host, that is, the locally deployed image. If the mirroring layer is downloaded, whether the user deletes the mirroring layer, etc., if the change occurs, the host image management module sends the layer identifier of the mirrored layer deployed on the host to the management node to update the information on the management node.
- the host can also report the layer ID of its deployed mirror layer when the preset period arrives.
- the host can also report the collection command sent by the management node.
- the management node After the management node receives and saves the layer identifier of the mirrored layer deployed on the host in the container system, refer to the image deployment method corresponding to Figure 8.
- the image deployment method is to determine the degree of overlap between the mirroring layer and the mirroring layer included in the image to be deployed on the host of the container system, and select the host with fewer mirroring layers to be deployed in the deployment process. It effectively improves the speed at which the container system deploys the image to be deployed.
- the embodiment of the invention also provides a first container system, the schematic structure of which is shown in FIG. 1 or FIG.
- the first image deployment method applied to the container system is performed.
- the embodiment of the invention further provides a second container system, and the organization structure of the container system is as follows: Figure 1 or Figure 2.
- Figure 1 the organization structure of the container system is as follows: Figure 1 or Figure 2.
- the implementation details of the image deployment method shown in FIG. 5 can be used in the image deployment apparatus 800, and the first image deployment method applied to the container system.
- the operations performed by the management node can also refer to the image deployment method shown in FIG. 5.
- the implementation details of the image deployment method shown in FIG. 8 can be used in the image deployment apparatus 1000, and the second image deployment method applied to the container system.
- the action performed by the management node can also refer to the image deployment method shown in FIG. .
- the management node of the first container system can be implemented by the computing device 200 or the image deployment device 800.
- the management node of the second container system can be implemented by the computing device or the image deployment device 1000 for performing the image deployment method shown in FIG.
- the methods described in connection with the present disclosure can be implemented by a processor executing software instructions.
- the software instructions can be composed of corresponding software modules, which can be stored in RAM, flash memory, ROM, erasable programmable read only memory (English: erasable programmable read only memory, abbreviation: EPROM), electrically erasable Programming an audio-only memory (English): hard disk, optical disk, or any other form of storage medium known in the art.
- the functions described herein may be implemented in hardware or software.
- the functions may be stored in a computer readable medium or transmitted as one or more instructions or code on a computer readable medium.
- a storage medium may be any available media that can be accessed by a general purpose or special purpose computer.
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Medical Treatment And Welfare Office Work (AREA)
- Processing Or Creating Images (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
一种镜像部署方法,该镜像部署方法运用于容器系统,通过采集各个主机上已部署的镜像信息,在获取待部署镜像的镜像标签后,判断各个主机上已部署的镜像与待部署镜像之间的重合程度,重合程度越高的主机部署该待部署镜像时需要下载的数据量越小,部署待部署镜像的速度越快,管理节点最后根据各个主机的重合程度,选择出部署该待部署镜像的部署主机。
Description
本申请涉及计算机技术领域,尤其涉及运用于容器技术中的镜像部署方法、镜像部署装置,用于镜像部署的计算设备,以及容器系统。
容器技术是一种基于操作系统的轻量级虚拟技术,容器运行于操作系统之上的用户空间,一个主机上的容器共用能够操作系统内核。近年来,容器技术逐渐成为云计算研究的热点,容器技术的核心之一即分层镜像的使用。容器技术中使用的镜像由镜像层组成,每一个镜像层包括在该镜像层的父镜像层(英文:parent image layer)的基础上进行的各种修改,因此一个完整的镜像必须包括其所需的全部镜像层。用户可以制作并发布自己的镜像,也可以从镜像库中下载所需的镜像,将镜像下载至主机上之后,根据下载的镜像可以启动该镜像对应的容器。
容器系统中一般运行有多个用于运行容器的主机,当用户希望在容器系统中部署某一容器时,容器系统首先需要从多个主机中选择一个来运行该容器,该主机随后检测被选择的主机已存储的镜像层能否支持该容器的启动,如果不能支持,该主机需要向镜像库请求缺乏的镜像层。因此,容器部署所消耗的时间包括容器所需镜像的下载时间和镜像下载后容器的启动时间,而镜像下载后容器的启动时间很短,制约容器部署速度的往往是下载镜像耗时较长。
发明内容
本申请提供了一种镜像部署方法,通过比较待部署镜像的父镜像与各个主机上已部署的镜像选择待部署镜像的部署主机,提升了镜像的部署速度。
本申请的第一方面,提供了一种镜像部署方法,管理节点获取各个主机上已部署的镜像的镜像标签,本步骤可以实现于镜像部署方法之前,无须在每次
部署镜像时都执行,例如可以周期性的执行,或在满足触发时机的情况下执行。管理节点获取待部署镜像的镜像标签后,获取待部署镜像的父镜像的镜像标签,并与之前获得的各个主机上已部署的镜像的镜像标签进行比较,则可以得知各个主机上已部署的镜像中哪些属于待部署镜像的父镜像,也即可以得知各个主机相对于待部署镜像,还缺乏哪些部分。通过各个主机的比较结果以及预定策略来选择一个相对需要下载量较少的主机来部署该待部署镜像,以提升镜像部署的速度。
结合第一方面,在第一方面的第一种实现方式中,管理节点获取各个主机上已部署的镜像的镜像标签的触发时机包括:预设的周期到达,接收到部署容器的指令或接收到用户发送的收集指令。
结合第一方面或第一方面的第一种实现方式,在第一方面的第二种实现方式中,管理节点还获取了每个主机的资源使用信息,被管理节点比较过的主机,可以为管理节点根据每个主机的资源使用信息确定满足待部署镜像的资源使用要求的主机,也即待选主机。通过待选主机的确定,减少了管理节点后续进行比较的工作量,提升了管理节点的工作效率。
结合第一方面或第一方面的任一种实现方式,在第一方面的第三种实现方式中,管理节点选择出的部署节点可以为已部署待部署镜像的父镜像数量最多的主机。已部署待部署镜像的父镜像数量最多的主机所需的下载量也最小,进一步提升了部署待部署镜像的速度。
结合第一方面或第一方面的任一种实现方式,在第一方面的第四种实现方式中,由于运用于容器领域的镜像与其父镜像有着对应关系,一般而言如果一个主机部署了一个镜像,则该主机部署了该镜像的全部父镜像。因此管理节点确定各个主机上已部署的待部署镜像的父镜像的过程中,可以不将待部署镜像的父镜像的镜像标签与各个主机上已部署的镜像的镜像标签逐一比较,而是从待部署镜像的镜像标签开始,从上往下用待部署镜像的父镜像的镜像标签与各个主机上已部署的镜像的镜像标签比较,节省了管理节点比较的时间,提升了管理节点的工作效率。
本申请的第二方面,提供了一种镜像部署方法,管理节点获取各个主机上
已部署的镜像层的层标识,本步骤可以实现于镜像部署方法之前,无须在每次部署镜像时都执行,例如可以周期性的执行,或在满足触发时机的情况下执行。管理节点获取待部署镜像的镜像标签后,获取待部署镜像的镜像层的层标识,并与之前获得的各个主机上已部署的镜像层的层标识进行比较,则可以得知各个主机上已部署的镜像层中哪些属于待部署镜像,也即可以得知各个主机相对于待部署镜像,还缺乏哪些镜像层。通过各个主机的比较结果和预定策略来选择一个相对需要下载量较少的主机来部署该待部署镜像,以提升镜像部署的速度。
结合第二方面,在第二方面的第一种实现方式中,管理节点获取各个主机上已部署的镜像层的层标识的触发时机包括:预设的周期到达,接收到部署容器的指令或接收到用户发送的收集指令。
结合第二方面或第二方面的第一种实现方式,在第二方面的第二种实现方式中,管理节点还获取了每个主机的资源使用信息,被管理节点比较过的主机,可以为管理节点根据每个主机的资源使用信息确定满足待部署镜像的资源使用要求的主机,也即待选主机。通过待选主机的确定,减少了管理节点后续进行比较时的工作量,提升了管理节点的工作效率。
结合第二方面或第二方面的任一种实现方式,在第二方面的第三种实现方式中,管理节点选择出的部署节点可以为已部署待部署镜像的镜像层数量最多的主机。已部署待部署镜像的镜像层数量最多的主机所需的下载量也最小,进一步提升了部署待部署镜像的速度。
结合第二方面或第二方面的任一种实现方式,在第二方面的第四种实现方式中,由于运用于容器领域的镜像层与其父镜像层有着对应关系,一般而言如果一个主机部署了一个镜像层,则该主机部署了该镜像层的父镜像层及其父镜像层的父镜像层等。因此管理节点确定各个主机上已部署的待部署镜像的镜像层的过程中,可以不将待部署镜像的镜像层的层标识与各个主机上已部署的镜像的层标识逐一比较,而是从待部署镜像的顶层镜像层的层标识开始,向下进行比较,节省了管理节点比较的时间,提升了管理节点的工作效率。
本申请的第三方面,提供了一种镜像部署装置,该镜像部署装置用于在容
器系统中部署镜像,该镜像部署装置包括了用于执行第一方面提供的镜像部署方法的至少一个单元。
本申请的第四方面,提供了一种镜像部署装置,该镜像部署装置用于在容器系统中部署镜像,该镜像部署装置包括了用于执行第二方面提供的镜像部署方法的至少一个单元。
本申请的第五方面,提供了一种计算设备,该计算设备用于在容器系统中部署镜像,该计算设备可以为容器系统中的管理节点,该计算设备运行时执行第一方面提供的镜像部署方法。
本申请的第六方面,提供了一种计算设备,该计算设备用于在容器系统中部署镜像,该计算设备可以为容器系统中的管理节点,该计算设备运行时执行第二方面提供的镜像部署方法。
本申请的第七方面,提供了一种镜像部署方法,该镜像部署方法运用于容器系统中的主机与管理节点,其中主机在满足触发时机的情况下,向管理节点发送本地已部署的镜像的镜像标签,其中管理节点执行的部分参考第一方面提供的镜像部署方法。
本申请的第八方面,提供了一种镜像部署方法,该镜像部署方法运用于容器系统中的主机与管理节点,其中主机在满足触发时机的情况下,向管理节点发送本地已部署的镜像层的层标识,其中管理节点执行的部分参考第二方面提供的镜像部署方法。
本申请的第九方面,提供了一种主机,该主机在满足触发时机的情况下,向管理节点发送本地已部署的镜像的镜像标签,满足触发时机包括:预设的周期到达,或接收到管理节点发送的收集指令,收集指令指示向管理节点发送已部署的镜像的镜像标签,或检测到本地已部署的镜像发生变化。
本申请的第十方面,提供了一种主机,该主机在满足触发时机的情况下,向管理节点发送本地已部署的镜像层的层标识,满足触发时机包括:预设的周期到达,或接收到管理节点发送的收集指令,收集指令指示向管理节点发送已部署的镜像层的层标识,或检测到本地已部署的镜像层发生变化。
本申请的第十一方面,提供了一种镜像标签发送模块,该模块运行于主机
上,使得主机在满足触发时机的情况下,向管理节点发送本地已部署的镜像的镜像标签。
本申请的第十二方面,提供了一种镜像标签发送模块,该模块运行于主机上,使得主机在满足触发时机的情况下,向管理节点发送本地已部署的镜像层的层标识。
本申请的第十三方面,提供了一种容器系统,该容器系统包括至少两个第九方面提供的主机,以及通过第三方面提供的镜像部署装置或第五方面提供的计算设备实现的管理节点。
可选的,容器系统中管理节点获取待部署镜像的父镜像的镜像标签后,还可以将待部署镜像的父镜像的镜像标签发送至各个主机,由各个主机确定已部署的待部署镜像的父镜像,各个主机再将各自已部署的待部署镜像的父镜像的镜像标签返回至管理节点,以供管理节点确定部署节点。这种容器系统将管理节点的部分工作分布式的卸载到各个主机上,进一步提升了管理节点的工作效率。
本申请的第十四方面,提供了一种容器系统,提供了一种容器系统,该容器系统包括至少两个第十方面提供的主机,以及通过第四方面提供的镜像部署装置或第六方面提供的计算设备实现的管理节点。
可选的,容器系统中管理节点获取待部署镜像的镜像层的层标识后,还可以将待部署镜像的镜像层的层标识发送至各个主机,由各个主机确定已部署的待部署镜像的镜像层,各个主机再将各自已部署的待部署镜像的镜像层的层标识返回至管理节点,以供管理节点确定部署节点。这种容器系统将管理节点的部分工作分布式的卸载到各个主机上,进一步提升了管理节点的工作效率。
为了更清楚地说明本申请实施例的技术方案,下面将对实施例中所需要使用的附图作以简单地介绍,显而易见的,下面描述中的附图是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的容器系统的架构的示意图;
图2为本申请实施例提供的容器系统的物理架构的示意图;
图3为本申请实施例提供的镜像组织关系示意图;
图4为本申请实施例提供的计算设备的组织结构示意图;
图5为本申请实施例提供的镜像部署方法的流程示意图;
图6为本申请实施例提供的镜像标签的存储结构示意图;
图7(a)至图7(d)为本申请实施例提供的镜像标签的匹配流程示意图;
图8为本申请实施例提供的另一镜像部署方法的流程示意图;
图9为本申请实施例提供的镜像层的层标识的存储结构示意图;
图10(a)至图10(c)为本申请实施例提供的镜像层的层标识的匹配流程示意图;
图11为本申请实施例提供的镜像部署装置的组织结构示意图;
图12为本申请实施例提供的另一镜像部署装置的组织结构示意图。
下面结合本申请实施例中的附图,对本申请实施例中的技术方案进行描述。
贯穿本说明书,镜像是根文件系统(英文:root filesystem)的修改以及对应的容器运行时参数的有序集合,镜像是只读(英文:read only)文件。
镜像由镜像层组成。镜像层包括该镜像层对应的元数据(英文:metadata)和该镜像层所描述的文件系统修改中的至少一个。其中该镜像层对应的元数据通过json格式描述,也可以称之为层元数据(英文:layer metadata);或该镜像层所描述的文件系统修改,也可以称之为镜像文件系统修改集(英文:image filesystem changeset)。不同的镜像可以共享相同的镜像层,使得镜像层得以复用,节省了主机上的存储开销,并且镜像的更新能够通过在原镜像的镜像层的基础上发布新镜像层来实现,提升了镜像的更新以及发布的效率。
其中,元数据描述了镜像层的基本信息,例如创建日期、作者、本镜像层的层标识、父镜像层的层标识、本镜像层的大小。镜像层的镜像文件系统修改
集记录了相对于该镜像层的父镜像层中的被修改的文件的存档。
每个镜像层由层标识表示,每个镜像由镜像标签表示。镜像层的层标识指代镜像层在创建时被赋予的标识,每一个镜像层的层标识唯一,常用一个256比特的16进制编码表达。镜像标签(英文:tag)指代与一个镜像层的层标识具有映射关系的描述性的、用户提供的名称。镜像标签包括两部分,即该镜像的应用名与版本号,例如Mysql:5.4,其中Mysql为应用名,5.4为Mysql的版本号。
除了基础镜像外的镜像由至少两个镜像层组成,每一个镜像层都有唯一的父镜像层。如图3所示,镜像标签为Mysql:5.4的镜像包括层标识为层标识1、层标识2、层标识3、层标识4、层标识5、层标识10的镜像层和基础镜像,以及图3中省略的Mysql:5.3与Ubuntu:12.10之间的镜像层,以及图3中省略的Ubuntu:12.10与基础镜像之间的镜像层。
除基础镜像外的镜像包括至少一个父镜像,如图3所示,Mysql:5.4的父镜像包括Mysql:5.3,Ubuntu:12.10,以及基础镜像,而Mongo:2.2的父镜像包括Ubuntu:12.10,以及基础镜像。因此,两个镜像可能有着相同的父镜像,而如果两个镜像共有的父镜像不是基础镜像,则这两个镜像还包括相同的镜像层。
基础镜像(英文:base image)没有父镜像,基础镜像一般包括了一个操作系统发行版所需的除去操作系统内核的部分。
镜像与容器对应,一个镜像对应的容器包括该镜像,以及叠加在该镜像上的读写层。例如如果需要运行一个版本为5.4的Mysql应用对应的容器,则运行该容器需要镜像标签为Mysql:5.4的镜像。在一个主机上可以运行多种容器,这些容器可以包括不同的基础镜像,但同一主机上运行的容器共享操作系统内核。
镜像库指代存储了各个镜像包括的镜像层信息,各个镜像包括的父镜像信息,以及多个镜像层的数据库。镜像库可以为公有的,用户通过互联网访问公有镜像库,例如Docker Hub。用户也可以在私有的数据中心中建立私有的镜像库。
镜像库中包括至少一个镜像族,每个镜像族包括n个镜像,n个镜像中的每两个镜像具有父子关系,第1层镜像为基础镜像,第n层镜像的父镜像包括第1层到第n-1层镜像,n为大于等于2的自然数。图3中包括两个镜像族,即包括了Mysql:5.4、Mysql:5.3、Ubuntu:12.10、基础镜像的镜像族1,以及包括了
Mongo:2.2、Ubuntu:12.10、基础镜像的镜像族2。镜像族1中基础镜像为第1层镜像,Mysql:5.4为第n层镜像,Mysql:5.3为第n-1层镜像。因此对于Mysql:5.4,Mysql:5.3为其顶层父镜像,也即对于第m层镜像而言,第m-1即镜像为其顶层父镜像,第m-2层镜像为其次一层父镜像,而对于Mysql:5.4,其顶层镜像层的层标识为1,次一层镜像层的层标识为2。需要说明的是,Mysql:5.3以及Mysql:5.3的父镜像也可以构成一个镜像族3,则镜像族3包括的镜像的数量比镜像族1包括的镜像的数量少1。
本申请实施例所应用的容器系统的架构
图1为本申请实施例所应用的容器系统的架构的示意图,容器系统包括管理节点和多个运行容器的主机。管理节点上运行容器系统调度模块和容器系统管理模块。容器系统管理模块用于管理各个主机的资源使用信息,包括中央处理器(英文:central processing unit,缩写:CPU)的利用率、内存总量、内存利用率、硬盘(英文:hard disk drive,缩写:HDD)或固态硬盘(英文:solid state drive,缩写:SSD)利用率等。容器系统管理模块还用于管理主机上已经部署的镜像层的信息,以及主机上已经部署的镜像的信息。容器系统调度模块用于根据主机的资源使用信息、主机上已经部署的镜像的信息、主机上已经部署的镜像层的信息等部署镜像,容器系统调度模块还可以根据伸缩策略对主机上的容器进行管理。主机上运行了主机镜像管理模块,用于管理主机上的已部署的镜像。容器系统管理模块和各个主机上的主机镜像管理模块可以为主从(英文:master slave)模式,即各个主机镜像管理模块收集各个主机的镜像信息给容器系统管理模块。容器系统调度模块根据容器系统管理模块收集来的各个主机的镜像信息以及各个主机的资源使用信息确定了由某一主机部署一个镜像,则会通知该主机上的主机镜像管理模块与镜像库交互,获取该主机上部署该镜像缺乏的镜像层。
每个主机上可以部署一个或多个镜像,一般而言,一种镜像会部署于多个主机上,以使得该镜像对应的容器不会因为某一主机的故障而全部停止运行。
主机可以为虚拟机或物理机,管理节点可以为物理机或虚拟机。管理节点一般与主机部署于不同物理机。容器系统调度模块与容器系统管理模块和各个主机通过网络访问镜像库。
容器系统的一种物理架构的示意图如图2所示,本物理架构中,主机与管理节点均为虚拟机,一个物理机上可以运行多个主机,管理节点与各个主机运行于不同的物理机,以使得容器系统的管理与实际容器的运行相隔离,提升容器系统的工作效率和稳定性。
图1或图2中的管理节点可以通过图4中的计算设备200实现。计算设备200的组织结构示意图如图4所示,包括处理器202、存储器204,还可以包括总线208、通信接口206。
其中,处理器202、存储器204和通信接口206可以通过总线208实现彼此之间的通信连接,也可以通过无线传输等其他手段实现通信。
存储器204可以包括易失性存储器(英文:volatile memory),例如随机存取存储器(英文:random-access memory,缩写:RAM);存储器也可以包括非易失性存储器(英文:non-volatile memory),例如只读存储器(英文:read-only memory,缩写:ROM),快闪存储器(英文:flash memory),硬盘(英文:hard disk drive,缩写:HDD)或固态硬盘(英文:solid state drive,缩写:SSD);存储器204还可以包括上述种类的存储器的组合。在通过软件来实现本申请提供的技术方案时,用于实现本申请图5提供的镜像部署方法的程序代码保存在存储器204中,并由处理器202来执行。
计算设备200通过通信接口206与镜像库和容器系统的各个主机通信。
处理器202可以为中央处理器(英文:central processing unit,缩写:CPU)。
处理器202获取待部署镜像的镜像标签,并根据待部署镜像的镜像标签,从镜像库获取待部署镜像的父镜像的镜像标签。随后从容器系统中的主机中确定至少两个待选主机,即根据各个主机的资源使用信息,以及待部署镜像的资源使用要求,从各个主机中选择能够符合待部署镜像的资源使用要求的待选主机。通过选择待选主机,使得接下来的处理只需针对各个待选主机,无须对容器系统的全部主机进行分析,提升了处理效率。
处理器202根据待部署镜像的父镜像的镜像标签,与每个待选主机上已部署的镜像的镜像标签,确定每个待选主机上已部署的待部署镜像的父镜像,最后比较每个待选主机上已部署的待部署镜像的父镜像,根据比较结果和预定策略
为待部署镜像指定部署主机,该部署主机用于部署待部署镜像。预定策略可以为选择已部署待部署镜像的父镜像最多的待选主机作为部署主机,也可以结合其他参数例如各个待选主机的资源使用情况进行选择。
该部署主机可以为已部署待部署镜像的父镜像最多的待选主机,也可以结合其他策略,选择至少两个待选主机中已部署待部署镜像的父镜像相对较多的。通过部署主机的选择过程,使得该部署主机在下载待部署镜像的过程中,需要下载的数据量较少,提升了镜像部署的速度。
处理器202还可以在满足触发时机的情况下,获取并保存容器系统中每个主机上已部署的镜像的镜像标签。满足触发时机包括:预设了获取每个主机上已部署的镜像的镜像标签的周期,该周期到达,管理节点需要获取每个主机上已部署的镜像的镜像标签,以刷新管理节点存储的各个主机上的镜像情况;还包括接收到部署容器的指令,例如用户发送请求部署容器,为了部署该容器,管理节点需要获取每个主机上已部署的镜像的镜像标签,以选择该容器的部署主机;还包括接收到用户发送给管理节点的收集指令,指示管理节点收集并保存每个主机上已部署的镜像的镜像标签。
本申请还提供了一种镜像部署方法,图1、图2中的管理节点以及图4中的计算设备200运行时执行该方法,其流程示意图如图5所示。
步骤402,管理节点获取待部署镜像的镜像标签。
容器系统需要部署某一容器时,管理节点会获取该待部署容器对应的待部署镜像的镜像标签。常见的场景中,根据容器系统预设的伸缩策略或用户发送的请求,容器系统中需要启动容器,则管理节点会接收到该容器对应的镜像的镜像标签,即待部署镜像的镜像标签。
可选的,还执行了步骤400。步骤400与步骤402可以不连续执行,在步骤402执行之前应该至少执行过一次步骤400。
步骤400,管理节点在满足触发时机的情况下,获取并保存容器系统中的每个主机上已部署的镜像的镜像标签。
可选的,管理节点获取的为每个主机上全部已部署的镜像的镜像标签,以
使得后续部署主机的选择过程更为准确。
可选的,满足触发时机包括:预设的周期到达,或接收到部署容器的指令,或接收到用户发送的收集指令,收集指令指示收集并保存容器系统中的主机上已部署的镜像的镜像标签。管理节点在预设的周期到达时,获取各个主机上已部署的镜像的镜像标签,以更新管理节点上存储的各个主机上已部署的镜像的镜像标签。管理节点也可以在接收到部署容器的指令的情况下,向各个主机发送指令,要求各个主机上报各自已部署的镜像的镜像标签。管理节点也可以接收用户发送的收集指令后,向各个主机发送指令,要求各个主机上报各自已部署的镜像的镜像标签。
需要说明的是,管理节点在镜像部署过程中选择待部署镜像的部署主机时,可以仅利用各个主机上已部署的部分镜像的镜像标签,因此,步骤400中可以获取各个主机上已部署的部分镜像的镜像标签,例如可以不获取各个主机上已部署的基础镜像的镜像标签。
需要说明的是,管理节点在镜像部署过程中选择待部署镜像的部署主机时,可以仅从容器系统中的部分主机中选择待部署镜像的部署主机,因此步骤400中,管理节点可以仅获取并保存容器系统中部分主机上已部署的镜像的镜像标签。常见的,可以预设容器系统中的部分主机不参与当前待部署镜像的部署,则管理节点在步骤400中无须获取这部分主机上已部署的镜像的镜像标签。
管理节点获取的各个主机上已部署的镜像的镜像标签可以为有依赖关系的,或无依赖关系的。以主机1上部署的镜像情况如图3所示为例,管理节点存储的主机1上已部署的镜像的镜像标签包括以下几种方式:
方式1,管理节点获取的为每个镜像族包括的镜像的有依赖关系的镜像标签,如镜像族1,Mysql:5.4-Mysql:5.3-Ubuntu:12.10-基础镜像;镜像族2,Mongo:2.2-Ubuntu:12.10-基础镜像,其中“-”指示后一个镜像为前一个镜像的父镜像。
方式2,管理节点获取的为每个镜像族包括的镜像的无依赖关系的镜像标签,如镜像族1,Mysql:5.4、Ubuntu:12.10、Mysql:5.3、基础镜像;镜像族2,Ubuntu:12.10、Mongo:2.2、基础镜像。方式2下,主机1只需上报各个镜像族包括的镜像标签即可,可以不指示各个镜像族内镜像之间的依赖关系。进一步的,方式2中,还可
以将不同镜像族包括的相同镜像的镜像标签合并,例如镜像族1和镜像族2中,Ubuntu:12.10和基础镜像为重复的,则主机1仅需上报主机1上已部署的镜像的镜像标签包括:Mysql:5.4、Ubuntu:12.10、Mysql:5.3、基础镜像、Mongo:2.2。主机1在上报前对其已部署的镜像的镜像标签进行合并,可以减少上传到管理节点的数据量,提升管理节点的工作效率。
进一步的,管理节点获取的各个主机上已部署的镜像的镜像标签后,可以进一步对各个主机上已部署的镜像的镜像标签进行处理后再存储为方式3。以图6为例,若管理获取了主机1到主机4上分别已部署的镜像的镜像标签,则可以根据各个主机上已部署的镜像的镜像标签中包括的应用名,以应用为索引,记录各个主机上已部署的镜像的镜像标签。方式3下,如果管理节点需要查询哪几个主机上部署了Mysql应用对应的镜像,无须对全部主机进行筛选,仅需根据应用名Mysql,即可获取主机1和主机2,提升了管理节点确定部署待部署镜像的主机的效率。
步骤404,管理节点根据待部署镜像的镜像标签,从镜像库获取待部署镜像的父镜像的镜像标签。
可选的,管理节点从镜像库获取的为待部署镜像的全部父镜像的镜像标签,以使得后续部署主机的选择过程更为准确。
可选的,管理节点可以本地存储有一部分镜像的父镜像的镜像标签,若待部署镜像属于其中之一,则管理节点无须向镜像库请求待部署镜像的父镜像的镜像标签。
需要说明的是,相应于步骤400中可以获取各个主机上已部署的部分镜像的镜像标签,步骤404中管理节点也可以从镜像库获取待部署镜像的部分父镜像的镜像标签,例如不获取待部署镜像的父镜像中的基础镜像的镜像标签。
步骤404中,从镜像库获取的待部署镜像的父镜像的镜像标签可以为有依赖关系的,以待部署镜像的镜像标签为Mysql:5.4为例,获取的该镜像的父镜像的镜像标签如:Mysql:5.4-Mysql:5.3-Ubuntu:12.10-基础镜像;获取的待部署镜像的父镜像的镜像标签也可以为无依赖关系的,获取的该镜像的父镜像的镜像标签如:Mysql:5.4、Ubuntu:12.10、Mysql:5.3、基础镜像。
步骤406,管理节点从容器系统中的主机中确定至少两个待选主机。
可选的,步骤406之前,管理节点还获取了容器系统中各个主机的资源使用信息,则步骤406包括根据容器系统中主机的资源使用信息,确定满足待部署镜像的资源使用要求的至少两个待选主机。通过待选主机的选取,使得管理节点在后续步骤中仅需从待选主机中选择部署节点,提升了管理节点的工作效率,由于待选主机需要满足待部署镜像的资源使用要求,因此也使得从待选主机中选取的部署节点在资源方面必然能够满足待部署镜像,提升了待部署镜像的部署成功率。
用户向管理节点发出请求,要求管理节点部署该待部署镜像的时候,可以同时发送用户期望的该待部署镜像的资源使用要求,例如部署该镜像的主机的CPU使用量、内存使用量、内存总量等,如果用户没有发送该待部署镜像的资源使用要求,管理节点可以查询历史已部署的镜像的资源使用请求,调用其中存储的该待部署镜像的资源使用要求。管理节点随后结合各个主机的资源使用信息,与待部署镜像的资源使用要求,确定能够满足待部署镜像的资源使用要求的至少两个待选主机。
需要说明的是,步骤404和步骤406的执行顺序不限定。尤其如果先执行步骤406,管理节点从容器系统中的主机中只能确定一个能够满足待部署镜像的资源使用要求的待选主机,则无需执行步骤404及步骤406后的步骤,直接将该待选主机选为待部署镜像的部署主机。
步骤408,管理节点确定每个待选主机上已部署的镜像的镜像标签。
在步骤400中,管理节点已经获取容器系统中的每个主机上已部署的镜像的镜像标签,则管理节点从中获取每个待选主机上已部署的镜像的镜像标签。
步骤410,管理节点根据待部署镜像的父镜像的镜像标签,与每个待选主机上已部署的镜像的镜像标签为待部署镜像指定部署主机,部署主机用于部署该待部署镜像,部署主机上已部署的所述待部署镜像的父镜像满足预定策略。
步骤410可以包括:将待部署镜像的父镜像的镜像标签,与每个待选主机上已部署的镜像的镜像标签进行匹配,确定每个待选主机上已部署的待部署镜像的父镜像;并将每个待选主机上已部署的待部署镜像的父镜像进行比较,根据
比较结果和预定策略指定所述部署主机,其中,预定策略为选择至少两个待选主机中已部署的待部署镜像的父镜像数量最多的待选主机为部署主机。
需要说明的是,获取了各个待选主机上已部署的待部署镜像的父镜像后,进一步,还可以获取相对于待部署镜像,各个待选主机上缺乏的镜像层的大小,并结合各个待选主机上的资源使用情况选择待部署主机,因此实际运用中,随着预定策略的设计,最后选择的部署主机也可能不是待部署镜像的父镜像数量最多的待选主机。
根据步骤400中,管理节点存储的各个主机上已部署的镜像的镜像标签的方式不同,以及步骤404中,从镜像库获取待部署镜像的父镜像的镜像标签是否有依赖关系,步骤410中管理节点确定每个待选主机上已部署的待部署镜像的父镜像的方式也有所不同。以待部署镜像的镜像标签为Mysql:5.4为例,管理节点获取的该待部署镜像的父镜像的镜像标签可以为,有依赖关系的Mysql:5.4-Mysql:5.3-Ubuntu:12.10-基础镜像,或无依赖关系的Mysql:5.4、Ubuntu:12.10、Mysql:5.3、基础镜像。
如果步骤404中从镜像库获取待部署镜像的父镜像的镜像标签没有依赖关系,则需要将待部署镜像的父镜像的镜像标签与各个待选主机上已部署的待部署镜像的父镜像的镜像标签逐个进行匹配,以确定各个待选主机上已部署的待部署镜像的父镜像。
如果步骤404中从镜像库获取待部署镜像的父镜像的镜像标签有依赖关系。
方式1的情况下,由于各个待选主机上报的已部署的镜像的镜像标签之间有依赖关系,如果步骤404中获取的待部署镜像的父镜像的镜像标签也有依赖关系,则首先从选择出的待选主机中确定当前待选主机,然后根据待部署镜像的镜像标签,与当前待选主机上已部署的镜像的镜像标签进行匹配。匹配顺序可以从顶层镜像向基础镜像进行匹配,包括以下步骤:步骤一,将待部署镜像的镜像标签,与当前待选主机上已部署的镜像的镜像标签进行匹配,若匹配上,确定当前待选主机上已部署待部署镜像及待部署镜像的全部父镜像,若未匹配上,执行步骤二;步骤二,将待部署镜像的顶层父镜像的镜像标签,当前待选主机
上已部署的镜像的镜像标签进行匹配,若匹配上,确定当前待选主机已部署待部署镜像的全部父镜像,若未匹配上,执行步骤三;步骤三,将当前镜像的镜像标签,与当前待选主机上已部署的镜像的镜像标签进行匹配,当前镜像为前一步骤中进行了匹配的待部署镜像的父镜像的顶层父镜像,若匹配上,确定当前待选主机上已部署当前镜像的全部父镜像,若未匹配上,返回执行步骤三,直至匹配过待部署镜像的每个父镜像。任一步骤中,当前待选主机匹配上了镜像标签,则不进行接下来的步骤。而一个待选主机被指定为当前待选主机并执行了前述步骤后,指定另一个待选主机执行前述步骤,直至所有待选主机全部执行了上述步骤,即确定了每个待选主机上已部署的待部署镜像的父镜像。
如图7(a),用Mysql:5.4与各个待选主机上已部署的镜像的镜像标签进行匹配,若在某一待选主机上匹配到了Mysql:5.4,由于待选主机上已部署的镜像的镜像标签已经具有依赖关系,则该待选主机上无须继续匹配,如501。若某一待选主机的匹配过程中一直未匹配到Mysql:5.4,则一直在该待选主机已部署的镜像的镜像标签中向下匹配,直至全部镜像标签匹配完毕,如502、503、504。待选主机3的部分匹配过程省略和待选主机4的匹配过程在图中省略。匹配上待部署镜像的镜像标签的待选主机上已部署待部署镜像,也即待选主机1上已部署Mysql:5.4,并且已部署Mysql:5.4的全部父镜像。
随后,将待部署镜像的顶层父镜像的镜像标签,与至少两个待选主机中主机1之外的待选主机上已部署的镜像的镜像标签进行匹配,匹配上待部署镜像的顶层父镜像的镜像标签的待选主机上已部署待部署镜像的父镜像。如图7(b),用Mysql:5.3与各个待选主机进行匹配,在之前步骤已经匹配上的待选主机无须再次进行匹配。具体的匹配过程如508至513。待选主机4的匹配过程在图中省略。匹配上待部署镜像的顶层父镜像的镜像标签的待选主机上已部署待部署镜像的全部父镜像,也即待选主机2上已部署Mysql:5.4的全部父镜像。
随后,将待部署镜像的次一层父镜像的镜像标签,与至少两个待选主机中之前步骤未匹配上的待选主机上已部署的镜像的镜像标签进行匹配,匹配上待部署镜像的次一层父镜像的镜像标签的待选主机上已部署除待部署镜像的顶层父镜像之外的父镜像,如图7(c),用Ubuntu:12.10与各个待选主机进行匹配,在
之前步骤已经匹配上的待选主机无须再次进行匹配。具体的匹配过程如514至517。匹配上待部署镜像的次一层父镜像的镜像标签的待选主机上已部署除待部署镜像的顶层父镜像之外的父镜像,即待选主机3上已部署Ubuntu:12.10与基础镜像。重复本步骤,待部署镜像的一层父镜像与各个待选主机匹配完毕后,用该父镜像的顶层父镜像与剩余待选主机匹配,直至匹配过每个待选主机上已部署的镜像的镜像标签。
以上获取每个待选主机上已部署的所述待部署镜像的父镜像的方法,避免了将待部署镜像与各个待选主机上全部的已部署的所述待部署镜像的父镜像逐一比较,提升了匹配效率。
方式2的情况下,待选主机上报给管理节点的为每个镜像族包括的镜像的无依赖关系的镜像标签,因此确定待选主机上已部署的所述待部署镜像的父镜像,需要将待部署镜像的父镜像的镜像标签,与所保存的至少两个待选主机上已部署的镜像的镜像标签进行逐一对比,才能获取各个待选主机上已部署的待部署镜像的父镜像。
方式3的情况下,与方式1的区别在于,首先根据待部署镜像的镜像标签中的应用为索引去查询管理节点中存储的各个主机上已部署的镜像的镜像标签。如图7(d)所示,通过518可知,仅有待选主机1上部署了Mysql:5.4,通过519可知仅有待选主机3上部署了Mysql:5.3,通过520可知待选主机1至4上均部署了Ubuntu:12.10。通过这种镜像标签的存储结构,管理节点可以更快获取各个待选主机上已部署的待部署镜像的父镜像。以上获取每个待选主机上已部署的所述待部署镜像的父镜像的方法,避免了将待部署镜像与各个待选主机上全部的已部署的所述待部署镜像的父镜像逐一比较,提升了匹配效率。
步骤400至步骤410可以由管理节点的容器系统管理模块执行,容器系统管理模块在步骤410中确定了部署主机后,将部署主机的标识发送至容器系统调度模块,容器系统调度模块根据部署主机的标识,指示部署主机部署待部署镜像。
图5对应的镜像部署方法,通过判断各个主机上已经部署的镜像与待部署镜像包括的父镜像的重合程度,选取出部署过程中需要下载的镜像较少的主机来部署待部署镜像,有效提升了待部署镜像的部署速度。
图1或图2中的管理节点还可以通过与图4中的计算设备200的结构相同的计算设备实现。该计算设备包括处理器、存储器,还可以包括总线、通信接口。
其中,处理器、存储器和通信接口可以通过总线实现彼此之间的通信连接,也可以通过无线传输等其他手段实现通信。
存储器可以包括易失性存储器,例如RAM;也可以包括非易失性存储器,例如ROM,快闪存储器,HDD或SSD;存储器还可以包括上述种类的存储器的组合。在通过软件来实现本申请提供的技术方案时,用于实现本申请图8提供的镜像部署方法的程序代码可以保存在存储器中,并由处理器来执行。
该计算设备通过通信接口与镜像库和容器系统的各个主机通信。
处理器可以为CPU。处理器获取待部署镜像的镜像标签,并根据待部署镜像的镜像标签,从镜像库获取待部署镜像的镜像层的层标识。随后从容器系统中的主机中确定至少两个待选主机,即根据各个主机的资源使用信息,以及待部署镜像的资源使用要求,从各个主机中选择能够符合待部署镜像的资源使用要求的待选主机。通过选择待选主机,使得接下来的处理只需针对各个待选主机,无须对容器系统的全部主机进行分析,提升了处理效率。
处理器根据待部署镜像的镜像层的层标识,与每个待选主机上已部署的镜像层的层标识,确定每个待选主机上已部署的待部署镜像的镜像层,最后比较每个待选主机上已部署的待部署镜像的镜像层的层标识,根据比较结果和预定策略为待部署镜像指定部署主机,该部署主机用于部署待部署镜像。预定策略可以为选择已部署待部署镜像的镜像层最多的待选主机作为部署主机,也可以结合其他参数例如各个待选主机的资源使用情况进行选择。
处理器还可以在满足触发时机的情况下,获取并保存获取并保存容器系统中每个主机上已部署的镜像层的层标识。满足触发时机包括:预设了获取各个主机上已部署的镜像层的层标识的周期,该周期到达,管理节点需要获取各个主机上已部署的镜像层的层标识,以刷新管理节点存储的各个主机上的镜像情况;还包括接收到部署容器的指令,例如用户发送请求部署容器,为了部署该容器,管理节点需要获取各个主机上已部署的镜像层的层标识,以选择该容器的部署主机;还包括接收到用户发送给管理节点的收集指令,指示管理节点收
集并保存个主机上已部署的镜像层的层标识。
通过部署主机的选择过程,使得该部署主机在下载待部署镜像的过程中,需要下载的数据量较少,提升了镜像部署的速度。
本申请还提供了一种镜像部署方法,图1、图2中的管理节点以及前述的计算设备运行时执行该方法,其流程示意图如图8所示。
步骤602,管理节点获取待部署镜像的镜像标签。
容器系统需要部署某一容器时,管理节点会获取该待部署容器对应的待部署镜像的镜像标签。常见的场景中,根据容器系统预设的伸缩策略或用户发送的请求,容器系统中需要启动容器,则管理节点会接收到该容器对应的镜像的镜像标签,即待部署镜像的镜像标签。
可选的,还执行了步骤600。步骤600与步骤602可以不连续执行,在步骤602执行之前应该至少执行过一次步骤600。
步骤600,管理节点在满足触发时机的情况下,获取并保存容器系统中的主机上已部署的镜像层的层标识。
可选的,管理节点从各个主机获取的为各个主机上全部已部署的镜像层的层标识,以使得后续部署主机的选择过程更为准确。
可选的,满足触发时机包括:预设的周期到达,或接收到部署容器的指令,或接收到用户发送的收集指令,收集指令指示收集并保存容器系统中的主机上已部署的镜像层的层标识。管理节点在预设的周期到达时,获取各个主机上已部署的镜像层的层标识,以更新管理节点上存储的各个主机上已部署的镜像层的层标识。管理节点也可以在接收到部署容器的指令的情况下,向各个主机发送指令,要求各个主机上报各自已部署的镜像层的层标识。管理节点也可以接收用户发送的收集指令后,向各个主机发送指令,要求各个主机上报各自已部署的镜像层的层标识。
需要说明的是,管理节点在镜像部署过程中选择待部署镜像的部署主机时,可以仅利用各个主机上已部署的部分镜像层的层标识,因此,步骤600中可以获取各个主机上已部署的部分镜像层的层标识。
需要说明的是,管理节点在镜像部署过程中选择待部署镜像的部署主机时,可以仅从容器系统中的部分主机中选择待部署镜像的部署主机,因此步骤600中,管理节点可以仅获取并保存容器系统中部分主机上已部署的镜像层的层标识。常见的,可以预设容器系统中的部分主机不参与当前待部署镜像的部署,则管理节点在步骤600中无须获取这部分主机上已部署的镜像层的层标识。
管理节点获取的各个主机上已部署的镜像层的层标识可以为有依赖关系的,或无依赖关系的。以主机5上部署的镜像情况如图3所示为例,管理节点存储的主机5上已部署的镜像层的层标识包括以下几种方式:
方式4,主机5上报给管理节点的为每个镜像族的镜像层的有依赖关系的层标识,如镜像族1,层标识1-层标识2-层标识3-层标识4-层标识5-层标识10;镜像族2,层标识7-层标识8-层标识10,其中“-”指示后一个镜像层为前一个镜像层的父镜像层。
方式5,主机5上报给管理节点的为每个镜像族的镜像层的无依赖关系的层标识,如镜像族1,层标识1、层标识3、层标识2、层标识5、层标识4、层标识10;镜像族2,层标识8、层标识7、层标识10。方式5下,主机5只需上报各个镜像族包括镜像的层标识即可,可以不指示各个镜像族内镜像层之间的依赖关系。进一步的,方式5中,还可以将不同镜像族的相同镜像层的层标识合并,例如镜像族1和镜像族2中,层标识10为重复的,则主机5仅需上报主机5上已部署的镜像的镜像标签包括:层标识1至层标识10。主机5在上报前对其已部署的镜像层的层标识进行合并,可以减少上传到管理节点的数据量,提升管理节点的工作效率。
进一步的,管理节点获取的各个主机上已部署的镜像层的层标识后,可以进一步对各个主机上已部署的镜像层的层标识进行处理后再存储为方式6。以图9为例,若管理获取了主机5到主机8上分别已部署的镜像层的层标识,则可以根据各个主机上已部署的镜像层的层标识中包括的应用名,以应用为索引,记录各个主机上已部署的镜像层的层标识。方式6下,如果管理节点需要查询哪几个主机上部署了Mysql应用对应的镜像层,无须对全部主机进行筛选,仅需根据应用名Mysql,即可获取主机5和主机6,提升了管理节点确定部署待部署镜像的主机的效率。
步骤604,管理节点根据待部署镜像的镜像标签,从镜像库获取待部署镜像的镜像层的层标识。
可选的,管理节点从镜像库获取的为待部署镜像的全部镜像层的层标识,以使得后续部署主机的选择过程更为准确。
可选的,管理节点可以本地存储有一部分镜像的镜像层的层标识,若待部署镜像属于其中之一,则管理节点无须向镜像库请求待部署镜像的镜像层的层标识。
需要说明的是,相应于步骤600中可以获取各个主机上已部署的部分镜像层的层标识,步骤604中管理节点也可以从镜像库获取待部署镜像的部分镜像层的层标识。
步骤604中,从镜像库获取的待部署镜像的镜像层的层标识可以为有依赖关系的,以待部署镜像的镜像标签为Mysql:5.4为例,获取的该镜像的镜像层的层标识如:层标识1-层标识2-层标识3-层标识4-层标识5-层标识10;获取的待部署镜像的镜像层的层标识也可以为无依赖关系的,获取的该镜像的镜像层的层标识如:层标识1、层标识2、层标识5、层标识4、层标识3、层标识10。
步骤606,管理节点从容器系统中的主机中确定至少两个待选主机。
可选的,步骤606之前,管理节点还获取了容器系统中各个主机的资源使用信息,则步骤606包括根据容器系统中主机的资源使用信息,确定满足待部署镜像的资源使用要求的至少两个待选主机。通过待选主机的选取,使得管理节点在后续步骤中仅需从待选主机中选择部署节点,提升了管理节点的工作效率,由于待选主机需要满足待部署镜像的资源使用要求,因此也使得从待选主机中选取的部署节点在资源方面必然能够满足待部署镜像,提升了待部署镜像的部署成功率。
用户向管理节点发出请求,要求管理节点部署该待部署镜像的时候,可以同时发送用户期望的该待部署镜像的资源使用要求,例如CPU使用量、内存使用量等,如果用户没有发送该待部署镜像的资源使用要求,管理节点也会查询历史已部署的镜像的资源使用请求,调用其中存储的该待部署镜像的资源使用要求。管理节点随后结合各个主机的资源使用信息,与待部署镜像的资源使用要
求,确定能够满足待部署镜像的资源使用要求的至少两个待选主机。
需要说明的是,步骤604和步骤606的执行顺序不限定。尤其如果先执行步骤606,管理节点从容器系统中的主机中只能确定一个能够满足待部署镜像的资源使用要求的待选主机,则无需执行步骤604及步骤606后的步骤,直接将该待选主机选为待部署镜像的部署主机。
步骤608,管理节点确定每个待选主机上已部署的镜像层的层标识。
在步骤600中,管理节点已经获取容器系统中的每个主机上已部署的镜像层的层标识,则管理节点从中获取每个待选主机上已部署的镜像层的层标识。
步骤610,根据待部署镜像的镜像层的层标识,与每个待选主机上已部署的镜像层的层标识,为待部署镜像指定部署主机,部署主机用于部署该待部署镜像,部署主机上已部署的待部署镜像的镜像层满足预定策略。
步骤610可以包括:将待部署镜像的镜像层的层标识,与每个待选主机上已部署的镜像层的层标识进行匹配,确定每个待选主机上已部署的待部署镜像的镜像层;并将每个待选主机上已部署的待部署镜像的镜像层进行比较,根据比较结果和预定策略指定部署主机,其中,预定策略为选择至少两个待选主机中已部署的待部署镜像的镜像层数量最多的待选主机为部署主机。
需要说明的是,获取了各个待选主机上已部署的待部署镜像的镜像层后,进一步,还可以获取相对于待部署镜像,各个待选主机上缺乏的镜像层的大小,并结合各个待选主机上的资源使用情况选择待部署主机,因此实际运用中,随着预定策略的设计,最后选择的部署主机也可能不是待部署镜像的镜像层数量最多的待选主机。
根据步骤600中,管理节点存储的各个主机上已部署的镜像层的层标识的方式不同,以及步骤604中,从镜像库获取待部署镜像的镜像层的层标识是否有依赖关系,步骤610中管理节点确定每个待选主机上已部署的待部署镜像的镜像层的方式也有所不同。以待部署镜像的镜像标签为Mysql:5.4为例,管理节点获取的该待部署镜像的镜像层的层标识可以为,有依赖关系的层标识1-层标识2-层标识3-层标识4-层标识5-层标识10,或无依赖关系的层标识1、层标识2、层标识5、层
标识4、层标识3、层标识10。
如果步骤604中从镜像库获取待部署镜像的镜像层的层标识没有依赖关系,则需要将待部署镜像的镜像层的层标识与各个待选主机上已部署的待部署镜像的镜像层的层标识逐个进行匹配,以确定各个待选主机上已部署的待部署镜像的镜像层。
如果步骤604中从镜像库获取待部署镜像的镜像层的层标识有依赖关系。方式4的情况下,由于各个待选主机上报的已部署的镜像层的层标识之间有依赖关系,如果步骤604中获取的待部署镜像的镜像层的层标识也有依赖关系,则首先从选择出的待选主机中确定当前待选主机,然后根据待部署镜像的镜像层的层标识,与当前待选主机上已部署的镜像层的层标识进行匹配。匹配顺序可以从顶层镜像层向下进行匹配,包括以下步骤:步骤一,将待部署镜像的顶层镜像层的层标识,与当前待选主机上已部署的镜像层的层标识进行匹配,若匹配上,确定当前待选主机上已部署待部署镜像的全部镜像层,若未匹配上,执行步骤二;步骤二,将当前镜像层的层标识,与当前待选主机上已部署的镜像层的层标识进行匹配,当前镜像层为前一步骤中进行了匹配的待部署镜像的镜像层的父镜像层,若匹配上,确定当前待选主机上已部署当前镜像层以下的全部镜像层,此处的当前镜像层以下的镜像层包括当前镜像层的父镜像以及当前镜像层的父镜像层的父镜像层等,若未匹配上,返回执行步骤二,直至匹配过待部署镜像的每个镜像层。任一步骤中,当前待选主机匹配上了镜像层的层标识,则不进行接下来的步骤。而一个待选主机被指定为当前待选主机并执行了前述步骤后,指定另一个待选主机执行前述步骤,直至所有待选主机全部执行了上述步骤,即确定了每个待选主机上已部署的待部署镜像的镜像层。
如图10(a),用层标识1与各个待选主机上已部署的镜像层的层标识进行匹配,若在某一待选主机上匹配到了层标识1,由于待选主机上已部署的镜像层的层标识已经具有依赖关系,则该待选主机上无须继续匹配,如701。若某一待选主机的匹配过程中一直未匹配到层标识1,则一直在该待选主机已部署的镜像层的层标识中向下匹配,直至全部层标识匹配完毕,如702、703、704、705。待选主机7和待选主机8的匹配过程在图中省略。匹配上待部署镜像的顶层镜像层的
层标识的待选主机上已部署待部署镜像,也即待选主机5上已部署Mysql:5.4的全部镜像层。
随后,将待部署镜像的次一层镜像层的层标识,与至少两个待选主机中之前步骤未匹配上的待选主机上已部署的镜像层的层标识进行匹配,匹配上待部署镜像的次一层镜像层的层标识的待选主机上已部署待部署镜像的顶层镜像层外的全部镜像层。如图10(b),用层标识2与各个待选主机进行匹配,在之前步骤已经匹配上的待选主机无须再次进行匹配。具体的匹配过程如706至709。待选主机7和待选主机8的匹配过程在图中省略。重复本步骤,待部署镜像的一层镜像层的层标签与各个待选主机匹配完毕后,用该镜像层的父镜像层与剩余待选主机匹配,直至匹配过每个待选主机上已部署的镜像层的层标识。
以上获取每个待选主机上已部署的所述待部署镜像的父镜像的方法,避免了将待部署镜像与各个待选主机上全部的已部署的所述待部署镜像的父镜像逐一比较,提升了匹配效率。
方式5的情况下,待选主机上报给管理节点的为每个镜像族包括的镜像层的无依赖关系的层标识,因此确定待选主机上已部署的所述待部署镜像的镜像层,需要将待部署镜像的镜像层的层标识,与所保存的至少两个待选主机上已部署的镜像层的层标识进行逐一对比,才能获取各个待选主机上已部署的待部署镜像的镜像层。
方式6的情况下,与方式5的区别在于,首先根据待部署镜像的镜像标签中的应用为索引去查询管理节点中存储的各个主机上已部署的镜像层的层标识。如图10(c)所示,首先层标识1至层标识5均属于Mysql的镜像层,因此仅在待选主机5和待选主机6上匹配,因此通过710至714可知仅有待选主机5上部署了层标识1对应镜像层以及其下层镜像层,而待选主机6上部署了层标识4对应镜像层以及其下层镜像层。层标识10对应的镜像层属于Ubuntu,因此通过715可知待选主机5至待选主机8上部署了层标识10对应的镜像层。通过这种镜像标签的存储结构,管理节点可以更快获取各个待选主机上已部署的待部署镜像的镜像层。以上获取每个待选主机上已部署的所述待部署镜像的镜像层的方法,避免了将待部署镜像的镜像层的层标识与各个待选主机上全部的已部署的所述待部署镜像的镜
像层的层标识逐一比较,提升了匹配效率。
步骤600至步骤610可以由管理节点的容器系统管理模块执行,容器系统管理模块在步骤610中确定了部署主机后,将部署主机的标识发送至容器系统调度模块,容器系统调度模块根据部署主机的标识,指示部署主机部署待部署镜像。
图8对应的镜像部署方法,通过判断各个主机上已经部署的镜像层与待部署镜像包括的镜像层的重合程度,选取出部署过程中需要下载的镜像层较少的主机来部署待部署镜像,有效提升了待部署镜像的部署速度。
图8对应的镜像部署方法与图5对应的镜像部署方法各有特点,图8对应的镜像部署方法通过待部署镜像的镜像层与已部署的镜像层的比较确定部署主机,更加精确,而图5对应的镜像部署方法通过待部署镜像的父镜像与已部署的镜像的比较确定部署主机,相对镜像层的比较而言,更加快速。实际运用中,这两种镜像部署方法也可以结合使用。
本发明实施例还提供了镜像部署装置800,该装置可以通过图4所示的计算设备200实现,还可以通过专用集成电路(英文:application-specific integrated circuit,缩写:ASIC)实现,或可编程逻辑器件(英文:programmable logic device,缩写:PLD)实现。上述PLD可以是复杂可编程逻辑器件(英文:complex programmable logic device,缩写:CPLD),FPGA,通用阵列逻辑(英文:generic array logic,缩写:GAL)或其任意组合。该镜像部署装置800用于实现图5所示的镜像部署方法。通过软件实现图5所示的镜像部署方法时,镜像部署装置800也可以为软件模块。
镜像部署装置800的组织结构示意图如图11所示,包括:获取单元802和处理单元804。获取单元802工作时,执行图5所示的镜像部署方法中的步骤400和402以及步骤406中获取容器系统中各个主机的资源使用信息的部分,处理单元804工作时,执行图5所示的镜像部署方法中的步骤404至步骤410及其可选方案。
本镜像部署装置,能够通过判断各个主机上已经部署的镜像与待部署镜像包括的父镜像的重合程度,选取出部署过程中需要下载的镜像较少的主机来部署待部署镜像,有效提升了待部署镜像的部署速度。
本发明实施例还提供了镜像部署装置1000,该装置可以通过图4所示的计算设备200实现,还可以通过ASIC实现,或PLD实现。上述PLD可以是复杂可编程CPLD,FPGA,GAL或其任意组合。该镜像部署装置1000用于实现图8所示的镜像部署方法。通过软件实现图8所示的镜像部署方法时,镜像部署装置1000也可以为软件模块。
镜像部署装置1000的组织结构示意图如图12所示,包括:获取单元1002和处理单元1004。获取单元1002工作时,执行图8所示的镜像部署方法中的步骤600和602及步骤606中获取容器系统中各个主机的资源使用信息的部分,处理单元1004工作时,执行图8所示的镜像部署方法中的步骤604至步骤610及其可选方案。
本镜像部署装置,能够通过判断各个主机上已经部署的镜像层与待部署镜像包括的镜像层的重合程度,选取出部署过程中需要下载的镜像层较少的主机来部署待部署镜像,有效提升了待部署镜像的部署速度。
本发明实施例还提供了运用于图1或图2所示的容器系统的第一种镜像部署方法,包括:
容器系统中的主机在满足触发时机的情况下,向管理节点发送本地已部署的镜像的镜像标签。
可选的,满足触发时机包括:预设的周期到达,或接收到管理节点发送的收集指令,收集指令指示向管理节点发送已部署的镜像的镜像标签,或检测到本地已部署的镜像发生变化。
如图1所示,容器系统的主机上部署了主机镜像管理模块,各个主机的主机镜像管理模块监控本主机上部署的镜像,也即本地部署的镜像,是否发生变化,例如是否有新下载的镜像、用户是否删除了镜像等,如果发生变化,则主机镜像管理模块向管理节点发送本主机上已部署镜像的镜像标签,以更新管理节点上的信息。主机也可以在预设周期到达时,上报其已部署的镜像的镜像标签。主机也可以接收到管理节点发送的收集指令后上报。
管理节点接收并保存容器系统中的主机上已部署的镜像的镜像标签后的动作,参考图5对应的镜像部署方法。
本镜像部署方法,通过判断容器系统的各个主机上已经部署的镜像与待部署镜像包括的父镜像的重合程度,选取出部署过程中需要下载的镜像较少的主机来部署待部署镜像,有效提升了容器系统部署待部署镜像的速度。
本发明实施例还提供了运用于图1或图2所示的容器系统的第二种镜像部署方法,包括:
容器系统中的主机在满足触发时机的情况下,向管理节点发送本地已部署的镜像层的层标识。
可选的,满足触发时机包括:预设的周期到达,或接收到管理节点发送的收集指令,收集指令指示向管理节点发送已部署的镜像的镜像标签,或检测到本地已部署的镜像发生变化。
如图1所示,容器系统的主机上部署了主机镜像管理模块,各个主机的主机镜像管理模块监控本主机上已部署的镜像层,也即本地部署的镜像,是否发生变化,例如是否有新下载的镜像层、用户是否删除了镜像层等,如果发生变化,则主机镜像管理模块向管理节点发送本主机上已部署的镜像层的层标识,以更新管理节点上的信息。主机也可以在预设的周期到达时,上报其已部署的镜像层的层标识。主机也可以接收到管理节点发送的收集指令后上报。
管理节点接收并保存容器系统中的主机上已部署的镜像层的层标识后的动作,参考图8对应的镜像部署方法。
本镜像部署方法,通过判断容器系统的各个主机上已经部署的镜像层与待部署镜像包括的镜像层的重合程度,选取出部署过程中需要下载的镜像层较少的主机来部署待部署镜像,有效提升了容器系统部署待部署镜像的速度。
本发明实施例还提供了第一种容器系统,该容器系统的组织结构示意图如图1或图2所示。该容器系统运行时,执行前述运用于容器系统的第一种镜像部署方法。
本发明实施例还提供了第二种容器系统,该容器系统的组织结构示意图如
图1或图2所示。该容器系统运行时,执行前述运用于容器系统的第二种镜像部署方法。
在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。图5所示的镜像部署方法的实现细节,可以用于镜像部署装置800,运用于容器系统的第一种镜像部署方法中,由管理节点执行的动作也可以参考图5所示的镜像部署方法。图8所示的镜像部署方法的实现细节,可以用于镜像部署装置1000,运用于容器系统的第二种镜像部署方法中,由管理节点执行的动作也可以参考图8所示的镜像部署方法。
第一种容器系统的管理节点,可以通过计算设备200或镜像部署装置800实现。第二种容器系统的管理节点,可以通过用于执行图8所示的镜像部署方法的计算设备或镜像部署装置1000实现。
结合本申请公开内容所描述的方法可以由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成,软件模块可以被存放于RAM、快闪存储器、ROM、可擦除可编程只读存储器(英文:erasable programmable read only memory,缩写:EPROM)、电可擦可编程只读存储器(英文:electrically erasable programmable read only memory,缩写:EEPROM)、硬盘、光盘或者本领域熟知的任何其它形式的存储介质中。
本领域技术人员应该可以意识到,在上述一个或多个示例中,本申请所描述的功能可以用硬件或软件来实现。当使用软件实现时,可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。存储介质可以是通用或专用计算机能够存取的任何可用介质。
以上所述的具体实施方式,对本申请的目的、技术方案和有益效果进行了进一步详细说明,所应理解的是,以上所述仅为本申请的具体实施方式而已,并不用于限定本申请的保护范围,凡在本申请的技术方案的基础之上,所做的任何修改、改进等,均应包括在本申请的保护范围之内。
Claims (32)
- 一种镜像部署方法,其特征在于,镜像库中保存多个镜像,每个镜像由镜像标签表示,所述多个镜像包括至少一个镜像族,每个镜像族包括n个镜像,所述n个镜像中的每两个镜像具有父子关系,第1层镜像为基础镜像,第n层镜像的父镜像包括所述第1层到第n-1层镜像,所述n为大于等于2的自然数;所述部署方法包括:获取待部署镜像的镜像标签;根据所述待部署镜像的镜像标签,从所述镜像库获取所述待部署镜像的父镜像的镜像标签;从容器系统中的主机中确定至少两个待选主机;确定每个待选主机上已部署的镜像的镜像标签;根据所述待部署镜像的父镜像的镜像标签,与所述每个待选主机上已部署的镜像的镜像标签为所述待部署镜像指定部署主机,所述部署主机用于部署所述待部署镜像,所述部署主机上已部署的所述待部署镜像的父镜像满足预定策略。
- 如权利要求1所述的镜像部署方法,其特征在于,所述方法还包括:在满足触发时机的情况下,获取并保存所述容器系统中的每个主机上已部署的镜像的镜像标签;所述满足触发时机包括:预设的周期到达,或接收到部署容器的指令,或接收到用户发送的收集指令,所述收集指令指示收集并保存所述每个主机上已部署的镜像的镜像标签;则,根据保存的所述每个主机上已部署的镜像的镜像标签,确定所述每个待选主机上已部署的镜像的镜像标签。
- 如权利要求1或2所述的镜像部署方法,其特征在于,所述从容器系统中的主机中确定至少两个待选主机前,还包括:获取所述每个主机的资源使用信息,所述资源使用信息包括内存使用率或中央处理器使用率;所述从容器系统中的主机中确定至少两个待选主机包括:根据所述每个主机的资源使用信息,确定满足所述待部署镜像的资源使用要求的所述至少两个待选主机。
- 如权利要求1至3任一项所述的镜像部署方法,其特征在于,所述根据所述待部署镜像的父镜像的镜像标签,与所述每个待选主机上已部署的镜像的镜像标签,为所述待部署镜像指定部署主机包括:将所述待部署镜像的父镜像的镜像标签,与所述每个待选主机上已部署的镜像的镜像标签进行匹配,确定所述每个待选主机上已部署的所述待部署镜像的父镜像;将所述每个待选主机上已部署的所述待部署镜像的父镜像进行比较,根据比较结果和所述预定策略指定所述部署主机,其中,所述预定策略为选择所述至少两个待选主机中已部署的所述待部署镜像的父镜像数量最多的待选主机为所述部署主机。
- 如权利要求4所述的镜像部署方法,其特征在于,所述将所述待部署镜像的父镜像的镜像标签,与所述每个待选主机上已部署的镜像的镜像标签进行匹配,确定所述每个待选主机上已部署的所述待部署镜像的父镜像包括:从所述至少两个待选主机中确定当前待选主机,将所述当前待选主机依次执行下述步骤,直到确定所述当前待选主机上已部署的所述待部署镜像的父镜像,所述步骤包括:步骤一,将所述待部署镜像的镜像标签,与所述当前待选主机上已部署的镜像的镜像标签进行匹配,若匹配上,确定所述当前待选主机上已部署所述待部署镜像,若未匹配上,执行步骤二;步骤二,将所述待部署镜像的顶层父镜像的镜像标签,与所述当前待选主机上已部署的镜像的镜像标签进行匹配,若匹配上,确定所述当前待选主机已部署所述待部署镜像的全部父镜像,若未匹配上,执行步骤三;步骤三,将当前镜像的镜像标签,与所述当前待选主机上已部署的镜像的镜像标签进行匹配,所述当前镜像为前一步骤中进行了匹配的所述待部署镜像的父镜像的顶层父镜像,若匹配上,确定所述当前待选主机上已部署所述当前镜像的全部父镜像,若未匹配上,返回执行步骤三,直至匹配过所述待部署镜像的每个父镜像。
- 一种镜像部署方法,其特征在于,镜像库中保存多个镜像,每个镜像包括至少两个镜像层,每个镜像层由层标识表示,所述每个镜像的至少两个镜像层具有父子关系;所述部署方法包括:获取待部署镜像的镜像标签;根据所述待部署镜像的镜像标签,从所述镜像库获取所述待部署镜像的镜像层的层标识;从容器系统中的主机中确定至少两个待选主机;确定每个待选主机上已部署的镜像层的层标识;根据所述待部署镜像的镜像层的层标识,与所述每个待选主机上已部署的镜像层的层标识,为所述待部署镜像指定部署主机,所述部署主机用于部署所述待部署镜像,所述部署主机上已部署的所述待部署镜像的镜像层满足预定策略。
- 如权利要求6所述的镜像部署方法,其特征在于,所述方法还包括:在满足触发时机的情况下,获取并保存所述容器系统中的每个主机上已部署的镜像层的层标识;所述满足触发时机包括:预设的周期到达,或接收到部署容器的指令,或接收到用户发送的收集指令,所述收集指令指示收集并保存所述每个主机已部署的镜像层的层标识;则,根据保存的所述每个主机上已部署的镜像层的层标识,确定所述每个待选主机上已部署的镜像层的层标识。
- 如权利要求6或7所述的镜像部署方法,其特征在于,所述从容器系统中的主机中确定至少两个待选主机前,还包括:获取所述每个主机的资源使用信息,所述资源使用信息包括内存使用率或中央处理器使用率;所述从容器系统中的主机中确定至少两个待选主机包括:根据所述每个主机的资源使用信息,确定满足所述待部署镜像的资源使用要求的所述至少两个待选主机。
- 如权利要求6至8任一项所述的镜像部署方法,其特征在于,所述根据所 述待部署镜像的镜像层的层标识,与所述每个待选主机上已部署的镜像层的层标识,为所述待部署镜像指定部署主机包括:将所述待部署镜像的镜像层的层标识,与所述每个待选主机上已部署的镜像层的层标识进行匹配,确定所述每个待选主机上已部署的所述待部署镜像的镜像层;将所述每个待选主机上已部署的所述待部署镜像的镜像层进行比较,根据比较结果和所述预定策略指定所述部署主机,其中,所述预定策略为选择所述至少两个待选主机中已部署的所述待部署镜像的镜像层数量最多的待选主机为所述部署主机。
- 如权利要求9所述的镜像部署方法,其特征在于,将所述待部署镜像的镜像层的层标识,与所述每个待选主机上已部署的镜像层的层标识进行匹配,确定所述每个待选主机上已部署的所述待部署镜像的镜像层包括:从所述至少两个待选主机中确定当前待选主机,将所述当前待选主机依次执行下述步骤,直到确定所述当前待选主机上已部署的所述待部署镜像的镜像层,所述步骤包括:步骤一,将所述待部署镜像的顶层镜像层的层标识,与所述当前待选主机上已部署的镜像层的层标识进行匹配,若匹配上,确定所述当前待选主机上已部署所述待部署镜像的全部镜像层,若未匹配上,执行步骤二;步骤二,将当前镜像层的层标识,与所述当前待选主机上已部署的镜像层的层标识进行匹配,所述当前镜像层为前一步骤中进行了匹配的所述待部署镜像的镜像层的父镜像层,若匹配上,确定所述当前待选主机上已部署所述当前镜像层以下的全部镜像层,若未匹配上,返回执行步骤二,直至匹配过所述待部署镜像的每个镜像层。
- 一种镜像部署装置,其特征在于,镜像库中保存多个镜像,每个镜像由镜像标签表示,所述多个镜像包括至少一个镜像族,每个镜像族包括n个镜像,所述n个镜像中的每两个镜像具有父子关系,第1层镜像为基础镜像,第n层镜像的父镜像包括所述第1层到第n-1层镜像,所述n为大于等于2的自然数,所述装置 包括:获取单元,用于获取待部署镜像的镜像标签;处理单元,用于根据所述待部署镜像的镜像标签,从所述镜像库获取所述待部署镜像的父镜像的镜像标签;还用于从容器系统中的主机中确定至少两个待选主机;还用于确定每个待选主机上已部署的镜像的镜像标签;还用于根据所述待部署镜像的父镜像的镜像标签,与所述每个待选主机上已部署的镜像的镜像标签为所述待部署镜像指定部署主机,所述部署主机用于部署所述待部署镜像,所述部署主机上已部署的所述待部署镜像的父镜像满足预定策略。
- 如权利要求11所述的镜像部署装置,其特征在于,所述获取单元,还用于在满足触发时机的情况下,获取并保存所述容器系统中的每个主机上已部署的镜像的镜像标签;所述满足触发时机包括:预设的周期到达,或接收到部署容器的指令,或接收到用户发送的收集指令,所述收集指令指示收集并保存所述每个主机上已部署的镜像的镜像标签;所述处理单元确定所述每个待选主机上已部署的镜像的镜像标签包括:根据保存的所述每个主机上已部署的镜像的镜像标签,确定所述每个待选主机上已部署的镜像的镜像标签。
- 如权利要求11或12所述的镜像部署装置,其特征在于,所述获取单元,还用于获取所述每个主机的资源使用信息,所述资源使用信息包括内存使用率或中央处理器使用率;所述处理单元从容器系统中的主机中确定至少两个待选主机包括:根据所述每个主机的资源使用信息,确定满足所述待部署镜像的资源使用要求的所述至少两个待选主机。
- 如权利要求11或13任一项所述的镜像部署装置,其特征在于,所述处理单元根据所述待部署镜像的父镜像的镜像标签,与所述每个待选主机上已部署的镜像的镜像标签,为所述待部署镜像指定部署主机包括:将所述待部署镜像的父镜像的镜像标签,与所述每个待选主机上已部署的镜像的镜像标签进行匹配,确定所述每个待选主机上已部署的所述待部署镜像的父镜像;将所述每个待选主机上已部署的所述待部署镜像的父镜像进行比较, 根据比较结果和所述预定策略指定所述部署主机,其中,所述预定策略为选择所述至少两个待选主机中已部署的所述待部署镜像的父镜像数量最多的待选主机为所述部署主机。
- 如权利要求14所述的镜像部署装置,其特征在于,所述处理单元将所述待部署镜像的父镜像的镜像标签,与所述每个待选主机上已部署的镜像的镜像标签进行匹配,确定所述每个待选主机上已部署的所述待部署镜像的父镜像包括:从所述至少两个待选主机中确定当前待选主机,将所述当前待选主机依次执行下述步骤,直到确定所述当前待选主机上已部署的所述待部署镜像的父镜像,所述步骤包括:步骤一,将所述待部署镜像的镜像标签,与所述当前待选主机上已部署的镜像的镜像标签进行匹配,若匹配上,确定所述当前待选主机上已部署所述待部署镜像,若未匹配上,执行步骤二;步骤二,将所述待部署镜像的顶层父镜像的镜像标签,与所述当前待选主机上已部署的镜像的镜像标签进行匹配,若匹配上,确定所述当前待选主机已部署所述待部署镜像的全部父镜像,若未匹配上,执行步骤三;步骤三,将当前镜像的镜像标签,与所述当前待选主机上已部署的镜像的镜像标签进行匹配,所述当前镜像为前一步骤中进行了匹配的所述待部署镜像的父镜像的顶层父镜像,若匹配上,确定所述当前待选主机上已部署所述当前镜像的全部父镜像,若未匹配上,返回执行步骤三,直至匹配过所述待部署镜像的每个父镜像。
- 一种镜像部署装置,其特征在于,镜像库中保存多个镜像,每个镜像包括至少两个镜像层,每个镜像层由层标识表示,所述每个镜像的至少两个镜像层具有父子关系,所述装置包括:获取单元,用于获取待部署镜像的镜像标签;处理单元,用于根据所述待部署镜像的镜像标签,从所述镜像库获取所述待部署镜像的镜像层的层标识;还用于从容器系统中的主机中确定至少两个待 选主机;还用于确定每个待选主机上已部署的镜像层的层标识;还用于根据所述待部署镜像的镜像层的层标识,与所述每个待选主机上已部署的镜像层的层标识,为所述待部署镜像指定部署主机,所述部署主机用于部署所述待部署镜像,所述部署主机上已部署的所述待部署镜像的镜像层满足预定策略。
- 如权利要求16所述的镜像部署装置,其特征在于,所述获取单元,还用于在满足触发时机的情况下,获取并保存所述容器系统中的每个主机上已部署的镜像层的层标识;所述满足触发时机包括:预设的周期到达,或接收到部署容器的指令,或接收到用户发送的收集指令,所述收集指令指示收集并保存所述每个主机已部署的镜像层的层标识;所述处理单元确定所述每个待选主机上已部署的镜像层的层标识包括:根据保存的所述每个主机上已部署的镜像层的层标识,确定所述每个待选主机上已部署的镜像层的层标识。
- 如权利要求16或17所述的镜像部署装置,其特征在于,所述获取单元,还用于获取所述每个主机的资源使用信息,所述资源使用信息包括内存使用率或中央处理器使用率;所述处理单元从容器系统中的主机中确定至少两个待选主机包括:根据所述每个主机的资源使用信息,确定满足所述待部署镜像的资源使用要求的所述至少两个待选主机。
- 如权利要求16至18任一项所述的镜像部署装置,其特征在于,所述处理单元根据所述待部署镜像的镜像层的层标识,与所述每个待选主机上已部署的镜像层的层标识,为所述待部署镜像指定部署主机包括:将所述待部署镜像的镜像层的层标识,与所述每个待选主机上已部署的镜像层的层标识进行匹配,确定所述每个待选主机上已部署的所述待部署镜像的镜像层;将所述每个待选主机上已部署的所述待部署镜像的镜像层进行比较,根据比较结果和所述预定策略指定所述部署主机,其中,所述预定策略为选择所述至少两个待选主机中已部署的所述待部署镜像的镜像层数量最多的待选主机为所述部署主机。
- 如权利要求19所述的镜像部署装置,其特征在于,所述处理单元将所 述待部署镜像的镜像层的层标识,与所述每个待选主机上已部署的镜像层的层标识进行匹配,确定所述每个待选主机上已部署的所述待部署镜像的镜像层包括:从所述至少两个待选主机中确定当前待选主机,将所述当前待选主机依次执行下述步骤,直到确定所述当前待选主机上已部署的所述待部署镜像的镜像层,所述步骤包括:步骤一,将所述待部署镜像的顶层镜像层的层标识,与所述当前待选主机上已部署的镜像层的层标识进行匹配,若匹配上,确定所述当前待选主机上已部署所述待部署镜像的全部镜像层,若未匹配上,执行步骤二;步骤二,将当前镜像层的层标识,与所述当前待选主机上已部署的镜像层的层标识进行匹配,所述当前镜像层为前一步骤中进行了匹配的所述待部署镜像的镜像层的父镜像层,若匹配上,确定所述当前待选主机上已部署所述当前镜像层以下的全部镜像层,若未匹配上,返回执行步骤二,直至匹配过所述待部署镜像的每个镜像层。
- 一种计算设备,其特征在于,包括处理器、存储器,所述处理器与所述处理器建立通信连接;所述处理器用于读取所述存储器中的程序执行如权利要求1至5任一项所述的镜像部署方法。
- 一种计算设备,其特征在于,包括处理器、存储器,所述处理器与所述处理器建立通信连接;所述处理器用于读取所述存储器中的程序执行如权利要求6至10任一项所述的镜像部署方法。
- 一种镜像部署方法,其特征在于,所述部署方法运用于容器系统,所述容器系统包括管理节点,与所述容器系统通信的镜像库中保存多个镜像,每个镜像由镜像标签表示,所述多个镜像包括至少一个镜像族,每个镜像族包括n 个镜像,所述n个镜像中的每两个镜像具有父子关系,第1层镜像为基础镜像,第n层镜像的父镜像包括所述第1层到第n-1层镜像,所述n为大于等于2的自然数;所述部署方法包括:所述管理节点获取待部署镜像的镜像标签;所述管理节点根据所述待部署镜像的镜像标签,从所述镜像库获取所述待部署镜像的父镜像的镜像标签;所述管理节点从容器系统中的主机中确定至少两个待选主机;所述管理节点确定每个待选主机上已部署的镜像的镜像标签;所述管理节点根据所述待部署镜像的父镜像的镜像标签,与所述每个待选主机上已部署的镜像的镜像标签为所述待部署镜像指定部署主机,所述部署主机用于部署所述待部署镜像,所述部署主机上已部署的所述待部署镜像的父镜像满足预定策略。
- 如权利要求23所述的镜像部署方法,其特征在于,所述方法还包括:在满足触发时机的情况下,所述容器系统中的每个主机向所述管理节点发送本地已部署的镜像的镜像标签;所述管理节点获取并保存所述每个主机上已部署的镜像的镜像标签;所述满足触发时机包括:预设的周期到达,或接收到所述管理节点发送的收集指令,所述收集指令指示向所述管理节点发送已部署的镜像的镜像标签,或检测到本地已部署的镜像发生变化;则,所述管理节点根据保存的所述每个主机上已部署的镜像的镜像标签,确定所述每个待选主机上已部署的镜像的镜像标签。
- 如权利要求23或24所述的镜像部署方法,其特征在于,所述管理节点从容器系统中的主机中确定至少两个待选主机前,还包括:获取所述每个主机的资源使用信息,所述资源使用信息包括内存使用率或中央处理器使用率;所述管理节点从容器系统中的主机中确定至少两个待选主机包括:根据所述每个主机的资源使用信息,确定满足所述待部署镜像的资源使用要求的所述至少两个待选主机。
- 如权利要求23至25任一项所述的镜像部署方法,其特征在于,所述管理节点根据所述待部署镜像的父镜像的镜像标签,与所述每个待选主机上已部署 的镜像的镜像标签,为所述待部署镜像指定部署主机包括:所述管理节点将所述待部署镜像的父镜像的镜像标签,与所述每个待选主机上已部署的镜像的镜像标签进行匹配,确定所述每个待选主机上已部署的所述待部署镜像的父镜像;所述管理节点将所述每个待选主机上已部署的所述待部署镜像的父镜像进行比较,根据比较结果和所述预定策略指定所述部署主机,其中,所述预定策略为选择所述至少两个待选主机中已部署的所述待部署镜像的父镜像数量最多的待选主机为所述部署主机。
- 如权利要求26所述的镜像部署方法,其特征在于,所述管理节点将所述待部署镜像的父镜像的镜像标签,与所述每个待选主机上已部署的镜像的镜像标签进行匹配,确定所述每个待选主机上已部署的所述待部署镜像的父镜像包括:所述管理节点从所述至少两个待选主机中确定当前待选主机,将所述当前待选主机依次执行下述步骤,直到确定所述当前待选主机上已部署的所述待部署镜像的父镜像,所述步骤包括:步骤一,将所述待部署镜像的镜像标签,与所述当前待选主机上已部署的镜像的镜像标签进行匹配,若匹配上,确定所述当前待选主机上已部署所述待部署镜像,若未匹配上,执行步骤二;步骤二,将所述待部署镜像的顶层父镜像的镜像标签,与所述当前待选主机上已部署的镜像的镜像标签进行匹配,若匹配上,确定所述当前待选主机已部署所述待部署镜像的全部父镜像,若未匹配上,执行步骤三;步骤三,将当前镜像的镜像标签,与所述当前待选主机上已部署的镜像的镜像标签进行匹配,所述当前镜像为前一步骤中进行了匹配的所述待部署镜像的父镜像的顶层父镜像,若匹配上,确定所述当前待选主机上已部署所述当前镜像的全部父镜像,若未匹配上,返回执行步骤三,直至匹配过所述待部署镜像的每个父镜像。
- 一种镜像部署方法,其特征在于,所述部署方法运用于容器系统,所 述容器系统包括管理节点,与所述容器系统通信的镜像库中保存多个镜像,每个镜像包括至少两个镜像层,每个镜像层由层标识表示,所述每个镜像的至少两个镜像层具有父子关系;所述部署方法包括:所述管理节点获取待部署镜像的镜像标签;所述管理节点根据所述待部署镜像的镜像标签,从所述镜像库获取所述待部署镜像的镜像层的层标识;所述管理节点从容器系统中的主机中确定至少两个待选主机;所述管理节点确定每个待选主机上已部署的镜像层的层标识;所述管理节点根据所述待部署镜像的镜像层的层标识,与所述每个待选主机上已部署的镜像层的层标识,为所述待部署镜像指定部署主机,所述部署主机用于部署所述待部署镜像,所述部署主机上已部署的所述待部署镜像的镜像层满足预定策略。
- 如权利要求28所述的镜像部署方法,其特征在于,所述方法还包括:在满足触发时机的情况下,所述容器系统中的每个主机向所述管理节点发送本地已部署的镜像层的层标识;所述管理节点获取并保存所述每个主机上已部署的镜像层的层标识;所述满足触发时机包括:预设的周期到达,或接收到所述管理节点发送的收集指令,所述收集指令指示向所述管理节点发送已部署的镜像层的层标识,或检测到本地已部署的镜像层发生变化;则,所述管理节点根据保存的所述每个主机上已部署的镜像层的层标识,确定所述每个待选主机上已部署的镜像层的层标识。
- 如权利要求28或29所述的镜像部署方法,其特征在于,所述管理节点从容器系统中的主机中确定至少两个待选主机前,还包括:获取所述每个主机的资源使用信息,所述资源使用信息包括内存使用率或中央处理器使用率;所述管理节点从容器系统中的主机中确定至少两个待选主机包括:根据所述每个主机的资源使用信息,确定满足所述待部署镜像的资源使用要求的所述至少两个待选主机。
- 如权利要求28至30任一项所述的镜像部署方法,其特征在于,所述管理 节点根据所述待部署镜像的镜像层的层标识,与所述每个待选主机上已部署的镜像层的层标识,为所述待部署镜像指定部署主机包括:所述管理节点将所述待部署镜像的镜像层的层标识,与所述每个待选主机上已部署的镜像层的层标识进行匹配,确定所述每个待选主机上已部署的所述待部署镜像的镜像层;所述管理节点将所述每个待选主机上已部署的所述待部署镜像的镜像层进行比较,根据比较结果和所述预定策略指定所述部署主机,其中,所述预定策略为选择所述至少两个待选主机中已部署的所述待部署镜像的镜像层数量最多的待选主机为所述部署主机。
- 如权利要求31所述的镜像部署方法,其特征在于,所述管理节点将所述待部署镜像的镜像层的层标识,与所述每个待选主机上已部署的镜像层的层标识进行匹配,确定所述每个待选主机上已部署的所述待部署镜像的镜像层包括:所述管理节点从所述至少两个待选主机中确定当前待选主机,将所述当前待选主机依次执行下述步骤,直到确定所述当前待选主机上已部署的所述待部署镜像的镜像层,所述步骤包括:步骤一,将所述待部署镜像的顶层镜像层的层标识,与所述当前待选主机上已部署的镜像层的层标识进行匹配,若匹配上,确定所述当前待选主机上已部署所述待部署镜像的全部镜像层,若未匹配上,执行步骤二;步骤二,将当前镜像层的层标识,与所述当前待选主机上已部署的镜像层的层标识进行匹配,所述当前镜像层为前一步骤中进行了匹配的所述待部署镜像的镜像层的父镜像层,若匹配上,确定所述当前待选主机上已部署所述当前镜像层以下的全部镜像层,若未匹配上,返回执行步骤二,直至匹配过所述待部署镜像的每个镜像层。
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/CN2015/100291 WO2017113374A1 (zh) | 2015-12-31 | 2015-12-31 | 镜像部署方法和装置 |
CN201580009116.4A CN107431720B (zh) | 2015-12-31 | 2015-12-31 | 镜像部署方法和装置 |
EP15906408.8A EP3211859B1 (en) | 2015-12-31 | 2015-12-31 | Mirror deployment method and device thereof |
US15/492,940 US10552133B2 (en) | 2015-12-31 | 2017-04-20 | Image deployment method and apparatus |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/CN2015/100291 WO2017113374A1 (zh) | 2015-12-31 | 2015-12-31 | 镜像部署方法和装置 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/492,940 Continuation US10552133B2 (en) | 2015-12-31 | 2017-04-20 | Image deployment method and apparatus |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2017113374A1 true WO2017113374A1 (zh) | 2017-07-06 |
Family
ID=59224365
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2015/100291 WO2017113374A1 (zh) | 2015-12-31 | 2015-12-31 | 镜像部署方法和装置 |
Country Status (4)
Country | Link |
---|---|
US (1) | US10552133B2 (zh) |
EP (1) | EP3211859B1 (zh) |
CN (1) | CN107431720B (zh) |
WO (1) | WO2017113374A1 (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108984268A (zh) * | 2018-07-13 | 2018-12-11 | 郑州云海信息技术有限公司 | Docker系统中容器管理的方法和装置 |
WO2019165573A1 (zh) * | 2018-02-27 | 2019-09-06 | 深圳中兴力维技术有限公司 | 一种基于Docker的镜像同步方法、装置及系统 |
Families Citing this family (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10614117B2 (en) * | 2017-03-21 | 2020-04-07 | International Business Machines Corporation | Sharing container images between mulitple hosts through container orchestration |
CN107590033B (zh) * | 2017-09-07 | 2021-06-22 | 网宿科技股份有限公司 | 一种创建docker容器的方法、装置和系统 |
CN109542493A (zh) * | 2017-09-22 | 2019-03-29 | 华为技术有限公司 | 一种镜像升级方法及设备 |
US10949250B2 (en) | 2018-02-07 | 2021-03-16 | Red Hat, Inc. | Image subunit based guest scheduling |
US10922118B2 (en) | 2018-05-11 | 2021-02-16 | International Business Machines Corporation | Distributed container image repository service |
CN110896404B (zh) * | 2018-09-12 | 2021-09-14 | 华为技术有限公司 | 数据处理的方法、装置和计算节点 |
US10838702B2 (en) | 2018-11-09 | 2020-11-17 | International Business Machines Corporation | Analyzing and optimizing container images in cloud computing |
CN111190608B (zh) * | 2018-11-14 | 2022-09-16 | 佛山市顺德区顺达电脑厂有限公司 | 用于待测装置的作业系统布署方法 |
CN111198745A (zh) * | 2018-11-16 | 2020-05-26 | 北京京东尚科信息技术有限公司 | 容器创建的调度方法、装置、介质及电子设备 |
US11132210B2 (en) | 2019-05-09 | 2021-09-28 | International Business Machines Corporation | Dynamic parallelism adjustment |
CN110704162B (zh) * | 2019-09-27 | 2022-09-20 | 北京百度网讯科技有限公司 | 物理机共享容器镜像的方法、装置、设备及存储介质 |
US11748171B2 (en) * | 2020-03-17 | 2023-09-05 | Dell Products L.P. | Method and system for collaborative workload placement and optimization |
CN111414234A (zh) * | 2020-03-20 | 2020-07-14 | 深圳市网心科技有限公司 | 镜像容器创建方法及装置、计算机装置及存储介质 |
WO2021197579A1 (en) * | 2020-03-31 | 2021-10-07 | Telefonaktiebolaget Lm Ericsson (Publ) | Method for deploying application software in cloud environments |
CN113934506A (zh) * | 2020-06-29 | 2022-01-14 | 伊姆西Ip控股有限责任公司 | 管理容器的映像的方法、设备和计算机程序产品 |
US11281443B1 (en) * | 2020-07-31 | 2022-03-22 | Tableau Software, LLC | Organizing deployment packages for software applications and services |
CN112269694B (zh) * | 2020-10-23 | 2023-12-22 | 北京浪潮数据技术有限公司 | 一种管理节点确定方法、装置、电子设备及可读存储介质 |
CN112714163B (zh) * | 2020-12-22 | 2022-06-10 | 北京百度网讯科技有限公司 | 数据传输方法、装置、电子设备和介质 |
US12039314B2 (en) * | 2021-01-15 | 2024-07-16 | Palantir Technologies Inc. | System and methods for using container layers to facilitate cloud resource sharing and decrease startup times |
US11928452B2 (en) * | 2022-02-03 | 2024-03-12 | Red Hat, Inc. | Reducing the size of image files usable for deploying software in computing environments |
US12045595B2 (en) * | 2022-06-14 | 2024-07-23 | Sap Se | Low-/no-code packaging of application based on artifacts and universal tags |
CN116700902B (zh) * | 2023-06-25 | 2024-03-12 | 天津大学 | 一种镜像层异步并行提取的容器加速部署方法及装置 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101594387A (zh) * | 2009-06-29 | 2009-12-02 | 北京航空航天大学 | 虚拟集群部署方法和系统 |
CN102088367A (zh) * | 2010-12-10 | 2011-06-08 | 北京世纪互联工程技术服务有限公司 | 虚拟化环境下快速部署方法 |
CN103037002A (zh) * | 2012-12-21 | 2013-04-10 | 中标软件有限公司 | 一种云计算集群环境中服务器集群的部署方法及系统 |
CN104809025A (zh) * | 2015-04-29 | 2015-07-29 | 北京奇艺世纪科技有限公司 | 一种项目上线方法及装置 |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103514023B (zh) * | 2013-10-22 | 2016-06-29 | 中国科学院信息工程研究所 | 一种虚拟机离线自动软件安装的方法及系统 |
US9116768B1 (en) * | 2014-11-20 | 2015-08-25 | Symantec Corporation | Systems and methods for deploying applications included in application containers |
US10365976B2 (en) * | 2015-07-28 | 2019-07-30 | Vmware, Inc. | Scheduling and managing series of snapshots |
US9965261B2 (en) * | 2015-08-18 | 2018-05-08 | International Business Machines Corporation | Dependency-based container deployment |
US9639558B2 (en) * | 2015-09-17 | 2017-05-02 | International Business Machines Corporation | Image building |
US10002247B2 (en) * | 2015-12-18 | 2018-06-19 | Amazon Technologies, Inc. | Software container registry container image deployment |
-
2015
- 2015-12-31 WO PCT/CN2015/100291 patent/WO2017113374A1/zh active Application Filing
- 2015-12-31 EP EP15906408.8A patent/EP3211859B1/en active Active
- 2015-12-31 CN CN201580009116.4A patent/CN107431720B/zh active Active
-
2017
- 2017-04-20 US US15/492,940 patent/US10552133B2/en active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101594387A (zh) * | 2009-06-29 | 2009-12-02 | 北京航空航天大学 | 虚拟集群部署方法和系统 |
CN102088367A (zh) * | 2010-12-10 | 2011-06-08 | 北京世纪互联工程技术服务有限公司 | 虚拟化环境下快速部署方法 |
CN103037002A (zh) * | 2012-12-21 | 2013-04-10 | 中标软件有限公司 | 一种云计算集群环境中服务器集群的部署方法及系统 |
CN104809025A (zh) * | 2015-04-29 | 2015-07-29 | 北京奇艺世纪科技有限公司 | 一种项目上线方法及装置 |
Non-Patent Citations (2)
Title |
---|
DIAO, JINMING: "Analysis of Mirror and Container Storage Structure Docker", 18 November 2014 (2014-11-18), XP055393219, Retrieved from the Internet <URL:http://www.csdn.net/article> * |
See also references of EP3211859A4 * |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2019165573A1 (zh) * | 2018-02-27 | 2019-09-06 | 深圳中兴力维技术有限公司 | 一种基于Docker的镜像同步方法、装置及系统 |
CN108984268A (zh) * | 2018-07-13 | 2018-12-11 | 郑州云海信息技术有限公司 | Docker系统中容器管理的方法和装置 |
Also Published As
Publication number | Publication date |
---|---|
EP3211859A1 (en) | 2017-08-30 |
EP3211859A4 (en) | 2017-10-25 |
CN107431720B (zh) | 2019-11-29 |
US10552133B2 (en) | 2020-02-04 |
EP3211859B1 (en) | 2018-11-14 |
CN107431720A (zh) | 2017-12-01 |
US20170220329A1 (en) | 2017-08-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2017113374A1 (zh) | 镜像部署方法和装置 | |
US11150916B2 (en) | Execution of workflows in distributed systems | |
EP3355193B1 (en) | Security-based container scheduling | |
US10585691B2 (en) | Distribution system, computer, and arrangement method for virtual machine | |
US9329889B2 (en) | Rapid creation and reconfiguration of virtual machines on hosts | |
CN105765575B (zh) | 数据流摄取和持久性技术 | |
RU2429529C2 (ru) | Динамическое конфигурирование, выделение и развертывание вычислительных систем | |
US8495352B2 (en) | System and method for instantiation of distributed applications from disk snapshots | |
WO2017041613A1 (zh) | 镜像部署方法、装置 | |
US20200042406A1 (en) | Continuous replication and granular application level replication | |
CN109933338B (zh) | 区块链部署方法、装置、计算机设备和存储介质 | |
US9612924B1 (en) | Fault tolerance in a distributed file system | |
Zhang et al. | Improving Hadoop service provisioning in a geographically distributed cloud | |
US7275142B1 (en) | Storage layout and data replication | |
WO2014080492A1 (ja) | 計算機システム、クラスタ管理方法、及び管理計算機 | |
US20200192744A1 (en) | Fast recovery from failures in a chronologically ordered log-structured key-value storage system | |
EP3230865B1 (en) | Recovery execution system using programatic generation of actionable workflows | |
US20200244766A1 (en) | Systems and methods for semi-automatic workload domain deployments | |
JP6002832B2 (ja) | 計算機システム、データ管理方法及びプログラムを格納する記録媒体 | |
JP5782563B2 (ja) | 情報取得方法、計算機システム及び管理計算機 | |
US9122511B2 (en) | Using preprovisioned mutated templates | |
US20180322675A1 (en) | Image Processing Method and Computing Device | |
GB2542585A (en) | Task scheduler and task scheduling process | |
Jayakar et al. | Managing small size files through indexing in extended Hadoop file system | |
WO2024136852A1 (en) | Network service stitching for cloud native network functions and virtual network functions |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
REEP | Request for entry into the european phase |
Ref document number: 2015906408 Country of ref document: EP |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 15906408 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |