Method and device for privatization deployment

What is AI technical title?
AI technical title is built by Patsnap AI team. It summarizes the technical point description of the patent document.
By using architecture declaration specifications to parse configuration files, and automatically generate privatized deployment products, it solves the problems of low efficiency and error-prone manual writing of deployment products in the existing technology, and achieves efficient and standardized privatized deployment.

CN113535188BActive Publication Date: 2025-02-21BEIJING WODONG TIANJUN INFORMATION TECH CO LTD +1

View PDF 2 Cites 0 Cited by

Patent Information

Application Number: CN202010295121.9
Authority / Receiving Office: CN · China
Patent Type: Patents(China)
Current Assignee / Owner
Filing Date: 2020-04-15
Publication Date: 2025-02-21
Estimated Expiration: 2040-04-15

AI Technical Summary

Technical Problem

In the prior art, privatized deployment requires manual writing of deployment products, which are inefficient, error-prone and instable.

Method used

Determine the configuration file of the application to be deployed through the preset architecture declaration specification, and parse the configuration file to automatically generate the deployment products required for the private deployment, including deployment scripts, Docker images and deployment documents.

Benefits of technology

It improves the efficiency and robustness of privatized deployment, realizes standardization of the deployment product writing style, and avoids inefficiency and errors caused by manual writing.

✦ Generated by Eureka AI based on patent content.

Smart Images

Figure CN113535188B_ABST

Patent Text Reader

Abstract

The present invention discloses a method and device for privatization deployment, and relates to the field of computer technology. A specific implementation of the method includes: determining a configuration file of an application to be deployed according to a preset architecture declaration specification; parsing the configuration file to generate a target deployment product; and privatizing and deploying the application to be deployed according to the target deployment product. This implementation can automatically generate the deployment product required for privatization deployment, avoid the shortcomings of the prior art caused by manually writing deployment products, improve the efficiency of privatization deployment, improve the robustness of privatization deployment, and achieve standardization of the deployment product writing style.

Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a method and device for privatization deployment. Background Art

[0002] Private deployment is to package the application's server, client, management backend, etc. into a solution and deliver it to the enterprise. Private deployment requires the preparation of many deployment products in advance, such as deployment scripts, Docker images, documents, system architecture diagrams, system dependency lists, FAQs, etc.

[0003] In the process of implementing the present invention, the inventors found that there are at least the following problems in the prior art:

[0004] Existing technologies are all manually written and deployed products, which are inefficient, error-prone, and not standardized enough. Summary of the invention

[0005] In view of this, an embodiment of the present invention provides a method and device for privatization deployment, which can automatically generate deployment products required for privatization deployment, avoid the shortcomings of the prior art caused by manually writing deployment products, improve the efficiency of privatization deployment, improve the robustness of privatization deployment, and achieve standardization of deployment product writing style.

[0006] To achieve the above object, according to one aspect of an embodiment of the present invention, a method for private deployment is provided, including:

[0007] Determine the configuration file of the application to be deployed according to the preset architecture declaration specification;

[0008] Parsing the configuration file to generate a target deployment product;

[0009] The to-be-deployed application is privately deployed according to the target deployment product.

[0010] Optionally, the architecture declaration specification includes: an application information template, a task configuration information template and an application description information template; the configuration file includes: application information, task configuration information and application description information of the application to be deployed.

[0011] Optionally, the target deployment product includes a deployment script, and the task configuration information includes configuration information of all tasks of each component in the application to be deployed;

[0012] Parse the configuration file to generate target deployment products, including:

[0013] For each component: generating a script file corresponding to each task in the component according to configuration information of all tasks of the component, and merging the script files corresponding to each task to obtain the script file of the component;

[0014] The script files of all components are merged to obtain the deployment script.

[0015] Optionally, the script file includes an installation script; the installation script corresponding to each task is generated according to the following steps:

[0016] An installation script is generated according to the component environment dependency field in the configuration information of the task, a code package script is generated according to the code package field in the configuration information of the task, and the installation script and the code package script are merged to obtain the installation script of the task.

[0017] Optionally, before merging the installation script with the code package script, the method further includes: confirming that no custom installation script exists in the task according to a custom script field in the configuration information of the task;

[0018] If a custom installation script exists in the task, the installation script, the code package script and the custom installation script are merged to obtain the installation script of the task.

[0019] Optionally, the script file includes a startup script; the startup script corresponding to each task is generated according to the following steps:

[0020] Determine the task type of the task according to the task type field in the configuration information of the task; the task type includes: static resource type, service type;

[0021] If the task type of the task is a static resource type, determine whether the component environment dependency field in the configuration information of the task is empty; if so, generate a startup script; otherwise, end the process;

[0022] If the task type of the task is a service type, the pre-startup script of the task is obtained according to the custom script field, a startup script fragment is generated, and the post-startup script of the task is obtained. The pre-startup script, the startup script fragment and the post-startup script are merged to obtain the startup script of the task.

[0023] Optionally, the target deployment product includes a Docker image, the application description information includes image configuration information of each image of the application to be deployed, and the image configuration information includes a task array of the image and description information of all tasks in the task array;

[0024] Parse the configuration file to generate target deployment products, including:

[0025] For each image: determining a task list of the image according to the task array of the image; generating an image file of each task in the task array according to the description information and configuration information of each task in the task array; merging the image files of each task in the task array to obtain an image file of the image;

[0026] Merge the image files of all images to obtain the Docker image of the application to be deployed.

[0027] Optionally, determining a task list of the image according to the task array of the image includes:

[0028] Determine whether the task array of the image is empty;

[0029] If so, arranging all tasks of each component in the application to be deployed according to the component environment dependency field in the configuration information of all tasks of each component in the application to be deployed, generating a task array of the image, and taking a list formed by all tasks in the task array as the task list;

[0030] Otherwise, a list formed by all tasks in the task array is used as the task list.

[0031] Optionally, the target deployment product includes a deployment document, the application description information includes installation document description information, precautions information, required software information, middleware information, fault handling information, and common problem information of the application to be deployed; the task configuration information includes document display information and task description information of all tasks of each component in the application to be deployed;

[0032] Parse the configuration file to generate target deployment products, including:

[0033] Generate a product introduction chapter of the application to be deployed according to the application information of the application to be deployed;

[0034] Generate a deployment process section of the application to be deployed according to the installation document description information;

[0035] Generate a precautions section for the application to be deployed according to the precautions information;

[0036] Generate a prerequisite software chapter for the application to be deployed according to the prerequisite software information;

[0037] Generate an installation preparation chapter for the application to be deployed according to the installation scaffolding script in the deployment engine;

[0038] Generate a document description of the initialization of the application to be deployed according to the middleware information, obtain the reverse proxy rules of the application to be deployed according to the document display information, obtain the deployment scripts of all tasks of each component in the application to be deployed, and obtain the document description of each task when installing according to the task description information of all tasks of each component in the application to be deployed or the task array of each image, so as to generate the installation chapter of the application to be deployed;

[0039] Generate a fault handling section of the application to be deployed according to the fault handling information;

[0040] Generate a frequently asked questions section for the application to be deployed according to the frequently asked questions information;

[0041] The product introduction section, the deployment process section, the precautions section, the required software section, the installation preparation section, the installation section, the troubleshooting section, and the FAQ section are combined to obtain a deployment document for the application to be deployed.

[0042] Optionally, the target deployment product includes a technical architecture diagram;

[0043] The configuration file is parsed to generate a target deployment product, including: generating a code snippet of the application to be deployed according to a format template of the deployment engine and the application description information, and rendering the code snippet to obtain the technical architecture diagram.

[0044] According to a second aspect of an embodiment of the present invention, a device for privatization deployment is provided, including:

[0045] The configuration module determines the configuration file of the application to be deployed according to the preset architecture declaration specification;

[0046] A generation module is used to parse the configuration file and generate a target deployment product;

[0047] A deployment module privatizes and deploys the to-be-deployed application according to the target deployment product.

[0048] Optionally, the architecture declaration specification includes: an application information template, a task configuration information template and an application description information template; the configuration file includes: application information, task configuration information and application description information of the application to be deployed.

[0049] Optionally, the target deployment product includes a deployment script, and the task configuration information includes configuration information of all tasks of each component in the application to be deployed;

[0050] The generation module parses the configuration file to generate a target deployment product, including:

[0051] For each component: generating a script file corresponding to each task in the component according to configuration information of all tasks of the component, and merging the script files corresponding to each task to obtain the script file of the component;

[0052] The script files of all components are merged to obtain the deployment script.

[0053] Optionally, the script file includes an installation script; the generation module is further used to generate the installation script corresponding to each task according to the following steps:

[0054] An installation script is generated according to the component environment dependency field in the configuration information of the task, a code package script is generated according to the code package field in the configuration information of the task, and the installation script and the code package script are merged to obtain the installation script of the task.

[0055] Optionally, the generating module is further used to: before merging the installation script with the code package script, confirm that there is no custom installation script in the task according to the custom script field in the configuration information of the task;

[0056] If a custom installation script exists in the task, the installation script, the code package script and the custom installation script are merged to obtain the installation script of the task.

[0057] Optionally, the generating module is further used to generate a startup script corresponding to each task according to the following steps:

[0058] Determine the task type of the task according to the task type field in the configuration information of the task; the task type includes: static resource type, service type;

[0059] If the task type of the task is a static resource type, determine whether the component environment dependency field in the configuration information of the task is empty; if so, generate a startup script; otherwise, end the process;

[0060] If the task type of the task is a service type, the pre-startup script of the task is obtained according to the custom script field, a startup script fragment is generated, and the post-startup script of the task is obtained. The pre-startup script, the startup script fragment and the post-startup script are merged to obtain the startup script of the task.

[0061] Optionally, the target deployment product includes a Docker image, the application description information includes image configuration information of each image of the application to be deployed, and the image configuration information includes a task array of the image and description information of all tasks in the task array;

[0062] The generation module parses the configuration file to generate a target deployment product, including:

[0063] For each image: determining a task list of the image according to the task array of the image; generating an image file of each task in the task array according to the description information and configuration information of each task in the task array; merging the image files of each task in the task array to obtain an image file of the image;

[0064] Merge the image files of all images to obtain the Docker image of the application to be deployed.

[0065] Optionally, the generating module determines the task list of the image according to the task array of the image, including:

[0066] Determine whether the task array of the image is empty;

[0067] If so, arranging all tasks of each component in the application to be deployed according to the component environment dependency field in the configuration information of all tasks of each component in the application to be deployed, generating a task array of the image, and taking a list formed by all tasks in the task array as the task list;

[0068] Otherwise, a list formed by all tasks in the task array is used as the task list.

[0069] Optionally, the target deployment product includes a deployment document, the application description information includes installation document description information, precautions information, required software information, middleware information, fault handling information, and common problem information of the application to be deployed; the task configuration information includes document display information and task description information of all tasks of each component in the application to be deployed;

[0070] The generation module parses the configuration file to generate a target deployment product, including:

[0071] Generate a product introduction chapter of the application to be deployed according to the application information of the application to be deployed;

[0072] Generate a deployment process section of the application to be deployed according to the installation document description information;

[0073] Generate a precautions section for the application to be deployed according to the precautions information;

[0074] Generate a prerequisite software chapter for the application to be deployed according to the prerequisite software information;

[0075] Generate an installation preparation chapter for the application to be deployed according to the installation scaffolding script in the deployment engine;

[0076] Generate a document description of the initialization of the application to be deployed according to the middleware information, obtain the reverse proxy rules of the application to be deployed according to the document display information, obtain the deployment scripts of all tasks of each component in the application to be deployed, and obtain the document description of each task when installing according to the task description information of all tasks of each component in the application to be deployed or the task array of each image, so as to generate the installation chapter of the application to be deployed;

[0077] Generate a fault handling section of the application to be deployed according to the fault handling information;

[0078] Generate a frequently asked questions section for the application to be deployed according to the frequently asked questions information;

[0079] The product introduction section, the deployment process section, the precautions section, the required software section, the installation preparation section, the installation section, the troubleshooting section, and the FAQ section are combined to obtain a deployment document for the application to be deployed.

[0080] Optionally, the target deployment product includes a technical architecture diagram;

[0081] The generation module parses the configuration file to generate a target deployment product, including: generating a code snippet of the application to be deployed according to a format template of the deployment engine and the application description information, and rendering the code snippet to obtain the technical architecture diagram.

[0082] According to a third aspect of an embodiment of the present invention, there is provided a privately deployed electronic device, including:

[0083] one or more processors;

[0084] a storage device for storing one or more programs,

[0085] When the one or more programs are executed by the one or more processors, the one or more processors implement the method provided in the first aspect of the embodiment of the present invention.

[0086] According to a fourth aspect of an embodiment of the present invention, a computer-readable medium is provided, on which a computer program is stored, and when the program is executed by a processor, the method provided by the first aspect of the embodiment of the present invention is implemented.

[0087] An embodiment of the above invention has the following advantages or beneficial effects: by determining the configuration file of the application to be deployed according to the preset architecture declaration specification and generating the target deployment product according to the configuration file, the deployment product required for private deployment can be automatically generated, thus avoiding the shortcomings of the prior art caused by manually writing deployment products, improving the efficiency of private deployment, and improving the robustness of private deployment. Since the configuration files of each application to be deployed can be determined according to the same architecture declaration specification, the standardization of the deployment product writing style can be achieved.

[0088] The further effects of the above-mentioned non-conventional optional manner will be described below in conjunction with the specific implementation manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0089] The accompanying drawings are used to better understand the present invention and do not constitute an improper limitation of the present invention.

[0090] Figure 1 It is a schematic diagram of the main process of the method for privatization deployment according to an embodiment of the present invention;

[0091] Figure 2 It is a schematic diagram of a flow chart of installation script generation in an optional embodiment of the present invention;

[0092] Figure 3 It is a schematic diagram of a process of starting script generation in an optional embodiment of the present invention;

[0093] Figure 4 It is a schematic diagram of the process of generating an image file of an image in an optional embodiment of the present invention;

[0094] Figure 5 It is a schematic diagram of main modules of a device for private deployment according to an embodiment of the present invention;

[0095] Figure 6 is a schematic diagram of the composition of a generation module in an optional embodiment of the present invention;

[0096] Figure 7 is an exemplary system architecture diagram to which embodiments of the present invention may be applied;

[0097] Figure 8 It is a schematic diagram of the structure of a computer system of a terminal device or a server suitable for implementing an embodiment of the present invention. DETAILED DESCRIPTION

[0098] The following is a description of exemplary embodiments of the present invention in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and conciseness, the description of well-known functions and structures is omitted in the following description.

[0099] According to one aspect of an embodiment of the present invention, a method for private deployment is provided.

[0100] Figure 1 Schematic diagram of the main process of the method for private deployment in an embodiment of the present invention. Figure 1 As shown, the method for private deployment includes: step S101, step S102 and step S103.

[0101] Step S101: Determine a configuration file of an application to be deployed according to a preset architecture declaration specification.

[0102] The architecture declaration specification is a set of general configuration rules that are abstractly defined based on the information required by each application during private deployment. It is used to describe what a microservice or component does, what dependencies it has, how it is configured, etc. The design principle of the architecture declaration specification is that convention is greater than configuration and industry best practices are actively adopted. The so-called convention is greater than configuration means that the content agreed upon in the architecture declaration specification is usually greater than the content of the configuration file of a single application. When performing private deployment, the deployment steps for different applications and programming languages are usually different, and the quality of deployment products such as deployment documents and scripts written by each person is also uneven. The embodiment of the present invention formulates the configuration file for each application according to the architecture declaration specification, which can achieve deployment standardization and apply industry best practices.

[0103] The specific content of the architecture declaration specification can be selectively set according to actual conditions. Optionally, the architecture declaration specification includes: an application information template, a task configuration information template, and an application description information template. The configuration file of the application to be deployed determined according to the preset architecture declaration specification includes: application information, task configuration information, and application description information of the application to be deployed.

[0104] An application product can be composed of multiple components. Components are the smallest units that actually make up an application and are used to divide tasks. Generally, the deployment of a component is implemented by only one task, or it may be implemented by multiple tasks. A component can be a microservice, a static resource file directory, a command line program, etc. Tasks can be used to deploy components.

[0105] The application information template is used to describe application information, including the application name, person in charge, contributors, application description, etc. Exemplarily, the architecture declaration specification includes the following content: name:erp; title:account system; owner:Xiaoming; contributors:Xiaogang, Xiaoliang; description:This system completes the xxxx function and has YYY features. In this example, name represents the system identifier, which is usually composed of lowercase letters and numbers; title represents the system name, such as the Chinese name of the system; owner represents who is responsible for the system; contributor represents the list of system developers, usually this parameter is the application description information including the image configuration information of each image of the application to be deployed; description represents the detailed description of the system, and this field can be used for document display.

[0106] The task configuration information template is used to describe the configuration instructions of each task (job). The fields included in the configuration instructions can be selectively set according to actual conditions. For example, the configuration instructions may include the following fields:

[0107] Title: Task name, such as Chinese name. Usually each task has a unique name, consisting of lowercase letters + numbers, but there are some reserved keywords that cannot be used for task names, such as config (configuration, generally to modify system configuration or settings).

[0108] type: task type, the parameter values are as follows: -service: service, such as API (calling interface), Web (web page), background tasks, etc.; -staticAsset: static resources, such as front-end static resources, program data directories, command line tools. This type generally does not require the launch of any scripts.

[0109] language: language type, used to indicate the programming language used to develop and deploy the product. For example, PHP (Hypertext Preprocessor), Go (a compiled language), C, C++, Java (an object-oriented programming language), Node.js (a JavaScript runtime environment based on the Chrome V8 engine), Ruby (an open source server-side scripting language for object-oriented programming), Python (an object-oriented dynamic type language), etc.

[0110] custom_script: used to describe user-defined scripts. For example, the custom_script:ins tall_post field indicates that a custom script is allowed to be executed after the default installation script is executed. The custom_script:start_pre field indicates that a custom script is allowed to be executed before starting the program. The custom_script:start field indicates a custom startup command. Generally, a custom startup command is not required, but some programs do. Among them, the custom_script:start:working_dir field indicates the working directory. Before executing the custom script, you need to enter this directory first. If the custom startup script can be executed directly with an absolute path, this parameter is optional; the custom_script:start:command field indicates the custom startup script path; the custom_script:start_post field indicates that a custom script is allowed to be executed after starting the program.

[0111] artifact: Code package field, used to describe information related to the code package. For example: artifact:source field indicates the package download address. artifact:destination field indicates the package storage directory, the default is / export / packages / system name / system name_job name / latest, this field is optional. If it is a compressed package, the package will be unzipped to this directory. artifact:canRecreateDestination field indicates whether the package storage directory can be rebuilt, the parameter can be bool (Boolean variable) type. The default value is true, in which case the directory destination will be deleted and then rebuilt to ensure that the directory is empty. When the value is false, it is suitable for storing files. The package storage directory will not be rebuilt, but the downloaded files will be moved into the directory.

[0112] network: Network policy. For example, the network:ingress:public field indicates the policy for traffic to enter from the public network. The network:ingress:public:ports field indicates which ports are exposed to the public network, such as TCP (Transmission Control Protocol), UDP (User Datagram Protocol), etc. For any port that needs to be exposed, a public domain name needs to be assigned to point to the service. This parameter is the application description information including the image configuration information of each image of the application to be deployed. The network:ingress:internal field indicates the policy for traffic to enter from the intranet. Among them, the network:ingress:internal:ports field indicates which ports are exposed in the intranet, such as TCP, UDP, etc. For any port that needs to be exposed, an intranet domain name needs to be assigned to point to the service. Some services are only used in the intranet and do not need to be exposed to the public network. The network:egress field indicates the network policy for going out. Among them, the network:egress:need_to_access_public field indicates whether it is necessary to access the public network, such as downloading resources from the public network, relying on packages, and requesting a certain interface of the public network. The parameter is of bool type.

[0113] docs: Parameters for document display. For example, the docs:external_access field indicates whether it is necessary to access through a browser / mobile phone. The parameter is of bool type. The docs:description field indicates a detailed description of the task, which will be displayed in the document deployed using the deployment script method, such as this service is used for XXXX. The docs:framework field indicates what framework the task is developed in, which is used for document display, such as Spring Boot (an application framework), Yii3 (a PHP framework), Gin (a web framework written in GO language), Koa (a web framework), etc. The docs:log field indicates the log path. Among them: the docs:log:start field indicates the startup log path, the docs:log:running field indicates the application log path list, this parameter is of array type, and can write the absolute path of files on multiple servers, the docs:log:running:path field indicates the application log path, and the docs:log:running:description field indicates the application log description, such as what the application is used for.

[0114] run: configuration related to running the program. For example, the run:schedule field indicates a scheduled task in Cron (a string expression) format. It is recommended that the task itself implement idempotence and concurrency control, otherwise the scheduled task cannot be run in multiple identical containers and can only be run in one container. The run:config_root_dir field indicates the root path of the configuration file. This field is optional, and the default value is related to the package type. If it is a compressed package, the configuration file is in the compressed package, and the root path is the decompressed directory of the compressed package, that is, artifact:destination. If it is a war package (a web application format), the configuration file is in the war package, and the file in the war package will be replaced according to the relative path. Some programs put the configuration file in the / etc directory, such as / etc / coredns / Corefile of CoreDNS (a DNS architecture). This parameter can be used to customize the root path. The run:u ser field indicates which user is used to run the program, and the default value is admin. The run:Java field indicates the configuration related to the Java program. For example, the run:Java:jar_path field indicates the path of the jar package (a platform-independent file format), which can be a relative path or an absolute path. If it is a relative path, it is the path relative to artifact:destination. For another example, the run:Java:jvm_options field indicates the jvm (Java Virtual Machine) configuration, and this parameter is the image configuration information of each image of the application to be deployed, including the application description information. For another example, the run:Java:jar_args field indicates the jar parameter, and this parameter is the image configuration information of each image of the application to be deployed, including the application description information. The run:python field indicates the Python program-related configuration. For example, the run:python:requirements_path field indicates the path of requirements.txt, which is a relative path. For another example, the run:python:use_uwsgi field indicates whether to use uwsgi to start the program. For another example, the run:python:uwsgi_options field indicates the uwsgi option, and this parameter is the application description information including the image configuration information of each image of the application to be deployed. The run:go field indicates the program-related field. For example, the run:go:binar y_path field indicates the binary program path, which is a relative path. For another example, the run:go:program_arguments field indicates a program parameter, and this parameter is the application description information including the image configuration information of each image of the application to be deployed.

[0115] dependencies: The environmental dependencies of a component. For example, the dependencies:nginx field indicates that the nginx vhost configuration file can be automatically generated. Among them, the dependencies:nginx:version field indicates the nginx version number; the dependencies:nginx:proxy_to_port field indicates which port the reverse proxy is to; the dependencies:nginx:enable_php_fpm field indicates whether to reverse proxy to PHPFPM (a PHPFast CGI manager) through the FCGI (a data transmission and reception protocol) protocol and generate related configurations for PHP applications; the dependencies:nginx:always_serve_index_html field indicates that the serve_index_html service is provided for a certain query, which is suitable for the front-end history mode (history mode); the dependencies:nginx:root field indicates the ROOT (an nginx file path) configuration that nginx listens to; the dependencies:nginx:locati on field indicates the address that nginx listens to, and this value is a map (a container) structure. The dependencies:router field indicates that an external load balancer is to be used to configure a reverse proxy. This parameter is the application description information, including the image configuration information of each image of the application to be deployed, which is used for document display. Among them, the dependencies:router:path field indicates the request path; the dependencies:router:url field indicates which address to forward to. The dependencies:rpm field indicates which rpm packages are dependent, and the parameter is an array type. If the value has a groupinstall: prefix, it means that the package is installed using the yum groupinstall command, and yuminstall is used for installation by default. The dependencies:cent_os field indicates the dependent CentOS (Community Enterprise Operating System, Community Enterprise Operating System) version. The dependencies:Java field indicates the dependent JDK (Java Development Kit, a software tool for Java programming) version. The dependencies:python field indicates the dependent Python version. The dependencies:php field indicates the dependent PHP version. The dependencies:go field indicates the dependent Go version.The dependencies:nodejs field indicates the dependent Node.js version. The dependencies:ruby field indicates the dependent ruby version. The dependencies:webapp_runner field indicates the dependent web app_runner. The dependencies:git field indicates the dependent git (an open source distributed version control system) version.

[0116] The above fields are examples of task configuration instructions, and do not mean that all tasks must have the above fields. In actual application, the above fields can be added, deleted, or modified according to actual needs.

[0117] The application description information template is used to describe other description information of the application, such as technical architecture diagram, middleware, Docker (an open source application container engine) configuration (image configuration information), etc.

[0118] Exemplarily, the application description information template includes the following fields:

[0119] miscellaneous:system_landscape: system architecture field. For example, the miscellaneous:system_landscape:diagram field indicates the address of the technical architecture panoramic diagram image, which is used for document display. This field is optional. The miscellaneous:system_landscape:person field indicates the role, such as application developer, etc. When rendering the architecture diagram, the operation entrances of different roles can be displayed. The miscellaneous:system_landscape:person_ext field indicates external roles, such as operators, testers, etc. The miscellaneous:system_landscape:system_ext field indicates external systems, such as account systems, unified consoles, GitLab (an open source project for warehouse management systems), Jenkins (a continuous integration tool developed based on Java), etc. The miscellaneous:system_landscape:boundary field indicates the boundary. Several components (services, command lines, etc.) can be divided into a range. Multiple ranges can be defined. The parameters are the application description information including the image configuration information of each image of the application to be deployed. Among them, the miscellaneous:system_landscape:boundary:label field indicates the boundary name. The architecture diagram can be divided into several logical parts according to the function. The label is used to name this logical part. The miscellaneous:system_landscape:boundary:container field indicates the container. A container can be considered as a microservice / component. The parameter is of map type. The key is the container ID, and the value is in the format of "container name: technical parameters: one sentence introduction". The miscellaneous:system_landscape:relationship field indicates the relationship description. Separated by semicolons, the full format is id1:id2:relationship description:communication protocol:arrow direction. The arrow direction is downward by default, and can also be set to upward, left, right, etc. Communication protocol and arrow direction are optional.

[0120] miscellaneous:depends_on: application-level dependencies, such as external systems, middleware, etc. For example, the miscellaneous:depends_on:description field indicates a description, which is used for document display and supports markdown. The miscellaneous:depends_on:initialize field indicates how to initialize the middleware data of the application, such as creating a table and inserting data in MySQL (a relational database management system), creating a topic (topic) in Kafka (an open source stream processing platform), etc., which is used for document display. The miscellaneous:depends_on:mysql field indicates MySQL-related information. Among them, the miscellaneous:depends_on:mysql:version field indicates the MySQL version used; the miscellaneous:depends_on:mysql:db_name field indicates how many MySQL databases are to be created, and the parameter is an array type. The miscellaneous:depends_on:elasticsearch field indicates elasticsearch-related information. For example, the miscellaneous:depends_on:elasticsearch:version field indicates the elasticsearch version used, which is used for document display. The miscellaneous:depends_on:hbase field indicates information related to HBase (a distributed, column-oriented open source database). The miscellaneous:depends_on:hbase:version field indicates the HBase version used, which is used for document display. The miscellaneous:depends_on:kafka field indicates information related to Kafka. Among them, the miscellaneous:depends_on:kafka:version field indicates the Kafka version used, which is used for document display; the miscellaneous:depends_on:kafka:create_topics field indicates the list of topics to be created, and the topics are separated by commas, such as Topic1:1:3,Topic2:2:1:compact. This configuration means creating two topics, where Topic1 uses 1 partition and 2 replicas, and Topic2 uses 2 partitions and 1 replica, and cleanup.policy is set to compact.The miscellaneous:depends_on:amazon_s3 field indicates object storage related information. Among them, the miscellaneous:depends_on:amazon_s3:buckets field indicates how many buckets are required, the miscellaneous:depends_on:amazon_s3:buckets:name field indicates the name of the bucket, and the miscellaneous:depends_on:amazon_s3:buckets:canned_acl field indicates setting the anonymous user access rights of the bucket, where private is private read and write, public-read is public read and private write, and public-read-write is public read and write. The miscellaneous:depends_on:storm field indicates Storm (a distributed real-time big data processing framework) related information. For example, the miscellaneous:depends_on:storm:version field indicates the Storm version. The miscellaneous:depends_on:flink field indicates Flink (an open source processing engine for batch and stream data). For example, the miscellaneous:depends_on:flink:version field indicates the Flink version. The miscellaneous:depends_on:redis field indicates information related to Redis (a key-value storage system), such as the miscellaneous:depends_on:redis:version field indicates the Redis version. The miscellaneous:depends_on:gitlab field indicates information related to GitLab.For example, the miscellaneous:depends_on:gitlab:version field indicates the GitLab version, the miscellaneous:depends_on:gitlab:account field indicates that a GitLab account needs to be registered, the miscellaneous:depends_on:gitlab:account:username field indicates the username, the miscellaneous:depends_on:gitlab:account:password field indicates the password, the miscellaneous:depends_on:gitlab:account:description field indicates the description, and the miscellaneous:de pends_on:gitlab:account:access_level field indicates the access level, which usually has two options: regular and admin. The miscellaneous:depends_on:nexus_repository_oss field indicates information related to Nexus Repository OSS (an open source project that publishes Java libraries to a central library), for example, the miscellaneous:depends_on:nexus_repository_oss:version field indicates the Nexus Repository OSS version. The miscellaneous:depends_on:zoo_keeper field indicates information related to ZooKeeper (a distributed, open source distributed application coordination service), such as the miscellaneous:depends_on:zoo_keeper:version field indicates the ZooKeeper version number, the miscellaneous:depends_on:zoo_keeper:create_znodes field indicates the creation of nodes, the miscellaneous:depends_on:zoo_keeper:create_znodes:path field indicates the node path, and the miscellaneous:depends_on:zoo_keeper:create_znodes:value field indicates the value of the node. The miscellaneous:depends_on:api_gateway field indicates information related to the API gateway, such as the miscellaneous:depends_on:api_gateway:version field indicates the version number.The miscellaneous:depends_on:rpc_framework field indicates information related to the RPC (Remote Procedure Call Protocol) remote call framework, such as the miscellaneous:depends_on:rpc_framework:version field is the version number of the RPC remote call framework, the miscellaneous:depends_on:rpc_framework:services field is the RPC interface to be registered, the miscellaneous:depends_on:rpc_framework:services:name field is the interface name, and the miscellaneous:depends_on:rpc_framework:services:description field indicates the interface description.

[0121] miscellaneous:unified_config_reference: Application unified configuration reference document field, used for document display, the parameter is an array type. This parameter indicates how to configure the configuration items required by the application in the application unified configuration file. For example, the miscellaneous:unified_config_reference:name field indicates the configuration item name. The miscellaneous:unified_config_reference:type field indicates the configuration value type, such as string, bool, number, etc. The miscellaneous:unified_config_reference:default field indicates the default value of the configuration. The miscellaneous:unified_config_reference:example field indicates a configuration example. The miscellaneous:unified_config_reference:description field indicates the introduction of the configuration item.

[0122] miscellaneous:docker: Image configuration information field, indicating Docker-related configuration information. For example, the miscellaneous:docker:group field indicates how the various components of the system are arranged into the image, which images there will be, which components are included in the image, etc. This parameter is an array type. Among them, the miscellaneous:docker:group:name field indicates the image name; the miscellaneous:docker:group:from field indicates which image the image inherits from, and sets the FROM keyword of Dockerfile; the miscellaneous:docker:group:docs_k8s field indicates the document for installing the image in the Kubernetes environment (an open source, containerized application for managing multiple hosts in the cloud platform); the miscellaneous:docker:group:docs_compose field indicates the document for installing the image in the Docker-compose environment (a Docker tool for defining and running complex applications); the miscellaneous:docker:group:component field indicates which jobs the image is composed of, and these jobs will be compiled into the same image.

[0123] miscellaneous:docs: document-related fields, indicating document-related information. For example, the miscellaneous:docs:install_process field indicates the installation process document description, and the parameter is of array type. The miscellaneous:docs:install_process:name field indicates the task name; the miscellaneous:docs:install_process:description field indicates the task description; the miscellaneous:docs:install_process:tag field indicates that the tag can be used to distinguish which deployment methods this process needs to be done in. The parameter is an enumeration type, and the values are of the following types: Kubernetes deployment method, Docker-compose deployment method, and deployment script method. The miscellaneous:docs:attention field indicates precautions, and the parameter is of array type. The miscellaneous:docs:essential_software field indicates essential software, and the parameter is of array type. The miscellaneous:docs:essential_software:name field indicates the software name, the miscellaneous:docs:essential_software:description field indicates the software description, the miscellaneous:docs:essential_software:how_to_get field indicates the software acquisition method, and the miscellaneous:docs:essential_software:tag field indicates that the software can be distinguished in which deployment methods according to the tag. The parameter is an enumeration type, and the value has the following types: Kubernetes deployment method, Docker-compose deployment method, and deployment script method. The miscellaneous:docs:trou bleshoot field indicates troubleshooting, how to deal with common installation problems, and the parameter is an array type. Among them, the miscellaneous:docs:troubleshoot:title field indicates the problem title; the miscellaneous:docs:troubleshoot:answer field indicates the answer, which can include a description of the phenomenon and the steps to solve the problem; the miscellaneous:docs:troubleshoot:possible_cau ses field indicates the possible cause of the problem.The miscellaneous:docs:faq field indicates frequently asked questions, which can answer common non-fault questions of the application. The parameter is an array type. Among them, the miscellaneous:docs:faq:question_title field indicates the question title; the miscellaneous:docs:faq:question_body field indicates the question description; and the miscellaneous:docs:faq:answer field indicates the answer to the question.

[0124] The above fields are exemplary descriptions of application description information, and do not mean that application description information of all applications must have the above fields. In actual application, the above fields can be added, deleted, or modified according to actual needs.

[0125] Step S102: Parse the configuration file to generate a target deployment product.

[0126] According to the output type of the configuration file and the target deployment product, different data processing logics can be applied to parse the configuration file and automatically generate the target deployment product of the corresponding output type, thereby avoiding the deficiencies in the prior art caused by manually writing deployment products, improving the efficiency of private deployment, and avoiding the problem of low robustness of private deployment caused by error-prone manual writing.

[0127] Optionally, the target deployment product includes a deployment script, and the task configuration information includes the configuration information of all tasks of each component in the application to be deployed. The configuration information is used to generate a script file for the task. Generally, the configuration information describes all tasks included in the task, the dependencies between the tasks, and related information. The configuration file is parsed to generate the target deployment product, including: for each component: generating a script file corresponding to each task in the component according to the configuration information of all tasks of the component, merging the script files corresponding to each task to obtain the script file of the component; merging the script files of all components to obtain the deployment script. By automatically generating a deployment script, it is possible to avoid the deficiencies in the prior art caused by the use of manually written deployment products, improve the efficiency of private deployment, and avoid the problem of low robustness of private deployment caused by error-prone manual writing.

[0128] exist Figure 2In the optional embodiment shown, the script file includes an installation script. The installation script corresponding to each task is generated according to the following steps: step S201, generating an installation script according to the component environment dependency field in the configuration information of the task; step S202, generating a code package script according to the code package field in the configuration information of the task; step S203, merging the installation script and the code package script to obtain the installation script of the task. This embodiment can automatically generate a script. Furthermore, before merging the installation script and the code package script, it can also include: confirming that there is no custom installation script in the task according to the custom script field in the configuration information of the task. If there is a custom installation script in the task, the installation script, the code package script and the custom installation script are merged to obtain the installation script of the task. This embodiment can generate an installation script for a task based on a user-defined installation script, meet the installation requirements of special applications, and achieve personalized settings.

[0129] Exemplarily, the process of automatically generating the installation script for each task is as follows:

[0130] (1) The engine reads the dependencies:nginx field of the task. The nginx field is divided into two types of information: one is used by the engine to generate the nginx vhost configuration file, and the other is used to determine which version of nginx is installed. Read dependencies:nginx:version to get the nginx version that the application depends on, and output the script for installing the specified nginx to the memory, which is recorded as script fragment 1; read dependencies:nginx:proxy_to_port field to know that the nginx reverse proxy script needs to be generated and which port the component listens to; read dependencies:nginx:enable_php_fpm to know that nginx needs to communicate with php_fpm; read dependencies:nginx:always_serve_index_html to know that all non-existent URL requests need to be redirected to index.html; read dependencies:nginx:root to know how to configure the nginx root directive; read dependencies:nginx:location to know how to configure the nginx location directive. If nginx location is not configured, the engine will generate a default configuration. Based on the engine's built-in nginx configuration file template and various conditional judgments, the nginx configuration file generation script is output to the memory, which is recorded as script fragment 2;

[0131] (2) The engine reads the dependencies:rpm field. The value of this field is an array type, which represents the list of rpm packages that the component depends on. The array is traversed. If the value of the array element has the prefix groupinstall:, yumgroupinstall is called to install the yum package. Otherwise, yum install is used to install it. The engine outputs the generated rpm package installation script to the memory, which is recorded as script fragment 3.

[0132] (3) The engine reads the other fields under the dependencies field in sequence, and the processing logic is similar to the above logic. It uses the built-in script template or command to generate a script for installing the specified dependency version and outputs it to the memory, which is recorded as script fragment 4;

[0133] (4) The engine reads the artifact field to know the code package download address and installation location, and generates a script based on the engine's built-in bash script template and outputs it to the memory, which is recorded as script fragment 5. The template uses wget to download the package, uses the arc tool to decompress the compressed package, uses the bash statement written by itself to verify whether the package download is complete (md5 verification, the md5 information will be obtained from the package download address through the HEAD (an http request method) method of the http request), and moves the downloaded package to the default or specified installation directory;

[0134] (5) The engine reads the customscript:installpost field and obtains the installation script customized by the application developer. This installation script will be executed after the script generated by the engine to meet the installation requirements of the special application. This customized installation script is recorded as script fragment 6;

[0135] (6) The engine merges the above scripts 1-6 and outputs them into a file to obtain the installation script.

[0136] exist Figure 3 In the optional embodiment shown, the script file includes a startup script. The startup script corresponding to each task is generated according to the following steps:

[0137] Step S301: determining the task type of the task according to the task type field in the configuration information of the task; the task type includes: static resource type, service type;

[0138] Step S302, determine whether the task type is a static resource type; if so, jump to step S303; otherwise, jump to step S305;

[0139] Step S303, determine whether the component environment dependency field in the configuration information of the task is empty; if so, jump to step S304 to generate a startup script; otherwise, end the process;

[0140] Step S305, according to the custom script field, obtain the pre-startup script of the task, generate a startup script fragment, obtain the post-startup script of the task, and merge the pre-startup script, the startup script fragment and the post-startup script to obtain the startup script of the task. This embodiment can automatically generate a startup script.

[0141] Exemplarily, the method for automatically generating the startup script corresponding to each task is as follows:

[0142] (1) Read the type field in the job description. This field has two values: staticAsset (static resource file) and service (API, website, background task);

[0143] (2) If the task type is staticAsset, the engine reads the dependencies:ng inx:version field to determine whether nginx needs to be started. If there is a version number, ngin x is started. Otherwise, since static resource file types are generally used to download files or display static websites, nothing can be done at this time.

[0144] (3) If the task type is service type, the engine reads the customscript:startpre field, obtains the pre-start script customized by the application developer, and outputs it to the memory, which is recorded as script fragment 1;

[0145] (4) If the task type is service type, read the run:user field to know which user to use to run the program. By default, admin is used (to comply with security practices, do not use root to run the program);

[0146] (5) If the task type is service type, read the custom_script:start field to obtain the startup script customized by the application developer (some components can only use their own startup scripts and cannot be automatically generated). The engine outputs the script to the memory and records it as script fragment 2-a;

[0147] (6) If the task type is service type and the custom_script:start field is empty, read the language field to obtain the programming language type of the component. If it is Java language, read run:Java:jvm_options and run:Java:jar_args to obtain the jvm setting parameters and Java startup parameters. Usually Java programs only have two package formats: .war and .jar. Read the artifact:source field and analyze the file extension type from the download link. If it is .war, generate a script to start the war package with webapprunner, eliminating the tedious steps of installing tomcat to start the program. The script will be output to the memory, recorded as script fragment 2-b; in other cases, it is a .jar package. If the code package is a compressed package, read run:Java:jar_path, and the file path of the jar package can be obtained from the storage directory after the code package is unzipped according to jar_path. Then generate a script to start the jar package through Java, and the engine will output the script to the memory, recorded as script fragment 2-b; read the dependencies:nginx:version field to determine whether nginx needs to be started. If there is a version number, start nginx and output the script to start nginx to the memory, recorded as script fragment 2-c. If it is python, Go, Node.js, and Ruby, similar logic is used. The engine only reads the most basic and necessary fields, and provides an out-of-the-box startup script generation experience through a large number of templates, command line tools, and best practices;

[0148] (7) If the task type is service type, read the customscript:startpost field to obtain the post-startup script customized by the application developer, output it to the memory, and record it as script fragment 3;

[0149] (8) The engine merges the above scripts 1-3 and outputs them into a file to obtain a startup script.

[0150] According to the best practices of Docker images: Do not run too many programs in a Docker image at the same time, so an application may have multiple images. By default, all components are in one image. Optionally, the target deployment product includes a Docker image, and the application description information includes the image configuration information of each image of the application to be deployed, and the image configuration information includes the task array of the image and the description information of all tasks in the task array. Parsing the configuration file to generate the target deployment product includes: using Figure 4The method shown generates an image file for each image, and then merges the image files of all images to obtain the Docker image of the application to be deployed. Figure 4 As shown, for each image, the steps of generating the corresponding image file are as follows: step S401, determining the task list of the image according to the task array of the image; step S402, generating the image file of each task in the task array according to the description information and configuration information of each task in the task array; step S403, merging the image files of each task in the task array to obtain the image file of the image. This embodiment can automatically generate a Docker image of an application to be deployed.

[0151] Optionally, determining the task list of the image according to the task array of the image includes: determining whether the task array of the image is empty; if so, arranging all tasks of each component in the application to be deployed according to the component environment dependency field in the configuration information of all tasks of each component in the application to be deployed, generating the task array of the image, and taking the list formed by all tasks in the task array as the task list; otherwise, taking the list formed by all tasks in the task array as the task list. In this way, the problem of being unable to generate the Docker image of the application to be deployed due to the empty task array in the configuration file can be avoided.

[0152] For example, after the installation script and the startup script are obtained by the aforementioned method, the following logic is used to generate a Docker image of the application to be deployed:

[0153] (1) The engine reads the config:docker:group field, the value of which is an array type. If group is not an empty array, the array is traversed. The array element contains multiple fields, among which the name field represents the image name. The from field is assigned to the FROM instruction of the image file Dockerfile. If the from field does not specify which image the current image is integrated from, the engine automatically generates one. The logic is: read the dependencies field, analyze the software versions that the job depends on, arrange the names of these dependencies in alphabetical order, add the corresponding versions, and generate the image in the from field. The image can use a name in the structure of base:Java-8-nodejs-12.1. The component field is an array type, which is used to describe which jobs the image consists of. The installation scripts and startup scripts of these jobs will be applied when generating the image;

[0154] (2) If group is an empty array, it means that all components are allowed to be in one Docker image. In this case, the engine will generate an array element of group named omnibus, and the component field contains all job names.

[0155] (3) The engine traverses the list of image names to be generated, and generates an image for each image through the image generation module. The following job list refers to the job list corresponding to a certain image. The image generation logic is: the engine uses the built-in dockerfile template to generate the dockerfile. The template contains scripts for setting the time zone and optimizing core parameters. Through the above step (2), the engine traverses the job list and uses the COPY and RUN instructions in the Dockerfile reference document to generate the execution command of the job installation script, and outputs the content to the memory, which is recorded as code snippet 1; the engine traverses the job list and determines whether there are php and nginx fields in the dependencies field in the job definition. If so, it outputs the corresponding startup script to the memory, which is recorded as code snippet 2-a; the engine traverses the job list and uses the command line tool replaced by the configuration file to export the script from / export / servers / env / doc Get the bash script that replaces the path corresponding to the directory where the package is stored in the configuration file in the ker directory, and output the replacement result to the memory, which is recorded as code snippet 2-b; the engine traverses the job list, reads the docs:log field, and obtains all log paths. The engine obtains the directory name from the path. Because the application component may not automatically create the log directory, the engine generates a script to create these directories and outputs it to the memory, which is recorded as code snippet 2-c; the engine traverses the job list and outputs the job startup script to the memory, which is recorded as code snippet 2-d; the engine merges code snippets 2-a to 2-d and outputs them to the file to obtain docker-entrypoint.sh. The engine uses the COPY and CMD instructions in the Dockerfile reference document to generate the execution command of docker-entrypoint.sh, which is recorded as code snippet 3. The engine merges code snippets 1 and 3 and outputs them to the file to obtain the Dockerfile of the image;

[0156] (4) When compiling an image, you need to ensure that the image corresponding to the FROM keyword in the Dockerfile exists. If the image is customized by the application developer, the application developer needs to first upload the image to the specified image repository, and the engine will pull the image when compiling the image. If the application developer does not specify the from field in the config:docker:group array element, the engine will analyze the from name automatically generated in step (1) above, and based on the base image base:zero, call the corresponding installation script to compile the image file corresponding to from;

[0157] (5) The engine traverses the list of image names to be generated, processes each image in turn, calls the docker build command, passes the image's Dockerfile path and image name, and obtains the Docker image of the application to be deployed.

[0158] Optionally, the target deployment product includes a deployment document, the application description information includes installation document description information, precautions information, required software information, middleware information, fault handling information, and common problem information of the application to be deployed; the task configuration information includes document display information and task description information of all tasks of each component in the application to be deployed. Parsing the configuration file to generate the target deployment product includes:

[0159] Generate a product introduction chapter of the application to be deployed according to the application information of the application to be deployed;

[0160] Generate a deployment process section of the application to be deployed according to the installation document description information;

[0161] Generate a precautions section for the application to be deployed according to the precautions information;

[0162] Generate a prerequisite software chapter for the application to be deployed according to the prerequisite software information;

[0163] Generate an installation preparation chapter for the application to be deployed according to the installation scaffolding script in the deployment engine;

[0164] Generate a document description of the initialization of the application to be deployed according to the middleware information, obtain the reverse proxy rules of the application to be deployed according to the document display information, obtain the deployment scripts of all tasks of each component in the application to be deployed, and obtain the document description of each task when installing according to the task description information of all tasks of each component in the application to be deployed or the task array of each image, so as to generate the installation chapter of the application to be deployed;

[0165] Generate a fault handling section of the application to be deployed according to the fault handling information;

[0166] Generate a frequently asked questions section for the application to be deployed according to the frequently asked questions information;

[0167] The product introduction section, the deployment process section, the precautions section, the required software section, the installation preparation section, the installation section, the troubleshooting section, and the FAQ section are combined to obtain a deployment document for the application to be deployed.

[0168] Exemplarily, the steps for generating a deployment document are as follows:

[0169] (1) The engine reads the description field in the application information section of the configuration file, which is used to display the application description information. The engine outputs the read information to the memory and records it as document fragment 1, which is used as the product introduction chapter;

[0170] (2) The engine reads the miscellaneous:docs:install_process field and generates a deployment process chapter. This field is of array type, and the array elements consist of multiple fields. The tag field in the array element that contains script will be regarded by the engine as the process required by the current deployment method. The engine traverses the array, generates a process description in a tabular form according to the markdown table syntax, and then generates a process description in a chart form according to the flowchart.js syntax, and outputs the generated content to the memory, recorded as document fragment 2, which is used as the installation process chapter;

[0171] (3) The engine reads the miscellaneous:docs:attention field, traverses the array, and outputs the contents to the memory in sequence, which is recorded as document fragment 3. This part is used as the attention section;

[0172] (4) The engine reads the miscellaneous:docs:essential_software field, which is an array type. If the tag field in the array element contains script, the engine will consider it as the essential software required for the current deployment method. The engine traverses the array and generates a list of essential software in a table format according to the markdown table syntax. The output content is stored in the memory and recorded as document fragment 4. This part is used as the chapter on preparing essential software.

[0173] (5) The engine outputs the built-in installation scaffolding script to the memory to obtain some basic scripts required for installation, which is recorded as document fragment 5. This part is used as the installation preparation chapter;

[0174] (6) The engine reads the miscellaneous:depends_on:initialize field to obtain the document description of the application data initialization. This field will be output to the memory in markdown format and recorded as document fragment 6; reads the dependencies:router field, traverses this field to obtain the reverse proxy configuration rules, and outputs them to the memory in the document template format, which is recorded as document fragment 7; the engine traverses all jobs contained in the application to be deployed, calls the deployment script generation module to generate the corresponding deployment script, and outputs the script content to the memory in the document template format in sequence, reads the docs:description field of the job description, and obtains the document description when the job is installed. These document contents are recorded as document fragment 8; this part is used as the installation chapter;

[0175] (7) The engine reads the miscellaneous:docs:troubleshoot field, which is an array type. The engine traverses the field, obtains the title field in the array element as the fault title, obtains the answer field as the fault handling solution, obtains the possible_causes field as the possible cause of the fault, and outputs it to the memory according to the document template format, recorded as document fragment 9, which is used as the fault handling chapter;

[0176] (8) The engine reads the miscellaneous:docs:faq field, which is an array type. The engine traverses the field, obtains the question_title field in the array element as the question title, obtains the question_body field as the question description, obtains the answer field as the question answer, and outputs it to the memory according to the document template format, recorded as document fragment 10, which is used as the FAQ chapter;

[0177] (9) The engine merges the above document fragments 1-10 and outputs them into a file to obtain a deployment document in a markeddown format.

[0178] The above process uses the deployment script to generate the deployment document. The logic of using the Docker-compose deployment method and the Kubernetes deployment method to generate the deployment document is similar to the above process. The difference is that both the Docker-compose deployment method and the Kubernetes deployment method use the docker image to start the container to provide services to the outside world. Therefore, the engine will read the miscellaneous:docker:group:docs_k8s and miscellaneous:docker:group:docs_compose fields to obtain the document description when installing the image. This part is used as the installation chapter.

[0179] Optionally, the target deployment product includes a technical architecture diagram. Parsing the configuration file to generate the target deployment product includes: generating a code snippet of the application to be deployed according to a format template of the deployment engine and the application description information, and rendering the code snippet to obtain the technical architecture diagram.

[0180] Exemplarily, the process of generating a technical architecture diagram is as follows:

[0181] (1) The engine reads the miscellaneous:system_landscape:person field and miscellaneous:system_landscape:person_ext field contained in the application description information in the configuration file. Both fields are in key / value format, with the key being the role name and the value being the role description. The engine traverses these two fields and generates plantuml (a drawing tool) code according to the C4-PlantUML (a drawing tool) format template built into the engine, recorded as code snippet 1, which is used for personnel role definition;

[0182] (2) The engine reads the miscellaneous:system_landscape:system_ext field, which is in key / value format, with the key being the name of the external system and the value being the description of the external system. The engine traverses the field and generates plantuml code according to the C4-PlantUML format template built into the engine, recorded as code snippet 2, which is used for external system definition;

[0183] (3) The engine reads the miscellaneous:system_landscape:boundary field, which is an array type. The engine traverses the field and generates .plantuml code according to the built-in C4-PlantUML format template, recorded as code snippet 3, which is used for range definition. The label field of the boundary array element represents the range name, and the container field is a component list. The container is in key / value format, where the key is the English name of the component and the value is the component information, separated by English colons, which are the Chinese name of the component, the technology used, and the purpose of the component. The parsing engine will split the value by colon to obtain the corresponding information;

[0184] (4) The engine reads the miscellaneous:system_landscape:relationship field, which is an array type. The engine traverses the field and generates .plantuml code according to the built-in C4-PlantUML format template, which is recorded as code snippet 4. The relationship array element consists of multiple pieces of information, separated by English colons, which respectively describe the relationship between components and the protocol used for communication. The engine will separate them with colons to obtain the desired information when processing;

[0185] (5) The engine combines the above code snippets 1-4 into a string and passes it as a parameter to the plantuml rendering software for rendering. The rendering software returns an architecture diagram in png (an image file storage format) format.

[0186] Step S103: Privately deploy the application to be deployed according to the target deployment product. Privately deploying according to the configuration file can make the private deployment method applicable to a variety of applications and have universality.

[0187] The embodiment of the present invention presets a set of general architecture declaration specifications applicable to multiple applications, standardizes non-standard and non-uniform information into field data, realizes corresponding parsing engine and functional scalability, and the engine obtains different fields from the configuration file for different output types to generate different products, which can solve the problems of inconsistent quality, different styles, low efficiency and other aspects caused by manual writing in the prior art, avoids manual writing and spending a lot of time, and helps system developers quickly obtain all materials required for private deployment and implementation.

[0188] According to a second aspect of an embodiment of the present invention, a device for implementing the above method is provided.

[0189] Figure 5 is a schematic diagram of the main modules of the device for private deployment according to an embodiment of the present invention, such as Figure 5 As shown, the device 500 for private deployment includes:

[0190] Configuration module 501, determining a configuration file of the application to be deployed according to a preset architecture declaration specification;

[0191] A generation module 502 parses the configuration file to generate a target deployment product;

[0192] The deployment module 503 privatizes and deploys the to-be-deployed application according to the target deployment product.

[0193] Optionally, the architecture declaration specification includes: an application information template, a task configuration information template and an application description information template; the configuration file includes: application information, task configuration information and application description information of the application to be deployed.

[0194] Optionally, the target deployment product includes a deployment script, and the task configuration information includes configuration information of all tasks of each component in the application to be deployed;

[0195] The generation module parses the configuration file to generate a target deployment product, including:

[0196] For each component: generating a script file corresponding to each task in the component according to configuration information of all tasks of the component, and merging the script files corresponding to each task to obtain the script file of the component;

[0197] The script files of all components are merged to obtain the deployment script.

[0198] Optionally, the script file includes an installation script; the generation module is further used to generate the installation script corresponding to each task according to the following steps:

[0199] An installation script is generated according to the component environment dependency field in the configuration information of the task, a code package script is generated according to the code package field in the configuration information of the task, and the installation script and the code package script are merged to obtain the installation script of the task.

[0200] Optionally, the generating module is further used to: before merging the installation script with the code package script, confirm that there is no custom installation script in the task according to the custom script field in the configuration information of the task;

[0201] If a custom installation script exists in the task, the installation script, the code package script and the custom installation script are merged to obtain the installation script of the task.

[0202] Optionally, the generating module is further used to generate a startup script corresponding to each task according to the following steps:

[0203] Determine the task type of the task according to the task type field in the configuration information of the task; the task type includes: static resource type, service type;

[0204] If the task type of the task is a static resource type, determine whether the component environment dependency field in the configuration information of the task is empty; if so, generate a startup script; otherwise, end the process;

[0205] If the task type of the task is a service type, the pre-startup script of the task is obtained according to the custom script field, a startup script fragment is generated, and the post-startup script of the task is obtained. The pre-startup script, the startup script fragment and the post-startup script are merged to obtain the startup script of the task.

[0206] Optionally, the target deployment product includes a Docker image, the application description information includes image configuration information of each image of the application to be deployed, and the image configuration information includes a task array of the image and description information of all tasks in the task array;

[0207] The generation module parses the configuration file to generate a target deployment product, including:

[0208] For each image: determining a task list of the image according to the task array of the image; generating an image file of each task in the task array according to the description information and configuration information of each task in the task array; merging the image files of each task in the task array to obtain an image file of the image;

[0209] Merge the image files of all images to obtain the Docker image of the application to be deployed.

[0210] Optionally, the generating module determines the task list of the image according to the task array of the image, including:

[0211] Determine whether the task array of the image is empty;

[0212] If so, arranging all tasks of each component in the application to be deployed according to the component environment dependency field in the configuration information of all tasks of each component in the application to be deployed, generating a task array of the image, and taking a list formed by all tasks in the task array as the task list;

[0213] Otherwise, a list formed by all tasks in the task array is used as the task list.

[0214] Optionally, the target deployment product includes a deployment document, the application description information includes installation document description information, precautions information, required software information, middleware information, fault handling information, and common problem information of the application to be deployed; the task configuration information includes document display information and task description information of all tasks of each component in the application to be deployed;

[0215] The generation module parses the configuration file to generate a target deployment product, including:

[0216] Generate a product introduction chapter of the application to be deployed according to the application information of the application to be deployed;

[0217] Generate a deployment process section of the application to be deployed according to the installation document description information;

[0218] Generate a precautions section for the application to be deployed according to the precautions information;

[0219] Generate a prerequisite software chapter for the application to be deployed according to the prerequisite software information;

[0220] Generate an installation preparation chapter for the application to be deployed according to the installation scaffolding script in the deployment engine;

[0221] Generate a document description of the initialization of the application to be deployed according to the middleware information, obtain the reverse proxy rules of the application to be deployed according to the document display information, obtain the deployment scripts of all tasks of each component in the application to be deployed, and obtain the document description of each task when installing according to the task description information of all tasks of each component in the application to be deployed or the task array of each image, so as to generate the installation chapter of the application to be deployed;

[0222] Generate a fault handling section of the application to be deployed according to the fault handling information;

[0223] Generate a frequently asked questions section for the application to be deployed according to the frequently asked questions information;

[0224] The product introduction section, the deployment process section, the precautions section, the required software section, the installation preparation section, the installation section, the troubleshooting section, and the FAQ section are combined to obtain a deployment document for the application to be deployed.

[0225] Optionally, the target deployment product includes a technical architecture diagram;

[0226] The generation module parses the configuration file to generate a target deployment product, including: generating a code snippet of the application to be deployed according to a format template built into the deployment engine and the application description information, and rendering the code snippet to obtain the technical architecture diagram.

[0227] Figure 6 FIG. 2 shows a schematic diagram of the composition of a generation module in an optional embodiment of the present invention. Figure 6As shown, the generation module includes a configuration parsing module, a traditional deployment module, a document module and a Docker image module. The configuration parsing module parses the configuration file, the traditional deployment module automatically generates and outputs the deployment script according to the parsing results and the required output type (i.e., deployment script), the document module automatically generates and outputs the deployment document, system architecture diagram, FAQ (Frequently Asked Questions, common question items and corresponding question answers), system dependency list, etc. according to the parsing results and the required output type (i.e., deployment document, system architecture diagram, FAQ, system dependency list, etc.), and the Docker image module automatically generates the image file dockerfile of each image and the Docker image of the application to be deployed according to the parsing results and the required output type (i.e., Docker image). The generation process is described in the method section and will not be repeated here.

[0228] The embodiment of the present invention determines the configuration file of the application to be deployed according to the preset architecture declaration specification, generates the target deployment product according to the configuration file, and can automatically generate the deployment product required for private deployment, avoiding the shortcomings caused by manually writing deployment products in the prior art, improving the efficiency of private deployment, and improving the robustness of private deployment. Since the configuration files of each application to be deployed can be determined according to the same architecture declaration specification, the standardization of the deployment product writing style can be achieved.

[0229] According to a third aspect of an embodiment of the present invention, there is provided a privately deployed electronic device, including:

[0230] one or more processors;

[0231] a storage device for storing one or more programs,

[0232] When the one or more programs are executed by the one or more processors, the one or more processors implement the method provided in the first aspect of the embodiment of the present invention.

[0233] According to a fourth aspect of an embodiment of the present invention, a computer-readable medium is provided, on which a computer program is stored, and when the program is executed by a processor, the method provided by the first aspect of the embodiment of the present invention is implemented.

[0234] Figure 7 An exemplary system architecture 700 is shown to which the method for private deployment or the apparatus for private deployment according to the embodiments of the present invention can be applied.

[0235] like Figure 7As shown, system architecture 700 may include terminal devices 701, 702, 703, network 704 and server 705. Network 704 is used to provide a medium for communication links between terminal devices 701, 702, 703 and server 705. Network 704 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

[0236] Users can use terminal devices 701, 702, and 703 to interact with server 705 through network 704 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 701, 702, and 703, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (only examples).

[0237] The terminal devices 701 , 702 , and 703 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, and desktop computers.

[0238] The server 705 may be a server that provides various services, such as a backend management server (only for example) that supports shopping websites browsed by users using the terminal devices 701, 702, and 703. The backend management server may analyze and process the received data such as product information query requests, and feed back the processing results (such as target push information, product information - only for example) to the terminal device.

[0239] It should be noted that the private deployment method provided in the embodiment of the present invention is generally executed by the server 705 , and accordingly, the private deployment device is generally set in the server 705 .

[0240] It should be understood that Figure 7 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

[0241] Reference below Figure 8 , which shows a schematic diagram of the structure of a computer system 800 of a terminal device suitable for implementing an embodiment of the present invention. Figure 8 The terminal device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0242] like Figure 8As shown, the computer system 800 includes a central processing unit (CPU) 801, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 802 or a program loaded from a storage part 808 into a random access memory (RAM) 803. In the RAM 803, various programs and data required for the operation of the system 800 are also stored. The CPU 801, the ROM 802, and the RAM 803 are connected to each other via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0243] The following components are connected to the I / O interface 805: an input section 806 including a keyboard, a mouse, etc.; an output section 807 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 808 including a hard disk, etc.; and a communication section 809 including a network interface card such as a LAN card, a modem, etc. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to the I / O interface 805 as needed. A removable medium 811, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 810 as needed, so that a computer program read therefrom is installed into the storage section 808 as needed.

[0244] In particular, according to the embodiments disclosed in the present invention, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present invention include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 809, and / or installed from the removable medium 811. When the computer program is executed by the central processing unit (CPU) 801, the above-mentioned functions defined in the system of the present invention are executed.

[0245] It should be noted that the computer-readable medium shown in the present invention may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present invention, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0246] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present invention. In this regard, each box in the flow chart or block diagram can represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0247] The modules involved in the embodiments of the present invention may be implemented in software or hardware. The modules described may also be set in a processor. For example, they may be described as follows: a processor includes: a configuration module that determines a configuration file of an application to be deployed according to a preset architecture declaration specification; a generation module that parses the configuration file to generate a target deployment product; and a deployment module that privately deploys the application to be deployed according to the target deployment product. The names of these modules do not, in some cases, constitute a limitation on the module itself. For example, the configuration module may also be described as a "module that parses the configuration file."

[0248] As another aspect, the present invention further provides a computer-readable medium, which may be included in the device described in the above embodiment; or may exist independently without being assembled into the device. The above computer-readable medium carries one or more programs, and when the above one or more programs are executed by a device, the device includes: determining a configuration file of an application to be deployed according to a preset architecture declaration specification; parsing the configuration file to generate a target deployment product; and privatizing and deploying the application to be deployed according to the target deployment product.

[0249] According to the technical solution of the embodiment of the present invention, the deployment products required for privatization deployment can be automatically generated, avoiding the shortcomings of the prior art caused by manually writing deployment products, improving the efficiency of privatization deployment, improving the robustness of privatization deployment, and realizing the standardization of deployment product writing style.

[0250] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A method for private deployment, characterized in that: include: Determine the configuration file of the application to be deployed according to the preset architecture declaration specification; Parsing the configuration file to generate a target deployment product; Deploy the to-be-deployed application privatized according to the target deployment product; The architecture declaration specification includes: application information template, task configuration information template and application description information template; the configuration file includes: application information, task configuration information and application description information of the application to be deployed; the target deployment product includes deployment script, Docker image, deployment document or technical architecture diagram.

2. The method according to claim 1, characterized in that The target deployment product includes a deployment script, and the task configuration information includes configuration information of all tasks of each component in the application to be deployed; Parse the configuration file to generate target deployment products, including: For each component: generating a script file corresponding to each task in the component according to configuration information of all tasks of the component, and merging the script files corresponding to each task to obtain the script file of the component; The script files of all components are merged to obtain the deployment script.

3. The method according to claim 2, characterized in that The script file includes an installation script; the installation script corresponding to each task is generated according to the following steps: An installation script is generated according to the component environment dependency field in the configuration information of the task, a code package script is generated according to the code package field in the configuration information of the task, and the installation script and the code package script are merged to obtain the installation script of the task.

4. The method according to claim 3, characterized in that Before merging the installation script with the code package script, the method further includes: confirming that no custom installation script exists in the task according to a custom script field in the configuration information of the task; If a custom installation script exists in the task, the installation script, the code package script and the custom installation script are merged to obtain the installation script of the task.

5. The method according to claim 2, characterized in that The script file includes a startup script; the startup script corresponding to each task is generated according to the following steps: Determine the task type of the task according to the task type field in the configuration information of the task; the task type includes: static resource type, service type; If the task type of the task is a static resource type, determine whether the component environment dependency field in the configuration information of the task is empty; if so, generate a startup script; otherwise, end the process; If the task type of the task is a service type, the pre-startup script of the task is obtained according to the custom script field, a startup script fragment is generated, and the post-startup script of the task is obtained. The pre-startup script, the startup script fragment and the post-startup script are merged to obtain the startup script of the task.

6. The method according to claim 1, characterized in that The target deployment product includes a Docker image, the application description information includes image configuration information of each image of the application to be deployed, and the image configuration information includes a task array of the image and description information of all tasks in the task array; Parse the configuration file to generate target deployment products, including: For each image: determining a task list of the image according to the task array of the image; generating an image file of each task in the task array according to the description information and configuration information of each task in the task array; merging the image files of each task in the task array to obtain an image file of the image; Merge the image files of all images to obtain the Docker image of the application to be deployed.

7. The method according to claim 6, characterized in that Determining a task list of the image according to the task array of the image includes: Determine whether the task array of the image is empty; If so, all tasks of each component in the application to be deployed are arranged according to the component environment dependency field in the configuration information of all tasks of each component in the application to be deployed, and a task array of the image is generated, and a list formed by all tasks in the task array is used as the task list; Otherwise, a list formed by all tasks in the task array is used as the task list.

8. The method according to claim 2, characterized in that The target deployment product includes a deployment document, the application description information includes installation document description information, precautions information, required software information, middleware information, fault handling information, and common problem information of the application to be deployed; the task configuration information includes document display information and task description information of all tasks of each component in the application to be deployed; Parse the configuration file to generate target deployment products, including: Generate a product introduction chapter of the application to be deployed according to the application information of the application to be deployed; Generate a deployment process section of the application to be deployed according to the installation document description information; Generate a precautions section for the application to be deployed according to the precautions information; Generate a prerequisite software chapter for the application to be deployed according to the prerequisite software information; Generate an installation preparation chapter for the application to be deployed according to the installation scaffolding script in the deployment engine; Generate a document description of the initialization of the application to be deployed according to the middleware information, obtain the reverse proxy rules of the application to be deployed according to the document display information, obtain the deployment scripts of all tasks of each component in the application to be deployed, and obtain the document description of each task when installing according to the task description information of all tasks of each component in the application to be deployed or the task array of each image, so as to generate the installation chapter of the application to be deployed; Generate a fault handling section of the application to be deployed according to the fault handling information; Generate a frequently asked questions section for the application to be deployed according to the frequently asked questions information; The product introduction chapter, the deployment process chapter, the precautions chapter, the required software chapter, the installation preparation chapter, the installation chapter, the troubleshooting chapter and the frequently asked questions chapter are combined to obtain a deployment document for the application to be deployed.

9. The method according to claim 1, characterized in that The target deployment product includes a technical architecture diagram; The configuration file is parsed to generate a target deployment product, including: generating a code snippet of the application to be deployed according to a format template built into a deployment engine and the application description information, and rendering the code snippet to obtain the technical architecture diagram.

10. A device for private deployment, characterized in that: include: The configuration module determines the configuration file of the application to be deployed according to the preset architecture declaration specification; A generation module is used to parse the configuration file and generate a target deployment product; A deployment module, privatizing and deploying the to-be-deployed application according to the target deployment product; The architecture declaration specification includes: application information template, task configuration information template and application description information template; the configuration file includes: application information, task configuration information and application description information of the application to be deployed; the target deployment product includes deployment script, Docker image, deployment document or technical architecture diagram.

11. A privately deployed electronic device, characterized in that: include: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 9.

12. A computer readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 9 is implemented.

Citation Information

Patent Citations

Generalized flowsheet platform for corporation
CN101364289A
Engineering automatic deployment method and device, computer equipment and storage medium
CN109800016A

Patent Information

AI Technical Summary

Abstract

Description

Patent Citations

Generalized flowsheet platform for corporation

Engineering automatic deployment method and device, computer equipment and storage medium