Disclosure of Invention
In view of the above, the present disclosure provides a container creation method and apparatus, so as to enable the container to be used more flexibly and conveniently for a device, and reduce the influence of device update on a container service.
Specifically, the present disclosure is realized by the following technical solutions:
in a first aspect, a container creating method is provided, where the method is applied to creating a container carrying a target device, and the method includes:
receiving a plug-in trigger request sent by a container engine for creating a container;
acquiring equipment information and drive of the target equipment according to the trigger request;
returning the device information and drive to the container engine to cause the container engine to create a container carrying the target device.
In a second aspect, a container creating method is provided, and the method is applied to creating a container carrying a target device, and includes:
sending a plug-in triggering request to a container plug-in, wherein the plug-in triggering request is used for triggering the container plug-in to acquire the equipment information and the drive of the target equipment;
receiving the equipment information and the drive returned by the container plug-in;
and using the device information and the driver to create a container carrying the target device.
In a third aspect, an apparatus for creating a container is provided, where the apparatus is applied to create a container carrying a target device, and the apparatus includes:
the trigger receiving module is used for receiving a plug-in trigger request sent by a container engine for creating a container;
the information acquisition module is used for acquiring the equipment information and the drive of the target equipment according to the trigger request;
and the information feedback module is used for returning the equipment information and the drive to the container engine so as to enable the container engine to create a container carrying the target equipment.
In a fourth aspect, an apparatus for creating a container is provided, where the apparatus is applied to create a container carrying a target device, and the apparatus includes:
the request sending module is used for sending a plug-in triggering request to a container plug-in, wherein the plug-in triggering request is used for triggering the container plug-in to acquire the equipment information and the drive of the target equipment;
the information receiving module is used for receiving the equipment information and the drive returned by the container plug-in;
and the container creating module is used for creating a container carrying the target equipment by using the equipment information and the drive.
In a fifth aspect, a computer-readable storage medium is provided, the medium having stored thereon computer instructions that, when executed by a processor, perform the steps of:
receiving a plug-in trigger request sent by a container engine for creating a container;
acquiring equipment information and drive of the target equipment according to the trigger request;
returning the device information and drive to the container engine to cause the container engine to create a container carrying the target device.
In a sixth aspect, there is provided a processing device having a target device installed therein, the processing device comprising a memory, a processor, and computer instructions stored on the memory and executable on the processor, the computer instructions comprising: plug-in instructions for implementing a container plug-in, and engine instructions for implementing a container engine;
the processor is used for realizing the following steps by executing the plug-in instruction: receiving a plug-in trigger request sent by a container engine for creating a container; acquiring equipment information and drive of the target equipment according to the trigger request; returning the device information and drive to the container engine;
the processor is used for realizing the following steps by executing the engine instruction: sending a plug-in triggering request to a container plug-in, wherein the plug-in triggering request is used for triggering the container plug-in to acquire the equipment information and the drive of the target equipment; receiving equipment information and a drive returned by the container plug-in; and using the device information and the driver to create a container carrying the target device.
According to the container creation method and device, when the container engine creates the container, the container plug-in of the container can be automatically triggered to replace equipment information and drive of the collection target equipment, so that the required information is acquired more quickly and conveniently when the container is created, and the business in the container cannot be influenced in a plug-in mode.
Detailed Description
The container (container) technology can create an independent sandbox running environment for the application program, instead of providing a complete set of operating system like a virtual machine, for example, a traditional virtual machine mode is to start ten virtual machines for running ten different applications, and the container technology only needs to start ten isolated applications, which are respectively located in different containers. The starting and running efficiency of the container is high, the utilization rate of system resources is high, the container basically does not consume extra system resources except for running the application programs in the container, and a large number of containers can be run on one host at the same time. Because of the above advantages, container technology is being applied to all aspects of work.
Fig. 1 illustrates an application scenario of a container, and as shown in fig. 1, the processing device 11 may be a physical machine such as a computer, a server, or the like, or may also be a virtual machine running on the physical machine, which is taken as an example in the following description. At least one hardware device may be installed in the processing device 11, and in one example, the hardware devices may be infiniband devices, which are a computer network communication standard suitable for the high performance computing field and have high throughput and low latency transmission characteristics, and may include infiniband switches, internetworking devices, and the like. The use of the infiniband apparatus requires a drive to carry the apparatus, and as shown in fig. 1, a physical machine infiniband apparatus 12 (i.e. infiniband installed on a processing apparatus in the form of a physical machine to distinguish containers infiniband appearing in the following description) and a physical machine infiniband drive 13 (similarly, to distinguish container drives appearing in the following) are included in the processing apparatus 11. In this example, the infiniband device may be referred to as a target device, and the infiniband device is taken as an example in the following description, but may be another hardware device in other application scenarios.
With continued reference to fig. 1, assuming that a container 14 is created and run on the processing device, and an application program in the container 14 needs to use the infiniband device to improve network throughput and network communication efficiency, the container 14 may be an "infiniband device carrying container (illustrated as infiniband container in fig. 1)", i.e., the infiniband device needs to be mounted in the container 14, and the container 14 needs to include a driver of the infiniband device, so that the infiniband device can be normally used. As shown in fig. 1, the container 14 includes therein a container infiniband device and an actuator to share the actual physical device through these.
The container creation method of the present disclosure is used to describe how to create the above-mentioned container 14, and make the infiniband device and its driver in the processing device 11 carried in the container 14. As shown in fig. 1, the container engine 15 may be responsible for creating the container, in one example, the container engine 15 may be, for example, a Docker, which is an open source application container engine, so that developers may package their applications and dependencies into a portable container and then distribute the portable container to any popular Linux machine, in order to implement building once and running everywhere, i.e., "Build once, Run everywhere", and the Docker may automate the task of deploying the application under the software container. Of course, in other application examples, other container engines may be used, and are not limited to Docker, and the following examples of the disclosure are described by taking Docker as an example.
Taking Docker as an example, Docker may provide an extension mechanism, i.e., Docker plug-in, for example, Docker may support volume plug-ins. The plug-in is an independent process, the Docker plug-in and the Docker can run on the same host, and the plug-in is triggered by the Docker process. The present disclosure provides a plug-in, such as the container plug-in 16 shown in fig. 1, from which the container plug-in 16 is responsible for collecting the required infiniband device information and drivers for the creation of the container and returning to the container engine 15 for the container engine 15 to create the container.
Fig. 2 illustrates a container creation flow of the present disclosure, which may include:
in step 201, the container engine receives a container creation request, which is used to request to create a container carrying a target device.
For example, as shown in FIG. 1, a user scheduler may send a container creation request to Docker, which schedules a Docker process to create a container carrying infiniband devices.
In step 202, the container engine sends a plug-in trigger request to the container plug-in.
For example, after receiving a container creation request, the Docker process starts to enter a process of creating a container. In this step, the container plugin in the present disclosure may be triggered to start working through the Volume Driver of the Docker process, which is equivalent to sending a plugin triggering request to the container plugin.
In step 203, the container plug-in obtains the device information and the driver of the target device according to the trigger request.
For example, after the container plug-in 16 in fig. 1 detects the trigger of the Docker process for creating the Volume event, it may determine whether the trigger parameter is correct, for example, whether the format of the parameter carried in the trigger request is correct. If the requirements are not met, failure of creating the Volume event can be returned to the Docker, otherwise, the device information and the driver of the infiniband device can be continuously acquired, which in this example may be the device information and the driver of the physical machine infiniband device in fig. 1.
In step 204, the container plug-in returns device information and drivers to the container engine.
In this step, the container plug-in 16 in fig. 1 may return the acquired device information and drive of the infiniband device to the Docker.
In step 205, the container engine creates a container carrying the target device using the device information and driver. For example, Docker may perform device mount and directory mount of infiniband devices based on device information and drivers.
The container creation method of this example is a method for designing acquisition of device information and drivers into plugins, which are flexible and lightweight operation modes and have plugging and unplugging characteristics, and generally, the plugging and unplugging process does not affect the main process. In this example, when the container engine creates a container, the container plug-in of the present disclosure may be automatically triggered to replace the device information and driver of the collection target device, so that the acquisition of the information required when creating the container is faster and more convenient, and the plug-in mode does not affect the service in the container.
In addition, when a plurality of containers are created by the Docker, in the prior art, a driver can be directly installed in each container, and when the version of the driver is updated, each container and the mirror image need to be updated accordingly. Moreover, the container plug-in can return the latest drive and equipment information of the equipment to the Docker, so that the Docker can be compatible with each equipment version, the container plug-in is responsible for collecting the drive and equipment information of the target equipment, the creation process of the container carrying the equipment is greatly simplified, and the container can be used for realizing more flexible and convenient use of the equipment.
In one example, the structure and operation of the container insert of FIG. 1 will be described in further detail.
As shown in fig. 3, for example, the container insert of the present disclosure may include three modules, respectively: a plug-in extension triggering module 31, a driver and device selection module 32, and a driver and device collection module 33. For example, the plug-in extension trigger module 31 may be a Docker Volume plug-in extension trigger module. The working process of the container plug-in unit can be executed by the cooperation of the three modules, and comprises the following three stages:
the first stage is as follows: the plug-in extends the flow of the trigger module.
As in the example of fig. 4, in step 401, a plug-in extension trigger module receives a plug-in trigger.
In this step, the plug-in extension triggering module may listen to whether a Volume event is to be created. When the Docker receives the container creation request, it may trigger the plug-in extension trigger module to create a Volume event. In this example, the plug-in extension triggering module may continue to execute 402 after receiving a plug-in triggering request for creating a Volume event sent by the Docker, or else, may continue to listen.
In step 402, the plug-in extension trigger module determines whether the trigger parameters are correct.
If the trigger parameter is correct, the driver and device selection module may be triggered to execute the next stage of process in step 403; otherwise, a failure to create a Volume event may be returned to Docker in step 404.
As can be seen from the flow of fig. 4, the plug-in extension triggering module in the container plug-in of this example may be mainly responsible for determining whether to receive plug-in trigger of Docker and whether to create a Volume event, that is, for determining whether the container plug-in needs to start to obtain device information and drive.
And a second stage: and the flow of the driving and equipment selecting module.
As in the example of fig. 5, in step 501, the driver and device selection module receives a trigger request.
In this step, the driver and device selection module receives the trigger of the plug-in extension trigger module.
In step 502, the driver and device selection module determines whether the user has imported a specified driver version.
For example, when a user schedules a Docker to create a container, a driver version may be specified in a container creation request, and then the Docker may also carry the specified driver version when sending a plug-in trigger request to a plug-in extension trigger module, and similarly, when the plug-in extension trigger module triggers a driver and device selection module, the driver version specified by the user may be transmitted to the driver and device selection module.
In this step, if the determination result is negative, that is, the user does not input the driver version, step 505 may be directly executed to trigger the driver and device collection module 33 to perform driver collection, and of course, the driver and device collection module 33 may also collect device information. If the result of the determination is yes, that is, the user has imported the specified drive version, step 503 may be performed.
In step 503, the driver and device selection module invokes the driver and device collection module query driver.
In step 504, it is determined whether a drive of the specified version exists.
In this step, it may be queried to the driver and device collection module whether the specified driver version exists, if not, step 506 may be performed, otherwise, step 505 may be performed.
In step 505, the driver and device selection module triggers the driver and device collection module to enter the next stage of process for collecting device information and drivers.
In step 506, the driver and device selection module returns a creation failure, that is, the driver and device selection module returns a failure to the plug-in extension trigger module, and then the plug-in extension trigger module returns a failure to the Docker.
As can be seen from the flow of fig. 5, the driver and device selection module in the container plug-in of this example may be mainly responsible for determining whether to continue triggering collection and acquisition of device information and drivers, and if a driver of a specified version does not exist, it is not necessary to continue collection, and it is sufficient to directly return a failure to the Docker, and if a specified driver exists or a specified driver does not exist, it is possible to trigger collection of device information and drivers.
And a third stage: and collecting the module flow by the driving and equipment.
As the example of FIG. 6, in step 601, the driver and device collection module receives a trigger request.
In this step, the driver and device collection module receives the trigger of the driver and device selection module.
In step 602, the driver and device collection module determines whether there is a specified driver version.
If the result is negative, i.e. without the driver version, and the user does not specify, step 604 may be executed; otherwise, if the determination result is yes, step 603 may be executed.
In step 603, the driver and device collection module determines whether a specified version of the driver exists in the cache. If yes, go to step 604; otherwise, step 605 may be performed.
In step 604, the driver and device collection module obtains the latest device information and driver from the cache. In this step, after the device information and the driver are obtained, the driver and device collection module may return the device information and the driver to the driver and device selection module, the driver and device selection module returns the device information and the driver to the plug-in extension trigger module, and finally the plug-in extension trigger module returns the device information and the driver to the Docker for creating the container carrying the infiniband device.
In step 605, the driver and device collection module determines whether to collect the version driver for the first time.
If not, it indicates that the driver does not exist, and step 608 can be directly executed; if it is the first time to collect, step 606 may be performed.
In step 606, the driver and device collection module invokes the driver device querier to collect device information and drivers. The structure and operation of the drive equipment interrogator are described in the following examples.
In step 607, the driver and device collection module updates the driver and device information in the cache after receiving the device information and driver returned by the driver device querier.
After the cache is updated in this step, the driver and device collection module may return to step 603, determine whether the specified version driver is in the cache again, if the specified version driver does not exist in the cache, according to the above description of the flow, a failure will be returned, and certainly, a failure may be returned to the Docker finally via the driver and device selection module and the plug-in extension trigger module in sequence; if the device information and the drive exist in the second judgment, the device information and the drive are returned to the Docker according to the flow description.
In step 608, the driver and device collection module returns a create failure.
As can be seen from the flow of fig. 6, the driver and device collection module in the container plug-in of this example may be mainly responsible for collecting and acquiring specific device information and drivers, and may be acquired from the cache preferentially, and the driver device querier may be called to acquire when there is no cache.
In one example, the above-mentioned driver device querier, which may be a part of the driver and device collection module, is mainly responsible for acquiring device information and drivers of target devices on the processing device where the container plug-in is located. Fig. 7 illustrates a structure of the drive device interrogator, which may include, as shown in fig. 7: a version maintainer 71, a drive information manager 72, a device information manager 73, and a physical device invoker 74.
For example, device information and drivers for different versions of infiniband devices may be maintained in the version maintainer 71. In addition, the version maintainer 71 may further maintain a driving information mapping key and a device information mapping key corresponding to infiniband devices of different versions, and may query the driving information manager 72 and the device information manager 73 through the mapping keys, where the driving information manager 72 stores a description and an acquisition manner of a driving, and the device information manager 73 stores a description and an acquisition manner of a device information.
When the driver device inquirer receives the call request, it can first inquire whether the driver and device information acquired by the request is stored in the version maintainer 71. If so, the data can be directly returned to the drive and equipment collection module; if not, the driver information manager 72 and the device information manager 73 can be queried through the mapping key of the version to obtain the device information and the acquisition mode of the driver. Then, the specific device information and driver can be obtained by the physical device invoker 74 (e.g., infiniband physical device invoker) according to the obtaining manner. Furthermore, the acquired device information and driver may be stored in the version maintainer 71, and may be directly acquired by the version maintainer 71 next time.
In this example, a timer may automatically run in the driver and device collection module, and the driver device querier is called at regular time to perform timing check and update of the driver, so as to ensure that the physical driver can be synchronized into the container plugin after being updated. Therefore, when a user creates the container, the user does not need to care about the drive version and the equipment, the most appropriate drive file can be flexibly injected into the container, and the corresponding equipment can be automatically mounted into the container. Meanwhile, the version of the target equipment used by the current processing equipment is inquired through the driving equipment inquirer, so that the infiniband equipment with various versions can be compatible and adapted.
In order to implement the container creation method of the present disclosure, the present disclosure also provides a container creation apparatus, which may be applied to creation of a container carrying a target device, and which may be applied to a container plug-in. As shown in fig. 8, the apparatus may include: a trigger receiving unit 81, an information acquiring unit 82, and an information feedback unit 83. It should be noted that the three units may be partitions of the container creation apparatus in terms of logical functions, and the actual apparatus structural design may include the logical functions corresponding to the three units, and is not necessarily designed strictly according to the partitions of the three units. For example, in the container plug-in of fig. 3, the plug-in extension triggering module may be equivalent to the trigger receiving unit 81 described above, and may implement a logic function corresponding to the trigger receiving unit 81; and the logical functions of the information obtaining unit 82 may be implemented by the functions of the driver and device selection module, the driver and device collection module of fig. 3.
A trigger receiving unit 81, configured to receive a plug-in trigger request sent by a container engine for creating a container;
an information obtaining unit 82, configured to obtain device information and a drive of the target device according to the trigger request;
an information feedback unit 83, configured to return the device information and the drive to the container engine, so that the container engine creates a container carrying the target device.
In one example, as shown in fig. 9, the information obtaining unit 82 includes:
a version judgment subunit 821, configured to judge whether the plug-in trigger request includes a specified drive version;
and an information collecting subunit 822, configured to collect the device information and the drive when the determination result is no, or the determination result is yes and it is determined that the drive of the drive version exists.
In one example, the information collecting subunit 822 is specifically configured to: if the judgment result is negative, the latest equipment information and drive are obtained from the cache; if the judgment result is yes, and the drive of the drive version is determined to exist in the cache, acquiring the equipment information and the drive in the cache; and when the judgment result is yes and the driver of the driver version is determined not to exist in the cache and is collected for the first time, calling a driver equipment querier to collect the equipment information and the driver, and putting the collected equipment information and the driver into the cache.
In one example, the information collecting subunit 822, when configured to invoke the driver device querier to collect the device information and the driver, and place the collected device information and the driver into the cache, includes: inquiring whether the version maintainer of the drive equipment inquirer stores the equipment information and the drive; if the device information does not exist, the device information and the drive are obtained from the maintained information manager, and the physical device invoker obtains the device information and the drive according to the obtaining mode; storing the device information and the driver to the version maintainer.
In order to implement the container creation method of the present disclosure, the present disclosure also provides a container creation apparatus, which may be applied to the creation of a container carrying a target device, and which may be applied to a container engine. As shown in fig. 10, the apparatus may include: a request sending module 1001, an information receiving module 1002, and a container creating module 1003.
A request sending module 1001, configured to send a plug-in trigger request to a container plug-in, where the plug-in trigger request is used to trigger the container plug-in to obtain device information and a driver of the target device;
an information receiving module 1002, configured to receive the device information and the driver returned by the container plugin;
a container creating module 1003, configured to create a container carrying the target device using the device information and the driver.
The apparatuses or modules illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.
For convenience of description, the above devices are described as being divided into various modules by functions, and are described separately. Of course, the functionality of the various modules may be implemented in the same one or more software and/or hardware implementations of the present disclosure.
As will be appreciated by one skilled in the art, embodiments of the present disclosure may be provided as a method, system, or computer program product. Accordingly, the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present disclosure may take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and so forth) having computer instructions embodied therein.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks. For example, computer instructions stored on the medium, when executed by a processor, may implement the steps of: receiving a plug-in trigger request sent by a container engine for creating a container; acquiring equipment information and drive of the target equipment according to the trigger request; returning the device information and drive to the container engine to cause the container engine to create a container carrying the target device.
In a typical configuration, the processing device in the present disclosure may further include one or more processors (CPUs), a memory, and computer instructions stored on the memory and executable on the processors, the computer instructions including: plug-in instructions for implementing container plug-ins, and engine instructions for implementing a container engine.
The processor is used for realizing the following steps by executing the plug-in instruction: receiving a plug-in trigger request sent by a container engine for creating a container; acquiring equipment information and drive of the target equipment according to the trigger request; returning the device information and drive to the container engine;
the processor is used for realizing the following steps by executing the engine instruction: sending a plug-in triggering request to a container plug-in, wherein the plug-in triggering request is used for triggering the container plug-in to acquire the equipment information and the drive of the target equipment; receiving equipment information and a drive returned by the container plug-in; and using the device information and the driver to create a container carrying the target device.
The above description is only exemplary of the present disclosure and should not be taken as limiting the disclosure, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present disclosure should be included in the scope of the present disclosure.