A task-oriented orchestration method for system deployment through declarative templates

Abstract

The present application relates to a kind of task-oriented orchestration method for system deployment by declarative template, the method includes the following steps: if there is no available environment or need to build environment, at least one environment is defined based on preset environment definition format, and the specific attribute of newly built environment is described;If there is no available module or need to build module, at least one module is defined based on preset module definition format, and the attribute, deployment process, dependency relationship and maintenance process of newly built module are described;If there is no available template or need to build template, at least one template is defined based on preset template definition format;Declarative template containing three-level abstract model of environment, module and template is transmitted to parsing engine, and parsing engine parses declarative template and generates work order task flow, and the work order task flow will be executed by semi-automatic or automatic mode.

Description

TECHNICAL FIELD

[0001] The application belongs to the field of infrastructure as code (IaC), and particularly relates to a task-oriented orchestration method for system deployment through a declarative template. BACKGROUND

[0002] The following technical pain points exist in the evolution of current distributed system architecture: architecture corruption problem: in the process of continuous iteration, uncontrolled temporary deployment (such as hot repair and emergency expansion) will lead to confusion of system topology relationship. Process standardization problem: from market demand to system architecture design by architects, system development by development team, system deployment and monitoring by operation personnel. The entire process is currently generally promoted in an artificial manner, which is prone to errors and cannot be controlled.

[0003] Specifically, existing declarative orchestration tools such as Terraform and Ansible require templates to describe underlying details (such as AWS resource ID), and the syntax complexity increases exponentially with the system size, so architects need to master both infrastructure and business knowledge.

[0004] Ticket management systems such as DingTalk and WeChat for Enterprise only support manual task assignment, lack of automatic connection with architecture design, and deployment process is separated from architecture design blueprint.

[0005] Low-code platforms such as OutSystems and Mendix are over-encapsulated, making it impossible to define module topology relationship and interface with existing OA systems, and can only be used for simple applications, which cannot meet the needs of complex architecture. SUMMARY

[0006] The present application provides a task-oriented orchestration method for system deployment through a declarative template, aiming to at least solve one of the technical problems existing in the prior art.

[0007] The technical solution of the present application relates to a task-oriented orchestration method for system deployment through a declarative template, which comprises the following steps:

[0008] S100, if there is no available environment or a new environment is needed, define at least one environment based on a preset environment definition format, and describe the specific attributes of the new environment;

[0009] S200, if there is no available module or a new module is needed, define at least one module based on a preset module definition format, and describe the attributes, deployment process, dependency relationship and maintenance process of the new module;

[0010] S300, if there is no available template or a new template is needed, define at least one template based on a preset template definition format;

[0011] S400, transmitting the declarative template containing the three-level abstract model of environment, module and template to a parsing engine, the parsing engine parsing the declarative template and generating a work order task flow to be executed in a semi-automated or automated manner.

[0012] Further, in the step S100, the environment definition format includes the following fields:

[0013] An environment name field for globally uniquely describing the name of the current environment;

[0014] An environment version number field for describing the version of the current environment definition;

[0015] An environment attribute list field for declaring the attribute list of the current environment.

[0016] Further, the environment attribute list field includes one or more attribute key-value pairs, each attribute key-value pair including an attribute name and an attribute type, the attribute name being defined according to the actual situation of the current environment, and the attribute type being a string, integer or floating-point format.

[0017] Further, in the step S200, the module definition format includes the following fields:

[0018] A module name field for globally uniquely describing the name of the current module;

[0019] A module version number field for describing the version of the current module definition;

[0020] A module attribute list field for declaring the attribute list of the current module;

[0021] An available environment field for declaring at least one deployable environment of the current module and declaring and limiting the attributes of the deployed environment;

[0022] An inter-module dependency relationship field for declaring the dependency relationship of the current module on one or more other modules, and if the current module does not need to depend on other modules, the inter-module dependency relationship field is not needed.

[0023] Further, the module attribute list field includes a public attribute list for inter-module sharing and a private attribute list that cannot be shared between modules in an unlicensed case,

[0024] The public attribute list and the private attribute list each include one or more attribute key-value pairs, each attribute key-value pair including an attribute name and an attribute type, the attribute name being defined according to the actual situation of the current module and environment, and the attribute type being a string, integer or floating-point format.

[0025] Further, the available environment field includes the following subfields:

[0026] Available environment name, the available environment name is one of the defined environment name field values, the available environment name includes the requirement subfield, the installation package subfield and the decompression file subfield;

[0027] The requirement subfield is used to declare the attribute requirements of the environment when the current module is deployed on the available environment, and the requirement subfield includes one or more attribute key-value pairs;

[0028] The installation package subfield is used to indicate the location and installation package name information of the installation package obtained when the current module is installed on the available environment, and the installation package subfield includes the installation package package name and the installation package md5 check value;

[0029] The decompression file subfield includes attribute key-value pairs for indicating the decompression file type and the relative path after decompression of the installation package file;

[0030] The inter-module dependency relationship field includes the following subfields:

[0031] Dependent module name, the dependent module name is one of the defined module name field values, and the dependent module name includes the version number subfield of the dependent module, the attribute supply subfield and the attribute requirement subfield;

[0032] The attribute supply subfield is used to indicate the attribute name and attribute value that the current module needs to provide to the dependent module; and the attribute requirement subfield is used to indicate the attribute name and attribute value that the dependent module needs to generate and transmit to the current module.

[0033] Further, in the step S300, the template definition format includes the following fields:

[0034] Template name field, used to globally and uniquely describe the name of the current template;

[0035] Template version number field, used to describe the version number of the current template;

[0036] Dependent module field, used to declare the module name that needs to be introduced in the current template, and if two modules have the same name, the name of the introduced module is changed by renaming;

[0037] Relationship field, used to declare the relationship between modules;

[0038] Module deployment environment field, used to declare the relationship between the module and the deployment environment, that is, to describe on which environment a certain module is deployed.

[0039] Further, in the step S400, the parsing engine includes:

[0040] Front-end pages, back-end services, message queues for delivering work order task flows, work order systems, and configuration storage centers;

[0041] The back-end services include a register, a storage, a syntax parser, a deployment relationship parser, a dependency relationship parser, a deployment plan generator, a deployment plan executor, and a deployment plan state manager.

[0042] Further, the step S400 includes the following steps:

[0043] S410, uploading the defined environment file, module file, and template file through the front-end page;

[0044] S420, sending the environment file, module file, and template file to the back-end service EngineServer to execute the parsing engine service;

[0045] S430, the back-end service EngineServer checks the environment Environment file, module Module file, and template Template file, and saves the successfully checked environment Environment file, module Module file, and template Template file to the storage of the back-end service EngineServer;

[0046] S440, submitting the environment Environment file, module Module file, and template Template file to the back-end service EngineServer for parsing.

[0047] Further, the present application also proposes a computer readable storage medium having program instructions stored thereon, the program instructions being executed by a processor to implement the task-oriented orchestration method for system deployment through declarative templates.

[0048] Compared with the prior art, the present application has the following characteristics:

[0049] The task-oriented orchestration method for system deployment through declarative templates enables an architect to design an architecture according to actual needs and describe an architecture by writing a template, thereby ensuring that the actual deployment online is the same as the architecture designed by the architect and avoiding the situation that the architecture online deviates from the control of the architect due to the iteration of needs. Through the syntax and parsing platform of the template, the deployment of the entire system architecture can be promoted by the platform, which can greatly reduce various problems caused by manual promotion, and even the platform can realize automatic implementation of each work order task and one-key deployment. Since the deployment of the system can be described in this way, the management of the entire company can be further integrated into the platform, and various matters of the company can be managed on the platform. Attached Figure Description

[0050] Figure 1 A flowchart illustrating a task-oriented orchestration method for system deployment using declarative templates.

[0051] Figure 2 This diagram illustrates how the parsing engine parses declarative templates and generates work order task flows.

[0052] Figure 3 This is a schematic diagram of a PostgreSQL database architecture with one master and two slaves. Detailed Implementation

[0053] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0054] The following will provide a clear and complete description of the concept, specific structure, and technical effects of the present invention in conjunction with the embodiments and accompanying drawings, so as to fully understand the purpose, solution, and effects of the present invention.

[0055] It should be noted that, unless otherwise specified, when a feature is referred to as "fixed" or "connected" to another feature, it can be directly fixed or connected to the other feature, or indirectly fixed or connected to the other feature. The singular forms "a," "described," and "the" used herein are also intended to include the plural forms, unless the context clearly indicates otherwise. Furthermore, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in this specification is for the purpose of describing particular embodiments only and not for limiting the invention. The term "and / or" as used herein includes any combination of one or more of the associated listed items.

[0056] It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various elements, these elements should not be limited to these terms. These terms are used only to distinguish elements of the same type from one another. For example, a first element may also be referred to as a second element without departing from the scope of this disclosure, and similarly, a second element may also be referred to as a first element. Any and all instances or exemplary language (“e.g.,” “such as,” etc.) used herein are intended only to better illustrate embodiments of the invention and, unless otherwise required, do not impose a limitation on the scope of the invention. Furthermore, the industry term “pose” as used herein refers to the position and orientation of an element relative to a spatial coordinate system.

[0057] Reference Figures 1 to 3 This invention provides a task-oriented orchestration method for system deployment using declarative templates. The declarative templates include a three-level abstract model: an Environment for defining the infrastructure deployment carrier, a Module for abstracting specific deployment units, and a Template. (Refer to...) Figure 1 The task-oriented orchestration method for system deployment using declarative templates includes the following steps:

[0058] S100. If no available Environment exists or a new Environment needs to be created, define at least one Environment based on the preset environment definition format and describe the specific attributes of the new Environment.

[0059] S200. If no available module exists or a new module needs to be created, define at least one module based on the preset module definition format, and describe the attributes, deployment process, dependencies, and maintenance process of the new module.

[0060] S300. If no available template exists or a new template needs to be created, define at least one template based on the preset template definition format.

[0061] S400: The declarative template containing a three-level abstract model of Environment, Module and Template is sent to the parsing engine. The parsing engine parses the declarative template and generates a work order task flow, which will be executed in a semi-automatic or automatic manner.

[0062] Compared with existing technologies, the present invention has the following characteristics:

[0063] By using declarative templates to implement a task-oriented orchestration method for system deployment, architects design the architecture based on actual needs and describe it using templates. This ensures that the actual online deployment matches the architect's design, preventing the online architecture from slipping out of the architect's control as requirements iterate. Through this template syntax and parsing platform, the entire system architecture deployment can be driven by the platform, significantly reducing the problems that arise from manual intervention. Furthermore, the platform can automate each work order task, enabling one-click deployment. Benefit 3: Since system deployment can be described in this way, the entire company's management can be integrated into this platform, managing all company matters on a single platform.

[0064] This invention belongs to the fields of DevOps and Infrastructure as Code (IaC) technology, specifically involving a system architecture orchestration method and system based on a declarative programming paradigm. By defining a three-level abstract model of environment-module-template and combining it with a parsing engine that integrates work orders, it achieves automated management and control of the entire lifecycle from architecture design to deployment, solving the problem of deviation between architecture design and actual deployment.

[0065] The following technical challenges exist in the current evolution of distributed system architecture:

[0066] (1) Architecture corruption problem: During continuous iteration, temporary deployments (such as hot repair and emergency expansion) that are not strictly controlled can lead to chaotic system topology.

[0067] (2) Process standardization issues: From market demand, architects design system architecture, development teams develop the system, and operations and maintenance personnel deploy and monitor the system. The entire process is currently driven manually, which is prone to errors and makes it impossible to control the process.

[0068] Based on the above-mentioned shortcomings, the present invention needs to solve the following cross-domain technology coupling problems, including the problems of syntax complexity, task flow integration and architecture controllability.

[0069] Therefore, a solution that combines the following characteristics is needed:

[0070] (1) Precise architectural control: solidify architectural design intent through machine-readable declarative templates (YAML / JSON, etc.);

[0071] (2) Hybrid task flow: Supports the hybrid orchestration of automated instructions (Ansible scripts) and manual work orders (OA system integration);

[0072] (3) Two-way verifiable: Establish a closed-loop verification mechanism from "design → deployment → runtime" (e.g., by comparing the hash values ​​of environment attributes).

[0073] This invention relates to automation and task management technologies for system architecture deployment. It is a method and system that describes the system architecture using custom declarative templates and generates executable task flows (including manual work orders or automated instructions) via a parsing engine. The custom declarative syntax comprises the following three concepts: (environment, module, template).

[0074] The core innovations of this invention are: the abstraction of the three concepts of environment, module, and template, and the grammatical definition of these three! Secondly, it is about the parsing rules and design ideas of the parsing engine in the process of parsing templates.

[0075] Furthermore, refer to Figure 1 In step S100, the environment definition format includes the following fields:

[0076] The EnvironmentName field is used to uniquely describe the current environment.

[0077] The EnvironmentVersion field describes the version of the current environment definition.

[0078] The EnvironmentProperties field is used to declare a list of properties for the current environment.

[0079] Specifically, an environment is the deployment platform for infrastructure, such as physical machines or the AWS cloud platform. Environment names are globally unique, and key-value pairs describe the specific attributes of the environment. After approval, they are stored in an environment repository for later use.

[0080] Furthermore, refer to Figure 1 The environment property list field includes one or more property key-value pairs. Each property key-value pair includes a property name (Property) and a property type (PropertyType). The property name is defined according to the actual situation of the current environment, and the property type is in string, integer, or float format.

[0081] Specifically, the definition format for Environment is as follows:

[0082] Environment: EnvironmentName # Required, environment name

[0083] Version: VersionNumber # Required, e.g., 1.1.1

[0084] Properties: # Required, list of environment properties

[0085] Property1: PropertyType1

[0086] Property2: PropertyType2 ...

[0087] PropertyN: PropertyTypeN

[0088] Among them, Environment: required, describes the current environment name, and the environment name must be globally unique.

[0089] Version: Required. Describes the version number of the current environment, such as 1.1.1.

[0090] Properties: A list of properties used to declare the current environment.

[0091] Each property is described using a key-value pair format like Property1: PropertyType1, where Property1 represents the property name and PropertyType1 represents the property type. The property name can be freely defined according to the specific context of the environment, and the property type can be in formats such as string, integer, or float. An environment can have multiple property lists, depending on the specific context of the defined environment.

[0092] In a specific embodiment, an example environment host is shown below:

[0093] Environment: Host

[0094] Version: 1.0.1

[0095] Properties:

[0096] type: string # Physical machine or virtual machine

[0097] os: string # Operating system, such as Linux or Windows

[0098] cpu: string # Number of CPU cores

[0099] memory: string # Memory size

[0100] The above declares an environment named Host, with version number 1.0.1. This environment has the following attributes: type, os, cpu, and memory. From this declaration, it's clear that the Host environment represents a host-based environment. The host type can be a physical machine or a virtual machine, and it has attributes like os, cpu, and memory. It's important to note that when defining an environment, only its abstract concept needs to be defined; concrete implementation is not required. Concretization is handled later through manual application or automation when implementing the project via a support ticket.

[0101] Furthermore, refer to Figure 1 In step S200, the module definition format includes the following fields:

[0102] The ModuleName field is used to uniquely describe the name of the current module.

[0103] The ModuleVersion field describes the version of the current module definition.

[0104] The ModuleProperties field is used to declare the list of properties for the current module.

[0105] The available Environments field is used to declare at least one deployable environment for the current module, and to declare and restrict the properties of the deployed environment;

[0106] The ModuleDependencies field is used to declare the dependencies of the current module on one or more other modules. If the current module does not depend on other modules, the ModuleDependencies field is not needed.

[0107] Specifically, a module is an abstraction of a specific deployment unit, representing a functional entity (such as a database, caching service, or middleware), describing its attributes, deployment process, dependencies, and maintenance tasks.

[0108] In a specific embodiment, the definition format of a module is as follows:

[0109] Module: Module name xxx

[0110] Version: Module version xxx

[0111] Properties:

[0112] Private:

[0113] Private attribute 1: Attribute type

[0114] Private attribute N: Attribute type

[0115] Public:

[0116] Public attribute 1: Attribute type

[0117] Public attribute N: Attribute type

[0118] Environments:

[0119] Environment name xxx:

[0120] - Requirement:

[0121] Environmental attribute xx: Environmental attribute value xx

[0122] Environment attribute xxx: Environment attribute value xxx

[0123] Install Package:

[0124] ReleaseName: The installation package xxx.tar.gz corresponding to the module.

[0125] Checksum: The MD5 hash of the installation package corresponding to the module.

[0126] DeploymentFiles:

[0127] File type xx: Relative path of the extracted files in the installation package xxx

[0128] File type xxx: Relative path of the extracted files in the installation package xxxx

[0129] - Requirement:

[0130] Environment attribute xxx: Environment attribute value xxx

[0131] Environment attribute xxxx: Environment attribute value xxxx

[0132] Install Package:

[0133] ReleaseName: The installation package xxx.tar.gz corresponding to the module.

[0134] Checksum: The MD5 hash of the installation package corresponding to the module.

[0135] DeploymentFiles:

[0136] File type xx: Relative path of the extracted files in the installation package xxx

[0137] File type xxx: Relative path of the extracted files in the installation package xxxx

[0138] Environment name xxxx:

[0139] - Requirement:

[0140] Environmental attribute xx: Environmental attribute value xx

[0141] Environment attribute xxx: Environment attribute value xxx

[0142] Install Package:

[0143] ReleaseName: The installation package xxx.tar.gz corresponding to the module.

[0144] Checksum: The MD5 hash of the installation package corresponding to the module.

[0145] DeploymentFiles:

[0146] File type xx: Relative path of the extracted files in the installation package xxx

[0147] File type xxx: Relative path of the extracted files in the installation package xxxx

[0148] ModuleDependencies:

[0149] Dependent module name xxx:

[0150] ModuleVersion: The module version of the dependent modules.

[0151] Provide:

[0152] - self.attributexxx

[0153] - self.attributexxx

[0154] Register:

[0155] - Attribute xxx

[0156] - Attribute xxxx

[0157] Dependent module name xxxx:

[0158] ModuleVersion: The module version of the dependent modules.

[0159] Provide:

[0160] - self.attributexxx

[0161] - self.attributexxx

[0162] Register:

[0163] - Attribute xxx

[0164] - Attribute xxxx

[0165] The ModuleName field is required and describes the current module name. The module name must be globally unique.

[0166] The ModuleVersion field is required and describes the current module version number, such as 1.1.1.

[0167] The `ModuleProperties` field declares the property list for the current module. Module properties are categorized as private or public, declared using the `Private` property list and the `Public` property list, respectively. Private properties are declared under the `Private` property list, and public properties are declared under the `Public` property list. Private properties require platform authorization before other modules can use them, while public properties can be used directly without authorization. Each property is described using a key-value pair format like `Property1: PropertyType1`, where `Property1` represents the property name and `PropertyType1` represents the property type. The property name can be freely defined according to the specific environment, and the property type can be in formats such as string, integer, or float. Similarly, a module can have multiple private and public properties, depending on the specific requirements of the module.

[0168] The available environment field, `Environments`, is used to declare the environments on which the current module can be deployed, and to define and restrict these environments. Multiple environments can be declared under `Environments`, representing descriptive information about how the module will be deployed in different environments. The first declaration under `Environments` is named `environment_name xxx`, where `environment_name xxx` is the name of a pre-defined environment. An incorrect or undefined environment name is invalid. The description of the module's environment name `xxx` includes the `Requirement` subfield, the `InstallPackage` subfield, and the `DeploymentFiles` subfield.

[0169] The `Requirement` subfield specifies the requirements for the environment when this module is deployed on environment name `xxx`. For example, an Nginx module might require the Host environment to run Linux. If there are multiple requirements for the environment, all of them should be declared here.

[0170] The InstallPackage field indicates where the installation package should be obtained when the current module is installed in this environment. ReleaseName represents the package name of the installation package, while Checksum is the MD5 value of the installation package, mainly for verification.

[0171] The DeploymentFiles subfield shows the files and their relative paths after the installation package is extracted. This information is mainly for future automation purposes.

[0172] The `ModuleDependencies` field describes the dependencies between modules. A dependency is a relationship where one module must depend on another to provide a service. For example, in a database, a slave database depends on the master database to provide a service, or a user management system must depend on the database itself to provide a service. This type of relationship is called a module dependency. If a defined module truly needs to depend on other modules to provide a service, then it must be explicitly declared when defining the module; multiple modules can be declared. If it does not depend on other modules, then no declaration is needed.

[0173] The `ModuleDependencies` field describes the dependent module name (`xxx`), including the module version number (`ModuleVersion`), property supply (`Provide`), and property requirement (`Register`). In a module's declaration, the dependent module name `xxx` must already exist; otherwise, it's invalid. The `ModuleVersion` field represents the version number of the dependent module. The `Provide` field describes which properties the current module will provide to the dependent module, and the `Register` field describes which properties the dependent module needs to generate.

[0174] For example, if there is a student information management system named StudentSystem that uses the PostgreSQL database to store data, then both StudentSystem and PostgreSQL can be defined as a module. Since StudentSystem needs the PostgreSQL module to provide services properly, it is necessary to declare its dependency on the PostgreSQL module in the StudentSystem module. At this time, StudentSystem needs the PostgreSQL module to create information such as database name, database username, and database password. Therefore, this information needs to be declared in the PostgreSQL module that StudentSystem depends on through Register. At this time, StudentSystem does not need to provide anything, so Provide is empty.

[0175] In a specific embodiment, the example module PostgresqlMaster is shown below:

[0176] Module: PostgresqlMaster

[0177] Version: 1.1.1

[0178] Properties:

[0179] Private:

[0180] AdminUser: String

[0181] AdminPassword: String

[0182] Public:

[0183] Port: Integer

[0184] Address: String

[0185] Environments:

[0186] Host:

[0187] - Requirement:

[0188] Os: ubuntu 22.04.4

[0189] Arch: x64

[0190] InstallPackage:

[0191] ReleaseName: postgresql-10.23-1-linux-x64-binaries.tar.gz

[0192] Checksum: bbfd9452247ec92cd8cd32d23d922f2f

[0193] DeploymentFiles:

[0194] BinaryFile: . / pgsql / bin / pg_ctl

[0195] InitFile: . / pgsql / bin / initdb

[0196] SyncFile: . / pgsql / bin / pg_basebackup

[0197] ConfigFile:

[0198] - . / pgsql / share / postgresql / postgresql.conf.sample

[0199] - . / pgsql / share / postgresql / pg_hba.conf.sample

[0200] - Requirement:

[0201] Os: ubuntu 22.04.4

[0202] Arch: x86

[0203] InstallPackage:

[0204] ReleaseName: postgresql-10.23-1-linux-x86-binaries.tar.gz

[0205] Checksum: bbfd9452247ec92cd8cd32d23d922f3f

[0206] DeploymentFiles:

[0207] BinaryFile: . / pgsql / bin / pg_ctl

[0208] InitFile: . / pgsql / bin / initdb

[0209] SyncFile: . / pgsql / bin / pg_basebackup

[0210] ConfigFile:

[0211] - . / pgsql / share / postgresql / postgresql.conf.sample

[0212] - . / pgsql / share / postgresql / pg_hba.conf.sample

[0213] The above declares a module named PostgresqlMaster (meaning the PostgreSQL master database), version 1.1.1. It has private attributes AdminUser and AdminPassword, representing the administrator's username and password. Public attributes are Address and Port, representing the access address and port. The Environments section declares that PostgresqlMaster can be deployed on an environment named Host (the host declared in the environment example above). When deploying on the Host environment, two options are provided: First, if OS is Ubuntu 22.04.4 and Arch is x64 (this is a Host attribute), the module's installation package is postgresql-10.23-1-linux-x64-binaries.tar.gz. Secondly, with OS set to Ubuntu 22.04.4 and Arch set to x86 (this is a Host attribute), the module's installation package is postgresql-10.23-1-linux-x86-binaries.tar.gz. The files declared under DeploymentFiles are simply database-specific information, which will not be described in detail here as they currently have little impact; their main purpose is declaration. Furthermore, the PostgresqlMaster module does not declare any dependencies, indicating that this module does not depend on other modules to provide services.

[0214] In another embodiment, the example module PostgresqlSlave is shown below:

[0215] Module: PostgresqlSlave

[0216] Version: 1.1.1

[0217] Properties:

[0218] Public:

[0219] Port: Integer

[0220] Address: String

[0221] Environments:

[0222] Host:

[0223] - Requirement:

[0224] Os: ubuntu 22.04.4

[0225] Arch: x64

[0226] InstallPackage:

[0227] ReleaseName: postgresql-10.23-1-linux-x64-binaries.tar.gz

[0228] Checksum: bbfd9452247ec92cd8cd32d23d922f2f

[0229] DeploymentFiles:

[0230] BinaryFile: . / pgsql / bin / pg_ctl

[0231] InitFile: . / pgsql / bin / initdb

[0232] SyncFile: . / pgsql / bin / pg_basebackup

[0233] ConfigFile:

[0234] - . / pgsql / share / postgresql / postgresql.conf.sample

[0235] - . / pgsql / share / postgresql / pg_hba.conf.sample

[0236] - Requirement:

[0237] Os: ubuntu 22.04.4

[0238] Arch: x86

[0239] InstallPackage:

[0240] ReleaseName: postgresql-10.23-1-linux-x86-binaries.tar.gz

[0241] Checksum: bbfd9452247ec92cd8cd32d23d922f3f

[0242] DeploymentFiles:

[0243] BinaryFile: . / pgsql / bin / pg_ctl

[0244] InitFile: . / pgsql / bin / initdb

[0245] SyncFile: . / pgsql / bin / pg_basebackup

[0246] ConfigFile:

[0247] - . / pgsql / share / postgresql / postgresql.conf.sample

[0248] - . / pgsql / share / postgresql / pg_hba.conf.sample

[0249] ModuleDependencies:

[0250] PostgresqlMaster:

[0251] ModuleVersion: '>1.1.1'

[0252] Provide:

[0253] - self.Address

[0254] Register:

[0255] - Address

[0256] - Port

[0257] - SyncUser

[0258] - SyncPassword

[0259] The above declares a module named PostgresqlSlave (meaning a PostgreSQL slave database), version 1.1.1. This module has no private attributes. Its public attributes are Address and Port, representing the access address and port. Then, in the Environments section, it's declared that the current PostgresqlSlave can be deployed on an environment named Host (the host environment declared in the environment example above). When deploying on the Host environment, two options are provided: First, with OS set to Ubuntu 22.04.4 and Arch set to x64 (this is a Host attribute), the module's installation package is postgresql-10.23-1-linux-x64-binaries.tar.gz. Second, with OS set to Ubuntu 22.04.4 and Arch set to x86 (this is a Host attribute), the module's installation package is postgresql-10.23-1-linux-x86-binaries.tar.gz. As for the files declared under DeploymentFiles, they are actually some file information unique to this database. They will not be described in detail here because they have little impact at present. Their main function is to make declarations.

[0260] The definition of the `PostgresqlSlave` module includes `ModuleDependencies`, indicating that this module depends on other services to provide its services. The definition shows that it depends on the `PostgresqlMaster` module. Furthermore, the dependency on `PostgresqlMaster` requires its `ModuleVersion` to be greater than or equal to 1.1.1, and it needs to provide the `self.Address` (address) of the current module, along with the `Address`, `Port`, `SyncUser`, and `SyncPassword` properties generated by the `PostgresqlMaster` module. (In essence, the definition of the `PostgresqlSlave` and `PostgresqlMaster` modules declares the master-slave relationship in database configuration, which requires a good understanding of master-slave configuration. The general configuration approach is that the master database needs to configure the slave's address and create the database account and password for synchronization. Conversely, the slave database needs to configure the master's address, port, and the database account and password for synchronization.)

[0261] Furthermore, refer to Figure 1The ModuleProperties field of the module property list includes a public property list for sharing between modules and a private property list that cannot be shared between modules under unauthorized circumstances.

[0262] Both the Public property list and the Private property list include one or more property key-value pairs. Each property key-value pair includes a property name (Property) and a property type (PropertyType). The property name (Property) is defined according to the actual situation of the current module and environment, and the property type (PropertyType) is in the format of string, integer, or float.

[0263] Furthermore, refer to Figure 1 The available environment field, Environments, includes the following subfields:

[0264] Available environment name, which is one of the values ​​of the defined EnvironmentName field, including the Requirement subfield, the InstallPackage subfield, and the DeploymentFiles subfield;

[0265] The Requirement subfield is used to declare the property requirements of the current module on the available Environments when it is deployed. The Requirement subfield includes one or more property key-value pairs.

[0266] The InstallPackage field is used to indicate the location and name of the installation package when the current module is installed in an available Environment. The InstallPackage field includes the installation package name ReleaseName and the installation package MD5 checksum.

[0267] The DeploymentFiles subfield includes attribute key-value pairs that represent the type of the decompressed file and the relative path after the installation package file is decompressed;

[0268] The ModuleDependencies field, which defines inter-module dependencies, includes the following subfields:

[0269] The dependent module name is one of the values ​​of the defined module name field ModuleName. The dependent module name includes the version number subfield ModuleVersion, the attribute supply subfield Provide, and the attribute requirement subfield Register of the dependent module.

[0270] The Provide subfield indicates the name and value of the attribute that the current module needs to provide to the dependent modules; the Register subfield indicates the name and value of the attribute that the dependent modules need to generate and transmit to the current module.

[0271] Furthermore, refer to Figure 1 In step S300, the template definition format includes the following fields:

[0272] The TemplateName field is used to uniquely describe the name of the current template.

[0273] The TemplateVersion field describes the version number of the current template.

[0274] The Modules field, which is used to declare the names of the modules that need to be imported in the current template, allows you to change the name of the imported module by renaming two modules with the same name.

[0275] The Relations field is used to declare the relationships between modules;

[0276] The Dispatches field, which is used to declare the relationship between a module and its deployment environment, describes the environment in which a module is deployed.

[0277] Specifically, a template is a blueprint for the system architecture, defining the system's topology by combining modules and environments. The template definition format is shown below:

[0278] Template: Template name xxx

[0279] Version: Template version number xxx

[0280] Modules:

[0281] - Module name a

[0282] - Module name b

[0283] - 'module_name b[Name=module_variable_name b2]'

[0284] - ...

[0285] Relations:

[0286] - Module name b: Module name a

[0287] - Module name b2: Module name a

[0288] - ...

[0289] Dispatches:

[0290] - Environment name xxx:

[0291] - Module name a

[0292] - Environment name xxx:

[0293] - Module name b

[0294] - Environment name xxx:

[0295] - Module name b2

[0296] - ...

[0297] Template: The name of the module to be declared, which must be globally unique.

[0298] Version: The version number of the template.

[0299] Modules: This is used to declare which modules will be used in the current template. If there are multiple modules, you can declare multiple modules. If two identical modules are imported, you can rename them to give them aliases.

[0300] Dispatches: Used to declare the deployment relationship between a module and its environment. That is, it describes in which environment a module is deployed. It's important to note that the environment in which a module is deployed must be specified according to the declaration in the module's definition; otherwise, it will be considered invalid.

[0301] Relations: Used to declare relationships between modules. For example, the format is module_name b: module_name a, where the left side is module_name b and the right side is module_name a. This means that module_name a is a module that module_name b depends on. This implies that the definition of module_name b may declare its dependency on module_name a within its dependency definition. However, if the definition of module_name b does not declare its dependency on module_name a within its dependency definition, then these two are not in a dependency relationship, but rather a regular association relationship. (A dependency relationship is defined to implement the dependence between two modules; while an association relationship is arbitrarily assigned by the architect based on the actual architecture, and the rationality of the association is determined by the architecture design.)

[0302] In a specific implementation, the example template instance PostgresqlMasterSlave2 is shown below:

[0303] Template: PostgresqlMasterSlave2

[0304] Version: 1.1.1

[0305] Modules:

[0306] - PostgresqlMaster

[0307] - PostgresqlSlave

[0308] - 'PostgresqlSlave[Name=PgSlave2]'

[0309] Dispatches:

[0310] - Host:

[0311] - PostgresqlMaster

[0312] - Host:

[0313] - PostgresqlSlave

[0314] - Host:

[0315] - PgSlave2

[0316] Relations:

[0317] - PgSlave2: PostgresqlMaster

[0318] - PostgresqlSlave: PostgresqlMaster

[0319] The template above first declares three modules: PostgresqlMaster, PostgresqlSlave, and PgSlave2. It then declares that PostgresqlMaster is deployed on one host, PostgresqlSlave on another, and PgSlave2 on a third. This clearly shows an architecture where one module is deployed on each of the three hosts. Finally, in the Relations section, it declares that PgSlave2 depends on a module named PostgresqlMaster within the PostgresqlMaster database, and the PostgresqlSlave depends on a module named PostgresqlMaster within the PostgresqlMaster database. Essentially, this establishes dependencies between the two slave databases and the master database. Therefore, this template example essentially describes a PostgreSQL database architecture with one master and two slaves.

[0320] Furthermore, refer to Figure 1 In step S400, the parsing engine includes:

[0321] The front-end page EngineWeb, the back-end service EngineServer, the message queue RabbitMQ used to transmit work order task flows, the work order system WorkOrderServer, and the configuration storage center Etcd;

[0322] The background service EngineServer includes a registry, a storage, a syntax parser, a deployment relationship parser, a dependency relationship parser, a deployment plan generator, a deployment plan executor, and a deployment plan status manager.

[0323] Specifically, the environment, modules, and templates are merely a grammatical foundation for achieving automation or semi-automation. Templates written using this grammar are submitted to the parsing engine, which then generates work order task flows.

[0324] First, the architecture design uses predefined environments, modules, and template syntax to design a system architecture template. This template is then submitted to the parsing engine, which parses it and generates numerous work orders. Each work order describes its task. These work orders can be completed manually or automatically. Each person completing a work order doesn't need to know the full system structure; they only need to complete the work order according to its description and provide feedback to the parsing engine. The parsing engine continuously receives feedback data from completed work orders. After all work orders are completed, the system architecture described in the template is deployed and ready to provide services.

[0325] Furthermore, refer to Figure 1 Step S400 includes the following steps:

[0326] S410. Upload the defined environment file (Environment), module file (Module), and template file (Template) through the front-end page EngineWeb.

[0327] S420: Send the Environment file, Module file, and Template file to the background service EngineServer to execute the parsing engine service;

[0328] S430, the background service EngineServer verifies the Environment file, Module file, and Template file, and saves the successfully verified Environment file, Module file, and Template file to the storage of the background service EngineServer;

[0329] S440. Submit the Environment file, Module file, and Template file to the backend service EngineServer for interpretation.

[0330] Specifically, the architecture design involves uploading environment files, module files, and template files that are defined according to format requirements to EngineWeb; these files are then uploaded to EngineServer, the parsing engine service; EngineServer validates the uploaded files based on syntax definition rules, and only those that pass validation are saved to the template storage; administrators can select a template and submit it to the parsing engine for parsing.

[0331] In one specific embodiment, the PostgresqlMasterSlave2 template example mentioned above will be used for explanation:

[0332] Template: PostgresqlMasterSlave2

[0333] Version: 1.1.1

[0334] Modules:

[0335] - PostgresqlMaster

[0336] - PostgresqlSlave

[0337] - 'PostgresqlSlave[Name=PgSlave2]'

[0338] Dispatches:

[0339] - Host:

[0340] - PostgresqlMaster

[0341] - Host:

[0342] - PostgresqlSlave

[0343] - Host:

[0344] - PgSlave2

[0345] Relations:

[0346] - PgSlave2: PostgresqlMaster

[0347] - PostgresqlSlave: PostgresqlMaster

[0348] 5. After the PostgreSQL MasterSlave2 template is submitted to the parsing engine, refer to... Figure 2 It will do the following:

[0349] (1) Syntax parser: Parses Modules and obtains the following information: To create a PostgresqlMaster module named PostgresqlMaster, to create a PostgresqlSlave module named PostgresqlSlave, and to create a PostgresqlSlave module named PgSlave2. Parses the Dispatches section and obtains the following information: To create a Host environment named Host1, to create a Host environment named Host2, and to create a Host environment named Host3; (Based on the definitions of environment and module, it is clear what needs to be done when creating a module or environment).

[0350] (2) Deployment Relationship Resolver: Parses the Dispatchers section and obtains the following information: The module named PostgresqlMaster should be deployed on the Host1 environment, the module named PostgresqlSlave should be deployed on the Host2 environment, and the module named PgSlave2 should be deployed on the Host3 environment. (Based on the module definition, it is clear how to deploy a certain module).

[0351] (3) Dependency Resolver: Parses the Relations section and obtains the following information: The module named PgSlave2 depends on the PostgresqlMaster module, which is also named PostgresqlMaster; the module named PostgresqlSlave depends on the PostgresqlMaster module, which is also named PostgresqlMaster. (Note: Currently, the dependency resolution is done manually. However, the module dependency definition has already been declared, which means that the conditions for subsequent automation are already in place.)

[0352] (4) Deployment plan generator: The information obtained from the above three steps is summarized and recorded into a DAG data structure. This data structure records multiple steps and what each step is to do.

[0353] (5) Deployment Plan Executor: The deployment plan executor parses the DAG data structure to generate multiple work orders. These work orders detail what needs to be done to complete the work order, as shown below:

[0354] ① Work order: Please apply for a Host environment named Host1 and report the CPU, memory, and other information of the applied host to the resolution engine.

[0355] ② Work Order Two: Please apply for a Host environment named Host2 and report the CPU, memory, and other information of the applied host to the parsing engine.

[0356] ③ Work Order 3: Please apply for a Host environment named Host3 and report the CPU, memory, and other information of the applied host to the parsing engine.

[0357] ④ Work order four: Please apply for a PostgresqlMaster module named PostgresqlMaster and obtain the documentation information for this module.

[0358] ⑤ Work Order 5: Please apply for a PostgresqlSlave module named PostgresqlSlave and obtain the documentation information for this module.

[0359] ⑥ Work Order Six: Please apply for a PostgresqlSlave module named PgSlave2 and obtain the documentation information for this module.

[0360] ⑦ Work Order 7: Please deploy the PostgresqlMaster module named PostgresqlMaster on the Host environment named Host1 according to the convention documentation, and report the deployed properties to the parsing engine.

[0361] ⑧ Work Order 8: Please deploy the PostgresqlSlave module named PostgresqlSlave on the Host environment named Host2 according to the convention documentation, and report the deployed properties to the parsing engine.

[0362] ⑨ Work Order Nine: Please deploy the PostgresqlSlave module named PgSlave2 on the Host environment named Host3 according to the convention documentation, and report the deployed properties to the parsing engine.

[0363] ⑩ Work Order 10: Please complete the dependency configuration of the PostgresqlSlave module named PostgresqlSlave and the PostgresqlMaster module named PostgresqlMaster according to the convention documentation, and report the deployed properties to the parsing engine.

[0364] ⑪ Work Order Eleven: Please complete the dependency configuration of the PostgresqlSlave module named PgSlave2 and the PostgresqlMaster module named PostgresqlMaster according to the convention documentation, and report the deployed properties to the parsing engine.

[0365] (6) These work order information will be sent to the WorkOrderServer by the deployment plan executor via RabbitMQ. The WorkOrderServer will provide a front-end page so that operations and maintenance personnel can view and submit work orders. After the work order is submitted, the data will be submitted to the configuration center ETCD for recording.

[0366] (7) Once all work orders are completed, the parsing of this template is finished (the deployment plan status manager is used to query the progress).

[0367] (8) Once the template is parsed, the actual architecture generated based on the template is deployed. In this way, the parsing engine drives the entire process to achieve semi-automation or full automation.

[0368] Furthermore, according to the method proposed in this invention, a master-slave PostgreSQL database architecture is designed, specifically including the following steps:

[0369] 1. Define the Host environment:

[0370] Environment: Host

[0371] Version: 1.1.1

[0372] Properties:

[0373] HostType: String

[0374] IP: 'String[]'

[0375] Os: String

[0376] Arch: String

[0377] Cpu: String

[0378] Memory: String

[0379] Disk: String

[0380] Bandwidth: String

[0381] 2. Define the PostgreSQLSlave module and the PostgreSQLMaster module:

[0382] 2.1 The information for the PostgreSQLSlave module is as follows:

[0383] Module: PostgresqlSlave

[0384] Version: 1.1.1

[0385] Properties:

[0386] Public:

[0387] Port: Integer

[0388] Address: String

[0389] Environments:

[0390] Host:

[0391] - Requirement:

[0392] Os: ubuntu 22.04.4

[0393] Arch: x64

[0394] InstallPackage:

[0395] ReleaseName: postgresql-10.23-1-linux-x64-binaries.tar.gz

[0396] Checksum: d41d8cd98f00b204e9800998ecf8427e

[0397] DeploymentFiles:

[0398] BinaryFile: . / pgsql / bin / pg_ctl

[0399] InitFile: . / pgsql / bin / initdb

[0400] SyncFile: . / pgsql / bin / pg_basebackup

[0401] ConfigFile:

[0402] - . / pgsql / share / postgresql / postgresql.conf.sample

[0403] - . / pgsql / share / postgresql / pg_hba.conf.sample

[0404] - Requirement:

[0405] Os: ubuntu 22.04.4

[0406] Arch: x86

[0407] InstallPackage:

[0408] ReleaseName: postgresql-10.23-1-linux-x86-binaries.tar.gz

[0409] 校验和:d41d8cd98f00b204e9800998ecf8427e

[0410] 部署文件:

[0411] 二进制文件:. / pgsql / bin / pg_ctl

[0412] 初始化文件:. / pgsql / bin / initdb

[0413] 同步文件:. / pgsql / bin / pg_basebackup

[0414] 配置文件:

[0415] - . / pgsql / share / postgresql / postgresql.conf.sample

[0416] - . / pgsql / share / postgresql / pg_hba.conf.sample

[0417] 模块依赖项:

[0418] Postgresql主服务器:

[0419] 模块版本:'>1.1.​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​

[0430] Properties:

[0431] Private:

[0432] AdminUser: String

[0433] AdminPassword: String

[0434] Public:

[0435] Port: Integer

[0436] Address: String

[0437] Environments:

[0438] Host:

[0439] - Requirement:

[0440] Os: ubuntu 22.04.4

[0441] Arch: x64

[0442] InstallPackage:

[0443] ReleaseName: postgresql-10.23-1-linux-x64-binaries.tar.gz

[0444] Checksum: d41d8cd98f00b204e9800998ecf8427e

[0445] DeploymentFiles:

[0446] BinaryFile: . / pgsql / bin / pg_ctl

[0447] InitFile: . / pgsql / bin / initdb

[0448] SyncFile: . / pgsql / bin / pg_basebackup

[0449] ConfigFile:

[0450] - . / pgsql / share / postgresql / postgresql.conf.sample

[0451] - . / pgsql / share / postgresql / pg_hba.conf.sample

[0452] - Requirement:

[0453] Os: ubuntu 22.04.4

[0454] Arch: x86

[0455] InstallPackage:

[0456] ReleaseName: postgresql-10.23-1-linux-x86-binaries.tar.gz

[0457] Checksum: d41d8cd98f00b204e9800998ecf8427e

[0458] DeploymentFiles:

[0459] BinaryFile: . / pgsql / bin / pg_ctl

[0460] InitFile: . / pgsql / bin / initdb

[0461] SyncFile: . / pgsql / bin / pg_basebackup

[0462] ConfigFile:

[0463] - . / pgsql / share / postgresql / postgresql.conf.sample

[0464] - . / pgsql / share / postgresql / pg_hba.conf.sample

[0465] 3. Write a template for one master and two slaves:

[0466] Template: PostgresqlMasterSlave2

[0467] Version: 1.1.1 [[ID=​​​​​

[0470] - PostgresqlSlave

[0471] - 'PostgresqlSlave[Name=PgSlave2]'

[0472] Dispatches:

[0473] - Host:

[0474] - PostgresqlMaster

[0475] - Host:

[0476] - PostgresqlSlave

[0477] - Host:

[0478] - PgSlave2

[0479] Relations:

[0480] - PgSlave2: PostgresqlMaster

[0481] - PostgresqlSlave: PostgresqlMaster

[0482] 4. Submit the template to the parsing engine, which will parse it according to the syntax rules to generate the following work order:

[0483] 4.1 Apply for an environmental work order:

[0484] 4.1.1 Apply for a work order for a Host environment named Host1. After completing the application, fill in the following information:

[0485] {"Ip":"","Os":"","Cpu":"","Arch":"","Disk":"","Memory":"","HostType":"","Bandwidth":""};

[0486] 4.1.2 Submit a support ticket for a Host environment named Host2. After submitting the application, fill in the following information:

[0487] {"Ip":"","Os":"","Cpu":"","Arch":"","Disk":"","Memory":"","HostType":"","Bandwidth":""};

[0488] 4.1.3 Request a work order for a Host environment named Host3. After completing the request, fill in the following information:

[0489] {"Ip":"","Os":"","Cpu":"","Arch":"","Disk":"","Memory":"","HostType":"","Bandwidth":""}.

[0490] 4.2 View the work order for the module (get installation package):

[0491] 4.2.1 View the ticket for the PostgresqlMaster module named PostgresqlMaster. After viewing it, please obtain all the installation packages and documentation for this module.

[0492] 4.2.2 View the ticket for the PostgresqlSlave module named PostgresqlSlave. After viewing it, please obtain all the installation packages and documentation for this module.

[0493] 4.2.3 View the ticket for the PostgresqlSlave module named PgSlave2. After viewing it, please obtain all the installation packages and documentation for this module.

[0494] 4.3 At this point, you need to complete the above-mentioned environment application work order and module viewing work order. After completion, you need to fill in the information back to the system. At this time, the system will record the following information:

[0495] 4.3.1 The Host environment named Host1 has the following properties:

[0496] {"Ip":"192.168.1.1","Os":"Centos","Cpu":"8","Arch":"X86","Disk":"500G","Memory":"10G","HostType":"VM","Bandwidth":"10G"};

[0497] 4.3.2 The Host environment named Host2 has the following properties:

[0498] {"Ip":"192.168.1.2","Os":"Centos","Cpu":"8","Arch":"X86","Disk":"500G","Memory":"10G","HostType":"VM","Bandwidth":"10G"};

[0499] 4.3.3 The Host environment named Host3 has the following properties:

[0500] {"Ip":"192.168.1.2","Os":"Centos","Cpu":"8","Arch":"X86","Disk":"500G","Memory":"10G","HostType":"VM","Bandwidth":"10G"}.

[0501] 4.4 The platform will then generate the following deployment work orders:

[0502] 4.4.1 Please deploy the PostgresqlMaster module named PostgresqlMaster on the Host environment named Host1, and fill in the AdminUser, AdminPassword, Address, and Port attribute information of the PostgresqlMaster module after deployment;

[0503] 4.4.2 Please deploy the PostgresqlSlave module named PostgresqlSlave on the Host environment named Host2, and fill in the Address and Port attribute information of the PostgresqlSlave module after deployment;

[0504] 4.4.3 Please deploy the PostgresqlSlave module named PgSlave2 on the Host environment named Host3, and fill in the Address and Port attribute information of the PgSlave2 module after deployment.

[0505] 4.5 At this point, you need to complete the deployment work order as described above. After completion, you need to fill the information back into the system, and the system will record the following information:

[0506] 4.5.1 The PostgresqlMaster module named PostgresqlMaster has the following AdminUser value: Postgres, AdminPassword: 123456, Address: 192.168.1.1, and Port: 5432;

[0507] 4.5.2 The PostgresqlSlave module named PostgresqlSlave has an Address value of 192.168.1.2 and a Port value of 5432;

[0508] 4.5.3 The PostgresqlSlave module named PgSlave2 has an Address value of 192.168.1.3 and a Port value of 5432.

[0509] 4.6 Next, the platform will generate the following work orders that require the completion of dependency configuration:

[0510] 4.6.1 Please create a dependency relationship between the PostgresqlSlave module named PostgresqlSlave and the PostgresqlMaster module named PostgresqlMaster (manual configuration), and have the PostgresqlMaster module provide values ​​for the SyncUser and SyncPassword properties.

[0511] 4.6.2 Please create a dependency relationship between the PostgresqlSlave module named PgSlave2 and the PostgresqlMaster module named PostgresqlMaster (manual configuration), and have the PostgresqlMaster module provide values ​​for the SyncUser and SyncPassword properties.

[0512] 4.7 At this point, you need to complete the work order for configuring the above dependencies. After completion, you need to fill in the information back to the system, and then the system will record the following information:

[0513] 4.7.1 The PostgresqlMaster module named PostgresqlMaster has added a new attribute for the PostgresqlSlave module: SyncUser, with the value pg1_sync_user and SyncPassword, with the value 123456.

[0514] 4.7.2 The PostgresqlMaster module named PostgresqlMaster has added a new attribute for the PgSlave2 module: SyncUser, with the value pg2_sync_user and SyncPassword, with the value 123456.

[0515] 4.8 Reference Figure 3 All work orders have been completed.

[0516] 4.8.1 The Host environment named Host1 has the following properties:

[0517] The environment has the following properties: {"Ip":"192.168.1.1","Os":"Centos","Cpu":"8","Arch":"X86","Disk":"500G","Memory":"10G","HostType":"VM","Bandwidth":"10G"} A PostgresqlMaster module named PostgresqlMaster is deployed on this environment. The properties of this PostgresqlMaster module are:

[0518] {"Address":"192.168.1.1","Port":"5432","SyncPassword":"123456","SyncUser":"pg2_sync_user","AdminPassword":"123456","AdminUser":"Postgres"};

[0519] 4.8.2 The Host environment named Host2 has the following properties:

[0520] The environment has the following properties: {"Ip":"192.168.1.2","Os":"Centos","Cpu":"8","Arch":"X86","Disk":"500G","Memory":"10G","HostType":"VM","Bandwidth":"10G"} A PostgreSQLSlave module named PostgresqlSlave is deployed on this environment. The properties of this PostgreSQLSlave module are:

[0521] {"Address":"192.168.1.2","Port":"5432"};

[0522] 4.8.3 The Host environment named Host3 has the following properties:

[0523] The environment has a PostgreSQL slave module named PgSlave2 deployed on it. The attributes of this PgSlave2 module are as follows: {"Ip":"192.168.1.3","Os":"Centos","Cpu":"8","Arch":"X86","Disk":"500G","Memory":"10G","HostType":"VM","Bandwidth":"10G"}

[0524] {"Address":"192.168.1.3","Port":"5432"}.

[0525] Furthermore, the present invention also proposes a computer-readable storage medium storing program instructions thereon, which, when executed by a processor, implement the task orchestration method for system deployment via declarative templates.

[0526] It should be understood that the method steps in the embodiments of the present invention can be implemented or carried out by computer hardware, a combination of hardware and software, or by computer instructions stored in a non-transitory computer-readable storage medium. The method can use standard programming techniques. Each program can be implemented in a high-level procedural or object-oriented programming language to communicate with the computer system. However, if necessary, the program can be implemented in assembly or machine language. In any case, the language can be a compiled or interpreted language. Furthermore, for this purpose, the program can run on a programmed application-specific integrated circuit (ASIC).

[0527] Furthermore, the procedures described herein may be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by the context. The procedures described herein (or variations and / or combinations thereof) may be executed under the control of one or more computer systems configured with executable instructions, and may be implemented by hardware or a combination thereof as code (e.g., executable instructions, one or more computer programs, or one or more applications) that commonly executes on one or more processors. The computer program comprises a plurality of instructions executable by one or more processors.

[0528] Furthermore, the method can be implemented in any suitable type of computing platform, including but not limited to personal computers, minicomputers, mainframes, workstations, networked or distributed computing environments, standalone or integrated computer platforms, or in communication with charged particle tools or other imaging devices, etc. Aspects of the invention can be implemented as machine-readable code stored on a non-transitory storage medium or device, whether removable or integrated into a computing platform, such as a hard disk, optical read and / or write storage medium, RAM, ROM, etc., such that it is readable by a programmable computer, and when the storage medium or device is read by the computer, it can be used to configure and operate the computer to perform the processes described herein. Furthermore, the machine-readable code, or portions thereof, can be transmitted via wired or wireless networks. The invention described herein includes these and other different types of non-transitory computer-readable storage media when such media comprises instructions or programs that implement the steps described above in conjunction with a microprocessor or other data processor. When programmed according to the methods and techniques described in the invention, the invention may also include the computer itself.

[0529] A computer program can be applied to input data to perform the functions described herein, thereby transforming the input data to generate output data stored in non-volatile memory. The output information can also be applied to one or more output devices, such as a display. In a preferred embodiment of the invention, the transformed data represents physical and tangible objects, including specific visual depictions of physical and tangible objects generated on the display.

[0530] The above description is merely a preferred embodiment of the present invention. The present invention is not limited to the above-described embodiments. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention, as long as they achieve the technical effects of the present invention by the same means, should be included within the scope of protection of the present invention. Within the scope of protection of the present invention, the technical solutions and / or implementation methods can have various modifications and variations.

Claims

1. A task-oriented orchestration method for system deployment using declarative templates, characterized in that, The declarative template includes a three-level abstract model: an environment for defining the infrastructure deployment carrier, modules for abstracting specific deployment units, and a basic template. The task-oriented orchestration method for system deployment using declarative templates includes the following steps: S100. If no available environment exists or a new environment needs to be created, define at least one environment based on the preset environment definition format and describe the specific attributes of the new environment. S200. If no available module exists or a new module needs to be created, define at least one module based on the preset module definition format, and describe the attributes, deployment process, dependencies, and maintenance process of the new module. In step S200, the module definition format includes the following fields: The module name field is used to uniquely describe the name of the current module. The module version number field describes the version of the current module definition; The module property list field is used to declare the property list of the current module; The available environment field is used to declare at least one deployable environment for the current module, and to declare and restrict the properties of the deployed environment; The inter-module dependency field is used to declare the dependency relationship between the current module and one or more other modules. If the current module does not depend on other modules, the inter-module dependency field is not needed. S300. If no available basic template exists or a new basic template needs to be created, define at least one basic template based on the preset template definition format. In step S300, the basic template definition format includes the following fields: The template name field is used to globally and uniquely describe the name of the current base template. The template version number field describes the version number of the current base template; The Dependency Module field is used to declare the names of modules that need to be imported in the current base template. If two modules have the same name, the name of the imported module will be changed by renaming it. The relationship field is used to declare the relationships between modules; The module deployment environment field is used to declare the relationship between the module and the deployment environment, that is, to describe in which environment a module is deployed; S400: The declarative template, containing a three-level abstract model of environment, module, and basic template, is sent to the parsing engine. The parsing engine parses the declarative template and generates a work order task flow, which will be executed in a semi-automatic or automatic manner. The parsing engine includes: a front-end page, a back-end service, a message queue for transmitting work order task flows, a work order system, and a configuration storage center.

2. The task-oriented orchestration method for system deployment using declarative templates as described in claim 1, characterized in that, In step S100, the environment definition format includes the following fields: The environment name field is used to uniquely describe the current environment. The environment version number field describes the version defined in the current environment; The Environment Property List field is used to declare the list of properties for the current environment.

3. The task-oriented orchestration method for system deployment using declarative templates as described in claim 2, characterized in that, The environment attribute list field includes one or more attribute key-value pairs. Each attribute key-value pair includes an attribute name and an attribute type. The attribute name is defined according to the actual situation of the current environment, and the attribute type is in string, integer, or floating-point format.

4. The task-oriented orchestration method for system deployment using declarative templates as described in claim 1, characterized in that, The module attribute list field includes a public attribute list for sharing between modules and a private attribute list that cannot be shared between modules under unauthorized circumstances. Both the public and private attribute lists include one or more attribute key-value pairs. Each attribute key-value pair includes an attribute name and an attribute type. The attribute name is defined according to the actual situation of the current module and environment, and the attribute type is in string, integer, or floating-point format.

5. The task-oriented orchestration method for system deployment using declarative templates as described in claim 1, characterized in that, The available environment fields include the following subfields: Available environment name, which is one of the defined environment name field values, including the requirement subfield, the installation package field, and the decompression file subfield; The requirement subfield is used to declare the attribute requirements of the current module on the available environment when it is deployed. The requirement subfield includes one or more attribute key-value pairs. The installation package field is used to indicate the location and name of the installation package when the current module is installed in an available environment. The installation package field includes the installation package name and the installation package MD5 checksum. The decompressed file subfield includes attribute key-value pairs that represent the type of the decompressed file and the relative path after the installation package file is decompressed; The inter-module dependency field includes the following subfields: The dependent module name is one of the defined module name field values, and the dependent module name includes the version number subfield, attribute supply subfield, and attribute requirement subfield of the dependent module. The attribute supply subfield is used to indicate the attribute name and attribute value that the current module needs to provide to the dependent modules; the attribute requirement subfield is used to indicate the attribute name and attribute value that the dependent modules need to generate and transmit to the current module.

6. The task-oriented orchestration method for system deployment using declarative templates according to claim 1, characterized in that, In step S400 The background services include a registry, a storage, a syntax parser, a deployment relationship parser, a dependency relationship parser, a deployment plan generator, a deployment plan executor, and a deployment plan state manager.

7. The task-oriented orchestration method for system deployment using declarative templates as described in claim 6, characterized in that, Step S400 includes the following steps: S410. Upload the defined Environment file, Module file, and Template file through the front-end page; S420: Send the Environment file, Module file, and Template file to the background service EngineServer to execute the parsing engine service; S430, the background service EngineServer verifies the Environment file, Module file, and Template file, and saves the successfully verified Environment file, Module file, and Template file to the storage of the background service EngineServer; S440. Submit the Environment file, Module file, and Template file to the backend service EngineServer for parsing.

8. A computer-readable storage medium, characterized in that, It stores program instructions, which, when executed by a processor, implement the task orchestration method for system deployment via declarative templates as described in any one of claims 1 to 7.

Images