Non-containerized service operation and maintenance method based on different network environments of a jump machine

Abstract

The application provides a non-containerized service operation and maintenance method based on a different network environment of a jump machine, the method comprising: creating a login account of a code hosting tool, setting corresponding permissions therefor, and pushing the code of a business system to the login account as needed; the non-containerized service operation and maintenance method based on the different network environment of the jump machine provides a visual interface for the pushed code in environment 1, and compiles and packages the code after selection according to actual needs; and the application provides a method for realizing non-containerized front-end and back-end engineering service operation and maintenance by taking the jump machine as a transfer station and integrating deployment and operation and maintenance work in two different network environments while indirectly connecting the two 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 files.

[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 based on the jump server in different network environments of the present invention packages the above-mentioned push code in environment 1, and packages 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 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 six application services or tools: code hosting service, upgrade and deployment service, and logging service in environment 1; relay tool in jump server; and 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 method for operating and maintaining non-containerized services in different network environments based on jump servers, characterized in that, The method includes: 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. Step 2: Using a Shell script in Environment 1, push the aforementioned front-end Vue project package dist.tar.gz and back-end Java project package xxx.jar to the upgrade and deployment server in Environment 1. 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; Step 4: Run the package file using a shell script in Environment 1, in a non-containerized java -jar command manner; 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. 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; Step 7: Use the jump server tool to transfer the locally built package file to the relay server in environment 2 as a file stream; Step 8: Using a Shell script in Environment 2, push the packet file transmitted in Step 7 to the relay server in Environment 2. Step 9: Push the package file to the upgrade deployment server in Environment 2 through the visual interface; 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; Step 11: Run the package file using a Shell script in Environment 2, in a non-containerized java -jar command manner.

2. The method according to claim 1, characterized in that, The method further includes: 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 files.

3. The method according to claim 2, characterized in that, The scaffolding 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 includes: 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.

5. The method according to claim 4, characterized in that, The jump starter 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 includes: 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.

7. The method according to claim 6, characterized in that, The method further includes: 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.

8. The method according to claim 1, characterized in that, The method further includes: 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.

Images