Non-containerization service operation and maintenance method in different network environments based on springboard machine

Abstract

The invention provides a non-containerized service operation and maintenance method in different network environments based on a springboard machine, and the method comprises the steps: creating a login account of a code hosting tool, setting a corresponding authority for the login account, and pushing a code of a business system to the login account according to the needs; according to the non-containerized service operation and maintenance method in different network environments based on the springboard machine, a visual interface is provided for the pushed codes in the environment 1, and compiling and packaging are carried out after selection according to actual requirements; the invention provides a method for realizing non-containerized front-end and back-end engineering service operation and maintenance by taking a springboard machine as a transfer and integrating deployment operation and maintenance work under two sets of environments while indirectly communicating the two sets of different network environments.

Description

Technical Field

[0001] This application belongs to the field of service operation and maintenance technology, and in particular relates to a non-containerized service operation and maintenance method and system based on jump servers in different network environments. Background Technology

[0002] By adopting the visual and modern Jenkins continuous integration framework, combined with Git, it is possible to quickly deploy and maintain containerized Vue front-end projects and microservices, simplifying IT management and improving service operation and maintenance efficiency. However, when the same service needs to be deployed on two Jenkins instances on different network segments, the indirect network connectivity leads to inefficient service deployment and susceptibility to errors caused by different package files.

[0003] Therefore, how to provide a method that uses a jump server as a relay to indirectly connect two different network environments while integrating the deployment and maintenance work in the two environments, thereby achieving non-containerized front-end and back-end engineering service operation and maintenance, has become an urgent technical problem to be solved. Summary of the Invention

[0004] Purpose of the invention: In order to overcome the shortcomings of the existing technology, the present invention aims to provide a method and system for the operation and maintenance of non-containerized services in different network environments based on jump servers.

[0005] This application provides a method for operating and maintaining non-containerized services in different network environments based on a jump server. The method includes:

[0006] Step 1: Pull the code of the business system from the relay server in Environment 1, and package the front-end Vue project into dist.tar.gz and the back-end Java project into xxx.jar through the visual interface, thereby realizing the package file construction.

[0007] Step 2: Using a Shell script in Environment 1, push the aforementioned front-end tar.gz file and back-end jar package to the upgrade deployment server in Environment 1;

[0008] Step 3: Using a Shell script in Environment 1, delete the package file built in Step 1, keeping only the package file pushed in Step 2;

[0009] Step 4: Run the package file using a shell script in Environment 1, in a non-containerized java -jar command manner;

[0010] Step 5: If the service starts successfully in step 4, proceed to step 6; otherwise, roll back to the previous version package file pushed in step 2 in environment 1 and execute step 4 again.

[0011] Step 6: Use the jump server tool to transfer the package file built in environment 1 to the specified folder directory of the local environment in the form of a file stream;

[0012] Step 7: Use the jump server tool to transfer the built package file locally to the relay server in environment 2 as a file stream;

[0013] Step 8: Using a Shell script in Environment 2, push the packet file transmitted in Step 7 to the relay server in Environment 2.

[0014] Step 9: Push the package file to the upgrade deployment server in Environment 2 through the visual interface;

[0015] Step 10: Using a Shell script in Environment 2, delete the packet file from the relay server in Step 8, keeping only the packet file pushed in Step 9;

[0016] Step 11: Run the package file using a Shell script in Environment 2, in a non-containerized java -jar command manner.

[0017] Preferably, the method further includes:

[0018] The jump server tool is designed and developed using the GoLang language, and comes with a YAML configuration file. The configuration file needs to be configured in advance with the IP addresses and ports of Environment 1, the local machine, and Environment 2, as well as the folder path address for the local storage package file.

[0019] Preferably, the springboard tool displays all package files of all projects in environment 1 in the form of a tree list.

[0020] Preferably, the method further includes:

[0021] When using the jump server tool to select and pull package files from environment 1, you need to enter log information, including IP, user, tag, and remarks.

[0022] Preferably, the springboard tool displays all package files of all projects in environment 2 in the form of a tree list.

[0023] Preferably, the method further includes:

[0024] When using the jump server tool to select a package file in push environment 2, you need to enter log information, including IP, user, tag, and remarks.

[0025] Preferably, the method further includes:

[0026] The jump server tool directly uploads the locally built package file, modifies its file extension format to match the package file format automatically built in environment 1, and then uses the same jump server tool to upload the modified package file from the local machine to environment 2.

[0027] Preferably, the method further includes:

[0028] Step 12: If the service starts successfully in step 11, the process ends; otherwise, roll back to the previous version package file pushed in step 9 in environment 2 and execute step 11 again.

[0029] The beneficial technical effects of this application are as follows:

[0030] This application provides a method for integrating deployment and maintenance work in two different network environments while indirectly connecting them, thereby achieving non-containerized front-end and back-end engineering service operation and maintenance. Attached Figure Description

[0031] Figure 1 This is a framework diagram provided in the embodiments of this application;

[0032] Figure 2 This is a flowchart provided in an embodiment of this application. Detailed Implementation

[0033] Please see Figure 1 This application provides a method for operating and maintaining non-containerized services in different network environments based on a jump server, including:

[0034] Create a login account for the code hosting tool, set the appropriate permissions for it, and push the code of the business system to it as needed;

[0035] Preferably, the non-containerized service operation and maintenance method of the present invention based on the jump server in different network environments provides a visual interface for the above-mentioned pushed code in environment 1, and compiles and packages it after selection according to actual needs;

[0036] Preferably, the non-containerized service operation and maintenance method of the present invention based on the jump host in different network environments packages the above-mentioned push code into environment 1, packaging the front-end Vue project as dist.tar.gz and the back-end Java project as xxx.jar;

[0037] Preferably, the non-containerized service operation and maintenance method based on the jump server in different network environments of the present invention will push the front-end and back-end packages to the designated server in the same environment 1 through the script in environment 1, and at the same time stop the original service and start the package pushed this time according to the specified command;

[0038] Preferably, in the non-containerized service operation and maintenance method based on the jump server in different network environments of the present invention, if the package file running in environment 1 is abnormal, a rollback of a specified version will be performed through the visual interface of environment 1.

[0039] Preferably, in the non-containerized service operation and maintenance method based on jump server in different network environments of the present invention, the push operation log information recorded in environment 1 includes time, remarks and responsible person;

[0040] Preferably, the non-containerized service operation and maintenance method based on the jump server in different network environments of the present invention will display the package files built in environment 1 and the package files downloaded locally in a tree list in the jump server tool that can connect to environment 1 and environment 2 at the same time, according to time and version order, and indicate the number of child nodes in the tree structure.

[0041] Preferably, in the non-containerized service operation and maintenance method of the present invention based on the jump server in different network environments, the jump server tool selects the pull program, selects the package file under environment 1, enters the log information, including IP, user, tag and remarks, and then downloads the package file in environment 1 to the local disk of the jump server. At the same time, the script in environment 1 is executed to delete the package file built in environment 1.

[0042] Preferably, in the non-containerized service operation and maintenance method of the present invention based on the jump server in different network environments, the push program is selected in the jump server tool, the locally downloaded package file is selected, log information including IP, user, tag and remarks is entered, and the package file in the local secondary disk is pushed to environment 2, but the pushed package file in the local disk is not deleted;

[0043] Preferably, in the non-containerized service operation and maintenance method of the present invention based on the jump host in different network environments, if the locally downloaded package file is not selected, the locally built package file can also be selected for uploading. Since the locally built package is not in tar.gz format, the conversion type function in the jump host tool can be selected to convert the local zip format file to tar.gz format file.

[0044] Preferably, the non-containerized service operation and maintenance method based on the jump server in different network environments of the present invention provides a visual interface for the pushed package file in environment 2. After selection according to actual needs, it is transferred to a designated server in environment 2. At the same time, the original service is stopped and the pushed package is started according to the specified command.

[0045] Preferably, in the non-containerized service operation and maintenance method based on the jump server in different network environments of the present invention, if the package file running in environment 2 is abnormal, a rollback of a specified version will be performed through the visual interface of environment 2.

[0046] Preferably, in the non-containerized service operation and maintenance method of the present invention based on the jump server under different network environments, after the above push is completed, the package file before the push is deleted, and only the package file running in the specified server is retained;

[0047] Preferably, in the non-containerized service operation and maintenance method based on the jump server in different network environments of the present invention, the push operation log information recorded in environment 2 includes time, remarks and responsible person;

[0048] In other embodiments of this application, a non-containerized service operation and maintenance system based on a jump server in different network environments is provided. This includes a service operation and maintenance system in environment 1, which pulls GitLab code from environment 1 and performs a non-containerized build, constructing the front-end project as a dist package and the back-end project as a jar package. After construction, the system pushes the packages to a specified server within environment 1 and runs the service, while simultaneously recording operation logs. A service relay system under the jump server is used to download the package files built in environment 1 and upload them individually or in batches to environment 2. This system can also call and modify scripts at specified paths in environments 1 and 2, delete package files in environments 1 and 2, and record operation logs. A service operation and maintenance system in environment 2 is used to push package files to a specified server within environment 2 and run the service. It can also perform corresponding service rollbacks as needed, while recording operation logs.

[0049] In other embodiments of this application, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in the first aspect of the present invention.

[0050] Reference Figure 2 The diagram illustrates a step-by-step flowchart of a non-containerized service operation and maintenance method (full process) based on a jump server in different network environments according to an embodiment of the present invention.

[0051] This example method involves 6 application services or tools, namely the code hosting service, upgrade and deployment service, and logging service in environment 1; the relay tool in the jump server; and the logging service and deployment service in environment 2.

[0052] In this example, development code is uploaded to the code hosting tool in Environment 1 by login account and business project for management. Each time an upgrade and deployment is needed, the automated deployment service running in Environment 1 pulls the specific front-end and back-end project code as needed, packages and builds them separately according to the configuration commands. After packaging and building, a shell script is triggered to push the package file to the specified business server to be deployed. This script also kills the original process, deletes the original package file, and starts the package service for this push. If startup fails, a historical package file is selected for rollback as needed. If successful, the relay tool in the jump server can be used to pull the code and upload it to Environment 2. Unlike Environment 1, the deployment service in Environment 2 does not perform a build operation; it only triggers a shell script to push the package file to the specific business server. This script also kills the original process, deletes the original package file, and starts the package service for this push. If startup fails, a historical package file is selected for rollback as needed. If there are no problems, the service upgrade is complete. The steps are as follows.

[0053] Step 1: Pull the code of the business system from the relay server in Environment 1, and package the front-end Vue project into dist.tar.gz and the back-end Java project into xxx.jar through the visual interface, thereby realizing the package file construction.

[0054] Step 2: Using a Shell script in Environment 1, push the aforementioned front-end tar.gz file and back-end jar package to the upgrade deployment server in Environment 1;

[0055] Step 3: Using a Shell script in Environment 1, delete the package file built in Step 1, keeping only the package file pushed in Step 2;

[0056] Step 4: Run the package file using a shell script in Environment 1, in a non-containerized java -jar command manner;

[0057] Step 5: If the service starts successfully in step 4, proceed to step 6; otherwise, roll back to the previous version package file pushed in step 2 in environment 1 and execute step 4 again.

[0058] Step 6: Use the jump server tool to transfer the package file built in environment 1 to the specified folder directory of the local environment in the form of a file stream;

[0059] The tool is designed and developed using the GoLang language and comes with a YAML configuration file. The configuration file needs to be configured in advance with the IP addresses and ports of Environment 1, the local machine, and Environment 2, as well as the folder path address for storing the package files locally.

[0060] The scaffolding tool displays all package files of all projects in Environment 1 in the form of a tree list;

[0061] When using the jump server tool to select to pull the package file in environment 1, you need to enter log information, including IP, user, tag and remarks.

[0062] Step 7: Use the jump server tool to transfer the built package file locally to the relay server in environment 2 as a file stream;

[0063] The scaffolding tool displays all package files of all projects in Environment 2 in the form of a tree list;

[0064] When using the jump server tool to select the package file in push environment 2, log information must be entered, including IP, user, tag and remarks.

[0065] Among them, the jump server tool can also directly upload locally built package files, modify their file extension format to make them consistent with the package file format automatically built in environment 1, and similarly use the jump server tool to upload the modified package file from the local machine to environment 2;

[0066] Step 8: Using a Shell script in Environment 2, push the packet file transmitted in Step 7 to the relay server in Environment 2.

[0067] Step 9: Push the package file to the upgrade deployment server in Environment 2 through the visual interface;

[0068] Step 10: Using a Shell script in Environment 2, delete the packet file from the relay server in Step 8, keeping only the packet file pushed in Step 9;

[0069] Step 11: Run the package file using a shell script in Environment 2, in a non-containerized java -jar command manner;

[0070] Step 12: If the service starts successfully in step 11, the process ends; otherwise, roll back to the previous version package file pushed in step 9 in environment 2 and execute step 11 again.

[0071] The present invention also provides a device including a processor, a communication interface, and a memory for storing processor-executable computer programs. When the device is running, the processor and the memory communicate via a bus, and the processor executes the aforementioned upgrade deployment method on the processor's readable instructions.

[0072] The computer program in the memory can be implemented in the form of software functional units and sold or used as an independent product, and can be stored in a computer-readable storage medium.

Claims

1. A non-containerized service operation and maintenance method in different network environments based on a jump server, characterized in that: The method comprises: Step 1: Pull the code of the business system on the transit server of environment 1, package the front-end Vue project into dist.tar.gz and the back-end Java project into xxx.jar through the visual interface, so as to build the package file; Step 2: Use the Shell script in environment 1 to push the front-end tar.gz and back-end jar packages to the upgrade deployment server in environment 1. Step 3: Use the Shell script in environment 1 to delete the package file built in step 1, and only keep the package file pushed in step 2; Step 4: Run the package file in the non-containerized java-jar command mode through the Shell script in environment 1; Step 5: If the service is successfully started in step 4, proceed to step 6; otherwise, roll back to the previous version package file pushed in step 2 in environment 1 and execute step 4 again; Step 6: Use the jump machine tool to transfer the package file built in environment 1 to the specified folder directory of the local environment in the form of a file stream; Step 7: Use the jump server tool to transfer the locally built package file to the transfer server in environment 2 in the form of a file stream; Step 8: Use the Shell script in environment 2 to push the package file transferred in step 7 to the transit server in environment 2. Step 9: Push the package file to the upgrade deployment server in environment 2 through the visual interface; Step 10: Use the Shell script in environment 2 to delete the package file of the transfer server in step 8, and only keep the package file pushed in step 9; Step 11: Use the Shell script in environment 2 to run the package file in the non-containerized java-jar command mode.

2. The method according to claim 1, characterized in that The method further comprises: The jump server tool is designed and developed in GoLang language, and comes with a configuration file in yaml format. The IP and port of environment 1, local and environment 2, as well as the folder path address of the local storage package file need to be configured in advance in the configuration file.

3. The method according to claim 2, characterized in that The jump machine tool displays all package files of all projects in environment 1 in the form of a tree list.

4. The method according to claim 3, characterized in that The method further comprises: When using the jump server tool to select the package file in pull environment 1, you need to enter the log information, including IP, user, label and remarks.

5. The method according to claim 4, characterized in that The springboard tool displays all package files of all projects in environment 2 in the form of a tree list.

6. The method according to claim 5, characterized in that The method further comprises: When using the jump server tool to select the package file in push environment 2, you need to enter the log information, including IP, user, label and remarks.

7. The method according to claim 6, characterized in that The method further comprises: The jump board tool directly uploads the locally built package file, and uses the jump board tool to modify its suffix name format to make it consistent with the package file format automatically built in environment 1. The jump board tool is also used to upload the package file with the modified format from the local to environment 2.

8. The method according to claim 1, characterized in that: The method further comprises: Step 12: If the service is successfully started in step 11, the process ends; otherwise, the process rolls back to the previous version package file pushed in step 9 in environment 2, and executes step 11 again.

Images