Automatic deployment system and method based on OpenStack
By employing a hybrid database architecture and closed-loop state management, the problem of insufficient state tracking during OpenStack deployment is resolved, enabling efficient and secure automated deployment of the cloud platform. This avoids redundant deployments and resource waste, and meets high-level security audit requirements.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SOUTHWEST PETROLEUM UNIV
- Filing Date
- 2026-03-05
- Publication Date
- 2026-05-01
AI Technical Summary
Existing technologies lack unified scheduling and state tracking during OpenStack deployment, leading to redundant deployments and wasted resources. Furthermore, log security is insufficient, failing to meet high-level security auditing and compliance requirements.
A hybrid database architecture is adopted, using a relational database to store node status and deployment task metadata, and a non-relational database to store tamper-proof audit logs. Through a closed-loop data write-back mechanism between the hardware discovery module, the operating system installation module, and the OpenStack deployment engine, full lifecycle status tracking and anti-reentry control are achieved.
This ensures the uniqueness and traceability of each physical server throughout the entire deployment process, avoiding duplicate deployments and guaranteeing the security and compliance of the deployment process.
Smart Images
Figure CN121967190A_ABST
Abstract
Description
An OpenStack-based automated deployment system and method Technical Field
[0001] This invention relates to the field of cloud computing infrastructure automation technology, specifically to an automated deployment system and method based on OpenStack. Background Technology
[0002] As enterprises continuously improve their IT infrastructure, building private cloud platforms has become a key means for many organizations to enhance IT resource utilization and reduce operational costs. OpenStack, as a mainstream open-source cloud platform solution, is widely used in the construction of private cloud environments.
[0003] Traditional deployment methods typically employ configuration management tools like Ansible to deploy OpenStack in batches. The approach involves writing a series of playbooks, each dedicated to installing the operating system, configuring the network, and deploying various OpenStack services. During the operating system installation phase, tools like PXE network boot and Kickstarter are used to perform a bare-metal installation of the operating system on the physical server. In the cloud platform deployment phase, configuration management tools such as Ansible are used to execute playbook scripts to configure the dependencies and deploy services for each OpenStack component (such as control nodes and compute nodes).
[0004] However, existing methods for installing the operating system on physical servers and deploying OpenStack components often require multiple independent tools and scripts, lack unified scheduling and status tracking, and cannot effectively track the status of each physical server throughout the entire deployment lifecycle, which can easily lead to duplicate deployments or wasted resources. Summary of the Invention
[0005] To address the shortcomings of existing technologies that cannot effectively track the status of each physical server throughout the entire deployment lifecycle, which can easily lead to duplicate deployments or resource waste, this invention proposes an automated deployment system and method based on OpenStack, thereby solving the problems existing in the prior art.
[0006] An OpenStack-based automated deployment system includes: a data management layer for storing and managing all data and status information during the automated deployment process; a hardware discovery module for automatically discovering newly added physical servers via the PXE protocol and obtaining server hardware information via the IPMI interface; registering the hardware information to the data management layer; an operating system installation module for performing unattended installation of the operating system on the registered physical servers according to a preset Kickstart configuration template in the data management layer via TFTP / HTTP service, and writing the successful installation status back to the data management layer; and an OpenStack deployment engine for reading the status recorded in the data management layer for the physical servers with the operating system installed and their node role definitions, automatically distributing and configuring OpenStack core components, and writing the deployment process status and results back to the data management layer.
[0007] Furthermore, the data management layer includes a MySQL relational database and an Elasticsearch non-relational database. The relational database stores metadata with strong consistency and transactional requirements, including at least a node information table and a deployment task table. The node information table records the MAC address, IP address, hardware configuration information, and deployment status field of the physical server. The deployment task table records the target node, task role, execution status, and associated log path for each deployment task. The non-relational database stores immutable audit logs, with at least one audit log index. The audit log index stores timestamps, user IDs, action types, resource IDs, operation details, and result information in a JSON document structure, and this index is configured in read-only mode.
[0008] Furthermore, it also includes a network configuration module and an image management module; the network configuration module and the image management module are used to automatically configure the Neutron network topology and manage and distribute the Glance image in response to the user's resource request after the OpenStack deployment engine has completed deployment.
[0009] Furthermore, it also includes a permission approval module, which performs role- and workflow-based approval control on users' resource creation requests, and only allows the resource configuration task to be triggered after approval.
[0010] Furthermore, the resource configuration task includes: automatically creating and configuring a Virtual Private Cloud (VPC) network by calling the network configuration module according to user requests; or calling the image management module to distribute a specified image to the target compute node through the Glance service to create virtual machines.
[0011] This invention also proposes an automated deployment method based on OpenStack, comprising the following steps: After the physical server is powered on, it boots via PXE. The hardware discovery module automatically discovers and obtains its hardware information, writes the server information into the node information table, and initially marks the state as discovered; according to the preset Kickstart template in the data management layer, the unattended installation of the operating system is completed via network boot; after installation, the successful installation status is written back to the data management layer, and the state in the node information table is updated to "operating system installed"; the deployment engine executes the corresponding deployment scripts sequentially according to the node role list to deploy the OpenStack core services; during the deployment process, the status of the deployment task table is updated in real time; after successful deployment and verification, the node status is updated to "OpenStack deployed"; if the deployment fails, an alarm is triggered and the node status is rolled back.
[0012] Furthermore, the unattended installation of the operating system is completed via network booting according to the preset Kickstart template in the data management layer. After installation, the successful installation status is written back to the data management layer, and the status in the node information table is updated to "operating system installed". This process includes the following steps: the physical server boots from the PXE network card, requests and obtains an IP address and a TFTP server address from the DHCP server; downloads and loads the Linux kernel and initialization script files from the TFTP server; after the Linux kernel starts, it obtains the Kickstart configuration file from the HTTP server; and automatically completes the installation of the operating system according to the parameters defined in the Kickstart configuration file. After installation, the physical server sends a registration request to the data management layer, reporting its MAC address and IP address. The data management layer writes this information into the node information table and updates the node's status to "operating system installed".
[0013] Furthermore, the successful deployment and verification specifically includes: after the deployment script is executed, the deployment engine actively calls the verification interface of the Nova service to check whether the core services are running normally; after confirming that there are no errors, the status of the corresponding node is updated to OpenStack deployed.
[0014] Furthermore, if the deployment fails, an alarm will be triggered and the node status will be rolled back. Specifically, if the deployment task fails, an alarm will be automatically triggered to notify the administrator, and the status of the node in the node information table will be rolled back to "operating system installed".
[0015] Furthermore, the documents in the audit log index shall at least include timestamp, user ID, action type, resource ID, operation details, and result fields.
[0016] This invention provides an automated deployment system based on OpenStack, which has the following advantages: By setting up a unified data management layer and constructing a closed-loop data write-back mechanism between the hardware discovery module, the operating system installation module, and the OpenStack deployment engine, the status of each step from physical server discovery and operating system installation to OpenStack component deployment is synchronized to the data management layer in real time. This full lifecycle status tracking and anti-re-entry mechanism ensures the uniqueness and traceability of each physical server in the entire deployment process, fundamentally avoiding the problem of duplicate deployment caused by unclear status. Attached Figure Description
[0017] Figure 1 is a schematic diagram of the automated deployment system structure based on the OpenStack platform in an embodiment of the present invention; Figure 2 is a schematic diagram of the batch installation process of the operating system in an embodiment of the present invention; Figure 3 is a schematic diagram of the deployment process of OpenStack components in an embodiment of the present invention. Detailed Implementation
[0018] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.
[0019] When building a private cloud platform based on OpenStack, the current deployment method usually relies on manual configuration or the use of general automated scripts. This method has the following problems: (1) Fragmented process: From the installation of the operating system on the physical server to the deployment of various OpenStack components, multiple independent tools and scripts are often required, lacking unified scheduling and status tracking. (2) Lack of status management: It is impossible to effectively track the status of each physical server throughout the entire deployment lifecycle, which can easily lead to duplicate deployment or waste of resources. (3) Insufficient audit compliance: Logs of user operations and critical system events are usually stored in ordinary files or modifiable databases, which are at risk of being tampered with or deleted, making it difficult to meet high-level security audit and compliance requirements. (4) Disconnect between resource application and deployment: There is a lack of effective approval and linkage mechanism between user resource applications and backend automated deployment processes.
[0020] For example, Ansible and other configuration management tools are used to deploy OpenStack in batches. The solution is to write a series of playbooks, which are used to install the operating system, configure the network, and deploy various OpenStack services. However, this solution has obvious defects: (1) Lack of global state view: Ansible itself does not provide persistent management of the full life cycle state of the managed nodes. Once the deployment is interrupted, it is difficult to accurately determine which stage the node is currently in, and manual intervention is required for investigation. (2) Insufficient log security: Deployment logs and operation logs are mostly stored in text files, and the administrator has full read and write permissions, which cannot guarantee the immutability of the logs. This is fatal in scenarios with strong supervision such as finance and government affairs. (3) Single data model: Structured task status and unstructured operation logs are usually stored in the same database, which cannot be optimized for the characteristics of different types of data.
[0021] Based on this, the present invention proposes an automated deployment system based on OpenStack, the core of which is to achieve secure, reliable and efficient automated deployment of cloud platforms through a hybrid database architecture and closed-loop state management.
[0022] As shown in Figure 1, the system includes a hardware discovery module 101, an operating system installation module 102, an OpenStack deployment engine 103, a network configuration module 104, an image management module 105, a permission approval module 106, and a unified data management layer 107. Among them, the data management layer 107 is responsible for storing and managing metadata, status information, and audit logs in all automated deployment processes.
[0023] Hardware discovery module 101: Used to automatically discover newly added physical servers via the PXE protocol and obtain server hardware information via the IPMI interface; hardware information includes CPU model, memory capacity, and disk serial number.
[0024] Operating system installation module 102: Used to push the Linux kernel and initialization script to the target server via TFTP server according to the preset Kickstart template, so as to complete the unattended installation of the operating system.
[0025] OpenStack Deployment Engine 103: Used to automatically distribute and configure OpenStack core components based on node roles such as control nodes and compute nodes. (In this step, the system logically designates ready servers as "control nodes" or "compute nodes" according to the administrator's plan, and distributes the corresponding OpenStack service component packages for configuration accordingly. These nodes refer to physical servers that have had their operating systems installed through previous steps (PXE / Kickstart). At this point, the system logically classifies them as control nodes or compute nodes based on their functions, rather than referring to their physical locations.)
[0026] Network Configuration Module 104: As the system's automated network resource management unit, its core function is to automatically create and configure OpenStack Neutron network components based on the Virtual Private Cloud (VPC) parameters submitted by the tenant. These components include, but are not limited to, virtual networks, subnets, routers, and security group rules, thereby providing users with an isolated, secure, and immediately usable network environment. Specifically, when a user submits a request to create a Virtual Private Cloud (VPC) through the web interface, the system calls the Network Configuration Module. This module automatically calls the relevant interfaces of the Neutron service to create an independent virtual network for the user, allocate subnet address ranges, configure routers to enable communication between internal and external networks, and record the entire operation process in the audit log index.
[0027] Image Management Module 105: This module provides and manages standardized operating system and application images. As the system's standardized image center, its core function is to centrally maintain a securely hardened and performance-optimized operating system and application software image library. This module supports the rapid and efficient distribution of user-selected images to designated compute nodes via the OpenStack Glance service, achieving virtual machine instance creation in seconds. Specifically, when a new virtual machine needs to be created, the system selects the user-specified image from the image library and quickly distributes it to the target compute node via the Glance service, thus achieving virtual machine creation in seconds.
[0028] The permission approval module 106 is used to perform role-based approval control on user resource creation requests. As a security gateway for system resource allocation, its core function is to execute role-based access control (RBAC) and workflow approval on all user-initiated resource creation requests (such as requests for virtual machines, storage volumes, etc.). Only requests approved by preset approvers can enter the subsequent automated deployment process (the complete operational chain context information from user application to approval decision and task execution is persisted in a read-only audit log index in the form of structured documents, ensuring that the entire process is traceable and auditable), ensuring that resource allocation strictly follows the organization's IT governance strategy.
[0029] The unified data management layer (107) is responsible for storing and managing metadata, status information, and audit logs throughout the automated deployment process. The data management layer uses a MySQL relational database and an Elasticsearch non-relational database. The relational database stores node information tables and deployment task tables with strong consistency requirements, while the non-relational database stores audit log indexes. Its core data entity design is as follows:
[0030] (1) Relational database: The node information table is used to record hardware information and key status fields such as the MAC address, IP, CPU, and memory of the physical server. The deployment task table is used to record the target node, role, status, and log path of each deployment task.
[0031] (2) Non-relational database: The audit log index is named audit_logs, the storage engine is Elasticsearch Index, the document structure is JSON format, and it contains timestamp, user ID, action type, resource ID, details, and result fields. Its purpose is to store user operations and system events, and it supports full-text search and security auditing.
[0032] Based on the above system, the present invention also proposes an automated deployment method, as shown in Figures 2 and 3. The method specifically includes the following steps: S1, Batch installation of the operating system; S1.1, After the physical server is powered on, it boots from the network card PXE, requests an IP address from the DHCP server, and obtains the TFTP server address.
[0033] S1.2 The client downloads and loads the Linux kernel and initialization script files from the TFTP server.
[0034] S1.3 After the kernel starts, it retrieves the Kickstart configuration file (ks.cfg) from the HTTP server.
[0035] S1.4 The physical server automatically completes the operating system installation based on the partition scheme, package list, network configuration and other parameters defined in ks.cfg.
[0036] S1.5 After installation, the server sends a registration request to the central management system, reporting its MAC address and IP address. The central management system receives the request data through the API interface, parses it by the logic processing layer, persists it to the node information table of the data management layer, and marks the server status as "operating system installed".
[0037] S2, OpenStack Component Deployment: S2.1, The deployment engine reads the node manifest file and identifies the roles of physical servers such as control nodes and compute nodes.
[0038] S2.2 For the control node, the deployment engine executes the following tasks in sequence: install and configure the database service (MariaDB), install and configure the message queue service (RabbitMQ), configure the authentication service (Keystone), and register the image service (Glance).
[0039] S2.3 After all tasks are completed, the system will write the result (success or failure) of this deployment task into the deployment task table.
[0040] S2.4 If the task fails, the system will automatically trigger an alarm to notify the administrator and roll back the status of the node in the node information table to "Operating system installed", waiting for manual intervention.
[0041] S2.5 If the task is successful, the deployment engine will actively call the Nova service's verification interface to check whether all core services are running normally; after confirming that there are no errors, the status of the node will be updated to "OpenStack deployed".
[0042] This invention proposes (1) an automated deployment data management method based on a hybrid database architecture, which uses a relational database to store node status and deployment task metadata with strong consistency and transaction requirements, and uses a non-relational database to store tamper-proof audit logs, wherein the audit log index is configured in read-only mode; (2) an end-to-end automated OpenStack deployment process: the process begins with the automatic discovery and registration of physical servers through PXE / IPMI, followed by the installation of an unattended operating system based on Kickstart, and then the deployment of role-based OpenStack components based on Ansible Playbook. In each step, the deployment status is closed-loop tracked and re-entry control is achieved by updating the status field of the node information table; (3) an integrated resource application and approval mechanism: the user's resource creation request must go through a role-based approval process. After approval, the system automatically triggers the deployment task and persists the complete context information of the entire operation chain in the form of a structured document to the read-only audit log index to meet security compliance requirements.
[0043] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.
Claims
1. An automated deployment system based on OpenStack, characterized in that, include: A data management layer used for storing and managing data and status information during all automated deployment processes; The hardware discovery module is used to automatically discover newly added physical servers via the PXE protocol and obtain server hardware information via the IPMI interface; it then registers the hardware information to the data management layer. The operating system installation module is used to perform unattended installation of the operating system on the registered physical servers via TFTP / HTTP service, based on a preset Kickstart configuration template in the data management layer, and writes the successful installation status back to the data management layer. The OpenStack deployment engine is used to read the status records in the data management layer for the physical servers with installed operating systems and their node role definitions, automatically distribute and configure OpenStack core components, and write the deployment process status and results back to the data management layer.
2. The automated deployment system based on OpenStack according to claim 1, characterized in that, The data management layer includes a MySQL relational database and an Elasticsearch non-relational database. The relational database stores metadata with strong consistency and transactional requirements, including at least a node information table and a deployment task table. The node information table records the physical server's MAC address, IP address, hardware configuration information, and deployment status field. The deployment task table records the target node, task role, execution status, and associated log path for each deployment task. The non-relational database stores immutable audit logs, with at least one audit log index. The audit log index stores timestamps, user IDs, action types, resource IDs, operation details, and result information in a JSON document structure, and is configured to read-only mode.
3. The automated deployment system based on OpenStack according to claim 1, characterized in that, It also includes a network configuration module and an image management module; the network configuration module and the image management module are used to automatically configure the Neutron network topology and manage and distribute the Glance image in response to the user's resource request after the OpenStack deployment engine has been deployed.
4. The OpenStack-based automated deployment system according to claim 1, characterized in that, It also includes a permission approval module, which performs role- and workflow-based approval control on users' resource creation requests, and only allows the resource configuration task to be triggered after approval.
5. The OpenStack-based automated deployment system according to claim 4, characterized in that, The resource configuration tasks include: automatically creating and configuring a Virtual Private Cloud (VPC) network by calling the network configuration module according to user requests; or calling the image management module to distribute a specified image to the target compute node through the Glance service to create virtual machines.
6. An automated deployment method based on the system of claim 1, characterized in that, Includes the following steps: After the physical server is powered on, it boots via PXE. The hardware discovery module automatically discovers and obtains its hardware information, writes the server information into the node information table, and marks the initial status as discovered. According to the Kickstart template preset in the data management layer, the unattended installation of the operating system is completed via network boot. After installation, the successful installation status is written back to the data management layer, and the status in the node information table is updated to "operating system installed". The deployment engine executes the corresponding deployment scripts in sequence according to the node role list to deploy the OpenStack core services. During deployment, the status of the deployment task table is updated in real time; After successful deployment and verification, update the node status to "OpenStack deployed"; If deployment fails, an alert will be triggered and the node state will be rolled back.
7. The automated deployment method based on OpenStack according to claim 6, characterized in that, The process involves unattended installation of the operating system via network boot using a pre-defined Kickstart template in the data management layer. Upon completion, the installation success status is written back to the data management layer, updating the node information table to show that the operating system is installed. Specifically, this includes the following steps: the physical server boots from the PXE network card, requests and obtains an IP address and a TFTP server address from the DHCP server; downloads and loads the Linux kernel and initialization script files from the TFTP server; after the Linux kernel boots, it obtains the Kickstart configuration file from the HTTP server; based on the parameters defined in the Kickstart configuration file, it automatically completes the operating system installation; after installation, the physical server sends a registration request to the data management layer, reporting its MAC address and IP address; the data management layer writes this information into the node information table and updates the node's status to show that the operating system is installed.
8. The automated deployment method based on OpenStack according to claim 6, characterized in that, The successful deployment and verification process specifically includes: after the deployment script is executed, the deployment engine actively calls the verification interface of the Nova service to check whether the core services are running normally; after confirming that there are no errors, the status of the corresponding node is updated to OpenStack deployed.
9. The automated deployment method based on OpenStack according to claim 6, characterized in that, If deployment fails, an alarm will be triggered and the node status will be rolled back. Specifically, if the deployment task fails, an alarm will be automatically triggered to notify the administrator, and the status of the node in the node information table will be rolled back to "operating system installed".
10. The automated deployment method based on OpenStack according to claim 6, characterized in that, The documents in the audit log index contain at least the timestamp, user ID, action type, resource ID, operation details, and result fields.