Micro-service application cluster deployment method and device

Abstract

The invention discloses a micro-service application cluster deployment method and device. The namespaces are created according to the user names, environment isolation between the namespaces is guaranteed, mutual calling of applications in the namespaces is achieved, and joint debugging testing can be independently carried out in the namespaces. The configuration information of the business system or the middleware determined by the user is obtained, the configuration information comprises the deployment type, the template and the dynamically mounted configuration file, flexibility and high expansibility are guaranteed, no business intrusion exists, and no script modification is needed when the newly added code warehouse is accessed. And finally, acquiring a mirror image according to the configuration information, making a file package, and deploying the file package in the namespace. According to the method, based on the interactive interface, quick and flexible deployment can be carried out on medium-scale and large-scale multi-micro-service clusters.

Description

Technical Field

[0001] The present application relates to the technical field of microservice systems, and in particular to a method and device for deploying a microservice application cluster. Background Art

[0002] Microservices is an architectural style that can split a project into multiple independent services, and multiple services run independently, all of which will occupy threads. In software with complex business scale, the same business domain often includes multiple large-scale microservice applications, which involves a large number of developers and testers.

[0003] In the existing technology, during the development and testing process, technicians need to deploy microservice clusters consisting of different business systems, different modules, different middleware, different versions, and different configuration files, which will lead to a lot of duplication of work and time-consuming deployment. Therefore, how to quickly and flexibly deploy medium and large-scale multi-microservice clusters has become an urgent problem to be solved. Summary of the invention

[0004] Based on the above problems, the present application provides a method and device for deploying a microservice application cluster to quickly and flexibly deploy medium and large-scale multi-microservice clusters.

[0005] The present application discloses a method for deploying a microservice application cluster, the method comprising:

[0006] Obtain a user name, and create a namespace based on the user name;

[0007] Obtaining configuration information of the application to be deployed determined by the user; the configuration information includes a deployment type, a template, and a dynamically mounted configuration file; the deployment type includes a business system and middleware;

[0008] Obtaining an image according to the configuration information, and making a file package of the application to be deployed;

[0009] The file package is deployed in the namespace.

[0010] Optionally, the configuration information includes a warehouse group, a warehouse, a module, and a code, and the obtaining of the configuration information of the application to be deployed determined by the user includes:

[0011] Obtaining the user name;

[0012] Get a list of warehouse groups corresponding to the permissions of the user name;

[0013] Obtain the warehouse group selected by the user in the warehouse group list, and expand the warehouse list corresponding to the warehouse group;

[0014] Obtain the code repository selected by the user in the repository list;

[0015] When the code repository is a multi-module application, requesting the user to select a startable module under the multi-module application;

[0016] Get the tagged code in the code repository.

[0017] Optionally, the deployment type is middleware, and the obtaining of configuration information of the application to be deployed determined by the user includes:

[0018] Selecting a middleware to be deployed from the middlewares whose versions can be published in the image repository as the application to be deployed;

[0019] Copying and obtaining the template corresponding to the application to be deployed; the template includes declaring the size of the persistent storage volume, the storage location and the external access port;

[0020] Replace the namespace placeholder in the template with the username.

[0021] Optionally, the deployment type is a business system, and the obtaining of configuration information of the application to be deployed determined by the user includes:

[0022] Select the application to be deployed from the applications that can be published in the business warehouse;

[0023] Copying and obtaining the template corresponding to the application to be deployed; the template includes declaring the size of the persistent storage volume, the storage location and the external access port;

[0024] Replace the namespace placeholder in the template with the username.

[0025] Optionally, obtaining an image according to the configuration information and making a file package of the application to be deployed includes:

[0026] When the deployment type is a business system, the code is pulled, a jar package is made through the gradle application programming interface API, and the jar package is packaged into a docker image as the file package according to the configuration file;

[0027] When the deployment type is middleware, the Docker image of the middleware to be deployed is pulled as the file package.

[0028] Optionally, after replacing the namespace placeholder in the template with the user name, the method further includes:

[0029] The kafka address, redis address, and mysql address in the configuration file are replaced with preset addresses respectively, so that the application to be deployed in the namespace is registered with the target registration center.

[0030] Optionally, before obtaining the tagged code in the code repository, the method further includes:

[0031] When the tag code is empty, the user is supported to input a tag name for the code to be tagged, and the code to be tagged is tagged.

[0032] Optionally, the deploying the file package in the namespace includes:

[0033] The file package is transferred to the master node of the kubernetes cluster to execute the deployment of the application to be deployed.

[0034] Based on the above-mentioned method for deploying a microservice application cluster, the present application also discloses a device for deploying a microservice application cluster, including: a creation unit, a determination unit, a production unit and a deployment unit;

[0035] The creation unit is used to obtain a user name and create a namespace according to the user name;

[0036] The determination unit is used to obtain configuration information of the application to be deployed determined by the user; the configuration information includes a deployment type, a template, and a dynamically mounted configuration file; the deployment type includes a business system and middleware;

[0037] The production unit is used to obtain the image according to the configuration information and produce the file package of the application to be deployed;

[0038] The deployment unit is used to deploy the file package in the namespace.

[0039] Optionally, the configuration information includes a warehouse group, a warehouse, a module, and a code, and the determining unit includes:

[0040] A user name acquisition subunit, used to acquire the user name;

[0041] A warehouse group acquisition subunit, used to acquire a warehouse group list corresponding to the permissions of the user name;

[0042] A warehouse list acquisition subunit is used to acquire the warehouse group selected by the user in the warehouse group list, and expand the warehouse list corresponding to the warehouse group;

[0043] A repository acquisition subunit, used to acquire the code repository selected by the user in the repository list;

[0044] A module acquisition subunit, used for requesting the user to select a startable module under the multi-module application when the code repository is a multi-module application;

[0045] The code acquisition subunit is used to acquire the tagged code in the code repository.

[0046] Optionally, the deployment type is middleware, and the determining unit includes:

[0047] A middleware selection subunit, used to select a middleware to be deployed from the middleware of the releasable version in the image repository as the application to be deployed;

[0048] A template copying subunit, used to copy and obtain the template corresponding to the application to be deployed; the template includes a declaration of the persistent storage volume size, storage location and external access port;

[0049] The replacement subunit is used to replace the namespace placeholder in the template with the user name.

[0050] Optionally, the deployment type is a business system, and the determining unit includes:

[0051] An application acquisition subunit is used to select an application to be deployed from the publishable applications in the business warehouse;

[0052] A copy subunit, used to copy and obtain the template corresponding to the application to be deployed; the template includes a declaration of the persistent storage volume size, storage location and external access port;

[0053] The placeholder replacement subunit is used to replace the namespace placeholder in the template with the user name.

[0054] Optionally, the production unit includes:

[0055] A production subunit, used for pulling the code when the deployment type is a business system, producing a jar package through a gradle application programming interface API, and packaging the jar package into a docker image as the file package according to the configuration file;

[0056] The pulling subunit is used to pull the Docker image of the middleware to be deployed as the file package when the deployment type is middleware.

[0057] Optionally, the device is also used for:

[0058] The kafka address, redis address, and mysql address in the configuration file are replaced with preset addresses respectively, so that the application to be deployed in the namespace is registered with the target registration center.

[0059] Optionally, the device is also used for:

[0060] When the tag code is empty, the user is supported to input a tag name for the code to be tagged, and the code to be tagged is tagged.

[0061] Optionally, the deployment unit includes:

[0062] The handover subunit is used to hand over the file package to the master node of the kubernetes cluster to execute the deployment of the application to be deployed.

[0063] The present application discloses a method and device for deploying a microservice application cluster. Create a namespace based on the user name to ensure environmental isolation between namespaces, enable mutual calls between microservice applications in each namespace, and be able to independently perform joint debugging tests within the namespace. Obtain the configuration information of the business system or middleware determined by the user, including configuration information including deployment type, template, and dynamically mounted configuration files, to ensure flexibility, high scalability and no business intrusion, and no script modification is required when accessing a new code repository. Finally, obtain the image based on the configuration information, create a file package, and deploy the file package in the namespace. Based on the interactive interface, the present application can be quickly and flexibly deployed for medium and large-scale multi-microservice clusters. BRIEF DESCRIPTION OF THE DRAWINGS

[0064] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0065] Figure 1a A flowchart of a method for deploying a microservice application cluster disclosed in an embodiment of the present application;

[0066] Figure 1b A schematic diagram of obtaining a user name disclosed in an embodiment of the present application;

[0067] Figure 1c Obtain a schematic diagram for the deployment type disclosed in the embodiment of this application;

[0068] Figure 1d A schematic diagram of obtaining the code repository disclosed in the embodiment of the present application;

[0069] Figure 1e A schematic diagram of obtaining a module disclosed in an embodiment of the present application;

[0070] Figure 1f A schematic diagram of obtaining the labeling code disclosed in the embodiment of the present application;

[0071] Figure 1gA schematic diagram of obtaining a template disclosed in an embodiment of the present application;

[0072] Figure 2 A flowchart of another method for deploying a microservice application cluster disclosed in an embodiment of the present application;

[0073] Figure 3 A schematic diagram of the structure of a device for deploying a microservice application cluster disclosed in an embodiment of the present application. DETAILED DESCRIPTION

[0074] In the development life cycle of medium and large-scale commercial software, due to the huge business scale and complex rules, the same business domain usually includes a large number of microservice applications (referred to as applications in this application), which also involves a large number of development and test personnel. Each technician can deploy applications (such as spring microservice applications) on their own servers and share one or more sets of middleware (such as mysql, redis, kafka), resulting in the inability to completely isolate the environment and interfere with each other, increasing the difficulty of troubleshooting. At the same time, when testers deploy applications, developers continue to add code or configuration to the original code branches of the application, which will cause application deployment failure or version incompatibility, and then cause business logic errors. Taking the spring microservice application as an example, the configuration file spring application.yml is scattered on different servers, resulting in chaotic management.

[0075] In the traditional method, the container deployment solution based on Jenkins is difficult to solve the problems of rapid deployment, environmental isolation, flexible configuration, etc. of a large number of medium and large microservice clusters at the same time. The method described in this application can solve the above problems. It can support the simultaneous deployment of any number of microservice clusters and also support the deployment of middleware. And the employee ID of the developer / tester can be used to create a namespace to ensure that each namespace is independent and environmentally isolated, and each application can be registered in an independent namespace. In addition, the method described in this application can be based on the labeled code, make a jar package, mirror and deploy it in a container. Among them, the static attribute of the label makes the application unaffected by the newly submitted code of the code branch, thereby improving the stability and success rate of application deployment. At the same time, the configuration file is flexibly configured in a dynamic mounting manner, and the containerized deployment configuration file does not need to be added to the project. Compared with the jenkins-based release, which needs to continuously modify the jenkinsfile script as the business scale expands, this application does not need to make any code or script changes when adding a new code repository.

[0076] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0077] Embodiment 1: This application discloses a method for deploying a microservice application cluster.

[0078] For details, please refer to Figure 1a , a method for deploying a microservice application cluster disclosed in this embodiment includes the following steps:

[0079] Step 101: Obtain a user name, and create a namespace according to the user name.

[0080] The method described in this embodiment interacts with the user through a UI (User Interface). Figure 1b As shown, as an optional method, the user's username, i.e., id, can be obtained through the UI interface. A namespace named after the id is generated, i.e., an independent namespace belonging to the user. The username defaults to ns-login username.

[0081] Step 102: Obtain configuration information of the application to be deployed determined by the user.

[0082] The configuration information includes repository groups, repositories, modules, codes, deployment types, templates, and dynamically mounted configuration files. As an optional method, such as Figure 1c As shown, you can obtain the deployment type through the UI.

[0083] In the method described in this embodiment, a general process framework can be first defined to support flexible expansion when adding new microservices, and then the permissions of the id can be queried in the system (such as the gitlab code repository), and all code repository groups (which can be git code repositories) under the permission group corresponding to the id in the intranet can be pulled to form a code repository group list. Among them, when there is no "middleware" option in the code repository group list, the "middleware" option can be added to it.

[0084] In the method described in this embodiment, the user selects a repository group in the code repository group list, and then pulls all the repositories in the repository group according to the selected repository group to form a repository list. Figure 1d As shown in the figure, the code repository can be obtained through the UI interface. As an optional method, the system can filter out the code repositories that are allowed to be released according to preset rules for users to choose. Figure 1eAs shown, when the code repository is a multi-module spring application, all the startable spring starter modules under the spring application are further pulled to form a module list for the user to select. For example, a project contains several modules, of which 3 can be used for independent deployment. The method described in this embodiment will filter out the modules that can be deployed independently according to the user's selection, so that any module can be deployed separately, achieving minimized deployment and saving cluster resources.

[0085] In the method described in this embodiment, Figure 1f As shown, you can select the tag of the code through the UI interface to obtain the tagged code in the code repository. When the tag code is empty, you can click "Tag" in the code branch through the gradle application programming interface API, enter the tag name for the code to be tagged, and tag the code to be tagged in real time.

[0086] In the method described in this embodiment, when the deployment type is middleware, the middleware to be deployed can be selected from the middleware that can be released in the docker image repository, and according to the different middleware to be deployed, the kubernetes resource file template is copied to obtain the template corresponding to the application to be deployed. As an optional method, Figure 1g As shown, you can select templates based on different middleware through the UI interface. The kubernetes resource file template includes information such as the size of the persistent storage volume, storage location, and external access port. Then, replace the namespace placeholder in the template with the user name.

[0087] In the method described in this embodiment, when the deployment type is a business system, the application to be deployed can be selected from the applications that can be published in the spring business warehouse, that is, the gitlab warehouse. And copy the template corresponding to the application to be deployed. Then, replace the namespace placeholder in the template with the user name. At the same time, the user can choose to update the springapplication.yml configuration file, which will be dynamically mounted when the application is published.

[0088] In the method described in this embodiment, as an optional method, the kubernetes resource file template is divided into two categories: middleware template and business system template, both of which can be preset according to user needs.

[0089] Among them, there are three business system templates: a) Template 1-single node, fixed external IP, b) Template 2-single node, randomly assigned external IP, c) Template 3-dual node. The template placeholders are namespace, imageName, tag, port, nodePort, which can be dynamically replaced during application deployment. Among them, single node and dual node represent the number of replicas deployed. For example, the number of replicas configuration item in template a) is 1, corresponding to a single node. The number of replicas configuration item in template c) is 2, corresponding to dual nodes.

[0090] In the middleware, Kafka templates include: a) Template 1-kafka-single node, b) Template 2-kafka-3 node cluster. MySQL templates include: a) Template 1-mysql-single node, b) Template 2-mysql-1 master 1 slave cluster, c) Template 3-mysql-1 master 3 slave cluster. Redis templates include Template 1-redis-single node. In the above middleware templates, placeholders include: namespace, imageName, tag, port, nodePort, which can be selected according to user needs and can be dynamically replaced when the application is deployed.

[0091] As an optional method, the template can include the business system deployment template bizsystem and the middleware deployment template middleware. For example, in the business system, the template 1-single node-fixed external IP only contains four parameters {namespace}, {imageName}, {tag}, and {port}, which are dynamically replaced during deployment. Other templates (such as the kafka multi-cluster template) contain more customized parameters. When expanding, no matter how much the business system is expanded, the spring microservice template shares a set of templates, which makes it possible to expand the business without code modification, and achieve high flexibility, high scalability, and high efficiency deployment.

[0092] In the method described in this embodiment, application publishing is started based on the configuration information of one or more applications selected by the user in the above steps (including deployment type, warehouse group, warehouse, module, code (i.e., tagged code), template and configuration file).

[0093] In the method described in this embodiment, Figures 1b to 1g This is only a schematic diagram of the UI interface. In actual applications, the order and method of expanding the list can be set according to needs. Figures 1b to 1g The UI interface shown is specifically limited to support users to implement deployment in a selected manner.

[0094] Step 103: Obtain an image according to the configuration information, and create a file package of the application to be deployed.

[0095] In the method described in this embodiment, when the deployment type is a business system, the background service receives the request published by the application, pulls the git code, executes the gradle API to make a jar package, and makes a docker image as a file package according to the dynamically mounted springapplication.yml configuration file, and uploads it to the intranet image warehouse. Specifically, the configuration file in the yml format in the spring application configuration file directory is moved to the container working directory to support dynamic loading configuration, and then the image is packaged. Specifically, after replacing the configuration items in the configuration file, the configuration file is moved to the config directory under the container working directory, and the configuration items under the default config directory are used (that is, the default configuration items when java-jar starts the spring microservice). When there is no default configuration item, the configuration item in the business code is used. Correspondingly, the configuration file path can also be explicitly specified through java-jar--spring.config.location= / home / config / application.yml. At this time, the path of the configuration file is the only configuration file for the application to be deployed.

[0096] In the method described in this embodiment, when the deployment type is middleware, the docker image of the middleware to be deployed is directly pulled as a file package. Specifically, the configuration file in the specified directory ( / home / configs / business system name / module name / namespace / config / application.yml) on the server is loaded into the image according to the application name to be deployed, and it is made effective when it is started in the container, so that the cluster deployment is completed in the state of 0 business code intrusion, and the user can deploy the configuration items of the configuration file that can be dynamically changed.

[0097] In the method described in this embodiment, after making a docker image and uploading it to the intranet image warehouse, the local image corresponding to the image name: tag name can also be deleted, so as to prevent the server image from expanding and filling up the physical disk space. At the same time, the image server can also clean up outdated images through scheduled cleanup tasks. Among them, the scheduled cleanup task can configure the retention policy according to actual needs, such as retaining the artifact images pushed in the last 2 days, or retaining the most recent 20 artifacts images. In this embodiment, the retention policy of the scheduled cleanup task is not specifically limited, and the above method can be implemented.

[0098] In the method described in this embodiment, the kafka address, redis address, and mysql address in the spring application.yml configuration file can be replaced with preset addresses respectively, so that the configuration file dynamically points to the middleware deployed in the cluster, and the application to be deployed in the namespace is registered with the target registration center, that is, the same registration center (middleware system). In this way, the mutual calls of each application can be supported, ensuring that the application and the middleware in each namespace form a dependent closed loop without being affected by external factors. For example, when the application to be deployed needs to be registered with the middleware system in the cluster, the address can be replaced with xxx-service, where xxx is the name of the application to be deployed. For example, the kafka address, redis address, and mysql address are replaced with kafka-service, redis-service, and mysql-svc respectively. When the application to be deployed needs to be registered with an external service reachable by the network, the address can be replaced with an external address (ip: port number).

[0099] In the configuration items of the configuration file, kafka-service:xx refers to the kafka deployed in the same namespace of the microservice cluster. There is also a configuration item admin-addresses:http: / / xx, which indicates that the configuration points to an external registration address. host:redis-service uses the redis deployed in the cluster as the microservice registration address. Other configuration items are similar.

[0100] Step 104: deploy the file package in the namespace.

[0101] In the method described in this embodiment, according to the placeholder replaced in the kubernetes resource file template, the file package is transferred to the master node of the kubernetes cluster for deployment. As an optional method, the file package can be deployed again in the already deployed cluster. When there are already deployed applications in the cluster, the newly released application can overwrite the old application. Among them, the configuration items deployed again will replace the configuration items deployed last time. It should be noted that the external access port after redeployment must be consistent with the last deployment, otherwise each deployment operation must frequently change the port to access the service in the cluster. Specifically, the file package can be split into a Deployment resource file (including the declared image name, persistent storage volume size, storage location, pod container port and number of copies, etc.) and a Service resource file (including the name of the application to be deployed and the external access port). When redeploying, delete the Deployment resource file and do not operate the Service resource file, so that the external access port can be guaranteed to no longer change.

[0102] In the method described in this embodiment, for each deployed application, the cluster can provide a random externally accessible port for external systems to access. And in the kubernetes master node, the unlabeled docker images of all nodes can be cleaned up regularly at a preset frequency. When cluster resources need to be recycled, all resources in the entire namespace (including deployed applications and configuration information) can be recycled with one click through the kubernetes API. At the same time, the method described in this embodiment also supports one-click deployment of multiple applications. Specifically, you can enter the namespace and select multiple application tags at one time for deployment.

[0103] The method described in this embodiment dynamically generates an independent namespace according to the user ID, and supports one-click recovery and one-click deployment of namespace resources. The application is deployed in an independent development and joint debugging environment by replacing the template placeholder. Based on template replacement, a new business system can be added without any code or script modification, which is suitable for microservice application deployment in medium and large-scale clusters. It also supports single module release in multi-module spring applications. The method described in this embodiment also supports the release of server middleware such as mysql / redis / kafka, and supports single / batch deployment. The configuration file plug-in form enables the configuration file to be loaded when needed, which improves the flexibility and scalability of the application. Finally, the method described in this embodiment also supports permission control. Git code repository groups without permission to access and applications that are not allowed to be released cannot be deployed, thereby ensuring the security of application deployment.

[0104] Example 2: This application discloses another method for deploying a microservice application cluster. Figure 2 The method described in this embodiment introduces the entire process of microservice application deployment.

[0105] Step 201: Determine whether the user enters a user name. If yes, proceed to step 202. If no, keep the default user name and proceed to step 202.

[0106] Step 202: Get the deployment type selected by the user. If it is middleware, go to step 203. If it is a business system, go to step 204.

[0107] Step 203: Dynamically pull all versions of middleware in the Docker image repository and request the user to select.

[0108] Step 204: Dynamically pull all publishable applications in the business repository and request the user to select.

[0109] Step 205: Obtain the application to be deployed selected by the user, and request the user to select a template corresponding to the application to be deployed.

[0110] Step 206: Request the user to select a code tag, and dynamically pull the code with the code tag.

[0111] Step 207: Dynamically pull all modules that can be deployed independently in the Docker image repository / business repository.

[0112] Step 208: Request the user to select a port.

[0113] Step 209: A configuration file is formed according to the information selected by the user, and the application to be deployed is deployed in an independent space named after the user according to the configuration file.

[0114] Based on the method for deploying a microservice application cluster disclosed in the above embodiment, this embodiment correspondingly discloses a device for deploying a microservice application cluster. Figure 3 , the device for deploying a microservice application cluster includes: a creation unit 301, a determination unit 302, a production unit 303 and a deployment unit 304;

[0115] The creation unit 301 is used to obtain a user name and create a namespace according to the user name;

[0116] The determination unit 302 is used to obtain configuration information of the application to be deployed determined by the user; the configuration information includes a deployment type, a template, and a dynamically mounted configuration file; the deployment type includes a business system and a middleware;

[0117] The making unit 303 is used to obtain an image according to the configuration information and make a file package of the application to be deployed;

[0118] The deployment unit 304 is used to deploy the file package in the namespace.

[0119] Optionally, the configuration information includes a warehouse group, a warehouse, a module, and a code, and the determining unit 302 includes:

[0120] A user name acquisition subunit, used to acquire the user name;

[0121] A warehouse group acquisition subunit, used to acquire a warehouse group list corresponding to the permissions of the user name;

[0122] A warehouse list acquisition subunit is used to acquire the warehouse group selected by the user in the warehouse group list, and expand the warehouse list corresponding to the warehouse group;

[0123] A repository acquisition subunit, used to acquire the code repository selected by the user in the repository list;

[0124] A module acquisition subunit, used for requesting the user to select a startable module under the multi-module application when the code repository is a multi-module application;

[0125] The code acquisition subunit is used to acquire the tagged code in the code repository.

[0126] Optionally, the deployment type is middleware, and the determining unit 302 includes:

[0127] A middleware selection subunit, used to select a middleware to be deployed from the middleware of the releasable version in the image repository as the application to be deployed;

[0128] A template copying subunit, used to copy and obtain the template corresponding to the application to be deployed; the template includes a declaration of the persistent storage volume size, storage location and external access port;

[0129] The replacement subunit is used to replace the namespace placeholder in the template with the user name.

[0130] Optionally, the deployment type is a business system, and the determining unit 302 includes:

[0131] An application acquisition subunit is used to select an application to be deployed from the publishable applications in the business warehouse;

[0132] A copy subunit, used to copy and obtain the template corresponding to the application to be deployed; the template includes a declaration of the persistent storage volume size, storage location and external access port;

[0133] The placeholder replacement subunit is used to replace the namespace placeholder in the template with the user name.

[0134] Optionally, the making unit 303 includes:

[0135] A production subunit, used for pulling the code when the deployment type is a business system, producing a jar package through a gradle application programming interface API, and packaging the jar package into a docker image as the file package according to the configuration file;

[0136] The pulling subunit is used to pull the Docker image of the middleware to be deployed as the file package when the deployment type is middleware.

[0137] Optionally, the device is also used for:

[0138] The kafka address, redis address, and mysql address in the configuration file are replaced with preset addresses respectively, so that the application to be deployed in the namespace is registered with the target registration center.

[0139] Optionally, the device is also used for:

[0140] When the tag code is empty, the user is supported to input a tag name for the code to be tagged, and the code to be tagged is tagged.

[0141] Optionally, the deployment unit 304 includes:

[0142] The handover subunit is used to hand over the file package to the master node of the kubernetes cluster to execute the deployment of the application to be deployed.

[0143] The embodiments in this specification are described in a progressive manner. As for the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the methods.

[0144] It should also be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0145] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0146] The features described in the embodiments of this specification can be replaced or combined with each other, so that professional and technical personnel in this field can implement or use the present application.

[0147] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for deploying a microservice application cluster, characterized in that: include: Get a user name, and create a namespace based on the user name; Obtain the configuration information of the application to be deployed determined by the user; The configuration information includes deployment type, template and dynamically mounted configuration files; the deployment type includes business system and middleware; Obtaining an image according to the configuration information, and making a file package of the application to be deployed; The file package is deployed in the namespace.

2. The method according to claim 1, characterized in that The configuration information includes a warehouse group, a warehouse, a module, and a code. The obtaining of the configuration information of the application to be deployed determined by the user includes: Obtaining the user name; Get a list of warehouse groups corresponding to the permissions of the user name; Obtain the warehouse group selected by the user in the warehouse group list, and expand the warehouse list corresponding to the warehouse group; Obtain the code repository selected by the user in the repository list; When the code repository is a multi-module application, requesting the user to select a startable module under the multi-module application; Get the tagged code in the code repository.

3. The method according to claim 1, characterized in that The deployment type is middleware, and the obtaining of configuration information of the application to be deployed determined by the user includes: Selecting a middleware to be deployed from the middlewares whose versions can be published in the image repository as the application to be deployed; Copying and obtaining the template corresponding to the application to be deployed; the template includes declaring the size of the persistent storage volume, the storage location and the external access port; Replace the namespace placeholder in the template with the username.

4. The method according to claim 1, characterized in that: The deployment type is a business system, and the obtaining of configuration information of the application to be deployed determined by the user includes: Select the application to be deployed from the applications that can be published in the business warehouse; Copying and obtaining the template corresponding to the application to be deployed; the template includes declaring the size of the persistent storage volume, the storage location and the external access port; Replace the namespace placeholder in the template with the username.

5. The method according to claim 3 or 4, characterized in that: The step of obtaining an image according to the configuration information and making a file package of the application to be deployed includes: When the deployment type is a business system, the code is pulled, a jar package is made through the gradle application programming interface API, and the jar package is packaged into a docker image as the file package according to the configuration file; When the deployment type is middleware, the Docker image of the middleware to be deployed is pulled as the file package.

6. The method according to claim 3 or 4, characterized in that: After replacing the namespace placeholder in the template with the user name, the method further includes: The kafka address, redis address, and mysql address in the configuration file are replaced with preset addresses respectively, so that the application to be deployed in the namespace is registered with the target registration center.

7. The method according to claim 2, characterized in that Before obtaining the tagged code in the code repository, the method further includes: When the tag code is empty, the user is supported to input a tag name for the code to be tagged, and the code to be tagged is tagged.

8. The method according to claim 1, characterized in that The deploying the file package in the namespace includes: The file package is transferred to the master node of the kubernetes cluster to execute the deployment of the application to be deployed.

9. The method according to claim 8, characterized in that The kubernetes cluster has deployed applications, and the execution of the deployment of the application to be deployed includes: Split the file package into a Deployment resource file and a Service resource file; Delete the Deployment resource file in the deployed application file package, and keep the Service resource file in the deployed application file package unchanged to fix the external access port; Execute the deployment of the application to be deployed.

10. A device for deploying a microservice application cluster, characterized in that: include: Create units, identify units, make units, and deploy units; The creation unit is used to obtain a user name and create a namespace according to the user name; The determination unit is used to obtain configuration information of the application to be deployed determined by the user; the configuration information includes a deployment type, a template, and a dynamically mounted configuration file; the deployment type includes a business system and middleware; The production unit is used to obtain the image according to the configuration information and produce the file package of the application to be deployed; The deployment unit is used to deploy the file package in the namespace.

Images