Deployment model and deployment method and device based on deployment model

Abstract

The invention discloses a deployment model and a deployment method and device based on the deployment model, and relates to the technical field of application automatic deployment. A specific embodiment of the method comprises the following steps: a physical subsystem comprises a workspace attribute; the deployment unit is associated with the physical subsystem and comprises basic attributes and deployment mode attributes; the deployment mode attribute is a virtual machine deployment mode or a container deployment mode, the virtual machine deployment mode does not establish an association relationship between the deployment unit and the workspace attribute, and the container deployment mode establishes an association relationship between the deployment unit and the workspace attribute; the virtual machine is associated with the deployment unit; the container service is associated with the deployment unit and comprises deployment space attributes; the container instance is associated with a container service. According to the embodiment, the unified deployment model is constructed and comprises the virtual machine deployment mode and the container deployment mode, dynamic adjustment can be achieved, an automatic deployment tool does not need to be developed again, the flexibility is improved, and the learning cost is reduced.

Description

Technical Field

[0001] The present invention relates to the technical field of application automated deployment, and in particular to a deployment model, and a deployment method and device based on the deployment model. Background Art

[0002] Depending on the deployment carrier, the application deployment mode can be divided into two categories: virtual machine deployment and container deployment. However, there is currently no deployment model on the market that is compatible with both virtual machine deployment and container deployment. Therefore, the existing automated deployment tools generally only implement one type of deployment capability, or one module in the tool implements virtual machine deployment and one module implements container deployment. This means that once the user's management requirements for the deployment model change, it cannot be adjusted dynamically, and the new deployment model can only be adapted by developing new modules or new tools. Therefore, the existing separate design has the problem of low flexibility when facing changing needs. Summary of the invention

[0003] In view of this, the embodiments of the present invention provide a deployment model, a deployment method and a device based on the deployment model, which can at least solve the problem that the existing separate design has low flexibility when facing changing requirements.

[0004] To achieve the above-mentioned purpose, according to one aspect of an embodiment of the present invention, a deployment model is provided, including a physical subsystem, a deployment unit, a virtual machine, a container service and a container instance; the physical subsystem includes a workspace attribute; the deployment unit is associated with the physical subsystem, including basic attributes and deployment mode attributes; wherein the deployment mode attribute is a virtual machine deployment mode or a container deployment mode, and when the deployment mode attribute is a virtual machine deployment mode, an association relationship between the deployment unit and the workspace attribute is not established; when the deployment mode attribute is a container deployment mode, an association relationship between the deployment unit and the workspace attribute is established; the virtual machine is associated with the deployment unit and applied to the virtual machine deployment mode; the container service is associated with the deployment unit and applied to the container deployment mode, including deployment space attributes; the container instance is associated with the container service.

[0005] Optionally, receive configuration operations on workspace properties and deployment space properties:

[0006] To achieve the above-mentioned purpose, according to one aspect of an embodiment of the present invention, a deployment method based on a deployment model is provided, comprising: in response to a user's start operation on a deployment tool, displaying a list of physical subsystems, and receiving a physical subsystem selected by the user from the list of physical subsystems; determining and displaying a list of deployment units associated with the physical subsystem, and receiving a deployment unit selected by the user from the list of deployment units; wherein the number of user selections is one or more; determining a deployment mode attribute of the deployment unit, and when the deployment mode attribute is a virtual machine deployment mode, determining a virtual machine associated with the deployment unit; and / or when the deployment mode attribute is a container deployment mode, determining a container service associated with the deployment unit; in response to a user's selection operation on generating a model in the deployment tool, generating a target deployment model based on the physical subsystem, the deployment unit, the virtual machine and / or the container service, and the container instance associated with the container service.

[0007] Optionally, the method further includes: creating a collection of storage data for each node in a database; wherein the node is one or more of a physical subsystem, a deployment unit, a virtual machine, a container service, and a container instance; obtaining the value pre-configured for each node under the configuration field, integrating the configuration values ​​under all configuration fields for each node to obtain a data record, and storing each data record as an instance data in the collection corresponding to each node.

[0008] Optionally, storing each data record as an instance data in a set corresponding to each node includes: determining a data header of each data record, using the data header as a key name to form a key-value pair with the instance data, and storing the key-value pairs in a set corresponding to each node.

[0009] Optionally, displaying the physical subsystem list includes: obtaining physical subsystem instance data from a database, generating and displaying a physical subsystem list based on the physical subsystem instance data; determining the deployment mode attribute of the deployment unit includes: obtaining the instance data of the deployment unit from a database, and then obtaining the deployment mode attribute from the deployment unit instance data; determining the virtual machine associated with the deployment unit also includes: obtaining the instance data of the virtual machine from a database; determining the container service associated with the deployment unit also includes: obtaining the instance data of the container service from a database.

[0010] To achieve the above-mentioned purpose, according to another aspect of an embodiment of the present invention, a deployment device based on a deployment model is provided, comprising: a physical subsystem module, for displaying a list of physical subsystems in response to a user's start operation on a deployment tool, and receiving a physical subsystem selected by the user from the list of physical subsystems; a deployment unit module, for determining and displaying a list of deployment units associated with the physical subsystem, and receiving a deployment unit selected by the user from the list of deployment units; wherein the number of user selections is one or more; a virtual machine / container service module, for determining a deployment mode attribute of the deployment unit, and when the deployment mode attribute is a virtual machine deployment mode, determining a virtual machine associated with the deployment unit; and / or when the deployment mode attribute is a container deployment mode, determining a container service associated with the deployment unit; and a model generation module, for generating a target deployment model based on the physical subsystem, the deployment unit, the virtual machine and / or the container service, and a container instance associated with the container service in response to a user's selection operation on generating a model in the deployment tool.

[0011] Optionally, the device also includes a collection module, which is used to: create a collection of storage data for each node in the database; wherein the node is one or more of a physical subsystem, a deployment unit, a virtual machine, a container service, and a container instance; obtain the value pre-configured for each node under the configuration field, integrate the configuration values ​​under all configuration fields for each node, obtain a data record, and store each data record as an instance data in the collection corresponding to each node.

[0012] Optionally, the collection module is used to: determine the data header of each data record, use the data header as a key name, form a key-value pair with the instance data, and store it in a collection corresponding to each node.

[0013] Optionally, the physical subsystem module is used to: obtain physical subsystem instance data from a database, generate and display a physical subsystem list based on the physical subsystem instance data; the virtual machine / container service module is used to: obtain instance data of the deployment unit from a database, and then obtain deployment mode attributes from the deployment unit instance data; obtain instance data of the virtual machine from a database; obtain instance data of the container service from a database.

[0014] To achieve the above objective, according to another aspect of an embodiment of the present invention, a deployment electronic device based on a deployment model is provided.

[0015] The electronic device of an embodiment of the present invention includes: one or more processors; a storage device for storing one or more programs, and when the one or more programs are executed by the one or more processors, the one or more processors implement any of the above-mentioned deployment methods based on the deployment model.

[0016] To achieve the above objectives, according to another 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, any of the above-mentioned deployment methods based on the deployment model is implemented.

[0017] To achieve the above object, according to another aspect of an embodiment of the present invention, a computer program product is provided. A computer program product of an embodiment of the present invention includes a computer program, and when the program is executed by a processor, the deployment method based on the deployment model provided by an embodiment of the present invention is implemented.

[0018] According to the solution provided by the present invention, an embodiment of the above invention has the following advantages or beneficial effects: building a unified deployment model to make the deployment method of container applications close to the deployment of virtual machine applications, allowing the simultaneous management and deployment of virtual machine applications and container applications, solving the problem of low flexibility of existing separate designs when facing changing needs, and realizing dynamic adjustment of deployment models without redeveloping automated deployment tools, thereby improving flexibility and reducing learning costs, and helping to reduce potential human errors.

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

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

[0021] Figure 1 (a) is a schematic diagram of the structure of the virtual machine deployment model;

[0022] Figure 1(b) is a schematic diagram of an example of a virtual machine deployment model;

[0023] Figure 2 (a) is a schematic diagram of the structure of the container deployment model;

[0024] Figure 2(b) is a schematic diagram of an example of a container deployment model;

[0025] Figure 3 It is a schematic diagram of the structure of the unified deployment model;

[0026] Figure 4 It is a schematic diagram of the generation process of the unified deployment model;

[0027] Figure 5It is a main flow diagram of a deployment method based on a deployment model according to an embodiment of the present invention;

[0028] Figure 6 is a flow chart of an optional deployment method based on a deployment model according to an embodiment of the present invention;

[0029] Figure 7 This is a diagram for configuring container services;

[0030] Figure 8 is a flowchart of a deployment method specifically based on a deployment model according to an embodiment of the present invention;

[0031] Fig. 9 is a schematic diagram of main modules of a deployment device based on a deployment model according to an embodiment of the present invention;

[0032] Fig.10 is an exemplary system architecture diagram to which embodiments of the present invention may be applied;

[0033] Fig.11 It is a schematic diagram of the structure of a computer system of a mobile device or a server suitable for implementing an embodiment of the present invention. DETAILED DESCRIPTION

[0034] 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.

[0035] It should be noted that in the embodiments of the present application, certain software, components, models and other existing solutions in the industry may be mentioned, and they should be regarded as exemplary. Their purpose is only to illustrate the feasibility of implementing the technical solution of the present application, but it does not mean that the applicant has or will necessarily use the solution.

[0036] In the absence of conflict, the embodiments and features of the embodiments of the present invention can be combined with each other. The acquisition, transmission, storage, use, and processing of data in the technical solution of the present invention are in compliance with the relevant provisions of national laws and regulations, and are used for legal and reasonable purposes, and are not shared, disclosed, or sold outside of these legal uses, and are subject to supervision and management by regulatory authorities.

[0037] For user information, necessary measures should be taken to prevent illegal access to such personal information data, ensure that persons who have access to personal information data comply with relevant laws and regulations, and ensure the security of user personal information. Once such user personal information data is no longer needed, risks should be minimized by limiting or even prohibiting data collection and / or deleting data. When applicable, including in certain relevant applications, protect user privacy by de-identifying data, such as by removing specific identifiers (e.g., date of birth, etc.), controlling the amount or specificity of stored data (e.g., collecting location data at the city level rather than at the specific address level), controlling how data is stored, and / or other methods of de-identification.

[0038] The terms involved in this plan are explained as follows:

[0039] Deployment: refers to the process of deploying application services in virtual machines or containers.

[0040] Deployment model: A structural framework or specification formed by summarizing the necessary physical or virtual resources involved in the deployment process.

[0041] MongoDB: A non-relational database that stores data in documents in JSON format and supports structured queries.

[0042] JSON: A lightweight data exchange format that uses key-value pairs to express an object.

[0043] Virtual machine: refers to a complete computer system that is simulated by software and has complete hardware system functions and runs in a completely isolated environment.

[0044] Deployment unit: A group of deployment resources with the same functions under an application system. A deployment unit can contain several nodes. Generally, it is required that exactly the same application system or service module be deployed on these nodes, that is, one deployment unit can provide a cluster of application services.

[0045] Container: A new way of packaging and deploying software. Its core idea is to encapsulate the application and its required operating environment (including code, runtime, system tools, system libraries, etc.) into a standardized image, and then reliably start and run this image on any platform that supports container technology.

[0046] Kubernetes: A container orchestration engine that supports automated deployment, large-scale scalability, and containerized application management. In this article, it can be understood as a low-level tool software for deploying and managing container applications. It is referred to as K8s for short.

[0047] Pod: The smallest deployable computing unit created and managed in Kubernetes, which encapsulates an application container, storage resources, an IP address, and options that control how the container should run.

[0048] The deployment of virtual machines is relatively traditional. After users connect to the virtual machine through tools, they need to install the corresponding basic software (such as JDK, Tomcat, etc.) on it, upload the application package, and start the application through scripts or commands. When deploying a virtual machine, you generally only need to know the virtual machine IP (Internet Protocol) to start deployment. However, in the process of enterprise-level automated deployment, hundreds of application systems, thousands or even tens of thousands of virtual machines will be involved. In order to facilitate unified management, a corresponding deployment model will be planned, and the deployment model and instance data at all levels will be managed and maintained through configuration management tools. The deployment model of a virtual machine is generally physical subsystem-deployment unit-virtual machine from top to bottom, as shown in Figure 1 (a).

[0049] See Figure 1 (b), which shows the example data of a typical virtual machine deployment model. In the example, "Customer Channel-Customer Channel Service" is a logical subsystem, indicating that this system serves the business related to customer channels. It is a virtual concept in business and does not correspond to actual applications. It has four physical subsystems, such as "Customer Channel Service-Public", "Customer Channel Message Service Subsystem", "Customer Channel Public Management Subsystem", and "Electronic Identity Authentication Security Gateway". These physical subsystems can be understood as sub-business modules of customer channel services. Each physical subsystem can provide corresponding service capabilities and can correspond to actual application services.

[0050] Under the physical subsystem of "Customer Channel Service - Corporate", there are three deployment units (CCCAP, CCCDB, CCCWB), which are also virtual concepts. A deployment unit represents a combination of a group of virtual machines, and each deployment unit is responsible for only providing one service, such as CCCWB is responsible for deploying the front-end page of the application, and CCCDB is responsible for deploying the database of the application; under the deployment unit CCCAP, there are 4 virtual machines, whose host names are bd61apcccap1001, etc. They are real deployment resource entities. When deploying virtual machine applications, users need to first select the physical subsystem in the automated deployment tool, and then further select the deployment unit. The tool automatically selects the virtual machine under this deployment unit as the deployment target.

[0051] Container deployment is a relatively new deployment method that requires the use of some container management tools (mainstream K8s). Users only need to compile the basic software required for the application (including the operating system, JDK (Java Development Kit), Tomcat, etc.) and the application package into an image file, and run the image file through the container management tool. This is a faster and more efficient deployment method. When deploying containers, according to the operating mechanism of K8s, the workspace, application system, deployment space, and container service need to be clearly defined from top to bottom, and K8s automatically allocates running containers (i.e., Pods), as shown in Figure 2 (a), where the workspace refers to the environment used by developers or teams to develop, build, and test software. The deployment space usually refers to the environment used to run and manage production applications.

[0052] See Figure 2 (b), which shows the instance data of a typical container deployment model. In the figure, private-jgshan-ead is a workspace, and the resources in different workspaces are completely isolated. ead is an application system, and its "number of deployment spaces" is 3, but it is not shown in the figure. There are several services under the application system, such as springdemo, test1225, etc. The relationship between deployment space and service is many-to-many, that is, multiple services can be deployed under one deployment space, and one service can also be deployed across multiple deployment spaces. Under each service, there can be one or more pod instances, such as springdemo-1.

[0053] Container deployment has become a general trend due to its advantages such as low resource consumption, fast deployment, automatic deployment, automatic scaling, and good portability. Well-known companies have gradually transformed to containerized deployment. During the transformation process, technical personnel need to accept many new concepts and new models of containers and encounter many difficulties. Therefore, the learning cost of the deployment model of container applications is high, which is not conducive to the transition of development and operation personnel to containerized deployment. In addition, the models of virtual machine deployment and container deployment are currently fixed, and the two deployment modes are not compatible. Virtual machines and containers cannot be deployed at the same time in a single deployment process. This means that once the customer's management requirements for the deployment model change, it cannot be adjusted dynamically, and the only way to adapt to the new deployment model is to develop new modules or new tools.

[0054] See also Figure 3 , shows a deployment model architecture diagram provided by an embodiment of the present invention, including a physical subsystem, a deployment unit, a virtual machine, a container service, and a container instance. According to the above description, when comparing the container deployment model with the virtual machine deployment model, the "application system" is similar to the "physical subsystem" in the virtual machine deployment model. Apart from this, the other model concepts of the two cannot be compared, such as "workspace", "deployment space", and "service" cannot be mapped to the virtual machine deployment model at all.

[0055] The software system of the present invention is a tool for deploying applications (referring to business systems). However, the present invention does not emphasize the software itself, but a deployment model designed in software development and its implementation scheme. This scheme first conceptually combines the deployment models of virtual machines and containers, see Figure 4 shown.

[0056] 1. The "physical subsystem" in the virtual machine deployment model and the "application system" in the container deployment model have the same meaning and can be directly mapped.

[0057] 2. Starting from the physical subsystem / application system, analyze upward: the logical subsystem is a concept that is basically not used in virtual machine deployment. After the physical subsystem is clarified, the logical subsystem has no practical effect and can be discarded. The workspace is a necessary layer in container deployment, but it has a one-to-many relationship with the application system. After the application system is clarified, you can know the workspace to which it belongs. It is preferred to use "workspace" as an attribute of the application system.

[0058] 3. Analyze downward step by step: The "deployment unit" in the virtual machine deployment model is actually a virtual concept, which often represents one or more business modules in terms of function. These "business modules" can basically correspond to the "services" in the container model in terms of usage. Therefore, the concept of "deployment unit" can be introduced in the container deployment model, and it has a one-to-many relationship with "services".

[0059] 4. In the container deployment model, the relationship between application system and deployment space, and between deployment space and service is one-to-many. Therefore, the relationship between application system and service can also be considered one-to-many. For example, there are two deployment spaces under one application system, and three services under each deployment space. Then the relationship between application system and service is one-to-six. Deployment space is a necessary level in the container model. The same as "workspace-application system". It can also be inferred from the subordinate service to its deployment space. Therefore, "deployment space" can be considered as an attribute of the service.

[0060] 5. Both virtual machines and Pods are instance data, but virtual machines are static resources that have been allocated before application deployment. Generally, their CPU, memory, capacity, IP and other attributes are unchanged. Pods are dynamically generated by K8s when applications are deployed, and their CPU, memory, capacity, IP and other attributes may be different each time they are released. Therefore, the two cannot be compared equally.

[0061] In order to make the physical subsystem compatible with container deployment, it must have a "workspace" attribute. This solution preferably sets the workspace attribute to remain in the open state. The workspace attribute value depends on manual setting. The workspace attribute should be defined as a configurable feature to indicate whether the physical subsystem needs to create an independent work environment for a specific deployment unit. This attribute can be set through a configuration file or an environment variable, and the user is allowed to manually adjust it according to needs. The deployment unit has a one-to-many relationship with the physical subsystem. Assuming that there are two deployment units, A1 and A2, and the deployment mode of A1 is the virtual machine deployment mode, the deployment unit A1 does not establish an association relationship with the workspace attribute of the physical subsystem. Since it does not involve the workspace attribute, this setting can be ignored in the configuration or explicitly specified as closed, such as not selected; the deployment mode of A2 is the container deployment mode, and the deployment unit A2 establishes an association relationship with the workspace attribute of the physical subsystem to ensure that the containerized physical subsystem can correctly initialize and maintain its workspace.

[0062] The deployment unit was originally a concept in virtual machine deployment, so it only has basic attributes such as name, type, and operating system account. In order to be compatible with container deployment, this solution extends the "deployment mode" attribute for the deployment unit. If the tool program is allowed to determine whether to search for a virtual machine or a container service after selecting a deployment unit, the deployment unit must have the "deployment mode (virtual machine / container)" attribute. Therefore, in the unified deployment model, the resource attributes at each level must be scalable, such as the deployment unit, physical subsystem, and other levels, all of which need to have the ability to expand.

[0063] A virtual machine is associated with a deployment unit, and there is a one-to-many relationship between a deployment unit and a virtual machine. A container service is associated with a deployment unit, and there is a one-to-many relationship between a deployment unit and a container service. For example, container services have a1 and a2, and a1 and a2 are associated with A2. The deployment space attribute is set in container services a1 and a2. This attribute is set manually and cannot be empty. A running container instance is associated with a container service, and there is a one-to-many relationship. For example, container service a1 can support running container instances C1 and C2.

[0064] The model provided by the above embodiment can flexibly support different types of deployment requirements by defining different deployment mode attributes (virtual machine deployment mode or container deployment mode) for the deployment unit. The virtual machine and container services are managed uniformly under the deployment unit, which simplifies the operation and maintenance work and improves resource utilization. The deployment models of virtual machine applications and container applications are merged and associated as a whole to form a unified deployment model. This model makes the deployment method of container applications close to the deployment of virtual machine applications, thereby allowing the simultaneous management and deployment of virtual machine applications and container applications, realizing dynamic adjustment of the deployment model without the need to redevelop automated deployment tools, improving flexibility and reducing learning costs, and helping to reduce potential human errors.

[0065] See also Figure 5 , shows a schematic diagram of a deployment method flow based on a deployment model according to an embodiment of the present invention, comprising the following steps:

[0066] S501: In response to a user's start operation on a deployment tool, displaying a physical subsystem list, and receiving a physical subsystem selected by the user from the physical subsystem list;

[0067] S502: Determine and display a deployment unit list associated with the physical subsystem, and receive a deployment unit selected by a user from the deployment unit list; wherein the user selects one or more times;

[0068] S503: Determine a deployment mode attribute of the deployment unit, and when the deployment mode attribute is a virtual machine deployment mode, determine a virtual machine associated with the deployment unit; and / or when the deployment mode attribute is a container deployment mode, determine a container service associated with the deployment unit;

[0069] S504: In response to the user's selection operation on generating a model in the deployment tool, a target deployment model is generated based on the physical subsystem, the deployment unit, the virtual machine and / or the container service and the container instance associated with the container service.

[0070] In the above implementation, if a customer's original application system is deployed through a virtual machine, then in the process of generating a deployment model, he needs to click to start the automated deployment tool. In response to this operation, the automated deployment tool first displays a list of physical subsystems. The user first selects a physical subsystem and then further selects a deployment unit. Since there can be multiple deployment units, there may be both virtual machines and container services. Therefore, it is necessary to select a deployment unit first. When the deployment mode attribute of the selected deployment unit is a virtual machine deployment mode, the tool automatically selects the virtual machine under this deployment unit as the deployment target. After the user clicks the option to generate a model, a virtual machine deployment model is generated based on the physical subsystem, deployment unit, and virtual machine. For example, the user selects the physical subsystem P1, and then selects A1 from the deployment units A1 (virtual machine deployment mode) and A2 (container deployment mode). The tool automatically selects the virtual machine V1 under A1 as the deployment target.

[0071] The same applies to container-only deployment operations. The user clicks to start the automated deployment tool. After the automated deployment tool responds to the user's startup operation, it displays a list of all available physical subsystems for the user to select. The user selects a physical subsystem from the list of physical subsystems. The system then displays a list of all deployment units related to the selected physical subsystem. The user selects one or more deployment units from the list of deployment units. If the deployment mode of the deployment unit selected by the user is the container deployment mode, the tool automatically selects the container service under this deployment unit as the deployment target. The user clicks the "Generate Model" option. According to the user's selection, the automated deployment tool generates the corresponding deployment model based on the physical subsystem, deployment unit, virtual machine, container service, and container instance associated with the container service. For example, if the user selects A2 from A1 and A2, the tool automatically selects container services a1 and a2 under A2 and their associated container instances as deployment targets.

[0072] Later, some of this customer's application systems were transformed into containers, and there were cases of parallel deployment of virtual machine containers. You need to re-operate the automated deployment tool to generate a new virtual machine container parallel deployment model. The user can repeat the above operation, that is, select the physical subsystem, deployment unit (the deployment unit can be different from the previous selection, but it is also a deployment unit of the virtual machine deployment mode), and virtual machine. Then select the deployment unit with the deployment mode attribute of the container deployment mode for the second time, and the tool automatically selects the container service under this deployment unit as the deployment target. After the user clicks the Generate Model option, a virtual machine container parallel deployment model is generated based on the physical subsystem, deployment unit, virtual machine, container service, and container instance associated with the container service.

[0073] The method provided in the above embodiment provides a more flexible and unified deployment solution, which not only simplifies the deployment process, but also reduces the learning cost of the team. Users can choose different physical subsystems and deployment units according to actual needs, support virtual machines, containers, and hybrid deployment modes to meet diverse deployment needs. The unified management of virtual machines and container services through deployment units simplifies the operation and maintenance workflow and improves resource utilization. Users can dynamically adjust the deployment model according to actual conditions, and only need to perform one or several simple selection operations to complete the construction of the deployment model. There is no need to redevelop automated deployment tools, which reduces operational complexity and learning costs, improves deployment efficiency and reduces the operation and maintenance burden. With this unified deployment model, enterprises can manage their infrastructure more efficiently, whether in a cloud environment or a local data center.

[0074] See also Figure 6 , shows a schematic diagram of a deployment method flow based on a deployment model according to an embodiment of the present invention, comprising the following steps:

[0075] S601: Create a collection of storage data for each node in a database; wherein a node is one or more of a physical subsystem, a deployment unit, a virtual machine, a container service, and a container instance;

[0076] S602: Obtain the value pre-configured for each node under the configuration field, integrate the configuration values ​​under all configuration fields for each node to obtain a data record, and store each data record as an instance data in a set corresponding to each node.

[0077] In the method provided in the above embodiment, for steps S601 and S602, the present invention preferably uses MongoDB to design the hierarchy and attributes of deployment resources. MongoDB has the characteristic of schema freedom, and its concept of "collection" is similar to the table in MySQL, but it does not need to define any schema and can use fewer data objects to represent complex domain model objects. For example, in the "deployment unit" collection, there can be several deployment unit instance data, some deployment unit instances have "operating system account" attributes (for virtual machines), and other deployment unit instances, such as containers, generally do not have these attributes.

[0078] This solution first designs a set config_model that represents the deployment model hierarchy, as shown in the following table (only key information is listed):

[0079]

[0080] Among them, table_name can be understood as a "directory", indicating which collection the data of this level is stored in; attrList is a list, and each data in the list represents an attribute of this level; isUse controls whether this level is enabled, and Y means it is used. Different collections are used to store instance data of different levels, such as storing specific virtual machine data in the config_host collection and storing specific container services in the container_service collection.

[0081] The data in these instance collections are all stored in JSON format, and the key in JSON comes from the attrList in the model collection. Taking the virtual machine as an example, specifically, obtain the values ​​pre-configured for the virtual machine under the configuration fields, such as the specific configuration values ​​under the name field and the code field. Integrate the configuration values ​​under all configuration fields for the virtual machine to obtain data records, such as {name: "", code: "}, and treat each data record as an instance data. Determine the data header of each data record and use the data header as the key name. For example, if the name is at the column header, use the name as the key. The column header can also be in the form of a primary key, such as sorting 1, 2, 3, then use it as the key. The key and instance data are combined into a key-value pair and stored in the collection corresponding to the virtual machine in JSON format.

[0082] Container services rely on deployment spaces. Figure 7 The following is a configuration diagram, and the list on the right is the detailed content of attrList. As can be seen from the figure, for the "container service" level, in order to associate it with the deployment space, the "belonging deployment space" and other attributes are specially set for it. For example, container_service includes "kyNamespaceId":111, / / redundant field, the id of the deployment space in the container platform, "containerNamespaceId":2222, / / the id of the deployment space to which the service belongs, "namespaceName":"mspl3", / / redundant field, the name of the deployment space to which the service belongs.

[0083] The deployment space actually contains many attributes (such as network, machine resources, etc.), but it is impossible to add all the attributes of the deployment space to the "service". Instead, the id of the deployment space is added to the service, which is equivalent to establishing an association relationship. Therefore, the most critical thing here is the "deployment space id". "Deployment space" and "deployment space id" are both used for redundancy. Considering that the relationship between the deployment space and the container service is many-to-many, in order to facilitate search, the storage collection of the deployment space can also be set, as shown in Table 2. In the table, N means unavailable, such as the SYSTEM logical subsystem above, because it is N, it means that this data is not used.

[0084]

[0085] In addition to using MongoDB to implement dynamic expansion of model attributes, it can also be implemented using relational databases such as MySql. For example, create a model table with several rows of data, where a row of data represents a specific instance data, such as a row of data representing "deployment unit A" and a row of data representing "virtual machine 1". Each row of data has an attributes field, which stores text in JSON format. When it is necessary to expand the attributes of deployment unit A, all its latest attributes are formatted into a JSON string and stored in attributes. However, in this way, the association between model data cannot be realized using the foreign keys of a relational database, because the attributes of "deployment unit A" and the attributes of "virtual machine 1" themselves cannot be associated, resulting in relatively low query efficiency. Therefore, this solution prefers to use MongoDB.

[0086] The method provided in the above embodiment uses MongoDB to create a special collection for each node to store data, ensuring that the data organization structure is clear and easy to manage and query. This structure can ensure that the levels of the deployment model and the attributes of each level can be dynamically expanded, and new node types can be easily added or the functions of existing nodes can be expanded. By integrating the configuration values ​​under all configuration fields of each node, the configuration management process is simplified and the possibility of errors is reduced. Each data record of the node is stored as an instance data, which is convenient for subsequent data retrieval and analysis, and improves data processing efficiency.

[0087] See also Figure 8 , shows a schematic diagram of a deployment method flow chart based on a deployment model according to an embodiment of the present invention, comprising the following steps:

[0088] S801: in response to opening the automated deployment tool, obtaining physical subsystem instance data from MongoDB, generating and displaying a physical subsystem list according to the physical subsystem instance data, and a user selecting a physical subsystem;

[0089] S802: Determine and display a list of deployment units associated with the physical subsystem, and the user selects a deployment unit; wherein the number of times the user selects is one or more;

[0090] S803: Obtain instance data of the deployment unit from MongoDB, and determine whether it is a virtual machine deployment mode or a container deployment mode according to a deployment mode attribute in the deployment unit instance data;

[0091] S804: If it is a virtual machine deployment mode, determine the virtual machine associated with the deployment unit, and obtain instance data of each virtual machine from MongoDB;

[0092] S805: If it is a container deployment mode, determine the container service associated with the deployment unit, and obtain instance data of each container service from MongoDB;

[0093] S806: In response to the user's selection operation on generating a model in the deployment tool, a virtual machine deployment model, a container deployment model, or a hybrid deployment model is generated based on the acquired content.

[0094] In the above implementation, for the physical subsystem list, the automated deployment tool obtains the physical subsystem instance data from MongoDB and generates it based on the physical subsystem instance data. Similarly, the deployment mode of the deployment unit can also be obtained from the instance data of the deployment unit. As for which virtual machines are associated with the deployment unit selected by the user, it can also be obtained from the instance data of the deployment unit, and then the instance data of the virtual machines can be obtained from MongoDB. As for which container services are associated with the deployment unit selected by the user, it can also be obtained from the instance data of the deployment unit, and then the instance data of the container services can be obtained from MongoDB.

[0095] As in the previous example, a certain customer's original application systems were all deployed through virtual machines. Later, part of this customer's application systems were transformed into containers, and there were situations where virtual machines and containers were deployed in parallel. Corresponding to the prior art, the original deployment unit had no deployment mode, while the new deployment unit of this application has a deployment mode, and can be a virtual machine or a container. Due to the characteristics of MongoDB, both new and old data can be stored and read normally. In addition, the product to which the present invention belongs defaults to the logical processing of "when there is a deployment mode and it is a container, it is processed as container deployment; in any other case, it is processed as virtual machine deployment", so there is no need to make any transformation and development to the product, that is, it can process virtual machine and container deployment units at the same time.

[0096] See also Fig. 9 , which shows a schematic diagram of main modules of a deployment device 900 based on a deployment model provided by an embodiment of the present invention, including:

[0097] The physical subsystem module 901 is used to display a physical subsystem list in response to a user's start operation on the deployment tool, and receive a physical subsystem selected by the user from the physical subsystem list;

[0098] A deployment unit module 902 is used to determine and display a deployment unit list associated with the physical subsystem, and receive a deployment unit selected by a user from the deployment unit list; wherein the user selects one or more times;

[0099] A virtual machine / container service module 903 is used to determine the deployment mode attribute of the deployment unit, and when the deployment mode attribute is a virtual machine deployment mode, determine the virtual machine associated with the deployment unit; and / or when the deployment mode attribute is a container deployment mode, determine the container service associated with the deployment unit;

[0100] The model generation module 904 is used to generate a target deployment model based on the physical subsystem, the deployment unit, the virtual machine and / or the container service and the container instance associated with the container service in response to the user's selection operation of generating a model in the deployment tool.

[0101] The implementation device of the present invention also includes a collection module, which is used to:

[0102] Creating a collection of storage data for each node in a database; wherein a node is one or more of a physical subsystem, a deployment unit, a virtual machine, a container service, and a container instance;

[0103] The value pre-configured for each node under the configuration field is obtained, the configuration values ​​under all configuration fields are integrated for each node to obtain a data record, and each data record is taken as an instance data and stored in a set corresponding to each node.

[0104] In the implementation device of the present invention, the collection module is used to:

[0105] The data header of each data record is determined, and the data header is used as a key name to form a key-value pair with the instance data, and is stored in a set corresponding to each node.

[0106] The physical subsystem module 901 in the implementation device of the present invention is used to: obtain physical subsystem instance data from a database, generate a physical subsystem list according to the physical subsystem instance data, and display it;

[0107] The virtual machine / container service module 903 is used to: obtain the instance data of the deployment unit from the database, and then obtain the deployment mode attribute from the deployment unit instance data;

[0108] Acquire instance data of the virtual machine from a database;

[0109] The instance data of the container service is obtained from the database.

[0110] In addition, the specific implementation content of the device described in the embodiment of the present invention has been described in detail in the method described above, so the repeated content will not be described again here.

[0111] Fig.10 An exemplary system architecture 1000 to which embodiments of the present invention may be applied is shown, including terminal devices 1001 , 1002 , 1003 , a network 1004 , and a server 1005 (only an example).

[0112] Terminal devices 1001, 1002, 1003 can be various electronic devices with display screens and supporting web browsing, and various communication client applications are installed. Users can use terminal devices 1001, 1002, 1003 to interact with server 1005 through network 1004 to receive or send messages, etc.

[0113] The network 1004 is used to provide a medium for communication links between the terminal devices 1001, 1002, 1003 and the server 1005. The network 1004 may include various connection types, such as wired, wireless communication links or optical fiber cables.

[0114] The server 1005 may be a server that provides various services, such as a backend management server that provides support for shopping websites browsed by users using terminal devices 1001, 1002, and 1003 (for example only). 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 - for example only) to the terminal device. It should be noted that the method provided in the embodiment of the present invention is generally executed by the server 1005, and accordingly, the device is generally set in the server 1005.

[0115] It should be understood that Fig.10 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 the implementation requirements.

[0116] Reference below Fig.11 , which shows a schematic diagram of the structure of a computer system 1100 of a terminal device suitable for implementing an embodiment of the present invention. Fig.11 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.

[0117] like Fig.11As shown, the computer system 1100 includes a central processing unit (CPU) 1101, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1102 or a program loaded from a storage portion 1108 into a random access memory (RAM) 1103. In the RAM 1103, various programs and data required for the operation of the system 1100 are also stored. The CPU 1101, the ROM 1102, and the RAM 1103 are connected to each other via a bus 1104. An input / output (I / O) interface 1105 is also connected to the bus 1104.

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

[0119] 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 contains 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 1109, and / or installed from the removable medium 1111. When the computer program is executed by the central processing unit (CPU) 1101, the above-mentioned functions defined in the system of the present invention are executed.

[0120] 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.

[0121] 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.

[0122] The modules involved in the embodiments of the present invention may be implemented in software or hardware. The modules described may also be provided in a processor. For example, they may be described as follows: a processor includes a physical subsystem module, a deployment unit module, a virtual machine / container service module, and a model generation module. The names of these modules do not, in some cases, constitute limitations on the modules themselves. For example, the model generation module may also be described as a "deployment model generation module."

[0123] 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 executes any of the above deployment methods based on the deployment model.

[0124] The computer program product of the present invention comprises a computer program, and when the computer program is executed by a processor, the deployment method based on the deployment model in the embodiment of the present invention is implemented.

[0125] 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 deployment model, It is characterized in that Includes physical subsystems, deployment units, virtual machines, container services, and container instances; The physical subsystem includes workspace attributes; The deployment unit is associated with the physical subsystem, including basic attributes and deployment mode attributes; wherein the deployment mode attribute is a virtual machine deployment mode or a container deployment mode. When the deployment mode attribute is a virtual machine deployment mode, an association relationship between the deployment unit and the workspace attribute is not established; when the deployment mode attribute is a container deployment mode, an association relationship between the deployment unit and the workspace attribute is established; The virtual machine is associated with the deployment unit and applied to the virtual machine deployment mode; The container service is associated with the deployment unit and is applied to the container deployment mode, including deployment space attributes; The container instance is associated with the container service.

2. The model according to claim 1, It is characterized in that Also includes: Receives configuration operations on workspace properties and deployment space properties.

3. A deployment method based on the deployment model of claim 1, It is characterized in that include: In response to a user's start operation on the deployment tool, displaying a physical subsystem list, and receiving a physical subsystem selected by the user from the physical subsystem list; Determine and display a deployment unit list associated with the physical subsystem, and receive a deployment unit selected by a user from the deployment unit list; wherein the user selects one or more times; Determine a deployment mode attribute of the deployment unit, and when the deployment mode attribute is a virtual machine deployment mode, determine a virtual machine associated with the deployment unit; and / or when the deployment mode attribute is a container deployment mode, determine a container service associated with the deployment unit; In response to a user's selection operation of generating a model in a deployment tool, a target deployment model is generated based on the physical subsystem, the deployment unit, the virtual machine and / or the container service and a container instance associated with the container service.

4. The method according to claim 3, It is characterized in that The method further comprises: Creating a collection of storage data for each node in a database; wherein a node is one or more of a physical subsystem, a deployment unit, a virtual machine, a container service, and a container instance; The value pre-configured for each node under the configuration field is obtained, the configuration values ​​under all configuration fields are integrated for each node to obtain a data record, and each data record is taken as an instance data and stored in a set corresponding to each node.

5. The model according to claim 4, It is characterized in that The storing each data record as an instance data in a set corresponding to each node includes: The data header of each data record is determined, and the data header is used as a key name to form a key-value pair with the instance data, and is stored in a set corresponding to each node.

6. The method according to claim 4, It is characterized in that The displaying of the physical subsystem list includes: acquiring physical subsystem instance data from a database, generating and displaying the physical subsystem list according to the physical subsystem instance data; The determining of the deployment mode attribute of the deployment unit includes: acquiring instance data of the deployment unit from a database, and then acquiring the deployment mode attribute from the deployment unit instance data; The determining the virtual machine associated with the deployment unit further includes: acquiring instance data of the virtual machine from a database; The determining the container service associated with the deployment unit further includes: acquiring instance data of the container service from a database.

7. A deployment device based on the deployment model of claim 1, It is characterized in that include: The physical subsystem module is used to display a physical subsystem list in response to a user's start operation on the deployment tool, and receive a physical subsystem selected by the user from the physical subsystem list; A deployment unit module, used to determine and display a deployment unit list associated with the physical subsystem, and receive a deployment unit selected by a user from the deployment unit list; wherein the user selection number is one or more times; A virtual machine / container service module, used to determine a deployment mode attribute of the deployment unit, and when the deployment mode attribute is a virtual machine deployment mode, determine a virtual machine associated with the deployment unit; and / or when the deployment mode attribute is a container deployment mode, determine a container service associated with the deployment unit; The model generation module is used to generate a target deployment model based on the physical subsystem, the deployment unit, the virtual machine and / or the container service and the container instance associated with the container service in response to the user's selection operation of generating a model in the deployment tool.

8. An electronic device, It is 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 3 to 6.

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

10. A computer program product comprising a computer program, It is characterized in that When the computer program is executed by a processor, the method according to any one of claims 3 to 6 is implemented.

Images