CN114995962A - Method for loading emergency patches by initializing container - Google Patents
Method for loading emergency patches by initializing container Download PDFInfo
- Publication number
- CN114995962A CN114995962A CN202210943870.7A CN202210943870A CN114995962A CN 114995962 A CN114995962 A CN 114995962A CN 202210943870 A CN202210943870 A CN 202210943870A CN 114995962 A CN114995962 A CN 114995962A
- Authority
- CN
- China
- Prior art keywords
- container
- file
- initialization
- jar
- original
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45562—Creating, deleting, cloning virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention discloses a method for loading emergency patches by initializing a container, which comprises the following steps: s1, according to the user request, using the annotation to identify the Class file which needs to be replaced by the application; s2, triggering callback service when creating a resource object by utilizing Kubernetes; s3, the callback service modifies the description definition information of the resource object according to the annotation information and adds an initialization container; s4, Kubernets completes the creation of the revised resource object and schedules the container instance to run on a specific node; s5, firstly starting an initialization container during running, and updating the Class file into a Jar package by the initialization container; and S6, normally starting the original container, loading the modified Jar package and running. The invention realizes the automatic update of the Class file without modifying the starting logic of the container and manufacturing the container mirror image, and realizes the quick version update.
Description
Technical Field
The invention relates to the field of DevOps, in particular to a method for loading emergency patches by initializing a container.
Background
During software delivery, many scenarios require version updates by replacing Class files in Java applications, such as: the production system finds an urgent defect and needs to be repaired as soon as possible. If the whole version is updated or all Jar package files are reconstructed, many changes which are not fully verified can be introduced, so in order to control the change range, the safest scheme is to update only the Class file to which the code logic belongs. In addition, in the scene of research and development and delivery at different places, if all containers are repackaged, tested and released with mirror images every time, the whole process is very long, and the time efficiency requirement for quickly repairing defects cannot be met because the release package is very large and the communication and transmission time is long.
At present, more and more applications are delivered in a containerization mode, a container arrangement engine is generally used for managing the applications, the most mainstream container platform at present is kubernets, and automatic deployment and operation and maintenance are realized by utilizing the kubernets. Compared with the traditional virtual machine deployment mode, the container platform realizes automatic resource scheduling, improves operation and maintenance efficiency, but some traditional operation and maintenance means cannot be used any more, for example, in the traditional mode, if a Class file of a certain Java application needs to be replaced, a user can directly log in the virtual machine to directly stop the process, modify the Jar file and then start the virtual machine. However, in the container delivery mode, the container is dynamically scheduled, the modification of the file in the container is volatile, if the file is directly modified, the container is rebuilt when the restart process takes effect, the modified content is reset, and the purpose of replacing the Class file cannot be achieved. In order to solve the problem, the existing method for realizing Class file replacement by containerized Java application includes:
1) and (5) re-making a mirror image. The main principle is that Jar files are downloaded from original mirror images, Class is merged and then made into new mirror image files, and the new mirror image files are upgraded. The scheme has the following problems that firstly, a container mirror image manufacturing platform needs to be deployed on site, mirror image warehouse authorization and the like are managed, extra resources are occupied, the process is long, time consumption is long, and meanwhile, due to the fact that mirror images are manufactured again, the risk of extension of the change range exists. Meanwhile, if container images of a plurality of versions exist, each version needs to be completely manufactured, otherwise, the original modified content is flushed away when the versions are upgraded or rolled back, all related parties of the container images need to be informed, and all version updates need to be merged into the Class first and then upgraded. It can be seen that this method is complex and cooperative, and changes are easily missed.
2) And modifying the container, and downloading and replacing the file before starting the process. The method does not need to make a mirror image again, but puts a special program (usually a script) into the container, modifies the container starting command, executes the script after the container is started, pulls a Class file from an external storage in the script, then joins the Class file into a Jar file, and then starts the original Java process. The method is replaced before the process is started, and the mirror image does not need to be made again, but the method has invasive modification on the container starting logic, needs to embed the script in advance, solves the problem of the failure of the survival probe, and has no universality.
3) And performing Class replacement in a hot update mode in the process running process. When the Java program runs, the hot updating capability provided by the JVM itself is utilized to directly replace the Java program without stopping the process. However, this method can only support very narrow scenes such as method level modification, and cannot meet the requirements of projects.
These methods all have some defects, and the capability of kubernets itself is not fully utilized, so that the method is not an optimal scheme for applying and loading a Class on a kubernets platform, and a better Java application replacement Class file scheme realized by fully utilizing the expansion capability of the kubernets needs to be provided.
An effective solution to the problems in the related art has not been proposed yet.
Disclosure of Invention
In view of the problems in the related art, the present invention provides a method for loading an emergency patch by initializing a container, so as to overcome the above technical problems in the related art.
Therefore, the invention adopts the following specific technical scheme:
a method for loading an emergency patch by initializing a container, the method comprising the steps of:
s1, according to the user request, using the annotation to identify the Class file which needs to be replaced by the application;
s2, triggering callback service when creating a resource object by utilizing Kubernetes;
s3, the callback service modifies the description definition information of the resource object according to the annotation information, adds an initialization container, and returns the revised content to Kubernets;
s4, Kubernets completes the creation of the revised resource object and schedules the container instance to run on a specific node;
s5, firstly starting an initialization container during running, wherein the initialization container updates the Class file into the Jar package and covers the original Jar package in the original container;
and S6, normally starting the original container, loading the modified Jar package and running.
Further, the step of identifying the Class file which needs to be replaced by the application by using the annotation according to the user request comprises the following steps:
s11, modifying the Java code within the minimum modification range to realize corresponding functions according to the creation or update request of the application, and compiling the modified Java file into a corresponding Class file;
s12, storing the Class file and the corresponding Jar packet path and Class path information by using a Configmap object of Kubernetes;
s13, revising the description of the application Workload object deployed on the Kubernetes platform, adding a comment in the metadata field of the Pod object inside the application Workload object, and setting the value as the name of the Configmap resource object.
Further, the triggering callback service by using kubernets when creating resource objects includes the following steps:
s21, newly adding a dynamic admission control strategy in a Kubernets platform through newly adding a mica WebHookconfiguration of the Kubernets;
s22, the dynamic admission control strategy automatically triggers the callback service of an admission controller plug-in when the Kubernets create Pod resources.
Further, the kubernets adopts a rolling updating mode to gradually replace Pod instances.
Further, the callback service modifies the description definition information of the resource object according to the annotation information, adds an initialization container, and returns the revised content to kubernets, including the following steps:
s31, acquiring description definition information of the Pod resource object of the application from the parameters after receiving the callback request of Kubernetes;
s32, judging whether the metadata field in the description definition information has a note needing updating the Class file, if not, directly returning to finish;
s33, if the annotation exists, the corresponding Configmap information is found according to the annotation value;
s34, adding an initialization container to the Pod object according to the Configmap information, and replacing an inlet program of the initialization container with a script for updating a Class file and mounting the script to the Configmap;
s35, adding a shared volume to the Pod object according to the Configmap information, and mounting the shared volume to the initialization container and the original container simultaneously;
and S36, returning the revised content of the Pod resource description to Kubernets to complete the editing of the resource object.
Further, the Configmap information includes the stored Class file and the path and Class path information.
Further, the initialization container is created by using the same container mirror as the original container.
Further, the runtime first starts an initialization container, and the initialization container updates the Class file into the Jar package and overwrites the original Jar package in the original container, including the following steps:
s51, reading the file of the original container by using the initialized container, and performing incremental modification on the basis of the original file;
s52, the initialization container mounts the Class file information into the initialization container in a volume mounting mode;
s53, placing the Jar file into a shared volume by utilizing the initialization container;
s54, the shared volume is mounted to the initialization container and the original container at the same time, and the path is consistent with the original Jar path, so that the modification of the original container file is realized.
Further, the step of using the initialization container to place the Jar file into a shared volume includes the following steps:
s531, modifying the entrance program of the initialization container into a section of Shell script according to the Configmap information,
s532, reading the Jar package, and covering a Class file corresponding to the Jar file with a new Class file by using a Jar-uf command through the Shell script;
and S533, storing the merged Jar file into a shared volume.
Further, the shared volume is created by using the EmptyDir storage volume of kubernets.
The invention has the beneficial effects that: the automatic replacement of the Class file is realized by utilizing mechanisms such as an automatic injection initialization container and a shared volume; firstly, an initialization container is automatically injected into a Java application container needing to update a Class file by using an extension mechanism of a Kubernets platform, the original Jar package is read from the initialization container, the corresponding Class file is updated, then the modified Jar package is mounted into the original container through a shared volume, and the Jar file in the original container is covered, so that the automatic update of the Class file is realized, the starting logic of the container does not need to be modified, a container mirror image does not need to be made, the Class file can be transparently and noninvasively updated into the Java application of the Kubernets platform, the quick version update is realized, and the Kubernets platform has the following advantages:
1. the change range is accurately controlled, only a few Class files are modified to complete the change, and the rest files are kept unchanged, so that scenes such as online faults can be safely and quickly repaired;
2. the container mirror image does not need to be manufactured again, the problems of long flow and time consumption caused by manufacturing the mirror image, easy introduction of unknown change and the like are solved, and meanwhile, the process is automatically executed when the container application is started, so that the problems of omission and the like can be avoided;
3. the method has good compatibility, the Jar package is modified in an independent initialization container, the original container is not invaded, the starting process of the original container is not influenced, the original container is isolated from the original container, and the problems of abnormal container starting and the like caused by modifying the Jar package are avoided;
4. the method is flexible and efficient, the Class files in the Jar package can be replaced, the hot loading updating limit of the JVM can be eliminated, meanwhile, the classes to be loaded can be directly selected according to the requirement during starting, the subsequent process is completely and automatically completed, a user does not need to know the implementation details, and the method is friendly to operation and maintenance personnel;
5. the invention has good universality, only depends on the self expansion mechanism of Kubernets, has no limit condition on application description files, Java versions, container basic mirror images, container starting commands and the like, and can be used for solving the emergency problem of the environment by replacing Class files as long as the application runs on the Kubernets.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required in the embodiments will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art that other drawings can be obtained according to the drawings without creative efforts.
FIG. 1 is a flow diagram of a method for loading an emergency patch by initializing a container according to an embodiment of the invention;
FIG. 2 is a schematic diagram of a method for loading an emergency patch by initializing a container according to an embodiment of the present invention;
FIG. 3 is a schematic flow chart diagram illustrating a Kubernets implementation in a method for loading an emergency patch by initializing a container according to an embodiment of the present invention;
FIG. 4 is a logical diagram of a Kubernetes callback service in a method for loading an emergency patch by initializing a container according to an embodiment of the invention;
fig. 5 is a schematic diagram illustrating a principle of updating Jar package files in an overlay container in a method for loading an emergency patch by initializing the container according to an embodiment of the present invention.
Detailed Description
According to an embodiment of the present invention, a method for loading an emergency patch by initializing a container is provided.
Referring now to the drawings and the detailed description, in accordance with an embodiment of the present invention, a method for loading an emergency patch by initializing a container, as shown in fig. 1-5, includes the steps of:
s1, according to the user request, using the annotation to identify the Class file that the application needs to replace, including the following steps:
s11, according to the application creating or updating request (when the application is created or updated under the minimum change requirement), modifying the Java codes within the minimum modification range to realize corresponding functions, and compiling the modified Java files into corresponding Class files (research and development personnel only need to send the Class files from the research and development center to the project site);
s12, storing the Class file and the corresponding Jar packet path and Class path information by using a Configmap object of Kubernets (operation and maintenance personnel);
s13, revise the description of the application workflow object deployed on the kubernets platform, add a comment (annotation) to the metadata (metadata) field of its internal Pod object, and set the value as the Configmap resource object name (indicating that the Java application needs to load the corresponding Class file).
S2, triggering callback service when creating resource object by Kubernetes, including the following steps:
s21, adding a dynamic admission control strategy in a Kubernets platform through a newly added MutatingWebhookConfiguration of the Kubernets;
s22, the dynamic admission control strategy automatically triggers the callback service of an admission controller plug-in (MutatingAdmissionWebhook) when the Kubernets create Pod resources.
Wherein, the Kubernets adopts a rolling updating mode to gradually replace Pod instances.
And completing the update of the Class file while completing the re-creation of the Pod, wherein if the updateStrength of the Kubernets work object of the application is specified to be in a Rollingpdate mode, the Kubernets gradually replace Pod instances by using a rolling update mode. And the Pod is created again in the rolling updating process, and the updating of the Class file can be completed under the condition that the service is not interrupted by using the rolling updating method.
S3, the callback service modifies the description definition information of the resource object according to the annotation information, adds an initialization container, and returns the modified content to Kubernetes;
as shown in fig. 4, step S3 includes the steps of:
s31, acquiring description definition information of the Pod resource object of the application from the parameters after receiving the callback request of Kubernetes;
s32, judging whether the metadata field in the description definition information has a note needing updating the Class file, if not, directly returning to finish;
s33, if the annotation exists, the corresponding Configmap information is found according to the annotation value;
the Configmap information comprises the stored Class file and path and Class path information.
S34, adding an initialization container to the Pod object according to the Configmap information, replacing an inlet program of the initialization container with a script for updating a Class file, and mounting the script to the Configmap;
wherein the initialization container is created by using the same container mirror as the original container.
S35, adding a shared volume to the Pod object according to the Configmap information, and mounting the shared volume to the initialization container and the original container simultaneously;
and S36, returning the revised content of the Pod resource description to Kubernets to complete the editing of the resource object.
S4, Kubernets completes the creation of the revised resource object and schedules the container instance to run on a specific node;
s5, firstly starting an initialization container during running, wherein the initialization container updates the Class file into the Jar package and covers the original Jar package in the original container;
as shown in fig. 5, step S5 includes the steps of:
s51, reading the file of the original container by using the initialized container, and performing incremental modification on the basis of the original file;
s52, the initialization container mounts the Class file information into the initialization container in a volume mounting mode;
s53, placing the Jar file into a shared volume by utilizing the initialization container;
the method for placing the Jar file into the shared volume by utilizing the initialization container comprises the following steps:
s531, modifying the entrance program of the initialization container into a section of Shell script according to the Configmap information,
s532, reading the Jar package, and covering a Class file corresponding to the Jar file with a new Class file by using a Jar-uf command through the Shell script;
and S533, storing the merged Jar file into a shared volume.
S54, the shared volume is mounted to the initialization container and the original container at the same time, and the path is consistent with the original Jar path, so that the modification of the original container file is realized.
Wherein the shared volume is created by using an EmptyDir storage volume of kubernets.
And S6, normally starting the original container, loading the modified Jar package and running.
In addition, FIG. 2 is a schematic diagram of incrementally modifying a Jar file. As shown in fig. 2, assuming that a certain abnormality occurs in the field, after a troubleshooting analysis, Class a of Java needs to be modified from version 1.0 to version 1.1, the method is to develop codes related to directly modifying Class a, derive a Class file corresponding to Class a, and combine the Class file into a new Jar package file based on Jar package in the field, so as to strictly control the range of change and avoid directly upgrading the entire Jar package to introduce modification of unrelated Class B and Class C.
The invention is based on a Kubernetes platform, the Kubernetes has very rich expansion capability, and the following mechanisms are utilized:
1) the automatic injection mechanism means that a user can register a callback function with kubernets, when the user creates an object (for example, deploys or upgrades an application), the kubernets can automatically callback the function, and in the function, some edits can be performed on an original object, for example, a storage volume is added, a sidecar container is added or a container is initialized, and the process can be automatically completed without perception of the user. Some functionality may be added using this mechanism, transparent to the user.
2) The initialization container mechanism means that a user on a Kubernetes platform can specify one or more initialization containers for an application container, and the initialization containers are operated before the application container is started. The user may do some preparatory work using an initialization container mechanism, which is two separate containers from the original container.
3) The storage volume is a capability provided by a Kubernetes platform, various external storages can be mounted in a container for use, and for some types of storage volumes, the storage volume can be simultaneously mounted in a plurality of containers, so that data sharing among different containers is realized.
The related formats and file types used in the present invention include:
r Jar: the Java software package format contains compiled class files and metadata and other data required for application operation
Class file: byte code file generated after Java class file is compiled
③ Configmap: the name of a resource object of the Kubernetes platform can save configuration files and the like into the resource object, and then mount the configuration files to an application for use.
And Pod: the name of an object on the Kubernetes platform is the smallest logical unit of deployment, and consists of one or more containers.
EmptyDir: the name of a model of a storage Volume (Volume) on the kubernets platform is mainly used for storing temporary files.
Sixthly, subPath: the name of a parameter of a storage Volume (Volume) is mounted on the kubernets platform and is used for specifying path information of the storage Volume.
The invention is further illustrated by the following specific examples.
In this embodiment, based on a currently mainstream container arrangement engine kubernets, a Java stateless containerization application web-demo is taken as an example to describe a specific technical implementation of the container arrangement engine kubernets, where a web-demo program includes a jar file web.
The specific implementation steps are as follows:
step one, using a Kubectl create Configmap command to store information such as emergency patch class files, paths and the like into a Configmap object of Kubernets, and naming the object as hot-demo.
And secondly, adding an annotation in the web-demo application description file, wherein the annotation is named as an object, hot fix, zcm/request and has a value of hot fix-demo, and the annotation indicates that the application needs to load a hot fix-demo patch.
And step three, adding a mutegdwebhookconfiguration object in Kubernets, and adding a mutegdmissionsWebhook callback for the Pod creation event of the Kubernets.
And step four, developing a callback service by using gold, and inserting initialization container and shared volume information if the Pod resource has an objector.
Step five, the entrance program of the initialization container is modified through the specified command parameter in the callback function, and the value is modified to the following content in the embodiment:
bash -c "cp /app/lib/web.jar /hotfix-patched/
mkdir -p /hotfix-patched/BOOT-INF/classes/com/example/controller/
cp/hotfix-demo/WebController.class /hotfix-patched/BOOT-INF/classes/com/example/controller/
cd /hotfix-patched/
jar-uf web.jar ./BOOT-INF/classes/com/example/controller/WebController.class"
step six, adding storage volume information for the initialization container and the original container in the callback function, wherein the added relevant content is as follows:
spec:
containers:
volumeMounts:
- mountPath: /app/lib/web.jar
name: hotfix
subPath: web.jar
initContainers:
volumeMounts:
- mountPath: /hotfix-patched/
name: hotfix
- mountPath: /hotfix-demo/
name: hotfix-demo
volumes:
- emptyDir: {}
name: hotfix
- configMap:
name: hotfix-demo
name: hotfix-demo
and step seven, the user uses a Kubectl rolling-update command to perform rolling update on the application (default updateStrength is Rolling update, containers are created and destroyed in batches in the rolling update process, but service interruption is not caused, and the update and the application of the Class file can be completed without service interruption.
In summary, with the above technical solution of the present invention, automatic replacement of a Class file is realized by using mechanisms such as an automatic injection initialization container and a shared volume; firstly, an initialization container is automatically injected into a Java application container needing to update a Class file by utilizing an extension mechanism of a Kubernetes platform, an original Jar package is read from the initialization container, the corresponding Class file is updated, then the modified Jar package is mounted into the original container through a shared volume, and the Jar file in the original container is covered, so that the automatic update of the Class file is realized, the starting logic of the container does not need to be modified, a container mirror image does not need to be made, the Class file can be transparently and noninvasively updated into the Java application of the Kubernetes platform, and the quick version update is realized; and has the following advantages:
1. the change range is accurately controlled, only a few Class files are modified to complete the change, and the rest files are kept unchanged, so that scenes such as online faults can be safely and quickly repaired;
2. the container mirror image does not need to be manufactured again, the problems of long flow and time consumption caused by manufacturing the mirror image, easy introduction of unknown change and the like are solved, and meanwhile, the process is automatically executed when the container application is started, so that the problems of omission and the like can be avoided;
3. the method has good compatibility, the Jar package is modified in an independent initialization container, the original container is not invaded, the starting process of the original container is not influenced, the original container is isolated from the original container, and the problems that the container is abnormally started and the like due to the modification of the Jar package are avoided;
4. the method is flexible and efficient, the Class files in the Jar package can be replaced, the restriction of JVM hot loading updating can be eliminated, meanwhile, the classes to be loaded can be directly selected according to the requirement during starting, the subsequent process is completely and automatically completed, a user does not need to know the implementation details, and the method is friendly to operation and maintenance personnel;
5. the invention has good universality, only depends on the self extension mechanism of Kubernets, has no limit condition on application description files, Java versions, container basic mirror images, container starting commands and the like, and can solve the emergency problem of the environment by utilizing the invention to replace Class files as long as the application running on the Kubernets.
The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents, improvements and the like that fall within the spirit and principle of the present invention are intended to be included therein.
Claims (10)
1. A method for loading an emergency patch by initializing a container, the method comprising the steps of:
s1, according to the user request, using the annotation to identify the Class file which needs to be replaced by the application;
s2, triggering callback service when creating a resource object by utilizing Kubernetes;
s3, the callback service modifies the description definition information of the resource object according to the annotation information, adds an initialization container, and returns the modified content to Kubernetes;
s4, Kubernets completes the creation of the revised resource object and schedules the container instance to run on a specific node;
s5, firstly starting an initialization container during running, wherein the initialization container updates the Class file into the Jar package and covers the original Jar package in the original container;
and S6, normally starting the original container, loading the modified Jar package and running.
2. A method for loading an emergency patch by initializing a container according to claim 1, wherein said step of using an annotation to identify a Class file that an application needs to replace according to a user request comprises the steps of:
s11, modifying the Java code within the minimum modification range to realize corresponding functions according to the creation or update request of the application, and compiling the modified Java file into a corresponding Class file;
s12, storing the Class file and the corresponding Jar packet path and Class path information by using a Configmap object of Kubernetes;
s13, revising the description of the application Workload object deployed on the Kubernetes platform, adding a comment in the metadata field of the Pod object inside the application Workload object, and setting the value as the name of the Configmap resource object.
3. The method for loading an emergency patch by initializing a container according to claim 2, wherein the step of triggering callback service at resource object creation by using kubernets comprises the following steps:
s21, adding a dynamic admission control strategy in a Kubernets platform through a newly added MutatingWebhookConfiguration of the Kubernets;
s22, the dynamic admission control strategy automatically triggers the callback service of an admission controller plug-in when the Kubernets create Pod resources.
4. The method for loading an emergency patch by initializing a container according to claim 3, wherein Kubernets replaces Pod instances step by step in a rolling update manner.
5. The method for loading an emergency patch according to claim 4, wherein the callback service modifies the description definition information of the resource object according to the annotation information, adds the initialization container, and returns the revised content to kubernets, and comprises the following steps:
s31, acquiring description definition information of the Pod resource object of the application from the parameters after receiving the callback request of Kubernetes;
s32, judging whether the metadata field in the description definition information has a note needing updating the Class file, if not, directly returning to finish;
s33, if the annotation exists, the corresponding Configmap information is found according to the annotation value;
s34, adding an initialization container to the Pod object according to the Configmap information, replacing an inlet program of the initialization container with a script for updating a Class file, and mounting the script to the Configmap;
s35, adding a shared volume to the Pod object according to the Configmap information, and mounting the shared volume to the initialization container and the original container at the same time;
and S36, returning the revised content of the Pod resource description to Kubernets to complete the editing of the resource object.
6. A method for loading an emergency patch according to claim 5, wherein the Configmap information includes the stored Class file and path and Class path information.
7. A method for loading an emergency patch according to claim 6, wherein the initialized container is created using the same container image as the original container.
8. The method for loading an emergency patch through an initialization container according to claim 1, wherein the runtime first starts the initialization container, and the initialization container updates the Class file into the Jar package and overwrites the original Jar package in the original container, comprising the following steps:
s51, reading the file of the original container by using the initialized container, and performing incremental modification on the basis of the original file;
s52, the initialization container mounts the Class file information into the initialization container in a volume mounting mode;
s53, placing the Jar file into a shared volume by utilizing the initialization container;
s54, the shared volume is mounted to the initialization container and the original container at the same time, and the path is consistent with the original Jar path, so that the modification of the original container file is realized.
9. The method for loading an emergency patch according to claim 1, wherein the step of using the initialization container to place the Jar file into a shared volume comprises the following steps:
s531, modifying the entrance program of the initialization container into a section of Shell script according to the Configmap information,
s532, reading the Jar package, and covering a Class file corresponding to the Jar file with a new Class file by using a Jar-uf command through the Shell script;
and S533, storing the merged Jar file into a shared volume.
10. A method for loading an emergency patch by initializing a container as recited in claim 9, wherein the shared volume is created by using an EmptyDir storage volume of Kubernetes.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210943870.7A CN114995962B (en) | 2022-08-08 | 2022-08-08 | Method for loading emergency patches by initializing container |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210943870.7A CN114995962B (en) | 2022-08-08 | 2022-08-08 | Method for loading emergency patches by initializing container |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114995962A true CN114995962A (en) | 2022-09-02 |
| CN114995962B CN114995962B (en) | 2022-12-02 |
Family
ID=83023075
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210943870.7A Active CN114995962B (en) | 2022-08-08 | 2022-08-08 | Method for loading emergency patches by initializing container |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114995962B (en) |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105404524A (en) * | 2014-09-15 | 2016-03-16 | 阿里巴巴集团控股有限公司 | Class loading and isolating method and apparatus in Java application |
| US20170220335A1 (en) * | 2016-02-02 | 2017-08-03 | ZeroTurnaround AS | System and Method for Fast Initial and Incremental Deployment of Apps |
| CN109947452A (en) * | 2019-03-26 | 2019-06-28 | 南京联创信息科技有限公司 | A kind of Kubernetes container platform application update method |
| CN110780822A (en) * | 2019-10-28 | 2020-02-11 | 浪潮云信息技术有限公司 | Management container cloud local storage system and implementation method |
| CN114489927A (en) * | 2021-12-13 | 2022-05-13 | 航天信息股份有限公司 | Container deployment method and system for decoupling dependent files |
| CN114706767A (en) * | 2022-03-24 | 2022-07-05 | 网易（杭州）网络有限公司 | Code coverage rate acquisition method, device and equipment |
-
2022
- 2022-08-08 CN CN202210943870.7A patent/CN114995962B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105404524A (en) * | 2014-09-15 | 2016-03-16 | 阿里巴巴集团控股有限公司 | Class loading and isolating method and apparatus in Java application |
| US20170220335A1 (en) * | 2016-02-02 | 2017-08-03 | ZeroTurnaround AS | System and Method for Fast Initial and Incremental Deployment of Apps |
| CN109947452A (en) * | 2019-03-26 | 2019-06-28 | 南京联创信息科技有限公司 | A kind of Kubernetes container platform application update method |
| CN110780822A (en) * | 2019-10-28 | 2020-02-11 | 浪潮云信息技术有限公司 | Management container cloud local storage system and implementation method |
| CN114489927A (en) * | 2021-12-13 | 2022-05-13 | 航天信息股份有限公司 | Container deployment method and system for decoupling dependent files |
| CN114706767A (en) * | 2022-03-24 | 2022-07-05 | 网易（杭州）网络有限公司 | Code coverage rate acquisition method, device and equipment |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114995962B (en) | 2022-12-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4878715B2 (en) | Method, computer system and computer readable recording medium for patching applications that do not conform to operating system | |
| US7539985B2 (en) | Systems and methods for dynamic component versioning | |
| US7484223B2 (en) | System and method for building a run-time image from components of a software program | |
| US9477462B2 (en) | System and method for software product versioning packaging, distribution, and patching | |
| CN102053831B (en) | Linux operating system customizing method and system | |
| US20040088397A1 (en) | System and method for management of software applications | |
| US20090210857A1 (en) | Automated merging in a software development environment | |
| CN105490860A (en) | Method, device and system for deploying application program operation environment | |
| CN109002033B (en) | Automatic calibration system and method based on UDS | |
| US20050120344A1 (en) | Optimal component installation | |
| CN113238819B (en) | Dynamic loading method and system of drive file suitable for U-Boot | |
| CN112181858B (en) | Automatic detection method for Java software project dependent conflict semantic consistency | |
| CN117435512B (en) | Unit test method for automatically switching different database types based on Junit5 | |
| CN114995962B (en) | Method for loading emergency patches by initializing container | |
| CN111522623B (en) | Modularized software multi-process running system | |
| CN112565416A (en) | Cloud-native-based large-scale edge android equipment nanotube system and nanotube method thereof | |
| CN115599434A (en) | MySQL database RPM packaging method | |
| CN111831314B (en) | Method and device for patching non-writable partition | |
| CN115220873A (en) | Method for running Open Harmony application in Android system | |
| CN114398155A (en) | Method and system for configuring automatic deployment pipeline of application program | |
| CN114968277A (en) | Method and device for generating master burning program file, computer equipment and medium | |
| CN109947407B (en) | Data acquisition method and device | |
| CN113590179A (en) | Plug-in detection method and device, electronic equipment and storage medium | |
| CN106648797A (en) | Method and system for installing test software, test server and shared server | |
| CN113849181A (en) | Cross compiling tool chain construction method and device, electronic equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |