An OpenStack deployment method, device and electronic equipment

Abstract

This application provides an OpenStack deployment method, apparatus, and electronic device. The method includes: acquiring production delivery environment information of the OpenStack to be deployed; determining the target storage backend to be connected to each block storage service component in the OpenStack to be deployed based on the production delivery environment information; and configuring the block storage service component corresponding to the target storage backend according to the storage type and connection configuration parameters of the target storage backend, so that the target storage backend can only be accessed by the block storage service component. The method provided above establishes a connection relationship between the block storage service component and the target storage backend by differentially configuring the block storage service components included in the OpenStack to be deployed based on the production delivery environment information. This makes the deployed OpenStack suitable for a production delivery environment with network isolation, laying the foundation for further improving the information security of the storage backend.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to an OpenStack deployment method, apparatus, and electronic device. Background Technology

[0002] With the continuous development of cloud computing technology, major enterprises have gradually replaced traditional data centers with private clouds. At the same time, OpenStack, as a cloud computing management platform, has been widely used. Therefore, how to deploy the OpenStack cloud computing management platform has become a hot research topic.

[0003] In existing technologies, the block storage service Cinder component in OpenStack typically deploys configuration information for all cloud storage backends, meaning that users can access all cloud storage backends based on any block storage service Cinder component.

[0004] However, due to the increasing emphasis on information security, there may be network isolation requirements between different storage backends in the current OpenStack production delivery environment. In such a production delivery environment, if the OpenStack cloud computing management platform is deployed based on existing technologies, a large number of block storage service Cinder components may experience storage backend access errors. Summary of the Invention

[0005] This application provides an OpenStack deployment method, apparatus, and electronic device to address the shortcomings of existing OpenStack cloud computing management platform deployment methods, such as their unsuitability for production delivery environments with network isolation.

[0006] The first aspect of this application provides an OpenStack deployment method, including:

[0007] Obtain information about the production delivery environment for the OpenStack deployment;

[0008] Based on the production delivery environment information, determine the target storage backend to be connected for each block storage service component in the OpenStack to be deployed;

[0009] Configure the block storage service component corresponding to the target storage backend according to the storage type and docking configuration parameters of the target storage backend, so that the target storage backend can only be accessed by the block storage service component.

[0010] Optionally, before configuring the block storage service component corresponding to the target storage backend according to the storage type and interface configuration parameters of the target storage backend, the method further includes:

[0011] Each block storage service component is containerized to deploy the block storage service component as a block storage service POD on Kubernetes.

[0012] Optionally, configuring the block storage service component corresponding to the target storage backend according to the storage type and interface configuration parameters of the target storage backend includes:

[0013] Based on the storage type of the target storage backend, install the target client tools and target storage drivers to the corresponding block storage service POD;

[0014] Based on the docking configuration parameters of the target storage backend, the block storage service POD is docked with the target storage backend to obtain a block storage service POD to be deployed after docking configuration with the target storage backend is completed.

[0015] Optionally, configuring the block storage service POD to interface with the target storage backend based on the interface configuration parameters of the target storage backend includes:

[0016] Obtain the global default configuration parameters of the block storage service POD;

[0017] Based on the connection configuration parameters of the target storage backend, adjust the global default configuration parameters of the block storage service POD.

[0018] Optional, also includes:

[0019] Obtain the container image of the block storage service POD to be deployed;

[0020] Based on the container image of the block storage service POD to be deployed, start the block storage service POD to be deployed on the target node to deploy the block storage service POD to the target node.

[0021] Optional, also includes:

[0022] Containerize the other service components in the OpenStack to be deployed, excluding the block storage service component, so that the other service components can be deployed on Kubernetes as other service PODs.

[0023] Optional, also includes:

[0024] Obtain the container images of the other service PODs;

[0025] Based on the container image of the other service POD, start the other service POD on the target node to deploy the other service POD to the target node.

[0026] A second aspect of this application provides an OpenStack deployment apparatus, comprising:

[0027] The acquisition module is used to obtain production delivery environment information for the OpenStack deployment to be deployed.

[0028] The determination module is used to determine the target storage backend to be connected to each block storage service component in the OpenStack to be deployed, based on the production delivery environment information.

[0029] The deployment module is used to configure the block storage service component corresponding to the target storage backend according to the storage type and interface configuration parameters of the target storage backend, so that the target storage backend can only be accessed by the block storage service component.

[0030] Optionally, the device further includes:

[0031] The containerization module is used to containerize each block storage service component so that the block storage service component can be deployed on Kubernetes as a block storage service POD.

[0032] Optionally, the deployment module is specifically used for:

[0033] Based on the storage type of the target storage backend, install the target client tools and target storage drivers to the corresponding block storage service POD;

[0034] Based on the docking configuration parameters of the target storage backend, the block storage service POD is docked with the target storage backend to obtain a block storage service POD to be deployed after docking configuration with the target storage backend is completed.

[0035] Optionally, the deployment module is specifically used for:

[0036] Obtain the global default configuration parameters of the block storage service POD;

[0037] Based on the connection configuration parameters of the target storage backend, adjust the global default configuration parameters of the block storage service POD.

[0038] Optionally, the deployment module is specifically used for:

[0039] Obtain the container image of the block storage service POD to be deployed;

[0040] Based on the container image of the block storage service POD to be deployed, start the block storage service POD to be deployed on the target node to deploy the block storage service POD to the target node.

[0041] Optionally, the deployment module is further configured to:

[0042] Containerize the other service components in the OpenStack to be deployed, excluding the block storage service component, so that the other service components can be deployed on Kubernetes as other service PODs.

[0043] Optionally, the deployment module is further configured to:

[0044] Obtain the container images of the other service PODs;

[0045] Based on the container image of the other service POD, start the other service POD on the target node to deploy the other service POD to the target node.

[0046] A third aspect of this application provides an electronic device, comprising: at least one processor and a memory;

[0047] The memory stores computer-executed instructions;

[0048] The at least one processor executes computer execution instructions stored in the memory, causing the at least one processor to perform the method described in the first aspect above and various possible designs of the first aspect.

[0049] The fourth aspect of this application provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the method described in the first aspect above and various possible designs of the first aspect.

[0050] The technical solution of this application has the following advantages:

[0051] This application provides an OpenStack deployment method, apparatus, and electronic device. The method includes: acquiring production delivery environment information of the OpenStack to be deployed; determining the target storage backend to be connected to each block storage service component in the OpenStack to be deployed based on the production delivery environment information; and configuring the block storage service component corresponding to the target storage backend according to the storage type and connection configuration parameters of the target storage backend, so that the target storage backend can only be accessed by the block storage service component. The method provided above establishes a connection relationship between the block storage service component and the target storage backend by differentially configuring the block storage service components included in the OpenStack to be deployed based on the production delivery environment information. This makes the deployed OpenStack suitable for a production delivery environment with network isolation, laying the foundation for further improving the information security of the storage backend. Attached Figure Description

[0052] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0053] Figure 1 This is a schematic diagram of the structure of the OpenStack deployment system on which the embodiments of this application are based;

[0054] Figure 2 A flowchart illustrating the OpenStack deployment method provided in this application embodiment;

[0055] Figure 3 This is a schematic diagram of the structure of the OpenStack deployment device provided in the embodiments of this application;

[0056] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0057] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the present disclosure in any way, but rather to illustrate the concepts of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

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

[0059] Furthermore, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. In the following descriptions of embodiments, "a plurality of" means two or more, unless otherwise explicitly defined.

[0060] In existing technologies, the Cinder block storage service component in OpenStack typically deploys configuration information for all cloud storage backends, meaning users can access all cloud storage backends based on any Cinder component. However, due to increasing emphasis on information security, current OpenStack production environments may require network isolation between different storage backends. In such a production environment, if an OpenStack cloud management platform is deployed using existing technology, the current block storage service component might attempt to access a network-isolated storage backend, resulting in storage backend access errors. Furthermore, the OpenStack Cinder block storage service component needs to interface with storage backends to provide virtual machine and data storage for cloud computing. Commonly used storage in data center production scenarios includes Ceph distributed storage and FC centralized storage. Large-scale data centers often purchase storage devices from multiple companies of varying types, requiring an OpenStack cloud platform to support flexible configuration of multiple backend storage systems and differentiated configurations.

[0061] To address the aforementioned issues, the OpenStack deployment method, apparatus, and electronic device provided in this application obtain production delivery environment information of the OpenStack to be deployed; based on the production delivery environment information, determine the target storage backend to be connected to each block storage service component in the OpenStack to be deployed; and configure the block storage service component corresponding to the target storage backend according to the storage type and connection configuration parameters of the target storage backend, so that the target storage backend can only be accessed by that block storage service component. The method provided above, by differentially configuring the block storage service components included in the OpenStack to be deployed based on the production delivery environment information, establishes the connection relationship between the block storage service components and the target storage backend, making the deployed OpenStack suitable for a production delivery environment with network isolation, thus laying the foundation for further improving the information security of the storage backend.

[0062] The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0063] First, the structure of the OpenStack deployment system on which this application is based will be described:

[0064] The OpenStack deployment method, apparatus, and electronic device provided in this application are applicable to deploying OpenStack for cloud computing platforms, such as... Figure 1The diagram shows the structure of the OpenStack deployment system based on the embodiments of this application. It mainly includes the OpenStack instance to be deployed, a storage backend, and an OpenStack deployment device. This device can be deployed on an OpenStack deployment node of a cloud computing platform. Specifically, the OpenStack deployment device performs differentiated deployment between the storage backend and the block storage service components in the OpenStack based on the production delivery environment information of the OpenStack instance to be deployed, ensuring that the deployed OpenStack is suitable for the current production delivery environment.

[0065] This application provides an OpenStack deployment method for deploying OpenStack on a cloud computing platform. The execution subject of this application embodiment is an electronic device, such as a server, desktop computer, laptop computer, tablet computer, or other electronic devices that can be used to deploy OpenStack.

[0066] like Figure 2 The diagram shown is a flowchart illustrating the OpenStack deployment method provided in this embodiment of the application. The method includes:

[0067] Step 201: Obtain the production delivery environment information for the OpenStack deployment.

[0068] It should be noted that OpenStack production delivery environments typically require a single cluster to connect to multiple storage backends. Different storage backends may have network isolation requirements, and the generated delivery environment information should at least include the network isolation information of the OpenStack to be deployed.

[0069] Step 202: Based on the production delivery environment information, determine the target storage backend to be connected for each block storage service component in the OpenStack to be deployed.

[0070] For example, different storage backends can correspond to different enterprises. In order to ensure the confidentiality of the enterprise's cloud computing data, network isolation can be pre-configured for the storage backend corresponding to that enterprise, such as only opening it to all block storage service components of that enterprise.

[0071] Specifically, based on the correspondence between the storage backend and block storage service components reflected in the production delivery environment information, the target storage backend to be connected for each block storage service component in the OpenStack to be deployed can be determined.

[0072] Step 203: Configure the block storage service component corresponding to the target storage backend according to the storage type and docking configuration parameters of the target storage backend, so that the target storage backend can only be accessed by the block storage service component.

[0073] Specifically, by configuring the block storage service component corresponding to the target storage backend according to the storage type and connection configuration parameters of the target storage backend, the block storage service component is equipped with the access interface of the target storage backend. It is ensured that only the block storage service component among all block storage service components has the access interface of the target storage backend. That is, the data storage of other block storage service components will not fall to the target storage backend, and the storage backend access failure will not occur due to network isolation.

[0074] For example, after completing the OpenStack deployment described above, one OpenStack instance can simultaneously support the connection to multiple storage systems, such as Ceph distributed storage 01, Ceph distributed storage 02, FC centralized storage 01, and FC centralized storage 02. The block storage service component on Node01 can only access Ceph distributed storage 01, Ceph distributed storage 02, and FC centralized storage 01, while the block storage service component on Node02 can only access FC centralized storage 02. At this time, the block storage service POD on Node01 is configured with the connection information for Ceph01, Ceph02, and FC01, while the block storage service POD on Node02 is configured with the connection information for FC01.

[0075] Based on the above embodiments, in order to ensure the security of the OpenStack deployment process, as an implementable approach, in one embodiment, before configuring the block storage service component corresponding to the target storage backend according to the storage type and interface configuration parameters of the target storage backend, each block storage service component can be containerized to deploy the block storage service component as a K8S block storage service POD on K8S.

[0076] It's important to note that K8S stands for Kubernetes, a platform for managing containerized applications across multiple hosts in a cloud computing environment. Kubernetes aims to make deploying containerized applications simple and efficient, providing a mechanism for application deployment, planning, updating, and maintenance. A POD is the smallest schedulable atomic unit in Kubernetes. A POD can contain multiple containers. A block storage service POD refers to a containerized block storage service component, i.e., the application container corresponding to the block storage service component.

[0077] The specific containerization process can refer to existing technologies, and this application does not limit it in this regard.

[0078] Based on the above embodiments, as an implementable approach, in one embodiment, the block storage service component corresponding to the target storage backend is configured according to the storage type and interface configuration parameters of the target storage backend, including:

[0079] Step 2031: Based on the storage type of the target storage backend, install the target client tools and target storage drivers to the corresponding block storage service POD;

[0080] Step 2032: Configure the block storage service POD to interface with the target storage backend according to the interface configuration parameters of the target storage backend, so as to obtain the block storage service POD to be deployed after completing the interface configuration with the target storage backend.

[0081] Client tools are typically RMP installation packages, while storage drivers are usually Python code.

[0082] Specifically, you can first determine whether the corresponding client tools need to be installed based on the storage type of the target storage backend. For example, when the storage type of the target storage backend is Ceph distributed storage, install the corresponding Ceph client tools to the block storage service POD; when the storage type of the target storage backend is FC storage, no client tools are needed, but regardless of the storage type, the corresponding storage driver (target driver) needs to be installed to the block storage service POD.

[0083] Specifically, in one embodiment, the global default configuration parameters of the block storage service POD can be obtained; and the global default configuration parameters of the block storage service POD can be adjusted according to the docking configuration parameters of the target storage backend.

[0084] It should be noted that the Cinder service (block storage service) can read the corresponding backend configuration information (interface configuration parameters) of the specified storage backend. The connection between the two can be achieved through the storage driver and the interface configuration. The configuration information of the block storage service includes global default configuration parameters and custom storage configuration block parameters. By changing the global default configuration parameters, the node POD (block storage service POD) can control which storage backend it connects to.

[0085] For example, if the global default configuration `DEFAULT.enabled_backends` is defined, and its value is configured to `Ceph01` to enable the storage backend parameters, then the custom storage configuration block parameters can be maintained under the `Ceph01` configuration module. When connecting to multiple storage backends, the `enabled_backends` values ​​are separated by commas. Specifically, the global default configuration `DEFAULT.enabled_backends_node01` is defined as the differentiated configuration for the `node01` node POD (the current block storage service POD), and other nodes are configured similarly. `enabled_backends_node01` has higher priority than `enabled_backends`. When the POD on this node starts, it will replace the `enabled_backends` value with the value of `enabled_backends_node01` to complete the differentiated configuration for different nodes. Otherwise, if there are inaccessible storage clusters, it may cause OpenStack to fail to create storage resources. OpenStack specifies the storage backend type when creating storage resources. The purpose of differentiated configuration is to ensure that the task of creating storage resources by OpenStack can only be distributed to the POD service on the node whose `enabled_backends` parameter is configured with that backend type, as shown in the following configuration:

[0086]

[0087] Based on the above embodiments, in order to improve the deployment efficiency of OpenStack, as an implementable approach, in one embodiment, a container image of the block storage service POD to be deployed can be obtained; based on the container image of the block storage service POD to be deployed, the block storage service POD to be deployed is started on the target node to deploy the block storage service POD to the target node.

[0088] It should be noted that the deployment process of each component will pull the corresponding component image to start the corresponding service POD. Container image management can use tools such as Harbor or Registry.

[0089] Similarly, in one embodiment, other service components in OpenStack besides the block storage service component can be containerized to deploy these other service components as other service PODs on Kubernetes.

[0090] Furthermore, it is also possible to obtain container images of other service PODs; based on the container images of other service PODs, start the other service PODs on the target node to deploy the other service PODs to the target node.

[0091] To further improve OpenStack deployment efficiency, one-click deployment and integration of multiple storage Helm charts files and Ansible playbook files are available. Helm charts files are deployment files written for OpenStack on Kubernetes and used to deploy Kubernetes applications. Ansible files are used for abstraction, assigning charts variables, and one-click deployment. The block storage Cinder service volume and backup component POD controller are of type deployment. During POD startup, the storage client and driver are loaded from the host machine into the container using the hostpath method. After the POD startup is complete, an initialization script is executed to install the corresponding target client tools and target storage drivers into the POD. The storage integration configuration is mounted to the corresponding POD using Kubernetes Secrets objects. Additionally, the storage backend parameter enabled_backends_node01 can be configured differently based on the node host name: "Ceph01". After the POD is started, the initialization script executes to determine whether to configure differently based on the configuration parameter enabled_backends_node01, which matches the node name where the POD is located. Here, enabled_backends_node01: "Ceph01" means that the storage backend of the POD on node01 is configured differently as Ceph01, while other POD nodes without differentiated configurations will use the storage backend configured by the enabled_backends parameter.

[0092] For example, performing deployment and configuration changes in Cinder:

[0093] bash deploy.sh -m openstack -t cinder

[0094] Specifically, in one embodiment, in order to ensure that the OpenStack to be deployed can be deployed normally, the deployment status of each service POD can be monitored during the deployment of service PODs to determine whether all service PODs are deployed normally. If a service POD fails to deploy, a corresponding alarm message is generated.

[0095] The OpenStack deployment method provided in this application obtains the production delivery environment information of the OpenStack to be deployed; based on the production delivery environment information, it determines the target storage backend to be connected to each block storage service component in the OpenStack to be deployed; and configures the block storage service component corresponding to the target storage backend according to the storage type and connection configuration parameters of the target storage backend, so that the target storage backend can only be accessed by that block storage service component. The method provided above, by differentially configuring the block storage service components included in the OpenStack to be deployed based on the production delivery environment information, establishes the connection relationship between the block storage service components and the target storage backend, making the deployed OpenStack suitable for a production delivery environment with network isolation, laying the foundation for further improving the information security of the storage backend. Furthermore, it makes OpenStack deployment and configuration of the storage backend more flexible and convenient, allowing for differentiated configuration of the storage backend for block storage service PODs on different nodes, effectively improving the efficiency of deployment and delivery.

[0096] This application provides an OpenStack deployment apparatus for executing the OpenStack deployment method provided in the above embodiments.

[0097] like Figure 3 The diagram shown is a structural schematic of the OpenStack deployment device provided in an embodiment of this application. The OpenStack deployment device 30 includes an acquisition module 301, a determination module 302, and a deployment module 303.

[0098] The module includes an acquisition module for acquiring production delivery environment information of the OpenStack to be deployed; a determination module for determining the target storage backend to be connected to each block storage service component in the OpenStack to be deployed based on the production delivery environment information; and a deployment module for configuring the block storage service component corresponding to the target storage backend according to the storage type and connection configuration parameters of the target storage backend, so that the target storage backend can only be accessed by the block storage service component.

[0099] Specifically, in one embodiment, the device further includes:

[0100] The containerization module is used to containerize each block storage service component so that the block storage service component can be deployed on Kubernetes as a block storage service POD.

[0101] Specifically, in one embodiment, the deployment module is specifically used for:

[0102] Based on the storage type of the target storage backend, install the target client tools and target storage drivers to the corresponding block storage service POD;

[0103] Based on the connection configuration parameters of the target storage backend, the block storage service POD is configured to connect with the target storage backend to obtain a block storage service POD to be deployed after the connection configuration with the target storage backend is completed.

[0104] Specifically, in one embodiment, the deployment module is specifically used for:

[0105] Retrieve the global default configuration parameters for the block storage service POD;

[0106] Adjust the global default configuration parameters of the block storage service POD according to the connection configuration parameters of the target storage backend.

[0107] Specifically, in one embodiment, the deployment module is specifically used for:

[0108] Obtain the container image of the block storage service POD to be deployed;

[0109] Based on the container image of the block storage service POD to be deployed, start the block storage service POD to be deployed on the target node to deploy the block storage service POD to the target node.

[0110] Specifically, in one embodiment, the deployment module is further configured to:

[0111] Containerize other service components in OpenStack besides the block storage service component so that they can be deployed on Kubernetes as other service PODs.

[0112] Specifically, in one embodiment, the deployment module is further configured to:

[0113] Obtain container images of other service PODs;

[0114] Based on the container image of another service POD, start the other service POD on the target node to deploy the other service POD to the target node.

[0115] Regarding the OpenStack deployment apparatus in this embodiment, the specific methods by which each module performs operations have been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0116] The OpenStack deployment apparatus provided in this application embodiment is used to execute the OpenStack deployment method provided in the above embodiment. Its implementation method and principle are the same, and will not be described again.

[0117] This application provides an electronic device for executing the OpenStack deployment method provided in the above embodiments.

[0118] like Figure 4 The diagram shown is a structural schematic of an electronic device provided in an embodiment of this application. The electronic device 40 includes at least one processor 41 and a memory 42.

[0119] The memory stores computer-executable instructions; at least one processor executes the computer-executable instructions stored in the memory, causing the at least one processor to execute the OpenStack deployment method provided in the above embodiment.

[0120] This application provides an electronic device for executing the OpenStack deployment method provided in the above embodiments. Its implementation method and principle are the same, and will not be described again.

[0121] This application provides a computer-readable storage medium storing computer-executable instructions. When a processor executes the computer-executable instructions, it implements the OpenStack deployment method provided in any of the above embodiments.

[0122] The storage medium containing computer-executable instructions in this embodiment can be used to store the computer-executable instructions of the OpenStack deployment method provided in the foregoing embodiments. Its implementation method and principle are the same, and will not be described again.

[0123] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0124] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0125] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units.

[0126] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0127] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional modules is merely an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the device described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0128] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. An OpenStack deployment method, characterized in that, include: Obtain the production delivery environment information for the OpenStack deployment; wherein, the production delivery environment information includes at least the network isolation information for the OpenStack deployment. Based on the production delivery environment information, determine the target storage backend to be connected for each block storage service component in the OpenStack to be deployed; Configure the block storage service component corresponding to the target storage backend according to the storage type and docking configuration parameters of the target storage backend, so that the target storage backend can only be accessed by the block storage service component; Before configuring the block storage service component corresponding to the target storage backend according to the storage type and interface configuration parameters of the target storage backend, the method further includes: Each block storage service component is containerized to deploy the block storage service component as a block storage service POD on Kubernetes. The step of configuring the block storage service component corresponding to the target storage backend according to the storage type and interface configuration parameters of the target storage backend includes: Based on the storage type of the target storage backend, install the target client tools and target storage drivers to the corresponding block storage service POD; Based on the docking configuration parameters of the target storage backend, the block storage service POD is docked with the target storage backend to obtain a block storage service POD to be deployed after docking configuration with the target storage backend is completed.

2. The method according to claim 1, characterized in that, The step of configuring the block storage service POD to interface with the target storage backend according to the interface configuration parameters of the target storage backend includes: Obtain the global default configuration parameters of the block storage service POD; Based on the connection configuration parameters of the target storage backend, adjust the global default configuration parameters of the block storage service POD.

3. The method according to claim 1, characterized in that, Also includes: Obtain the container image of the block storage service POD to be deployed; Based on the container image of the block storage service POD to be deployed, start the block storage service POD to be deployed on the target node to deploy the block storage service POD to the target node.

4. The method according to claim 1, characterized in that, Also includes: Containerize the other service components in the OpenStack to be deployed, excluding the block storage service component, so that the other service components can be deployed on Kubernetes as other service PODs.

5. The method according to claim 4, characterized in that, Also includes: Obtain the container images of the other service PODs; Based on the container image of the other service POD, start the other service POD on the target node to deploy the other service POD to the target node.

6. An OpenStack deployment device, characterized in that, include: The acquisition module is used to acquire production delivery environment information of the OpenStack to be deployed; wherein, the production delivery environment information includes at least the network isolation information of the OpenStack to be deployed; The determination module is used to determine the target storage backend to be connected to each block storage service component in the OpenStack to be deployed, based on the production delivery environment information. The deployment module is used to configure the block storage service component corresponding to the target storage backend according to the storage type and docking configuration parameters of the target storage backend, so that the target storage backend can only be accessed by the block storage service component. The device further includes: The containerization module is used to containerize each block storage service component so that the block storage service component can be deployed on Kubernetes as a block storage service POD. The deployment module is specifically used for: Based on the storage type of the target storage backend, install the target client tools and target storage drivers to the corresponding block storage service POD; Based on the docking configuration parameters of the target storage backend, the block storage service POD is docked with the target storage backend to obtain a block storage service POD to be deployed after docking configuration with the target storage backend is completed.

7. An electronic device, characterized in that, include: At least one processor and memory; The memory stores computer-executed instructions; The at least one processor executes computer execution instructions stored in the memory, causing the at least one processor to perform the method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, implement the method as described in any one of claims 1 to 5.

Images