CN112052067A - Virtualized container startup and information maintenance method, electronic device and storage medium - Google Patents

Abstract

Embodiments of the present invention provide a virtualized container startup and information maintenance method, an electronic device, and a storage medium, and a startup tool is configured for each container. After the startup tool obtains the identity of the dependent container of any container where it is located, or queries the identity of the dependent container of any container from the dependent container relationship stored in the shared storage space through the pre-start callback interface, if the startup tool passes the startup The pre-callback interface queries the shared storage space to the identity mapping of the dependent container and completes the start-up identity, and then any container is started by executing the callback interface. Through the shared storage space shared by the container set to which any container belongs, the startup tool can implement container-dependent query, container startup status query, and write container startup status through a unified interface, so that there is no need to encapsulate different containers for different containers. , which standardizes the container startup process and simplifies the implementation process of container sequential startup.

Description

Virtualized container startup and information maintenance method, electronic device and storage medium

technical field

The present invention relates to the technical field of virtualized containers, and in particular, to a virtualized container startup and information maintenance method, electronic device and storage medium.

Background technique

There are currently two ways to start a virtualized container. The first way: In Docker Compose, use tools such as scripts to encapsulate the startup command of the container. However, since the script is not universal, the script for encapsulation needs to be rewritten for each container, and the encapsulation process is complicated. The second method is only applicable during the initialization of the container. In the process of container initialization, it is necessary to ensure that the latter container can be initialized and started only after the previous container is initialized and started and then exits. However, in the process of actual business operation, multiple containers are usually required to run at the same time, so the second method is not suitable for controlling the startup process of the container during the business operation process.

It can be seen that in the prior art, the startup of a container needs to rely on a script encapsulated for each container. Since the scripts encapsulated for each container are different, the implementation process is complicated.

SUMMARY OF THE INVENTION

Embodiments of the present invention provide a virtualized container startup and information maintenance method, an electronic device, and a storage medium, so as to solve the problem that in the prior art, the startup of a container needs to rely on a script packaged for each container, because the scripts packaged for each container are different. , the implementation process is complex.

In view of the above technical problems, in a first aspect, an embodiment of the present invention provides a method for starting a virtualized container, including:

The startup tool configured in any container obtains the identifier of the dependent container of any container from the configuration file of any container, or according to the identifier of any container, obtains the identifier from the shared storage space through the pre-start callback interface Query the identifier of the dependent container of the any container in the stored dependency container relationship; wherein, the dependent container is a container whose startup order is before any of the containers, and the startup order is adjacent to the any of the containers; The shared storage space is shared by the container set to which any container belongs; the container set includes at least two containers with a startup sequence; in the container-dependent relationship, the identifier of the container in the container set is recorded, and the corresponding startup sequence;

According to the identifier of the dependent container and the mapping relationship between the identifier of the start-up completed and the identifier of the container that has completed the start-up written into the shared storage space by the container that has completed the startup in the container set, the pre-start callback The interface queries whether the identifier of the dependent container is mapped to the startup identifier, and sends a startup command to any of the containers through the execution callback interface until the identifier of the dependent container is queried and mapped to the startup identifier, otherwise, it does not send a startup command to any of the containers. A container sends the start command.

Optionally, after starting the to-be-started container, the method further includes:

After detecting that the startup of any container is completed, write a file in a preset format to the folder where the any container is located in the shared storage space through a notification callback interface, and use the file in the preset format as the The completion startup identifier of any of the container mappings.

Optionally, the querying, through the pre-start callback interface, whether the identity of the dependent container is mapped to the start-up identity, until the start-up identity of the dependent container is queried after the identity mapping is completed, includes:

It is queried through the pre-start callback interface whether the identification of the dependent container is mapped to the start-up identification every preset time period, until the identification of the dependent container is queried to complete the start-up identification mapping.

Optionally, before the startup tool configured in the any container obtains the identifier of the dependent container of the any container from the configuration file of the any container, it includes:

The configuration file is generated according to the identifier of the dependent container that is configured when any container is created and depends on which any container is started.

In a second aspect, an embodiment of the present invention provides a method for maintaining virtualized container information, which is applied to a shared storage space, including:

Obtain the startup sequence corresponding to any container configured by the interactive interface for any container in the container set, when each container in the container set is started, the identifier of the any container, and the start sequence of the any container. The corresponding startup sequence is stored in the dependency container relationship in the shared storage space;

Wherein, the startup sequence corresponding to any one of the containers is determined according to the container on which each container is configured to start each container when each container in the container set is created; wherein, the shared storage space is determined by the It is shared by the container set to which any container belongs; the container set includes at least two containers in a startup order.

Optionally, also include:

Receive a first query request sent by the startup tool configured in any container through the pre-start callback interface; the first query request is used to request to query the identity of the dependent container of any container according to the identity of the container;

The startup sequence of the dependent container relationship query stored in the shared storage space is adjacent to the startup sequence of any container, and the identifier of the container started before the any container is used as the identifier of the queried container. The identity of the dependent container of any of the above containers;

Return the identifier of the dependent container of any container to the startup tool through the pre-start callback interface.

Optionally, also include:

Receive a second query request sent by the startup tool configured in any container through the pre-start callback interface, where the second query request is used to request to query whether the identifier of the dependent container of any container is mapped to the startup identifier;

According to the mapping relationship between the start completion identifier written into the shared storage space by the container that has completed startup in the container set and the identifier of the container that has completed startup, query whether the identifier of the dependent container of any container has been mapped. Startup identifier, if yes, send a query response to the startup tool through the pre-start callback interface, otherwise, do not send the query response to the startup tool; the query response is used to indicate that the dependency container is queried. Identity mapping completes the startup identity.

Optionally, also include:

Receive a write instruction sent by the startup tool configured in any container through the notification callback interface; the write instruction is used to indicate that the writing of the startup identifier to any of the containers is completed;

A file in a preset format is written in the folder where the any container is located in the shared storage space, and the file in the preset format is used as the completion startup identifier of the mapping of the any container.

In a third aspect, an embodiment of the present invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and running on the processor, where the processor implements the above-mentioned virtual reality when executing the program. The steps of the method for starting the virtualized container or the method for maintaining the information of the virtualized container.

In a fourth aspect, an embodiment of the present invention provides a non-transitory readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, implements any of the above-described methods for starting a virtualized container or virtualization Steps of container information maintenance method.

Embodiments of the present invention provide a virtualized container startup and information maintenance method, an electronic device, and a storage medium, and a startup tool is configured for each container. After the startup tool obtains the identity of the dependent container of any container where it is located, or after querying the identity of the dependent container of any container from the dependent container relationship stored in the shared storage space through the pre-start callback interface, if the startup tool passes the startup After the pre-callback interface queries the shared storage space to the identity mapping of the dependent container and completes the start-up identity, any container is started by executing the callback interface. Through the shared storage space shared by the container set to which any container belongs, the startup tool can implement the container-dependent query, the container-dependent startup status query, and write the container startup status through a unified interface, so that there is no need to encapsulate different containers for different containers. , which standardizes the container startup process and simplifies the implementation process of container sequential startup.

Description of drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the accompanying drawings that need to be used in the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description These are some embodiments of the present invention. For those of ordinary skill in the art, other drawings can also be obtained according to these drawings without creative efforts.

1 is a schematic flowchart of a method for starting a virtualized container provided by an embodiment of the present invention;

2 is a schematic diagram of the principle of a startup tool controlling the startup of a container provided by another embodiment of the present invention;

3 is a schematic flowchart of a method for maintaining virtualized container information provided by another embodiment of the present invention;

FIG. 4 is a schematic flowchart of an implementation of orderly startup of containers provided by another embodiment of the present invention;

5 is a structural block diagram of an apparatus for starting a virtualized container provided by another embodiment of the present invention;

6 is a structural block diagram of an apparatus for maintaining virtualized container information provided by another embodiment of the present invention;

FIG. 7 is a schematic diagram of a physical structure of an electronic device provided by another embodiment of the present invention.

Detailed ways

In order to make the purposes, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments These are some embodiments of the present invention, but not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

In some scenarios, it is necessary to control the startup order of virtualized containers. To this end, the present application provides a method for starting a virtualized container, where the method for starting a virtualized container is executed by any starting tool that manages the starting of a virtualized container. A startup tool is configured in each container to control the startup of the container.

The virtualized container startup method provided by this application can be applied to at least one of the following application scenarios:

Scenario 1: The startup of a container needs to rely on the services provided by the previous container. If you need to rely on the services provided by the previous container: Web Server and/or database, where the Web Server must wait for the database to be started and available before it can be started.

Scenario 2: The container needs to complete the initial configuration for the next container or service. If you need to collect the necessary cluster information, node information, network service information, etc. for the next container and preset it into the configuration file, or download the required configuration file or data file from the remote Git repository or file system.

Scenario 3: The container needs to send the self-registration information of the Pod or service to the remote service, and after the registration is completed, other containers in the Pod or service can be started.

FIG. 1 is a schematic flowchart of a method for starting a virtualized container provided by this embodiment. Referring to FIG. 1 , the method for starting a virtualized container includes the following steps:

Step 101: The startup tool configured in any container obtains the identifier of the dependent container of any container from the configuration file of any container, or according to the identifier of any container, obtains the identifier from the shared container through the pre-start callback interface. Query the identifier of the dependent container of the any container in the dependency container relationship stored in the storage space; wherein, the dependent container is the one whose startup order is before any one of the containers, and the startup order is adjacent to the any one of the containers. container; the shared storage space is shared by the container set to which any container belongs; the container set includes at least two containers with a startup sequence; in the container-dependent relationship, the container in the container set is recorded , and the corresponding startup sequence;

Step 102: According to the identifier of the dependent container, and the mapping relationship between the identifier of the start-up completed written in the shared storage space by the container that has completed the startup in the container set and the identifier of the container that has completed the start-up, through the The callback interface before startup inquires whether the identifier of the dependent container is mapped to the startup identifier, and sends a startup command to any of the containers through the execution callback interface until the identifier of the dependent container is queried and the startup identifier is mapped and completed. The any container sends the start command.

FIG. 2 is a schematic diagram of the principle of the startup tool controlling the startup of a container provided in this embodiment. Referring to FIG. 2 , each container in the container set is configured with a startup tool, and the startup tool cyclically executes the above steps 101 and 102 to start the container it is in. A dependent container of any container refers to a container that must have finished starting when any container starts.

For the startup tool configured in any container, first determine the identifier of the dependent container of the any container through step 101 . There are two ways to get it:

Approach 1: Obtain from the configuration file of any container. Wherein, the configuration file includes the identifiers of containers (ie, dependent containers of any container) whose startup sequence is configured before any container and whose startup sequence is adjacent to any container when any container is created. The startup tool configured in any container obtains the identifier of the dependent container of any container from the configuration file of any container through the get command.

Approach 2: The startup tool, according to the identifier of any container it is in (the identifier of any container can be written to the startup tool when the startup tool is configured into any container), from the shared storage through the pre-start callback interface provided externally. In the dependent container relationship stored in the space, query to obtain the identifier of the dependent container of any container.

For the above approach 2, specifically, the startup tool sends the identifier of any container and the first query instruction to the shared storage space through the pre-start callback interface, so that the shared storage space can be stored according to the identifier of any container from the dependent container relationship stored The identifier of the dependent container of any container is obtained by querying in the middle, and the identifier of the dependent container of any container is returned to the startup tool through the pre-start callback interface. Wherein, the first query request is used for requesting to query the identity of the dependent container of any container according to the identity of any container.

After determining the identifier of the dependent container of any container, query whether the dependent container of any container has been started through step 102, and if so, send a start command to any container through the execution callback interface to realize the start of any container, otherwise, Do not send a start command to any container, leaving any container in a state of waiting to start.

It should be noted that, for any container in the container set that has completed the startup, the mapping relationship between the identifier of the container that has completed startup and the startup identifier is stored in the shared storage space. Therefore, each startup tool can query from the shared storage space whether the dependent container of any container has completed startup through the mapping relationship.

Specifically, in the above step 102, the startup tool sends the identifier of the dependent container of any container and the second query request to the shared storage space through the pre-start callback interface, so that the shared storage space is based on the dependent container of any container. The flag queries whether the dependent container of any container has been mapped to complete the startup flag. If so, it means that the dependent container of any container has been started. Otherwise, the dependent container of any container has not been started. Wherein, the second query request is used to request to query whether the identifier of the dependent container of any container is mapped to the completion startup identifier.

In this embodiment, a startup tool is configured for each container, the startup tool queries the dependent container of the container through the shared storage space through the pre-start callback interface, and the startup status of the dependent container, and sends the startup command to the container through the execution callback interface, Finish starting the container. The startup tool can query the relevant information of the dependent container from the shared storage space through the unified pre-start callback interface and write the notification callback interface of the startup completion mark after the container completes startup, and interact with the container through the execution callback interface to complete the startup. control. It can be seen that through the interaction between the startup tool and the shared storage volume, as well as the interaction between the startup tool and the container where it is located, the startup of the container is realized in a unified process. This embodiment standardizes the process of container startup. Compared with the prior art, there is no need to encapsulate different scripts for different containers, and only the startup tool installed in the container can implement the interaction between the startup tool and the shared storage space. The container starts. The standardization of the container startup process is conducive to simplifying the implementation process of container sequential startup.

This embodiment provides a method for starting a virtualized container, and a starting tool is configured for each container. After the startup tool obtains the identity of the dependent container of any container where it is located, or after querying the identity of the dependent container of any container from the dependent container relationship stored in the shared storage space through the pre-start callback interface, if the startup tool passes the startup After the pre-callback interface queries the shared storage space to the identity mapping of the dependent container and completes the start-up identity, any container is started by executing the callback interface. Through the shared storage space shared by the container set to which any container belongs, the startup tool can implement the container-dependent query, the container-dependent startup status query, and write the container startup status through a unified interface, so that there is no need to encapsulate different containers for different containers. , which standardizes the container startup process and simplifies the implementation process of container sequential startup.

Further, on the basis of the foregoing embodiment, it also includes:

After detecting that the startup of any container is completed, write a file in a preset format to the folder where the any container is located in the shared storage space through a notification callback interface, and use the file in the preset format as the The completion startup identifier of any of the container mappings.

Wherein, the startup tool configured in any container can judge whether the startup of any container is completed according to the parameter changes before and after the startup of the container is completed.

After detecting that the startup of any container is completed, the startup tool invokes the notification callback interface to write the completion startup identifier mapped with the identifier of the any container in the shared storage volume. It should be noted that, in this embodiment, the startup completion identifier refers to a file in a preset format. For example, the default format file is finish.ok. For example, after the container named "container name 1" is started, the startup tool configured in the container sends the file of finish.ok to the shared storage space through the notification callback interface. The file where the container is located stores the finish.ok file to store the finished The following file exists in the file directory where the .ok file is located: "/service name1/container name1/finish.ok".

Specifically, after detecting that any container has been started, the startup tool sends a write instruction to the shared storage space through the notification callback interface, so as to store the preset in the folder of any container in the shared storage space according to the write instruction format file, and the preset format file is used as the startup completion identifier of any container. Wherein, the write instruction includes the identifier of any container.

In this embodiment, after the container startup is completed, the container startup tool stores a file in a preset format in a folder of the container in the shared storage space through a notification callback interface, and uses the file in the preset format as a startup completion identifier. Provided is a simple method for writing a startup completion identifier, which realizes the identification of a container after startup is completed, and provides a basis for judging whether the startup of the container is completed.

Further, on the basis of the above-mentioned embodiments, the querying through the pre-start callback interface whether the identification of the dependent container is mapped to the start-up identification, until after the identification of the dependent container is queried and the identification of the dependent container is mapped and completes the startup identification, including: :

It is queried through the pre-start callback interface whether the identification of the dependent container is mapped to the start-up identification every preset time period, until the identification of the dependent container is queried to complete the start-up identification mapping.

In the process of querying whether the identifier of the dependent container of any container has been mapped to the startup identifier, the startup tool will continue to repeat the query process every preset time period until the query is completed if the identifier of the dependent container is not queried for the first time. The identity mapping to the dependent container completes the startup identity. The preset duration may be preset, for example, 5 seconds.

This embodiment can ensure the timeliness of the query result by repeatedly querying whether the identifier of the dependent container is mapped to complete the startup identifier, and start any container in time after the startup completion identifier of the dependent container is queried in time, which improves the ability to start the containers in sequence. control efficiency.

Further, on the basis of the above embodiments, before the startup tool configured in the any container obtains the identifier of the dependent container of the any container from the configuration file of the any container, the method includes:

The configuration file is generated according to the identifier of the dependent container that is configured when any container is created and depends on which any container is started.

The process of creating any container configures the dependent container on which the startup of any container depends, and the configuration file writes the identifier of the dependent container on which the startup of any container depends, which is configured when any container is created. The startup tool of any container can determine the identity of the dependent container of any container by accessing the configuration file.

In this embodiment, the startup tool determines the identifier of the dependent container of any container through the configuration file in any container, so as to query the startup status of the dependent container according to the identifier of the dependent container of any container, so as to realize the startup of the containers according to the startup sequence control process.

Based on the above-mentioned control of the startup tool on the container startup process, referring to FIG. 2 , in the virtualized container startup method provided in this embodiment, (1) the service containers that have startup dependencies between each other are formed into a set (for example, Container1, Container2 ...Containern), in which each container is mounted and shared with the same shared storage volume (container.meta, that is, shared storage space). (2) Provide a unified container command startup tool, which provides three callback interfaces:

The callback interface before startup is the callback interface that depends on the startup. This interface returns the list of other service containers that the current container depends on to start, which is used to predict and wait for the startup of the dependent container to complete.

The execution callback interface is a callback interface for the execution of the start command, and the interface returns the start command of the current container, which is used to start the container.

The notification callback interface is the notification callback interface for the startup completion of the current container to be started. It is used to register with the specified directory and file when the container startup is completed.

For the shared storage space, (3) a set of operation and maintenance WEB interface is also provided in Figure 2. The background displays the startup dependencies between containers by reading the directories and files of the shared storage volume. Specifically, FIG. 3 is a schematic flowchart of a method for maintaining information on a virtualized container provided in this embodiment. The method for maintaining information on a virtualized container is applied to a shared storage space. Referring to FIG. 3 , the method for maintaining information on a virtualized container includes:

Step 301: Acquire the startup sequence corresponding to any container in the container set configured through the interactive interface, when each container in the container set is started, the identifier of the any container, and the The startup sequence corresponding to any container is stored in the dependent container relationship in the shared storage space;

Wherein, the startup sequence corresponding to any one of the containers is determined according to the container on which each container is configured to start each container when each container in the container set is created; wherein, the shared storage space is determined by the It is shared by the container set to which any container belongs; the container set includes at least two containers in a startup order.

The interactive interface refers to a human-computer interactive interface (for example, a WEB interface). The user can write the startup sequence of the container through the interactive interface, and the shared storage space stores the startup sequence in the dependent container relationship. It is understandable that the user writes the startup sequence of the container according to the container configuration dependency when the container is created. If the startup order written by the user is different from the startup order determined according to the dependent containers configured for each container, an error will occur during the startup process, resulting in the termination of the sequential startup.

In this embodiment, the dependent container relationship in the shared storage space is stored and edited through the interactive interface, which provides a way for the user to manage the shared storage space in a unified manner, and realizes the management of the dependent container relationship in the shared storage space.

The embodiment provides a method for maintaining virtualized container information, in which a startup tool is configured for each container. After the startup tool obtains the identity of the dependent container of any container where it is located, or after querying the identity of the dependent container of any container from the dependent container relationship stored in the shared storage space through the pre-start callback interface, if the startup tool passes the startup After the pre-callback interface queries the shared storage space to the identity mapping of the dependent container and completes the start-up identity, any container is started by executing the callback interface. Through the shared storage space shared by the container set to which any container belongs, the startup tool can implement the container-dependent query, the container-dependent startup status query, and write the container startup status through a unified interface, so that there is no need to encapsulate different containers for different containers. , which standardizes the container startup process and simplifies the implementation process of container sequential startup.

Further, on the basis of the foregoing embodiment, it also includes:

Receive a first query request sent by the startup tool configured in any container through the pre-start callback interface; the first query request is used to request to query the identity of the dependent container of any container according to the identity of the container;

The startup sequence of the dependent container relationship query stored in the shared storage space is adjacent to the startup sequence of any container, and the identifier of the container started before the any container is used as the identifier of the queried container. The identity of the dependent container of any of the above containers;

Return the identifier of the dependent container of any container to the startup tool through the pre-start callback interface.

In the process of realizing the sequential startup of containers, the startup tool interacts with the shared storage space through the pre-start callback interface, and realizes the identification of the dependent container and the query of the startup status of the dependent container. After the shared storage space receives the first query request, it queries the identifier of the dependent container of any container from the dependent container relationship according to the identifier of any container, and returns the queried identifier of the dependent container to the startup through the pre-start callback interface. The tool enables the startup tool to query the startup status of the dependent container according to the identifier of the dependent container, so that any container can be started after the dependent container is started, which realizes the control that the containers are started according to the startup sequence.

Further, on the basis of the above embodiments, it also includes:

Receive a second query request sent by the startup tool configured in any container through the pre-start callback interface, where the second query request is used to request to query whether the identifier of the dependent container of any container is mapped to the startup identifier;

According to the mapping relationship between the start completion identifier written into the shared storage space by the container that has completed startup in the container set and the identifier of the container that has completed startup, query whether the identifier of the dependent container of any container has been mapped. Startup identifier, if yes, send a query response to the startup tool through the pre-start callback interface, otherwise, do not send the query response to the startup tool; the query response is used to indicate that the dependency container is queried. Identity mapping completes the startup identity.

After determining the identifier of the dependent container of any container, the startup tool of any container sends a second query request to the shared storage space according to the identifier of the dependent container. After receiving the second query request, the shared storage space queries, according to the identifier of the dependent container, whether the dependent container has completed startup by storing the completed startup identifier of each container that has completed startup in advance. After the shared storage space determines that the identifier of the dependent container of any container is mapped with the completion startup identifier, a query response is returned to the startup tool, so that the startup tool of any container receives the query response. Launch control.

It should be noted that when there are multiple dependent containers in any container, any container will be started only after receiving a query response corresponding to each dependent container.

In this embodiment, by querying the startup status of the dependent container through the pre-start callback interface, after the startup tool of any container receives the query response corresponding to each dependent container of any container, it controls the startup of any container, thereby realizing Sequential startup of containers.

Further, on the basis of the above embodiments, it also includes:

Receive a write instruction sent by the startup tool configured in any container through the notification callback interface; the write instruction is used to indicate that the writing of the startup identifier to any of the containers is completed;

A file in a preset format is written in the folder where the any container is located in the shared storage space, and the file in the preset format is used as the completion startup identifier of the mapping of the any container.

The startup tool also provides a notification callback interface. When the startup tool detects that the startup of any container is completed, it writes the startup completion flag to any container through the notification callback interface, so that after any container finishes startup, the shared storage volume can be The startup status of any container can be queried, so that when any container is used as a dependent container of other containers, the correct startup status updated in time can be queried to ensure the sequential startup of subsequent containers.

In this embodiment, the notification callback interface is used to realize the timely update of the startup status of any container after the startup of any container is completed, so that the shared storage space can provide the timely updated container status, and avoid the startup process due to the untimely update of the startup status. The delay ensures the startup efficiency of container startup in sequence.

In general, for virtualized container startup and information maintenance methods, the following information is included:

When the container is started and called back, the startup tool needs to write an empty file finish.ok to the specified directory of the shared storage volume, and the corresponding directory path is as follows: /service name/container name/finish.ok; and in the shared storage volume Update its own container information (container status information) in the container.meta file in the root directory of the . Here, the storage of the flag file and the container information is used to determine whether the container has been started and completed, and it is used for the visual display and configuration of the interface on the other hand.

When a callback is made before the container is started, the startup tool needs to read whether there is a finish.ok file in the specified container directory under the specified service according to the list of dependent service containers returned by the interface. If yes, return true and execute the startup command; if not, Return false to continue waiting.

FIG. 4 is a schematic diagram of the implementation flow of the container orderly startup provided by this embodiment. Referring to FIG. 4 , the flow includes the following processes:

1. The user presets a container collection through the visual interface, and configures the startup dependency list of each container. In the specific implementation method, the startup order of each container in the collection can be configured, and multiple containers can be configured in the same order.

2. The visual interface interacts with the shared storage area. By parsing the user's preset information, the startup dependency list of each container in the collection is obtained, and then the information is stored in the container.meta file in the shared storage area.

3. Before the container is started, the startup tool obtains the current container identifier, such as the name, by reading the environment variable or the specified configuration file in the container.

4. Start the tool in the container.meta file of the shared storage area to query the list of dependent containers of the current container. If the current container does not depend on other containers, go directly to step 6, otherwise continue to the following steps.

5. According to the list of dependent containers, the startup tool goes to the shared storage area to find out whether the completion flag file finish.ok of each container already exists. If one does not exist, wait for 5S before continuing the query.

6. If the completion flag files of the dependent container all exist, call the start command of the container to start the container.

7. After the container startup is complete, notify the startup tool. Notification methods include

a. The container provides a probe service, and the startup tool detects whether the service has been started;

b. After the container is started, the notification interface of the startup tool is called back.

8. After the startup tool receives the container startup completion instruction, it writes the container startup completion flag file to the shared storage area, such as "/service name1/container name1/finisho.ok", and in the container.meta file Update the container's own information, such as the state of the container and its dependent containers, and the path of the flag file.

To sum up, the method provided by this embodiment, on the one hand, standardizes the start process of the container by encapsulating the start command of the container through a unified start tool, and on the other hand, realizes the judgment of the container start dependency through the communication method of shared storage Wait and notify records.

It is understandable that the methods provided by the above embodiments are applicable to Docker Compose and K8S, and are not even limited to Docker, as long as the container provides the implementation of the startup command callback interface and the shared storage mount.

Compared with the existing Docker Compose way of realizing the sequential startup of containers, on the one hand, the method provided by this embodiment standardizes the startup process of the container through a unified startup tool (specifically, the startup process in the embodiments of the present application is The tool exposes three interface callbacks, which can unify and standardize callback processing for container pre-start dependency judgment and waiting, startup command execution, startup completion notification and recording). On the other hand, in the method provided by this embodiment, containers that depend on each other share the same storage volume, and by storing the volume directory file and displaying it in combination with the WEB, the startup dependency is managed, which is more concise, intuitive, and easy to maintain.

Compared with the existing Init container solution of Kubernetes, first of all, the method provided in this embodiment does not require that the container needs to exit the service after the start of the container is completed. That is, after the container completes the startup completion notification, it can enter continuous online operation and provide services. Secondly, the implementation of the method provided in this embodiment can be directly used in the Pod to realize the startup sequence of multiple containers in the pod, and can also realize the control of the startup sequence of different services and containers in different pods, and the control granularity is finer. Finally, the method provided in this embodiment does not need to rely on the concept of an initial container (init-container) adopted in Kubernetes, has small limitations, and can be used across platforms.

FIG. 5 is a structural block diagram of a virtualized container startup device provided in this embodiment. The virtualized container startup device is applied to a startup tool. Referring to FIG. 5 , the virtualized container startup device includes an acquisition module 501 and a startup module 502 , wherein ,

The obtaining module 501 is configured to obtain the identifier of the dependent container of the any container from the configuration file of the any container, or according to the identifier of the any container, store the identifier from the shared storage space through the pre-start callback interface. Query the identifier of the dependent container of the any container in the dependent container relationship; wherein, the dependent container is a container whose startup order is before any of the containers, and the startup order is adjacent to the any of the containers; the shared container The storage space is shared by the container set to which any of the containers belongs; the container set includes at least two containers with a startup sequence; the container-dependent relationship records the identifiers of the containers in the container set, and the corresponding the startup sequence;

The startup module 502 is configured to, according to the identifier of the dependent container, and the mapping relationship between the identifier of the completed startup written in the shared storage space by the container that has completed the startup in the container set and the identifier of the container that has completed the startup, Use the pre-start callback interface to query whether the identifier of the dependent container is mapped to the startup identifier, and send a startup command to any of the containers through the execution callback interface until the identifier of the dependent container is queried to complete the startup identifier. , do not send the start command to any of the containers.

The virtualized container startup device provided in this embodiment is applicable to the virtualized container startup methods provided by the above embodiments, and details are not described herein again.

The embodiment of the present invention provides a virtualized container startup and information maintenance device, and a startup tool is configured for each container. After the startup tool obtains the identity of the dependent container of any container where it is located, or queries the identity of the dependent container of any container from the dependent container relationship stored in the shared storage space through the pre-start callback interface, if the startup tool passes the startup The pre-callback interface queries the shared storage space to the identity mapping of the dependent container and completes the start-up identity, and then any container is started by executing the callback interface. Through the shared storage space shared by the container set to which any container belongs, the startup tool can implement container-dependent query, container startup status query, and write container startup status through a unified interface, so that there is no need to encapsulate different containers for different containers. , which standardizes the container startup process and simplifies the implementation process of container sequential startup.

Optionally, also include:

After detecting that the startup of any container is completed, write a file in a preset format to the folder where the any container is located in the shared storage space through a notification callback interface, and use the file in the preset format as the The completion startup identifier of any of the container mappings.

Optionally, the querying, through the pre-start callback interface, whether the identity of the dependent container is mapped to the start-up identity, until the start-up identity of the dependent container is queried after the identity mapping is completed, includes:

It is queried through the pre-start callback interface whether the identification of the dependent container is mapped to the start-up identification every preset time period, until the identification of the dependent container is queried to complete the start-up identification mapping.

Optionally, before the startup tool configured in the any container obtains the identifier of the dependent container of the any container from the configuration file of the any container, it includes:

The configuration file is generated according to the identifier of the dependent container that is configured when any container is created and depends on which any container is started.

FIG. 6 is a structural block diagram of an apparatus for maintaining virtualized container information provided in this embodiment. The apparatus for maintaining virtualized container information is applied to a shared storage space. Referring to FIG. 6 , the apparatus for maintaining virtualized container information includes a storage module 601, where ,

The storage module 601 is configured to obtain the start sequence corresponding to any container in the container set configured through the interactive interface, when each container in the container set is started, and convert the identifier of the any container to And the startup sequence corresponding to any of the containers is stored in the dependency container relationship in the shared storage space;

Wherein, the startup sequence corresponding to any one of the containers is determined according to the container on which each container is configured to start each container when each container in the container set is created; wherein, the shared storage space is determined by the It is shared by the container set to which any container belongs; the container set includes at least two containers in a startup order.

The method for maintaining virtualized container information provided in this embodiment is applicable to the methods for maintaining virtualized container information provided by the foregoing embodiments, and details are not described herein again.

The embodiment of the present invention provides a virtualized container startup and information maintenance device, and a startup tool is configured for each container. After the startup tool obtains the identity of the dependent container of any container where it is located, or after querying the identity of the dependent container of any container from the dependent container relationship stored in the shared storage space through the pre-start callback interface, if the startup tool passes the startup After the pre-callback interface queries the shared storage space to the identity mapping of the dependent container and completes the start-up identity, any container is started by executing the callback interface. Through the shared storage space shared by the container set to which any container belongs, the startup tool can implement the container-dependent query, the container-dependent startup status query, and write the container startup status through a unified interface, so that there is no need to encapsulate different containers for different containers. , which standardizes the container startup process and simplifies the implementation process of container sequential startup.

Optionally, also include:

Receive a first query request sent by the startup tool configured in any container through the pre-start callback interface; the first query request is used to request to query the identity of the dependent container of any container according to the identity of the container;

The startup sequence of the dependent container relationship query stored in the shared storage space is adjacent to the startup sequence of any container, and the identifier of the container started before the any container is used as the identifier of the queried container. The identity of the dependent container of any of the above containers;

Return the identifier of the dependent container of any container to the startup tool through the pre-start callback interface.

Optionally, also include:

Receive a second query request sent by the startup tool configured in any container through the pre-start callback interface, where the second query request is used to request to query whether the identifier of the dependent container of any container is mapped to the startup identifier;

According to the mapping relationship between the start completion identifier written into the shared storage space by the container that has completed startup in the container set and the identifier of the container that has completed startup, query whether the identifier of the dependent container of any container has been mapped. Startup identifier, if yes, send a query response to the startup tool through the pre-start callback interface, otherwise, do not send the query response to the startup tool; the query response is used to indicate that the dependency container is queried. Identity mapping completes the startup identity.

Optionally, also include:

Receive a write instruction sent by the startup tool configured in any container through the notification callback interface; the write instruction is used to indicate that the writing of the startup identifier to any of the containers is completed;

A file in a preset format is written in the folder where the any container is located in the shared storage space, and the file in the preset format is used as the completion startup identifier of the mapping of the any container.

FIG. 7 illustrates a schematic diagram of the physical structure of an electronic device. As shown in FIG. 7 , the electronic device may include: a processor (processor) 701, a communication interface (Communications Interface) 702, a memory (memory) 703, and a communication bus 704, The processor 701 , the communication interface 702 , and the memory 703 communicate with each other through the communication bus 704 . The processor 701 may invoke logic instructions in the memory 703 to perform the following methods:

The startup tool configured in any container obtains the identifier of the dependent container of any container from the configuration file of any container, or according to the identifier of any container, obtains the identifier from the shared storage space through the pre-start callback interface Query the identifier of the dependent container of the any container in the stored dependency container relationship; wherein, the dependent container is a container whose startup order is before any of the containers, and the startup order is adjacent to the any of the containers; The shared storage space is shared by the container set to which any container belongs; the container set includes at least two containers with a startup sequence; in the container-dependent relationship, the identifier of the container in the container set is recorded, and the corresponding startup sequence; according to the identifier of the dependent container, and the mapping relationship between the identifier of the completed startup written in the shared storage space by the container that has completed the startup in the container set and the identifier of the container that has completed the startup, Use the pre-start callback interface to query whether the identifier of the dependent container is mapped to the startup identifier, and send a startup command to any of the containers through the execution callback interface until the identifier of the dependent container is queried to complete the startup identifier. , do not send the start command to any of the containers;

Or, obtain the startup sequence corresponding to any container when starting each container in the container set configured through the interactive interface for any container in the container set, the identifier of any container, and the start sequence of each container in the container set. The startup sequence corresponding to a container is stored in the dependent container relationship in the shared storage space; wherein, the startup sequence corresponding to any container is based on the startup sequence configured for each container when each container in the container set is created. The container on which a container depends is determined; wherein, the shared storage space is shared by the container set to which the any container belongs; the container set includes at least two containers in a startup sequence.

In addition, the above-mentioned logic instructions in the memory 703 can be implemented in the form of software functional units and can be stored in a computer-readable storage medium when sold or used as an independent product. Based on this understanding, the technical solution of the present invention can be embodied in the form of a software product in essence, or the part that contributes to the prior art or the part of the technical solution. The computer software product is stored in a storage medium, including Several instructions are used to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, Read-Only Memory (ROM, Read-Only Memory), Random Access Memory (RAM, Random Access Memory), magnetic disk or optical disk and other media that can store program codes .

Further, an embodiment of the present invention discloses a computer program, the computer program includes a computer program stored on a non-transitory readable storage medium, the computer program includes program instructions, and when the program instructions are executed by a computer, The computer can execute the methods provided by the above method embodiments, for example, including:

The startup tool configured in any container obtains the identifier of the dependent container of any container from the configuration file of any container, or according to the identifier of any container, obtains the identifier from the shared storage space through the pre-start callback interface Query the identifier of the dependent container of the any container in the stored dependency container relationship; wherein, the dependent container is a container whose startup order is before any of the containers, and the startup order is adjacent to the any of the containers; The shared storage space is shared by the container set to which any container belongs; the container set includes at least two containers with a startup sequence; in the container-dependent relationship, the identifier of the container in the container set is recorded, and the corresponding startup sequence; according to the identifier of the dependent container, and the mapping relationship between the identifier of the completed startup written in the shared storage space by the container that has completed the startup in the container set and the identifier of the container that has completed the startup, Use the pre-start callback interface to query whether the identifier of the dependent container is mapped to the startup identifier, and send a startup command to any of the containers through the execution callback interface until the identifier of the dependent container is queried to complete the startup identifier. , do not send the start command to any of the containers;

Or, obtain the startup sequence corresponding to any container when starting each container in the container set configured through the interactive interface for any container in the container set, the identifier of any container, and the start sequence of each container in the container set. The startup sequence corresponding to a container is stored in the dependent container relationship in the shared storage space; wherein, the startup sequence corresponding to any container is based on the startup sequence configured for each container when each container in the container set is created. The container on which a container depends is determined; wherein, the shared storage space is shared by the container set to which the any container belongs; the container set includes at least two containers in a startup sequence.

On the other hand, an embodiment of the present invention also provides a non-transitory readable storage medium on which a computer program is stored, and the computer program is implemented when executed by a processor to execute the transmission methods provided by the foregoing embodiments, for example, including:

The startup tool configured in any container obtains the identifier of the dependent container of any container from the configuration file of any container, or according to the identifier of any container, obtains the identifier from the shared storage space through the pre-start callback interface Query the identifier of the dependent container of the any container in the stored dependency container relationship; wherein, the dependent container is a container whose startup order is before any of the containers, and the startup order is adjacent to the any of the containers; The shared storage space is shared by the container set to which any container belongs; the container set includes at least two containers with a startup sequence; in the container-dependent relationship, the identifier of the container in the container set is recorded, and the corresponding startup sequence; according to the identifier of the dependent container, and the mapping relationship between the identifier of the completed startup written in the shared storage space by the container that has completed the startup in the container set and the identifier of the container that has completed the startup, Use the pre-start callback interface to query whether the identifier of the dependent container is mapped to the startup identifier, and send a startup command to any of the containers through the execution callback interface until the identifier of the dependent container is queried to complete the startup identifier. , do not send the start command to any of the containers;

Or, obtain the startup sequence corresponding to any container when starting each container in the container set configured through the interactive interface for any container in the container set, the identifier of any container, and the start sequence of each container in the container set. The startup sequence corresponding to a container is stored in the dependent container relationship in the shared storage space; wherein, the startup sequence corresponding to any container is based on the startup sequence configured for each container when each container in the container set is created. The container on which a container depends is determined; wherein, the shared storage space is shared by the container set to which the any container belongs; the container set includes at least two containers in a startup sequence.

The device embodiments described above are only illustrative, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in One place, or it can be distributed over multiple network elements. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution in this embodiment. Those of ordinary skill in the art can understand and implement it without creative effort.

From the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a necessary general hardware platform, and certainly can also be implemented by hardware. Based on this understanding, the above-mentioned technical solutions can be embodied in the form of software products in essence or the parts that make contributions to the prior art. The computer software products can be stored in readable storage media, such as ROM/RAM, magnetic disks, etc. , optical disc, etc., including several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to perform the methods described in various embodiments or some parts of the embodiments.

Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, but not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that it can still be The technical solutions described in the foregoing embodiments are modified, or some technical features thereof are equivalently replaced; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims (10)

1. A virtualized container startup method, characterized in that, applied to a startup tool, comprising: The startup tool configured in any container obtains the identifier of the dependent container of any container from the configuration file of any container, or according to the identifier of any container, obtains the identifier from the shared storage space through the pre-start callback interface Query the identifier of the dependent container of the any container in the stored dependency container relationship; wherein, the dependent container is a container whose startup order is before any of the containers, and the startup order is adjacent to the any of the containers; The shared storage space is shared by the container set to which any container belongs; the container set includes at least two containers with a startup sequence; in the container-dependent relationship, the identifier of the container in the container set is recorded, and the corresponding startup sequence; According to the identifier of the dependent container and the mapping relationship between the identifier of the start-up completed and the identifier of the container that has completed the start-up written into the shared storage space by the container that has completed the startup in the container set, the pre-start callback The interface queries whether the identifier of the dependent container is mapped to the startup identifier, and sends a startup command to any of the containers through the execution callback interface until the identifier of the dependent container is queried and mapped to the startup identifier, otherwise, it does not send a startup command to any of the containers. A container sends the start command. 2. The method for starting a virtualized container according to claim 1, further comprising: After detecting that the startup of any container is completed, write a file in a preset format to the folder where the any container is located in the shared storage space through a notification callback interface, and use the file in the preset format as the The completion startup identifier of any of the container mappings. 3 . The method for starting a virtualized container according to claim 1 , wherein the method for querying through the pre-start callback interface whether the identifier of the dependent container is mapped to a completed startup identifier, until the identifier of the dependent container is queried. 4 . After mapping the startup ID, it includes: It is queried through the pre-start callback interface whether the identification of the dependent container is mapped to the start-up identification every preset time period, until the identification of the dependent container is queried to complete the start-up identification mapping. 4 . The method for starting a virtualized container according to claim 1 , wherein the starting tool configured in the any container obtains the information of the dependent container of the any container from the configuration file of the any container. 5 . Before identification, include: The configuration file is generated according to the identifier of the dependent container that is configured when any container is created and depends on which any container is started. 5. A method for maintaining virtualized container information, characterized in that, applied to a shared storage space, comprising: Obtain the startup sequence corresponding to any container configured by the interactive interface for any container in the container set, when each container in the container set is started, the identifier of the any container, and the start sequence of the any container. The corresponding startup sequence is stored in the dependency container relationship in the shared storage space; Wherein, the startup sequence corresponding to any one of the containers is determined according to the container on which each container is configured to start each container when each container in the container set is created; wherein, the shared storage space is determined by the It is shared by the container set to which any container belongs; the container set includes at least two containers in a startup order. 6. The method for maintaining virtualized container information according to claim 5, further comprising: Receive a first query request sent by the startup tool configured in any container through the pre-start callback interface; the first query request is used to request to query the identity of the dependent container of any container according to the identity of the container; The startup sequence of the dependent container relationship query stored in the shared storage space is adjacent to the startup sequence of any container, and the identifier of the container started before the any container is used as the identifier of the queried container. The identity of the dependent container of any of the above containers; Return the identifier of the dependent container of any container to the startup tool through the pre-start callback interface. 7. The method for maintaining virtualized container information according to claim 6, further comprising: Receive a second query request sent by the startup tool configured in any container through the pre-start callback interface, where the second query request is used to request to query whether the identifier of the dependent container of any container is mapped to the startup identifier; According to the mapping relationship between the start completion identifier written into the shared storage space by the container that has completed startup in the container set and the identifier of the container that has completed startup, query whether the identifier of the dependent container of any container has been mapped. Startup identifier, if yes, send a query response to the startup tool through the pre-start callback interface, otherwise, do not send the query response to the startup tool; the query response is used to indicate that the dependency container is queried. Identity mapping completes the startup identity. 8. The method for maintaining virtualized container information according to claim 6, further comprising: Receive a write instruction sent by the startup tool configured in any container through the notification callback interface; the write instruction is used to indicate that the writing of the startup identifier to any of the containers is completed; A file in a preset format is written in the folder where the any container is located in the shared storage space, and the file in the preset format is used as the completion startup identifier of the mapping of the any container. 9. An electronic device, comprising a memory, a processor and a computer program stored on the memory and running on the processor, wherein the processor implements any one of claims 1 to 4 when the processor executes the program The steps of the virtualized container startup method described in item 1, or the steps of implementing the virtualized container information maintenance method according to any one of claims 5 to 8 when the program is executed. 10. A non-transitory readable storage medium on which a computer program is stored, characterized in that, when the computer program is executed by a processor, the method for starting a virtualized container according to any one of claims 1 to 4 is implemented. step, or a step of the method for maintaining information on a virtualized container according to any one of claims 5 to 8.

Images