Detailed Description
In order to make the objects, 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 drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all, embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict. The present application will be described in detail below with reference to the embodiments with reference to the attached drawings.
Fig. 1 is a block diagram of a container assembly system according to an embodiment of the present invention.
As shown in fig. 1, the system may include: the system comprises an interface module 101, a parsing module 102, a parsing result cache 103, an execution module 104, a judgment module 105, an acquisition module 106, a container command layer (or application programming interface API)107, a log module 108, and containers 109, 110, 111, and 112.
The interface module 101 may interpret the command information of the user and the configuration file specified by the user, and call the parsing module 102. The parsing module 102 may translate the configuration file content into a container command or a call of a container API according to a user command, generating a parsing result. The parsing result cache area 103 may store parsing results. The execution module 104 may call a container related command (or API) through the container command layer (or API)107 according to the analysis result to perform an operation, and if the operation is executed to an execution point where a container state determination needs to be performed or a process in the container returns to an information state determination, pass control to the determination module 105. The determining module 105 determines whether to call the collecting module 106 according to the specific content of the analysis result, and if so, calls the collecting module 106. The collecting module 106 collects the status information of the container 109, 110, 111, or 112 and the process information running in the container, and then sends the return status information of the container itself and the application in the container to the determining module 105. The determining module 105 compares the predefined expected state (or by running an external comparison program) with the returned process information to generate a comparison result (true or false), and then passes control to the executing module 104. The execution module 104 may operate on the next container or derive error information based on predefined operations for which the comparison yields a result. In the whole process of assembling and operating the container package (group), all output information is imported into the log module 108 in real time, and the log module 108 records information such as the state of the container and the state of a process in the container, so that tracking and auditing bases are provided for the state of the container and the state of the process running in the container.
It will be appreciated that the number of individual functional modules and the number of containers within the framework are exemplary and can be flexibly adjusted as desired. In addition, the parsing result buffer 103 may be omitted, and the parsing result may be directly sent to the execution module 104 by the parsing module 102.
The following embodiments can be applied to the system architecture of the present embodiment to assemble each container one by one. The system of the present embodiment can perform a specific container assembling operation as an implementation subject of each of the following embodiments. For simplicity of description, the various embodiments may be applied with reference to each other.
Fig. 2 is a schematic flow diagram of a method of assembling a container according to an embodiment of the invention.
As shown in fig. 2, the method comprises the steps of: s210, receiving command information and configuration files for assembling the container; s220, analyzing the configuration file based on the command information to generate an analysis result; s230, directly assembling the current container when the analysis result is the first result; s240, when the analysis result is the second result, whether the state of the application in the previous container supports the assembly of the current container is judged, and if the state supports the assembly of the current container, the current container is assembled.
In step S210, the container may be a docker container. The command to assemble a container may be a command to define, create, assemble a container in a specific file format (json, yann). The profile may be user specified. The configuration file may include generating a container name, container parameters, and the like.
In step S220, the parsing result may include: directly assembling a first result of the current container, or determining whether a state of an application in a container previous to the current container supports assembling a second result of the current container.
The implementation manner of parsing the configuration file is, for example: the parsing module reads the content of the json format or yann format configuration file, converts the content of the file into a docker container call command or a set of docker API and program code segments according to the file content, and can be a bash shell program or a python script program or other programming languages. This parsed script program set may be placed into a disk file (e.g., a.sh or a.py). Or in order to reduce the disk IO expense, a memory buffer area is directly opened up, and the analyzed content is directly put into the memory buffer area.
In step S230, when the parsing result is the first result, for example, the current container is the first container, and there is no other container before the current container, so that the current container can be assembled without being restricted by the previous container when assembling the current container. For example, if the result of the parsing is a command to start a container (docker start) or stop a container (docker stop), the device may execute the current container.
In step S240, each container in the container group (container package) has an interdependence relationship, for example, a containerized web cluster, the starting sequence should be a database container, a web application container, and a load balancing container, and the web application container should be started and provide a service to the outside only after the database container is completely started successfully (the container itself + the internal data instance); when the container stops or quits, the container with the dependency relationship also needs to be stopped and quitted one by one in sequence, otherwise, the problem of data inconsistency is easily caused.
The determination of whether the state of the application in the previous container supports the assembly of the current container may be, for example: and when the previous container (database container) is completely started successfully, the starting of the current container (web application container) can be supported, and the current container can be externally provided with services after being started.
According to the method, command information of a user and a configuration file specified by the user are interpreted, the content of the configuration file is translated into a container command or calling of a container API according to the user command to generate an analysis result, a container related command is called according to the analysis result to operate, if the operation is operated to an execution point needing to judge the state of the container or judge the state of a process in the container returning information, whether the container state information and the process information running in the container are called or not is determined according to the specific content of the analysis result, if the operation is needed to be called, the returned process information is compared through a predefined expected state to generate a comparison result, and then a next container is operated or error information is derived according to predefined operation of the comparison result. The embodiment considers the dependency relationship of the operation process in the container, realizes the error-free assembly of the dependent container, and can provide an audit trail function for the operation of the whole container package.
In some embodiments, an implementation of determining whether the state of the application within the previous container supports assembling the current container may include:
judging whether the state information of the previous container needs to be acquired or not;
if the state information of the previous container needs to be collected, collecting the state information of the previous container, comparing the collected state information with expected state information to generate a comparison result, and judging whether the state of the application in the previous container supports assembling the current container or not based on the comparison result;
and if the state information of the previous container does not need to be collected, judging whether the current container is supported to be assembled or not based on an internal preset judgment rule.
The embodiment not only provides a method for collecting the running process state information in the container, but also provides a method for judging the running process state information in the container, and combines the above mode with the operation of the container to obtain the dependency relationship of the running process in the container, thereby realizing the error-free assembly of the dependent container.
In some embodiments, the status information of the previous container includes: container running state information of a previous container (e.g., information of container start or container stop) and/or running state information of a process within a previous container (e.g., process interrupt or complete execution).
On the basis of the embodiment of fig. 2, the following steps can be added: based on the state of the application within the current container, a subsequent container to the current container is assembled.
On the basis of the above embodiments, the following steps can be added: and collecting log information of each container in real time, and storing the log information into a log file. In the whole operation process, the log module collects log information of each step in real time and stores the log information into a log file to provide tracking and auditing bases for the state of the container and the state of the process running in the container.
Fig. 3 is a schematic flow diagram of a method of assembling a container according to another embodiment of the present invention.
As shown in fig. 3, the method comprises the steps of:
s301, defining a container assembly file according to the file format requirement.
S302, a container assembly command is sent out through a command line or a web (Internet general name) interface.
S303, the interface module obtains the user command and sends the user command and the configuration file to the analysis module.
S304, the analysis module combines the command sent by the user and the content in the configuration file, analyzes the combination into the related command executed by the container and the pseudo program code segment, and puts the related command and the pseudo program code segment into an analysis buffer area (which can be a memory or a file).
S305, the execution module reads the content of the analysis buffer area.
S306, container relevant operation is carried out according to the read content, if the read content is not a pseudo code segment, judgment of a container state and a process running state in the container is not involved, and a container command or an API is directly called to carry out container operation.
S307, if the read content is a pseudo code segment, the container state and the running state of the process in the container are judged, and the control right is transferred to a judging module.
S308, the judging module determines whether the acquisition module needs to be called according to the program pseudo code segment of the analysis buffer area, and if so, the step S309 is executed; if not, an internal judgment is performed, and the step S311 is executed after returning the judgment result.
The pseudo code segment is an algorithm description language. The purpose of the pseudo-code is to make the described algorithm easily implementable in any programming language (Pascal, C, Java, etc.). Therefore, pseudo-code must be clear in structure, simple in code, good in readability, and resemble natural language. Between natural and programming languages. The algorithm function is specified in written form in a programming language. Pseudo-code is used without being bound to a specific implementation. It is more natural language like programming languages (e.g., Java, C + +, C, Dephi, etc.). It is a semi-angled, non-standard language. The structure of the whole algorithm operation process can be described in a form close to natural language (any familiar words can be used for expressing the meaning of the program).
And S309, starting the acquisition module, acquiring the state of the previous container and the state information of the running process in the container, and sending the acquired result to the judgment module after the acquisition is finished (the judgment basis of the acquisition is the combination of a time threshold or a specific ending condition).
And S310, the judging module judges the acquisition result according to the predefined expected return information (or operates an external program), and sends the judgment result value to the executing module.
S311, internal judgment is executed, and a judgment result is returned.
S312, the execution module performs the operation of the next container according to the judgment result value.
The operation steps of S305 to S312 are repeated to complete the assembly of the entire container pack (set). In the whole operation process, the log module collects log information of each step in real time and stores the log information into a log file to provide tracking and auditing bases for the state of the container and the state of the process running in the container.
In this embodiment, the execution module reads the script file and executes the script file. If the script executes to the application program judgment state logic, for example:
Flag=true
While flag
if tnping 10.209.124.1 (the ip address is the address of the oracle database, and the judgment of whether the oracle database is completely started or not) then
Flag=false
else
Loop wait or other operation (e.g. sleep 5)
The next container initiates an operation, such as a docker run-rm docker container name or ID.
The judgment module can be used for judging the circulation, and particularly can package the circulation into a function. The judging module judges whether the database is completely started or not, if not, the judging module continuously and circularly judges and does not start the next container until the database is completely started; if the starting is completed, the next container is directly started. In addition, in the case of no conflict, a person skilled in the art may flexibly adjust the order of the above-mentioned operation steps or flexibly combine the above-mentioned steps according to actual needs. Various implementations are not described again for the sake of brevity.
Fig. 4 is a schematic structural view of a container mounting apparatus according to an embodiment of the present invention.
As shown in fig. 4, the container mounting apparatus 400 may include: an interface module 410, a parsing module 420, a determination module 430, and an execution module 440. Wherein: the interface module 410 may be used to receive command information for assembling a container and a configuration file; the parsing module 420 may be configured to parse the configuration file based on the command information, and generate a parsing result, where the parsing result includes: directly assembling a first result of the current container, or judging whether the state of an application in a previous container of the current container supports assembling a second result of the current container; the determining module 430 may be configured to determine whether the state of the application in the previous container supports assembling the current container when the parsing result is the second result; the executing module 440 may be configured to assemble the current container if the determining result supports assembling the current container; and if the analysis result is the first result, directly assembling the current container.
It should be noted that the implementation manner of the functional units or the functional modules shown in the present embodiment may be hardware, software, firmware, or a combination thereof. When implemented in hardware, it may be, for example, an electronic circuit, an Application Specific Integrated Circuit (ASIC), suitable firmware, plug-in, function card, or the like. When implemented in software, the elements of the invention are the programs or code segments used to perform the required tasks. The program or code segments may be stored in a machine-readable medium or transmitted by a data signal carried in a carrier wave over a transmission medium or a communication link. A "machine-readable medium" may include any medium that can store or transfer information. Examples of a machine-readable medium include electronic circuits, semiconductor memory devices, ROM, flash memory, Erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, Radio Frequency (RF) links, and so forth. The code segments may be downloaded via computer networks such as the internet, intranet, etc.
On the basis of the embodiment of fig. 4, it is also possible to add: and the acquisition module is connected with the judgment module. The acquisition module can be used for acquiring the state information of the previous container according to the acquisition instruction of the judgment module and feeding back the acquired state information to the judgment module.
For example, the collection module not only needs to collect the state information of the container, but also needs to call the relevant commands of the container to go deep inside the container to obtain the return information of the business process running in the container. After the return information is obtained, the information format is sorted, and the information is pushed to a judging module.
The indexes collected by the collection module are divided into two categories:
a type index: and (5) vessel operation index. For example, whether the container is normally started or exited; resource information consumed by the container, memory, cpu, etc.;
b type index: applying process information in the container. For example, process start information (PID, memory usage, etc.), process log information (final start result information), process output information, and the like.
The acquisition dimensions of the A-type and B-type indexes are configured by a user configuration file, and the judgment module calls an acquisition module to generate the acquisition dimensions.
For the type B index, in order to ensure the correctness and integrity of the process information acquisition in the container, acquisition time threshold information may be set (for example, the acquisition time is set to 5s, and the acquired information is pushed to the judgment module only after 5 s), or configuration such as an end condition is triggered (for example, an env parameter is set, after the process in the container is started, the relevant env parameter is rewritten as a return value, and after the parameter value is rewritten, the acquisition is considered to be completed).
In some embodiments, the determining module 430 is further configured to: judging whether the state information of the previous container needs to be acquired or not; if the state information of the previous container needs to be collected, sending an instruction for collecting the state information of the previous container to the collection module, receiving the collected state information, comparing the collected state information with expected state information to generate a comparison result, and judging whether the state of the application in the previous container supports assembly of the current container or not based on the comparison result; and if the state information of the previous container does not need to be acquired, judging whether the current container is supported to be assembled or not based on an internal preset judgment rule.
The determination module 430 is the core of the apparatus. For example, the judging module 430 receives the information pushed by the collecting module, and divides the information into two types, one type is the self-state information of the container; one type is the return information of the running process within the container. The determining module 430 performs a comparison operation according to the two types of information.
A. The simple comparison operation may be implemented as follows:
the comparison of the simple return information is defined in the assembly file (for example, if preset state ═ container return state then 0else return 1; preset state 1 ═ container return state and preset state 2 ═ container in-container process return state then 0; else return 1, etc.). The judging module simply compares the information and pushes the comparison result to the executing module.
B. The external program import comparison can be realized by the following steps:
for complex business applications, the returned information may be complex and cannot be simply compared. An application return information analysis program can be written and embedded into the container assembly file for the judgment module to call. (e.g., if localized run (/ usr/local/sbin/a.sh) the return 0; else return 1). The judging module reads the pseudo generation section of the buffer area, calls the analysis program, analyzes the return information and pushes the comparison result to the executing module according to the calling result.
In some embodiments, the execution module 440 is further configured to: based on the state of the application within the current container, a subsequent container to the current container is assembled.
For example, the execution module 440 reads the relevant content of the result buffer parsed from the user-defined configuration file, and calls a container command or an API to execute an operation. When a program pseudo code segment is encountered, the control right is delivered to the judging module, and after the judging module generates a comparison structure according to the pseudo code segment, the control right is delivered to the executing module to continue executing the container operation.
On the basis of the embodiment of fig. 4, it is also possible to add: and a log module. The log module can be used for collecting log information of each container in real time and storing the log information into a log file.
In some embodiments, the status information of the previous container includes: container running state information of a previous container and/or running state information of a process within a previous container.
In some embodiments, the container is a docker container.
It should be noted that the apparatuses in the foregoing embodiments can be used as the execution main bodies in the methods in the foregoing embodiments, and can implement corresponding processes in the methods, and for brevity, the contents of this aspect are not described again.
Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware. With this understanding in mind, the above-described technical solutions may be embodied in the form of a software product, which can be stored in a computer-readable storage medium such as ROM/RAM, magnetic disk, optical disk, etc., and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments.
Finally, it should be noted that: the above examples are only intended to illustrate the technical solution of the present invention, but not to limit it; although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the corresponding technical solutions of the embodiments of the present invention.