Application migration method and apparatus, electronic device, and readable storage medium

Abstract

The application discloses an application program migration method and device, electronic equipment and a readable storage medium, and belongs to the technical field of computers. The application program migration method comprises the following steps: setting an application program list. Parameters in the application program list are analyzed, and the application type of the application program is determined. Based on the application type, an application data packet and an executable file packet are acquired. A cache directory of an RPM packet is created, a SPEC file template is generated, and in the case that the application program depends on external software, the external software is added to a source code packet of the RPM packet. The executable file packet is imported, the RPM packet is constructed based on a deployment target system architecture, and an application installation packet is obtained. The application data packet is sent to a server specified path, and the application installation packet is installed.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and specifically relates to an application migration method and apparatus, electronic device and readable storage medium. Background Technology

[0002] In related technologies, enterprise operations may be deployed on operating systems that do not support cloud-native architectures. In such cases, it is necessary to migrate applications from cloud-native environments to physical machines for deployment. However, the migration process may involve many uncertainties that can impact the migrated business, including:

[0003] (1) The current cloud-native environment relies on various other software, and it is difficult to achieve out-of-the-box use in the offline environment.

[0004] (2) Currently, there are difficulties in the process of extracting applications from cloud-native applications. Different types of application software and special applications require targeted processing, which heavily relies on human accuracy and is prone to migration errors.

[0005] (3) Cross-platform and cross-architecture applications need to address whether the application supports them and the situation of regenerating new architecture software. Summary of the Invention

[0006] The purpose of this application is to provide an application migration method and apparatus, electronic device and readable storage medium that can solve the problems of difficulty in extracting applications from cloud-native environments, the need for targeted processing for different types of applications and special applications, heavy reliance on manual labor, low accuracy, and easy migration errors.

[0007] In a first aspect, embodiments of this application provide an application migration method, comprising: setting an application inventory; parsing parameters in the application inventory to determine the application type; obtaining application data packages and executable file packages based on the application type; creating a cache directory for RPM (Red Hat Package Manager) packages, generating a SPEC file template, and adding the external software to the source code package of the RPM package if the application depends on external software; importing the executable file package, constructing the RPM package based on the target system architecture, and obtaining an application installation package; and sending the application data package to a specified path on the server to install the application installation package.

[0008] Secondly, embodiments of this application provide an application migration apparatus, including a setting module, an acquisition module, a creation module, a building module, and an installation module. The setting module is used to set an application manifest. The acquisition module is used to parse parameters in the application manifest, determine the application type, and, based on the application type, acquire application data packages and executable file packages. The creation module is used to create a cache directory for the RPM package, generate a SPEC file template, and, if the application depends on external software, add the external software to the source code package of the RPM package. The building module is used to import the executable file package, build the RPM package based on the target system architecture, and obtain the application installation package. The installation module is used to send the application data package to a specified path on the server and install the application installation package.

[0009] Thirdly, embodiments of this application provide an electronic device including a processor and a memory, the memory storing a program or instructions that can run on the processor, the program or instructions being executed by the processor to implement the steps of the application migration method of the first aspect.

[0010] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, and when the program or instructions are executed by a processor, the steps of the application migration method as described in the first aspect are implemented.

[0011] This embodiment can automatically determine the application type, avoiding manual judgment, reducing labor costs, and preventing operational errors. When the application depends on external software, this embodiment adds the external software to the source code package of the RPM package, eliminating the need for users to install any additional software, thus solving the application dependency problem and greatly improving the integrity of the application. Attached Figure Description

[0012] Figure 1 One of the flowcharts of the application migration method provided in this application embodiment is shown;

[0013] Figure 2 The second schematic flowchart of the application migration method provided in this application embodiment is shown;

[0014] Figure 3 The third schematic diagram of the application migration method provided in this application embodiment is shown;

[0015] Figure 4 The fourth flowchart of the application migration method provided in this application embodiment is shown;

[0016] Figure 5 The fifth illustration shows a flowchart of the application migration method provided in this application embodiment;

[0017] Figure 6 A structural block diagram of the application migration apparatus provided in an embodiment of this application is shown;

[0018] Figure 7 A structural block diagram of the electronic device provided in an embodiment of this application is shown;

[0019] Figure 8 The fifth illustration shows a flowchart of the application migration method provided in this application embodiment;

[0020] Figure 9 The sixth illustration shows a flowchart of the application migration method provided in this application embodiment.

[0021] in, Figure 6 and Figure 7 The correspondence between the reference numerals and component names in the attached drawings is as follows:

[0022] 100: Application migration device; 110: Setting module; 120: Acquisition module; 130: Creation module; 140: Building module; 150: Installation module; 1000: Electronic device; 1002: Processor; 1004: Memory. Detailed Implementation

[0023] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0024] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0025] The following is in conjunction with the appendix Figures 1 to 9 The application migration method and apparatus, electronic device and readable storage medium provided in this application will be described in detail through specific embodiments and application scenarios.

[0026] This application provides an application migration method. Figure 1This document illustrates one of the flowcharts of the application migration method provided in an embodiment of this application, such as... Figure 1 As shown, the application migration methods include:

[0027] Step 102: Set up the list of applications.

[0028] Step 104: Parse the parameters in the application's manifest to determine the application's application type.

[0029] Step 106: Based on the application type, obtain the application data package and executable file package.

[0030] Step 108: Create a cache directory for the RPM package, generate a SPEC file template, and add the external software to the source code package of the RPM package if the application depends on external software.

[0031] Step 110: Import the executable package, build an RPM package based on the target system architecture, and obtain the application installation package.

[0032] Step 112: Send the application data package to the specified path on the server and install the application installation package.

[0033] Understandably, the SPEC file is a configuration specification file and is the core of the RPM package compilation process. It explains how the software package is configured, which patches are applied, which files are installed, where it is installed, and what system-level activities are required during the installation process.

[0034] Understandably, applications can be deployed on SaaS (Software-as-a-Service) platforms. Migrating applications from cloud-native deployments to domestically developed physical machine deployments presents technical challenges, including poor stability, the need for cross-platform compatibility, the need for cross-architecture compatibility, and difficulty in using them out of the box.

[0035] Understandably, when enterprises have numerous business lines, each may employ different technology stacks. Automating the identification of application types and their extraction from cloud-native environments for deployment to domestically developed physical machine environments presents a significant technical challenge. Manual operation is labor-intensive, costly, and prone to errors. Furthermore, manual operation may result in incomplete data extraction from the cloud-native environment, leading to application startup failures during deployment, hindering troubleshooting, delaying project progress, and increasing costs.

[0036] In this embodiment, an application manifest template is pre-set. Application developers complete the application information by submitting it via a webpage, automatically generating the application manifest. An application extraction tool can be used to extract the application manifest, passing it as a parameter for parsing. The tool then extracts applications from the cloud-native environment, confirming the application type only after comparing it with the specified application type in the manifest. Application data packages and executable file packages are generated according to different application types. This embodiment automates the determination of application types, avoiding manual judgment, reducing labor costs, and preventing operational errors.

[0037] This embodiment, by determining the application type and obtaining the application data package, avoids the situation where incomplete data content is extracted from the cloud-native environment due to manual operation. This, in turn, prevents application startup failures, difficulties in troubleshooting, project delays, and increased costs during the deployment phase.

[0038] This embodiment can use a domestic application creation tool to automatically identify or manually set the target physical machine architecture (i.e., the target system architecture), thereby enabling cross-platform application compilation and RPM package creation, shielding the impact of the underlying architecture, and deploying the application to the target physical machine server in a seamless manner.

[0039] This embodiment addresses situations where software cannot be installed in offline environments and the application depends on external software. It adds the external software to the source code of the RPM package, meaning that many environment runtime dependency plugins are built-in when creating the application RPM package. By embedding external software into the application software, the user can use the application software without installing any other software, solving the application dependency problem and greatly improving the integrity of the application. It provides a complete and runnable environment out of the box.

[0040] This embodiment can be applied to special and common scenarios such as information technology innovation deployment, business architecture optimization, software resource reduction, and underlying application architecture adjustment.

[0041] This embodiment simplifies the process of migrating applications from cloud-native deployments to domestically developed physical machine deployments. It can extract applications from cloud-native environments and deploy them directly on domestically developed physical machines, eliminating reliance on container technology and special application software. This automates the extraction process, reduces human error, and enables cross-platform deployment through recompiling the software package.

[0042] This embodiment provides a complete solution for migrating applications from cloud-native environments to deployments on domestically developed physical machines. It does not rely on other software packages, simplifies the risks associated with the migration process, achieves out-of-the-box usability, and enables cross-architecture application installation package creation, solving the compatibility issues of application installation across different architectures.

[0043] This embodiment greatly reduces the uncertainties brought about by migrating from a cloud-native environment to a domestically developed physical machine deployment. The advantages of this embodiment are even more obvious in the field of domestically developed applications. This embodiment is a general solution that can shield the application software from the impact of the underlying architecture.

[0044] In some embodiments of this application, the list includes one or a combination of the following:

[0045] Application name, application code, application port number, application server address, application type, application memory usage, application health check, application access to UpStream.

[0046] Understandably, UpStream stands for upstream server.

[0047] In this embodiment, different manifest contents can be set for different applications. By setting the manifest and parsing its contents, relevant information about the application can be accurately obtained, providing a foundation for subsequently obtaining application data packages, executable file packages, application categories, and creating installation file packages.

[0048] In some embodiments of this application, Figure 2 This illustrates a second flowchart of the application migration method provided in an embodiment of this application, as shown below. Figure 2 As shown, the parameters in the application's manifest are parsed to determine the application's type, specifically including:

[0049] Step 202: Pass parameters from the application manifest as input parameters and parse the parameters from the application manifest.

[0050] Step 204: Based on the fact that the application is not a customized application, determine the first application type of the application through the parameters in the application manifest.

[0051] Step 206: Detect the application using the application type detection command to obtain the application's second application type.

[0052] Step 208: Based on the fact that the first application type and the second application type are the same, the application type of the application is determined to be the first application type.

[0053] It is understood that applications can be divided into customized applications and non-customized applications. For customized applications, the migration process is carried out through a set method or form, which is not within the scope of this embodiment.

[0054] In this embodiment, the first application type of the application can be obtained through the parameters in the list. The second application type of the application can be obtained by detecting the application through the detection command. The two results are compared. Only when the results are consistent is the application type of the application set as the first application type.

[0055] In this embodiment, the application type obtained by the instruction is compared with the application type set in the list. Only after the comparison is consistent can the application type be confirmed. Then, application data packages are extracted and executable file packages are generated according to different types of applications.

[0056] In some embodiments of this application, Figure 3 The third schematic diagram of the application migration method provided in this application embodiment is shown, as follows: Figure 3 As shown, based on the application type, the application data package and executable file package are obtained, specifically including:

[0057] Step 302: If the application type is Tomcat, call the communication command to extract the application's WAR package and generate the Tomcat startup file and configuration information.

[0058] The WAR file is the application data package, while the Tomcat startup file and configuration information are executable file packages.

[0059] Step 304: If the application type is Java, call the communication command to extract the application's JAR file and related dependent JAR files, and generate the startup script, shutdown script, service script and configuration information.

[0060] The JAR file (Java Archive) and related dependent JAR files constitute the application data package, while the startup script (startup.sh), shutdown script (shutdown.sh), service script (service), and configuration information are executable file packages.

[0061] Step 306: If the application type is Node, call the communication command to extract the application's js file and generate the startup script, shutdown script, service script, configuration information and executable binary file.

[0062] The .js (with the extension for JavaScript files) file is the application package, while the startup script (startup.sh), shutdown script (shutdown.sh), service script (service), configuration information, and executable binary file are the executable file package.

[0063] Step 308: If the application type is other types, call the communication command to extract the application file of the application and generate an executable file.

[0064] Among them, the application file is the application data package, and the executable file is the executable file package.

[0065] It's understandable that Tomcat is a free web (World Wide Web) server. A WAR file is a web application format proposed by Sun Microsystems, and Java is a computer programming language. A JAR file (Java Archive) is a platform-independent file format that combines multiple files into one. Node.js is a computer programming language. A JS file is a text file that stores JavaScript code, with the extension ".js".

[0066] This embodiment categorizes applications into Tomcat, Java, Node, and other types. For each type, specific methods for obtaining application data packages and executable files are provided. By generating different application data packages and executable files for different application types, this embodiment increases the completeness of the extracted application data and the accuracy of the executable files.

[0067] In some embodiments of this application, Figure 4 The fourth flowchart of the application migration method provided in this application embodiment is shown. Figure 4 As shown, when an application depends on external software, the external software is added to the source code package of the RPM package, specifically including:

[0068] Step 402: If the application depends on Java, add the Java package to the source code package of the RPM package;

[0069] Step 404: If the application depends on Node, add the Node package to the source code package of the RPM package;

[0070] Step 406: If the application depends on Python, add the Python package to the source code package of the RPM package;

[0071] Step 408: If the application depends on Go, add the Go package to the source code package of the RPM package;

[0072] Step 410: If the application depends on PHP, add the PHP package to the source code package of the RPM package;

[0073] Step 412: If the application depends on Nginx, add the Nginx package to the source code package of the RPM package;

[0074] Step 414: If the application depends on Ruby, add the Ruby package to the source code package of the RPM package.

[0075] Understandably, when deploying software systems in a domestically developed physical machine environment, the challenge lies in achieving out-of-the-box functionality—simply installing software packages on top of the native operating system without installing any other software. This is a major hurdle encountered during the migration of software systems from cloud-native environments to domestically developed physical machine environments. For example, issues such as the need to install the JDK (Software Development Kit) before application deployment arise.

[0076] Understandably, Java, Node, Python, Go, PHP, Nginx, or Ruby represent different computer programming languages.

[0077] In this embodiment, when the application depends on Java, Node, Python, Go, PHP, Nginx, or Ruby, the relevant software packages can be added to the resource package of the RPM package. When the relevant dependent software cannot be installed in an offline environment, the dependent plugin is built into the RPM package, so that users can use the application software without installing any other software, which can reduce the application's dependence on external software.

[0078] In some embodiments of this application, Figure 5 The fifth schematic diagram of the application migration method provided in this application embodiment is shown, as follows: Figure 5 As shown, based on the target system architecture, an RPM package is built to obtain the application installation package, which specifically includes:

[0079] Step 502: If the target system architecture is X86, add X86 architecture parameters and build the RPM package using instructions.

[0080] Step 504: If the target system architecture is AARCH, add AARCH architecture parameters and build an RPM package using instructions.

[0081] Step 506: If the target system architecture is other than the architecture, construct the RPM package using instructions.

[0082] Understandably, the x86 architecture generally refers to a series of processor architectures developed by Intel. The AARCH architecture is an execution state of ARM. ARM (Advanced RISC Machine, or Acorn RISC Machine) is also an architecture, well-suited for low-cost, high-performance, and low-power applications such as mobile communications.

[0083] Understandably, when applications migrate from cloud-native environments to deployment on domestically developed physical machines, the architecture of the physical machines will present the challenge of application type conversion. For example, the architecture of the physical machine can be x86 (The X86 architecture) or AARCH architecture. How to convert from x86 architecture to AARCH architecture, or from AARCH architecture to x86 architecture, is a problem that needs to be solved.

[0084] This embodiment can utilize application development tools to automatically identify or manually configure the target physical machine architecture (i.e., the target system architecture). By adding architecture parameters, it enables cross-platform application compilation and RPM package creation. This embodiment can shield the impact of the underlying architecture, allowing for seamless application deployment to the target physical machine server. Furthermore, this embodiment can improve application compatibility and usability, preventing system type and application architecture from becoming bottlenecks in application development.

[0085] In some embodiments of this application, the application migration method further includes:

[0086] After installing the application package, execute the application launch command to start the application.

[0087] In this embodiment, when deploying the software system in a domestically developed physical machine environment, only the software package needs to be installed on the basis of the native operating system, without installing any other software. That is, after installing the application package, it can be used out of the box, which greatly simplifies the application migration process and improves the user experience.

[0088] The application migration method provided in this application embodiment can be executed by an application migration device. This application embodiment uses an application migration device executing the application migration method as an example to illustrate the application migration device provided in this application embodiment.

[0089] Some embodiments of this application provide an application migration apparatus. Figure 6 This application provides a block diagram of the application migration apparatus according to an embodiment of the present application. Figure 6As shown, the application migration device 100 includes a setting module 110, an acquisition module 120, a creation module 130, a building module 140, and an installation module 150. The setting module 110 is used to set the application manifest. The acquisition module 120 is used to parse the parameters in the application manifest, determine the application type, and, based on the application type, acquire the application data package and executable file package. The creation module 130 is used to create a cache directory for the RPM package, generate a SPEC file template, and, if the application depends on external software, add the external software to the source code package of the RPM package. The building module 140 is used to import the executable file package, build the RPM package based on the target system architecture, and obtain the application installation package. The installation module 150 is used to send the application data package to a specified path on the server and install the application installation package.

[0090] This embodiment can automatically determine the application type, avoiding manual judgment, reducing labor costs, and preventing operational errors. When the application depends on external software, this embodiment adds the external software to the source code package of the RPM package, eliminating the need for users to install any additional software, thus solving the application dependency problem and greatly improving the integrity of the application.

[0091] The application migration apparatus 100 provided in this application embodiment can implement all the processes of the above application migration method embodiment and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0092] like Figure 7 As shown, this application embodiment also provides an electronic device 1000, which includes a processor 1002 and a memory 1004. The memory 1004 stores a program or instructions that can run on the processor 1002. When the program or instructions are executed by the processor 1002, they implement the various steps of the above method embodiments and can achieve the same technical effect. To avoid repetition, they will not be described again here.

[0093] For example, electronic device 1000 can be a server.

[0094] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described application migration method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0095] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk. Specific implementation examples:

[0097] To extract applications from cloud-native environments and deploy them to domestically developed physical machines, this embodiment designs an application extraction tool. The toolkit is designed as follows: a template file for an application list is pre-defined. Application developers submit their application information via a webpage, automatically generating an application list. The application extraction tool then takes this list as a parameter, parses it, and begins extracting application software from the cloud-native environment. The application type is confirmed only after the command matches the application type set in the list. Then, software packages are extracted and executable files are generated according to different application types. For example... Figure 8 As shown, the steps for applying the data package and executable file package include:

[0098] Step 602, obtain the application manifest;

[0099] Prepare an application list in advance, including the application name, application code, application port number, application server IP, application type (Java, Tomcat, Node, etc.), application memory usage, application health check URI, and application access Upstream.

[0100] Step 604: Perform application extraction;

[0101] Specifically, it includes:

[0102] Step 6042: Pass the application's manifest as a parameter;

[0103] Step 6044: Parse the parameters of the application's manifest;

[0104] Using an application extraction tool, the application list in step 6042 is parsed to determine if a customized application exists. If it is a customized application, the customized application process is executed separately; otherwise, step 6046 is continued.

[0105] Step 6046: Determine the application type;

[0106] The application type is determined by the application parameters. At the same time, the kubectl exec command is called to enter the cloud-native application (the kubectl exec process: when kubectl exec... is run on a computer, the process can access containers running on any node of the k8s (Kubernetes, container orchestrator) server) and execute application type detection commands (Node-v Java-version, etc.). Only when the two match can the application type be confirmed.

[0107] If the application type is Tomcat, proceed to step 6048.

[0108] If the application type is Java, proceed to step 6050.

[0109] If the application type is Node, proceed to step 6052.

[0110] If the application type is other, proceed to step 6054.

[0111] Step 6048: If the application type is Tomcat, call Kubectl to extract the application's WAR package and generate the Tomcat startup file, service file, and env.conf. The WAR package is the application data package, while the Tomcat startup file, service file, and env.conf are executable file packages.

[0112] kubectl is the official CLI (command line interface) command-line tool.

[0113] Step 6050: If the application type is Java, use Kubectl to extract the application's JAR file and related dependent JAR files, generating startup.sh, shutdown.sh, service files, and env.conf. The JAR file and related dependent JAR files constitute the application package, while startup.sh, shutdown.sh, service files, and env.conf are executable file packages.

[0114] Step 6052: If the application type is Node, call Kubectl to extract the application's JS files, generating startup.sh, shutdown.sh, service files, and env.conf, and extract the executable file. The JS files constitute the application data package, while the startup script, shutdown script, service script, configuration information, and executable binary file constitute the executable file package.

[0115] Step 6054: If the application type is other types, call Kubectl to extract the application file and the executable file. The application file is the application data package, and the executable file is the executable file package.

[0116] Step 6056: Generate application data package;

[0117] Step 6058: Generate an executable file package;

[0118] The application data package and executable file package generated through steps 6048 to 6054 are passed as parameters to the next stage of application package creation.

[0119] The detailed design process is as follows:

[0120] like Figure 9 As shown, the steps to generate the application installation package include:

[0121] Step 702 triggers the RPM package creation process;

[0122] Step 704: Create the build RPM cache directory;

[0123] Step 706: Generate SPEC file;

[0124] Step 708: Determine if it depends on external software;

[0125] If dependent, proceed to step 710; otherwise, proceed to step 712, where external software includes Java, Node, Python, Go, PHP, Nginx, or Ruby, etc.

[0126] Step 710: Add the relevant software packages;

[0127] Add the relevant software packages to the source code package of the RPM package.

[0128] Step 712, import the executable file package;

[0129] The executable package is either x86 or AARCH.

[0130] Step 714, triggers the rpmbuild command;

[0131] Step 716: Determine if it is an x86 architecture;

[0132] If yes, proceed to step 718; otherwise, proceed to step 720.

[0133] Step 718, add X86 parameters;

[0134] Proceed to step 724.

[0135] Step 720: Determine if it is an AARCH architecture;

[0136] If yes, proceed to step 722; otherwise, determine it as another frame and proceed to step 724.

[0137] Step 722, add AARCH parameters;

[0138] Proceed to step 724.

[0139] Step 724, obtain the RPM package product;

[0140] The output of the rpmbuild command is the xxx.RPM application installation package.

[0141] Step 726: Send the application data packet to the specified path on the server;

[0142] Step 728, Install the RPM package;

[0143] Step 730: Launch the application.

[0144] This embodiment can solve the problem of automatically identifying or manually setting the target physical machine architecture when migrating from a cloud-native environment to a physical machine deployment. It can realize application compilation and RPM package creation across platform architectures, shield the impact of the underlying architecture, and deploy applications to the target physical machine server in a seamless manner.

[0145] For applications where software cannot be installed in offline environments, this embodiment incorporates many environment dependency plugins when creating the application RPM package. These plugins can be embedded into the application software, thus eliminating the need to install any other software. This solves the application dependency problem, greatly improves the integrity of the application, and provides a complete, runnable environment out of the box.

[0146] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0147] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the related technology, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0148] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. An application migration method, characterized in that, The migration involves extracting applications from the cloud-native environment and deploying them on domestically developed physical machines, removing dependencies on container technologies, including: Set up an application inventory; Parse the parameters in the application's manifest to determine the application type; Based on the application type, obtain the application data package and executable file package; Create a cache directory for the RPM package, generate a SPEC file template, and add the external software to the source code package of the RPM package if the application depends on external software. Import the executable file package, and based on the target system architecture, build an RPM package to obtain the application installation package; Send the application data package to the specified path on the server and install the application installation package; The list includes one or a combination of the following: Application name, application code, application port number, application server address, application type, application memory usage, application health check, application access to UpStream; Different list contents are set for different applications; The process of parsing the parameters in the application's manifest to determine the application type specifically includes: The parameters in the application manifest are passed in as parameters, and the parameters in the application manifest are parsed. Since the application is not a customized application, the first application type of the application is determined by the parameters in the application list; The application is detected by an application type detection command to obtain a second application type for the application; Based on the fact that the first application type is the same as the second application type, the application type of the application is determined to be the first application type; The step of obtaining the application data package and executable file package based on the application type specifically includes: When the application type is Tomcat, Kubectl is called to extract the application's WAR package and generate the Tomcat startup file and configuration information. The WAR package is an application data package, and the Tomcat startup file and configuration information are executable file packages. If the application type is Java, Kubectl is called to extract the application's JAR file and related dependent JAR files, and to generate a startup script, a shutdown script, a service script, and configuration information. The JAR file and related dependent JAR files are the application data package, and the startup script, shutdown script, service script, and configuration information are the executable file package. When the application type is Node, Kubectl is called to extract the application's js file, generating a startup script, a shutdown script, a service script, configuration information, and an executable binary file. The js file is the application data package, and the startup script, shutdown script, service script, configuration information, and executable binary file are the executable file package. If the application type is other types, call Kubectl to extract the application file of the application and generate an executable file, wherein the application file is the application data package and the executable file is the executable file package.

2. The application migration method according to claim 1, characterized in that, When the application depends on external software, adding the external software to the source code package of the RPM package specifically includes: Determine whether the application depends on external software including Java, Node, Python, Go, PHP, Nginx, or Ruby; If the application depends on Java, add the Java package to the source code package of the RPM package; If the application depends on Node, add the Node package to the source code package of the RPM package; If the application depends on Python, add the Python package to the source code package of the RPM package; If the application depends on Go, add the Go package to the source code package of the RPM package; If the application depends on PHP, add the PHP package to the source code package of the RPM package; If the application depends on Nginx, add the Nginx package to the source code package of the RPM package; If the application depends on Ruby, add the Ruby package to the source code package of the RPM package.

3. The application migration method according to claim 1, characterized in that, The process of constructing an RPM package based on the target system architecture to obtain the application installation package specifically includes: If the target system architecture is x86, add the x86 architecture parameter and construct the RPM package using instructions; If the target system architecture is AARCH, add AARCH architecture parameters and construct an RPM package using instructions; If the target system architecture is otherwise specified, an RPM package is constructed using instructions.

4. The application migration method according to claim 1, characterized in that, Also includes: After installing the application package, execute the application launch command to start the application.

5. An application migration device, characterized in that, The application migration apparatus implements the steps of the application migration method as described in any one of claims 1 to 4, and the application migration apparatus includes: The settings module is used to set the application list; The acquisition module is used to parse the parameters in the application manifest, determine the application type, and acquire the application data package and executable file package based on the application type; A module is created to create a cache directory for RPM packages, generate SPEC file templates, and add the external software to the source code package of the RPM package if the application depends on external software. The build module is used to import the executable file package, build an RPM package based on the target system architecture, and obtain the application installation package; The installation module is used to send the application data package to a specified path on the server and install the application installation package.

6. An electronic device, characterized in that, include: A memory that stores programs or instructions; A processor for implementing the steps of the application migration method as described in any one of claims 1 to 4 when executing the program or instructions.

7. A readable storage medium having a program or instructions stored thereon, characterized in that, When the program or instructions are executed by the processor, they implement the steps of the application migration method as described in any one of claims 1 to 4.

Images