OpenStack服务部署方法、装置、设备及介质

技术领域

本申请涉及云计算技术领域，尤其涉及一种OpenStack服务部署方法、装置、设备及介质。

背景技术

OpenStack是由多个服务组件组合起来提供公共及私有云的建设与管理提供软件的开源云服务管理平台。Kubernetes是一个用于自动部署、扩展和监视容器化应用程序的开源解决方案，可用于部署OpenStack服务。Helm是Kubernetes的包管理器，由客户端组件helm和服务端组件Tiller组成，能快速查找、下载和安装软件包。Armada是一种基于helm，用于批量管理包与配置文件的开源管理工具。

现有的技术方案在部署或更新升级OpenStack服务时，一次调用Armada就会将OpenStack的所有服务的容器化信息以及相关的所有配置信息提供给Armada，完成对OpenStack所有服务的部署或更新。但是，无法只针对某个或某几个OpenStack服务进行部署或者升级，使得在OpenStack的演进过程中，会出现意外更新升级了不需要更新的服务的情况。

发明内容

本申请提供一种OpenStack服务部署方法、装置、设备及介质，用以解决现有技术中只针对某个或某几个OpenStack服务进行部署或者升级，使得在OpenStack的演进过程中，会出现意外更新升级了不需要更新的服务的情况的技术问题。

第一方面，本申请提供一种OpenStack服务部署方法方法，包括：

接收用户触发的服务部署请求；所述服务部署请求包括至少一个目标服务标识、以及用户对OpenStack服务的部署类型；所述目标服务标识是用户从多个预设OpenStack服务标识中选择的，所述部署类型为指定类型或非指定类型；

获取各目标服务的固定配置文件；

采用配置管理服务，根据所述服务部署请求，生成各目标服务的可选配置文件；

响应于所述部署类型为指定类型，采用配置管理服务，根据各所述目标服务标识，生成OpenStack的第一目标配置清单文件；所述第一目标配置清单文件包括各目标服务标识，不包括除目标服务标识之外的其它预设OpenStack服务标识；

采用对包与配置文件批量管理的预设管理工具，根据各固定配置文件、各可选配置文件、以及所述第一目标配置清单文件，对OpenStack的各目标服务进行部署或更新。

可选地，如上所述的方法，所述服务部署请求还包括各目标服务的配置信息；

所述采用配置管理服务，根据所述服务部署请求，生成各目标服务的可选配置文件，包括：

将各目标服务的配置信息发送给配置管理服务，以使配置管理服务根据各目标服务的配置信息生成，生成各目标服务的可选配置文件；

接收配置管理服务发送的各可选配置文件。

可选地，如上所述的方法，所述服务部署请求还包括各目标服务的操作标识；所述操作标识为新建操作、更新操作或删除操作；

所述采用配置管理服务，根据各所述目标服务标识，生成OpenStack的第一目标配置清单文件，包括：

将所述部署类型和各所述目标服务标识发送给配置管理服务，以使配置管理服务根据各目标服务标识，在生成OpenStack的第一目标配置清单文件的流程中，禁用除了各目标服务之外的其它预设OpenStack服务；

将各目标服务的操作标识、固定配置文件和可选配置文件发送给配置管理服务，以使配置管理服务根据各目标服务的操作标识、固定配置文件和可选配置文件生成所述第一目标配置清单文件；

接收配置管理服务发送的第一目标配置清单文件。

可选地，如上所述的方法，所述采用对包与配置文件批量管理的预设管理工具，根据各固定配置文件、各可选配置文件、以及所述第一目标配置清单文件，对OpenStack的各目标服务进行部署或更新，包括：

基于各固定配置文件、各可选配置文件、以及所述第一目标配置清单文件，通过第一预设调用命令调用所述预设管理工具对OpenStack的各目标服务进行部署或更新。

可选地，如上所述的方法，所述第一目标配置清单文件还包括各目标服务的服务状态，所述服务状态为启用状态或禁用状态；

所述基于各固定配置文件、各可选配置文件、以及所述第一目标配置清单文件，通过第一预设调用命令调用所述预设管理工具对OpenStack的各目标服务进行部署或更新，包括：

通过所述第一预设调用命令，调用所述预设管理工具，以使预设管理工具按以下操作对各目标服务进行遍历：

根据目标服务标识，确定目标服务在OpenStack中是否运行；

响应于目标服务的服务状态为启用状态，且目标服务在OpenStack中运行，根据目标服务标识对应的固定配置文件和可选配置文件，对目标服务进行更新；

响应于目标服务的服务状态为启用状态，且目标服务在OpenStack中未运行，根据目标服务标识对应的固定配置文件和可选配置文件，对目标服务进行部署。

可选地，如上所述的方法，所述采用配置管理服务，根据所述服务部署请求，生成各目标服务的可选配置文件之后，还包括：

响应于所述部署类型为非指定类型，采用配置管理服务，根据各所述目标服务标识，生成OpenStack的第二目标配置清单文件；所述第二目标配置清单文件包括多个预设OpenStack服务标识，以及各预设OpenStack服务的服务状态；所述服务状态为启用状态或禁用状态；

基于各固定配置文件、各可选配置文件、以及所述第二目标配置清单文件，通过第二预设调用命令调用所述预设管理工具对OpenStack的各目标服务进行部署或更新。

可选地，如上所述的方法，所述基于各固定配置文件、各可选配置文件、以及所述第二目标配置清单文件，通过第二预设调用命令调用所述预设管理工具对OpenStack的各目标服务进行部署或更新，包括：

通过所述第二预设调用命令，调用所述预设管理工具，以使预设管理工具按以下操作对各预设OpenStack服务进行遍历：

根据预设OpenStack服务标识，确定预设OpenStack服务在OpenStack中是否运行；

响应于预设OpenStack服务的服务状态为启用状态，且预设OpenStack服务在OpenStack中运行，根据预设OpenStack服务标识对应的固定配置文件和可选配置文件，对预设OpenStack服务进行更新；

响应于预设OpenStack服务的服务状态为启用状态，且预设OpenStack服务在OpenStack中未运行，根据预设OpenStack服务标识对应的固定配置文件和可选配置文件，对预设OpenStack服务进行部署；

响应于预设OpenStack服务的服务状态为禁用状态，且预设OpenStack服务在OpenStack中运行，停止运行并删除预设OpenStack服务。

第二方面，本申请提供一种OpenStack服务部署装置，包括：

接收模块，用于接收用户触发的服务部署请求；所述服务部署请求包括至少一个目标服务标识、以及用户对OpenStack服务的部署类型；所述目标服务标识是用户从多个预设OpenStack服务标识中选择的，所述部署类型为指定类型或非指定类型；

获取模块，用于获取各目标服务的固定配置文件；

第一生成模块，用于采用配置管理服务，根据所述服务部署请求，生成各目标服务的可选配置文件；

第二生成模块，用于响应于所述部署类型为指定类型，采用配置管理服务，根据各所述目标服务标识，生成OpenStack的第一目标配置清单文件；所述第一目标配置清单文件包括各目标服务标识，不包括除目标服务标识之外的其它预设OpenStack服务标识；

部署模块，用于采用对包与配置文件批量管理的预设管理工具，根据各固定配置文件、各可选配置文件、以及所述第一目标配置清单文件，对OpenStack的各目标服务进行部署或更新。

第三方面，本申请提供一种电子设备，包括：存储器、处理器和收发器；

所述存储器、所述处理器和所述收发器电路互连；

所述存储器存储计算机执行指令；

所述收发器用于收发数据；

所述处理器执行所述存储器存储的计算机执行指令，以实现如第一方面所述的方法。

第四方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如第一方面所述的方法。

第五方面，本申请提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时用于实现如第一方面所述的方法。

本申请提供的OpenStack服务部署方法、装置、设备及介质，通过接收用户触发的服务部署请求；所述服务部署请求包括至少一个目标服务标识、以及用户对OpenStack服务的部署类型；所述目标服务标识是用户从多个预设OpenStack服务标识中选择的，所述部署类型为指定类型或非指定类型；获取各目标服务的固定配置文件；采用配置管理服务，根据所述服务部署请求，生成各目标服务的可选配置文件；响应于所述部署类型为指定类型，采用配置管理服务，根据各所述目标服务标识，生成OpenStack的第一目标配置清单文件；所述第一目标配置清单文件包括各目标服务标识，不包括除目标服务标识之外的其它预设OpenStack服务标识；采用对包与配置文件批量管理的预设管理工具，根据各固定配置文件、各可选配置文件、以及所述第一目标配置清单文件，对OpenStack的各目标服务进行部署或更新。由于部署类型能够反应用户是否需要对指定的某个或某几个预设OpenStack服务进行部署、更新或删除，因此，在部署类型为指定类型时，采用配置管理服务，根据各所述目标服务标识，生成OpenStack的第一目标配置清单文件；所述第一目标配置清单文件包括各目标服务标识，不包括除目标服务标识之外的其它预设OpenStack服务标识。由于第一目标配置清单文件不包括除目标服务标识之外的其它预设OpenStack服务标识，因此，采用对包与配置文件批量管理的预设管理工具，根据各固定配置文件、各可选配置文件、以及所述第一目标配置清单文件，对OpenStack的各目标服务进行部署或更新，就不会影响到除了目标服务之外的其它预设OpenStack服务，因此，本申请的方案可以解决现有技术中的问题，只针对某个或某几个OpenStack服务进行部署或者升级，使得在OpenStack的版本演进过程中，避免意外更新升级了不需要更新的服务的情况。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1是本申请实施例提供的OpenStack服务更新方法的应用场景对应的网络架构图；

图2为本申请实施例一提供的OpenStack服务部署方法的流程示意图；

图3为本申请实施例二提供的OpenStack服务部署方法的流程示意图；

图4为本申请实施例三提供的OpenStack服务部署装置的结构示意图；

图5为本申请实施例四提供的电子设备的结构示意图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

首先对本申请所涉及的现有技术进行详细说明。

Armada是一种基于helm，用于批量管理包与配置文件的开源管理工具，现有技术中，可以使用Armada对OpenStack服务进行部署和更新，一次调用Armada就会将OpenStack的所有服务的容器化信息以及相关的所有配置信息提供给Armada，进而Armada可以完成对OpenStack所有服务的部署或更新。这提高了OpenStack服务的部署和更新效率，但是，也导致了无法只针对某个或某几个OpenStack服务进行部署或者升级的问题，使得OpenStack在版本演进的过程中，会出现意外更新升级了不需要更新的服务的情况。

这是因为，Armada是根据OpenStack的配置清单文件对OpenStack服务进行部署。而OpenStack的配置清单文件为全量清单，包括所有能够部署在OpenStack上的OpenStack服务标识，以及各OpenStack服务的服务状态。服务状态为启用状态或禁用状态。Armada根据配置清单文件中各OpenStack服务的服务状态，对OpenStack平台中的OpenStack服务进行处理，例如，对启用状态的OpenStack服务进行部署或更新，对禁用状态的OpenStack服务进行删除。

在只需要针对某个或某几个OpenStack服务进行部署或者升级时，如果在配置清单文件中将不需要进行更新的OpenStack服务禁用，则会导致Armada将不需要进行更新的OpenStack服务删除。因此，在对OpenStack服务进行更新时，对于OpenStack中正在使用的服务，只能将其启用，而OpenStack服务启用后，Armada就会对其进行更新。因此，Armada无法只针对某个或某几个OpenStack服务进行部署或者升级。

针对上述技术问题，本申请提出如下技术构思：在需要对某个或某几个OpenStack服务进行更新时，对OpenStack的配置清单文件进行修改，将不需要更新的OpenStack服务从配置清单文件中删除，以避免Armada工具对不需要更新的文件进行更新或删除。进而，就可以实现只针对某个或某几个OpenStack服务进行部署或者升级，避免在OpenStack的版本演进过程中，出现意外更新升级了不需要更新的服务的情况，解决现有技术中的技术问题。

下面将对本申请实施例提供的OpenStack服务部署方法的网络架构和应用场景进行介绍。下面的描述涉及附图时，除非另有表示，不同附图中的相同数据表示相同或相似的要素。

图1是本申请实施例提供的OpenStack服务更新方法的应用场景对应的网络架构图。如图1所示，本申请实施例提供的一种应用场景对应的网络架构中包括：电子设备10、配置管理服务设备11、预设管理工具12、Helm工具13、Kubernetes平台14、OpenStack平台15、chart包仓库16。其中，Helm工具13包括客户端组件helm131和服务端组件Tiller132。Kubernetes平台14部署在OpenStack平台15上。

用户可以在电子设备10上触发服务部署请求。服务部署请求包括至少一个目标服务标识、以及用户对OpenStack服务的部署类型。目标服务标识是用户从多个预设OpenStack服务标识中选择的。部署类型为指定类型或非指定类型。

chart包仓库16中存储有多个预设OpenStack服务的固定配置文件。电子设备10可以从chart包仓库16中获取各目标服务的固定配置文件。

配置管理服务设备11上运行有配置管理服务，电子设备10可以采用配置管理服务，根据服务部署请求，生成各目标服务的可选配置文件。第一目标配置清单文件包括各目标服务标识，不包括除目标服务标识之外的其它预设OpenStack服务标识。

预设管理工具12用于对包与配置文件的批量管理，可以被配置在电子设备10中。电子设备10可以采用预设管理工具12，根据各固定配置文件、各可选配置文件、以及第一目标配置清单文件，对OpenStack平台15的各目标服务进行部署或更新。

电子设备10中还可以配置有客户端组件helm131。Kubernetes平台14中可以配置有服务端组件Tiller132。

预设管理工具12通过客户端组件helm131对目标服务进行部署或更新。

实施例一

图2为本申请实施例一提供的OpenStack服务部署方法的流程示意图。如图2所示，本实施例的执行主体为OpenStack服务部署装置，该OpenStack服务部署装置位于电子设备中。本实施例提供的OpenStack服务部署方法包括步骤201至步骤205。

步骤201，接收用户触发的服务部署请求；服务部署请求包括至少一个目标服务标识、以及用户对OpenStack服务的部署类型；目标服务标识是用户从多个预设OpenStack服务标识中选择的，部署类型为指定类型或非指定类型。

本实施例中，用户为需要在OpenStack平台中部署OpenStack服务，或者，需要对OpenStack平台上已经部署的OpenStack服务进行更新或删除的工作人员。多个预设OpenStack服务可以是所有能够部署在OpenStack平台上的服务。目标服务标识和部署类型可以由用户在触发服务部署请求之前，在电子设备中进行选择。

本实施例中，部署类型用于表示用户是否指定了某个或某几个OpenStack服务进行部署、更新或删除。如果用户需要对某个或某几个在OpenStack服务进行部署、更新或删除，而又不希望其它的OpenStack服务受到影响，则选择部署类型为指定类型。如果用户需要一次性对OpenStack上的所有OpenStack服务进行重新部署或全部更新，则可以选择部署类型为非指定类型。

指定类型是指用户指定某个或某几个预设OpenStack服务进行部署、更新或删除，用户可以在一次指定类型的服务部署请求中，对3个不同的预设OpenStack服务分别进行不是、更新或删除。

非指定类型是指用户未指定对某个或某几个预设OpenStack服务进行部署，而是对所有预设OpenStack服务进行统一的部署、更新或删除，用户可以在一次非指定类型的服务部署请求中，对所有预设OpenStack服务中的一部分进行部署或更新，对所有预设OpenStack服务中的另一部分进行删除。

步骤202，获取各目标服务的固定配置文件。

本实施例中，固定配置文件也被称为chart模板文件。Helm使用的包格式称为chart。chart就是一个描述Kubernetes相关资源的文件集合。单个chart可以用来更新一些简单的，类似于memcache pod，或者某些复杂的HTTP服务器以及web全栈应用、数据库、缓存等等。chart模板文件使用Kubernetes可以识别的YAML格式描述。chart模板文件用于生成配置清单manifest文件。

chart仓库是一个配置了index.yaml文件和一些已经打包chart的HTTP服务器，电子设备在获取到目标服务标识后，可以根据目标服务标识从chart仓库中获取目标服务的固定配置文件。

步骤203，采用配置管理服务，根据服务部署请求，生成各目标服务的可选配置文件。

本实施例中，可选配置文件为values.yaml文件，values.yaml文件是Helm解析Chart包时默认的配置文件名称。

配置管理服务可以为sysinv服务，sysinv服务用于对OpenStack服务进行状态管理和配置的修改等。电子设备可以调用sysinv服务生成各目标服务的可选配置文件。

可选地，服务更新请求还包括各目标服务的配置信息，步骤203细化包括步骤301至步骤302。

步骤301，将各目标服务的配置信息发送给配置管理服务，以使配置管理服务根据各目标服务的配置信息生成，生成各目标服务的可选配置文件。

步骤302，接收配置管理服务发送的各可选配置文件。

本实施例中，目标服务的配置信息可以包括目标服务对外的公网接口域名等。电子设备将各目标服务的配置信息发送给配置管理服务。配置管理服务可以根据各目标服务的配置信息生成对应的可选配置文件，并将各可选配置文件发送给电子设备。

步骤204，响应于部署类型为指定类型，采用配置管理服务，根据各目标服务标识，生成OpenStack的第一目标配置清单文件；第一目标配置清单文件包括各目标服务标识，不包括除目标服务标识之外的其它预设OpenStack服务标识。

本实施例中，配置清单文件为manifest文件，用于描述需要在OpenStack上部署的OpenStack服务，需要部署的OpenStack服务间的依赖关系、部署顺序、环境配置等。

本实施例中，如果部署类型为指定类型，则表示用户只需要对OpenStack中的某个或某几个预设OpenStack服务进行处理，因此，为了避免不需要进行处理的OpenStack服务被处理，在采用配置管理服务生成目标配置清单的过程中，可以使得第一目标配置清单文件中包括目标服务标识而不包括除目标服务标识之外的其它预设OpenStack服务标识。这样，后续的预设管理工具在根据第一目标配置清单文件，对OpenStack的各目标服务进行处理时，就不会对除目标服务之外的其它预设OpenStack服务进行处理，进而可以实现对某个或某几个OpenStack服务的处理。此处的处理是指部署、更新或删除。

可选地，服务部署请求还包括各目标服务的操作标识；操作标识为新建操作、更新操作或删除操作；步骤204细化包括步骤401至步骤403。

步骤401，将部署类型和各目标服务标识发送给配置管理服务，以使配置管理服务根据各目标服务标识，在生成OpenStack的第一目标配置清单文件的流程中，禁用除了目标服务之外的其它预设OpenStack服务。

本实施例中，配置管理服务在接收到各目标服务标识后，在生成第一目标配置清单文件的流程中，禁用除了目标服务之外的其它预设OpenStack服务，也就是在生成第一目标配置清单文件的过程中，只生成各目标服务的依赖关系、部署顺序、环境配置等信息，而不生成除了目标服务之外的其它预设OpenStack服务的信息。

步骤402，将各目标服务的操作标识、固定配置文件和可选配置文件发送给配置管理服务，以使配置管理服务根据各目标服务的操作标识、固定配置文件和可选配置文件生成第一目标配置清单文件。

本实施例中，操作标识可以是用户在触发服务部署请求时选择的，用于表示用户对OpenStack服务的操作目的。例如，用户想要将OpenStack中已部署的某个目标服务删除，则可以将该目标服务的操作标识确定为删除操作；用户想要对OpenStack中已部署的某个目标服务进行更新，则可以将该目标服务的操作标识确定为更新操作；用户想要在OpenStack中部署新的目标服务，则可以将该目标服务的操作标识确定为新建操作。

本实施例中，第一目标配置清单文件还包括各目标服务的服务状态，服务状态为启用状态或禁用状态。配置管理服务可以根据各目标服务的操作标识，确定各目标服务在第一目标配置清单文件中的服务状态，例如，将操作标识为删除操作的目标服务的服务状态确定为禁用状态，将操作标识为新建操作或更新操作的目标服务的服务标识确定为启用状态。

步骤403，接收配置管理服务发送的第一目标配置清单文件。

本实施例提供的OpenStack服务部署方法，通过在生成OpenStack的第一目标配置清单文件的流程中，禁用除了各目标服务之外的其它预设OpenStack服务，将不需要部署、更新或删除的预设OpenStack从配置清单文件中删除，进而使得预设管理工具能够只对某个或某几个OpenStack服务进行部署、更新或删除。

步骤205，采用对包与配置文件批量管理的预设管理工具，根据各固定配置文件、各可选配置文件、以及第一目标配置清单文件，对OpenStack的各目标服务进行部署或更新。

本实施例中，预设管理工具可以为Armada。

可选地，步骤205细化包括步骤501。

步骤501，基于各固定配置文件、各可选配置文件、以及第一目标配置清单文件，通过第一预设调用命令调用预设管理工具对OpenStack的各目标服务进行部署或更新。

本实施例中，第一预设调用命令和第二预设调用命令是分别根据部署类型为指定类型和非指定类型两种应用场景进行预设的。

第二预设调用命令可以为调用Armada的开源命令，例如：

armada apply--enable-chart-cleanup mainifest.yaml--valuesoverride.yaml。

第一预设调用命令可以通过对第二预设调用命令进行修改后获得，例如：

armada apply mainifest.yaml--values override.yaml。

本实施例提供的OpenStack服务部署方法，通过第一预设调用命令调用预设管理工具对OpenStack的各目标服务进行部署或更新，由于第一预设调用命令由调用Armada的开源命令修改得到，因此，可以成功调用Armada，并且，能够在调用Armada的过程中，实现针对某个或某几个OpenStack服务进行部署、升级或删除。

可选地，第一目标配置清单文件还包括各目标服务的服务状态，服务状态为启用状态或禁用状态；步骤501细化包括步骤601至步骤604。

步骤601，通过第一预设调用命令，调用预设管理工具，以使预设管理工具按以下操作对各目标服务进行遍历：

步骤602，根据目标服务标识，确定目标服务在OpenStack中是否运行；

步骤603，响应于目标服务的服务状态为启用状态，且目标服务在OpenStack中运行，根据目标服务标识对应的固定配置文件和可选配置文件，对目标服务进行更新；

步骤604，响应于目标服务的服务状态为启用状态，且目标服务在OpenStack中未运行，根据目标服务标识对应的固定配置文件和可选配置文件，对目标服务进行部署。

本实施例中，电子设备可以获取OpenStack的实时服务清单。实时服务清单包括至少一个实时服务标识；实时服务标识为OpenStack中正在运行的预设OpenStack服务的标识。电子设备可以确定目标服务标识在实时服务清单中是否存在，如果目标服务标识在实时服务清单中存在，则可以确定目标服务在OpenStack中运行。如果目标服务标识在实时服务清单中不存在，则可以确定目标服务在OpenStack中未运行。

如果目标服务的服务状态为启用状态，且目标服务在OpenStack中运行，则表示需要对目标服务进行更新，因此，预设管理工具可以根据目标服务标识对应的固定配置文件和可选配置文件，对目标服务进行更新。

如果响应于目标服务的服务状态为启用状态，且目标服务在OpenStack中未运行，则表示需要在OpenStack中部署目标服务，因此，预设管理工具可以根据目标服务标识对应的固定配置文件和可选配置文件，对目标服务进行部署。

本实施例提供的OpenStack服务部署方法，通过第一预设调用命令，调用预设管理工具，进而由预设管理工具根据第一目标配置清单文件包括的各目标服务的服务状态，以及各目标服务的固定配置文件和可选配置文件，对目标服务进行部署或更新，由于第一目标配置清单文件不包括除目标服务之外的其它预设OpenStack服务，因此，预设管理工具可以针对各目标服务进行部署或更新，而不影响其它预设OpenStack服务。

本实施例提供的OpenStack服务部署方法，通过接收用户触发的服务部署请求；服务部署请求包括至少一个目标服务标识、以及用户对OpenStack服务的部署类型；目标服务标识是用户从多个预设OpenStack服务标识中选择的，部署类型为指定类型或非指定类型；获取各目标服务的固定配置文件；采用配置管理服务，根据服务部署请求，生成各目标服务的可选配置文件；响应于部署类型为指定类型，采用配置管理服务，根据各目标服务标识，生成OpenStack的第一目标配置清单文件；第一目标配置清单文件包括各目标服务标识，不包括除目标服务标识之外的其它预设OpenStack服务标识；采用对包与配置文件批量管理的预设管理工具，根据各固定配置文件、各可选配置文件、以及第一目标配置清单文件，对OpenStack的各目标服务进行部署或更新。由于部署类型能够反应用户是否需要对指定的某个或某几个预设OpenStack服务进行部署、更新或删除，因此，在部署类型为指定类型时，采用配置管理服务，根据各目标服务标识，生成OpenStack的第一目标配置清单文件；第一目标配置清单文件包括各目标服务标识，不包括除目标服务标识之外的其它预设OpenStack服务标识。由于第一目标配置清单文件不包括除目标服务标识之外的其它预设OpenStack服务标识，因此，采用对包与配置文件批量管理的预设管理工具，根据各固定配置文件、各可选配置文件、以及第一目标配置清单文件，对OpenStack的各目标服务进行部署或更新，就不会影响到除了目标服务之外的其它预设OpenStack服务，因此，本申请的方案可以解决现有技术中的问题，只针对某个或某几个OpenStack服务进行部署或者升级，使得在OpenStack的版本演进过程中，避免意外更新升级了不需要更新的服务的情况。

实施例二

图3为本申请实施例二提供的OpenStack服务部署方法的流程示意图。如图3所示，本实施例提供的OpenStack服务部署方法，在实施例一的基础上，步骤203之后，还包括步骤701至步骤702。

步骤701，响应于部署类型为非指定类型，采用配置管理服务，根据各目标服务标识，生成OpenStack的第二目标配置清单文件；第二目标配置清单文件包括多个预设OpenStack服务标识，以及各预设OpenStack服务的服务状态；服务状态为启用状态或禁用状态。

本实施例中，如果用户不需要对某个或某几个预设OpenStack服务进行部署，而是对所有预设OpenStack服务进行统一的部署、更新或删除，则第二目标配置清单文件包括多个预设OpenStack服务标识，以及各预设OpenStack服务的服务状态。并且，在第二目标配置清单文件中，若预设OpenStack服务为目标服务，则预设OpenStack服务的服务状态为启用状态。若预设OpenStack服务不为目标服务，则预设OpenStack服务的服务状态为禁用状态。

步骤702，基于各固定配置文件、各可选配置文件、以及第二目标配置清单文件，通过第二预设调用命令调用预设管理工具对OpenStack的各目标服务进行部署或更新。

本实施例中，预设管理工具可以为Armada，第二预设调用命令可以为调用Armada的开源命令，例如：

armada apply--enable-chart-cleanup mainifest.yaml--valuesoverride.yaml。

可选地，步骤702细化包括步骤801至步骤805。

步骤801，通过第二预设调用命令，调用预设管理工具，以使预设管理工具按以下操作对各预设OpenStack服务进行遍历：

步骤802，根据预设OpenStack服务标识，确定预设OpenStack服务在OpenStack中是否运行；

步骤803，响应于预设OpenStack服务的服务状态为启用状态，且预设OpenStack服务在OpenStack中运行，根据预设OpenStack服务标识对应的固定配置文件和可选配置文件，对预设OpenStack服务进行更新；

步骤804，响应于预设OpenStack服务的服务状态为启用状态，且预设OpenStack服务在OpenStack中未运行，根据预设OpenStack服务标识对应的固定配置文件和可选配置文件，对预设OpenStack服务进行部署；

步骤805，响应于预设OpenStack服务的服务状态为禁用状态，且预设OpenStack服务在OpenStack中运行，停止运行并删除预设OpenStack服务。

本实施例中，确定预设OpenStack服务在OpenStack中是否运行可以参见实施例一中的描述。由于通过第二预设调用命令调用Armada时，第二目标配置清单中包括多个预设OpenStack服务标识，以及各预设OpenStack服务的服务状态。而目标服务属于多个预设OpenStack服务，因此，第二目标配置请求包括各目标服务标识，各目标服务的服务状态，除目标服务之外的预设OpenStack服务标识，以及除目标服务之外的预设OpenStack服务的服务状态。

由于第二预设调用命令为预设管理工具的开源调用命令，因此，对于OpenStack中正在运行的服务，无论该服务是否为目标服务，只要预设管理工具确定该服务在配置清单manifest中对应的预设OpenStack服务的服务状态为禁用状态，则停止OpenStack中的该服务，并将该服务从OpenStack中删除。无论该服务是否为目标服务，只要该服务在配置清单manifest中的服务状态为启用状态，Armada会对该服务进行更新。

对于OpenStack中未运行的服务，如果预设管理工具确定该服务在配置清单manifest中的服务状态为启用状态，则会在OpenStack中部署该服务，如果预设管理工具确定该服务在配置清单manifest中的服务状态为禁用状态，Armada不会对该服务进行任何处理。

本实施例提供的OpenStack服务部署方法，通过响应于部署类型为非指定类型，采用配置管理服务，根据各目标服务标识，生成OpenStack的第二目标配置清单文件；第二目标配置清单文件包括多个预设OpenStack服务标识，以及各预设OpenStack服务的服务状态；服务状态为启用状态或禁用状态；基于各固定配置文件、各可选配置文件、以及第二目标配置清单文件，通过第二预设调用命令调用预设管理工具对OpenStack的各目标服务进行部署或更新。由于在部署类型为非指定类型时，生成的第二目标配置清单文件包括多个预设OpenStack服务标识，因此，可以满足用户对所有预设OpenStack服务进行统一的部署、更新或删除的需求。

实施例三

图4为本申请实施例三提供的OpenStack服务部署装置的结构示意图。如图4所示，本实施例提供的OpenStack服务部署装置40包括：接收模块41、获取模块42、第一生成模块43、第二生成模块44和部署模块45。

接收模块41，用于接收用户触发的服务部署请求；服务部署请求包括至少一个目标服务标识、以及用户对OpenStack服务的部署类型；目标服务标识是用户从多个预设OpenStack服务标识中选择的，部署类型为指定类型或非指定类型。

获取模块42，用于获取各目标服务的固定配置文件。

第一生成模块43，用于采用配置管理服务，根据服务部署请求，生成各目标服务的可选配置文件。

第二生成模块44，用于响应于部署类型为指定类型，采用配置管理服务，根据各目标服务标识，生成OpenStack的第一目标配置清单文件；第一目标配置清单文件包括各目标服务标识，不包括除目标服务标识之外的其它预设OpenStack服务标识。

部署模块45，用于采用对包与配置文件批量管理的预设管理工具，根据各固定配置文件、各可选配置文件、以及第一目标配置清单文件，对OpenStack的各目标服务进行部署或更新。

可选地，服务部署请求还包括各目标服务的配置信息；第一生成模块，具体用于：

将各目标服务的配置信息发送给配置管理服务，以使配置管理服务根据各目标服务的配置信息生成，生成各目标服务的可选配置文件；

接收配置管理服务发送的各可选配置文件。

可选地，服务部署请求还包括各目标服务的操作标识；操作标识为新建操作、更新操作或删除操作；第二生成模块具体用于：

将部署类型和各目标服务标识发送给配置管理服务，以使配置管理服务根据各目标服务标识，在生成OpenStack的第一目标配置清单文件的流程中，禁用除了各目标服务之外的其它预设OpenStack服务；

将各目标服务的操作标识、固定配置文件和可选配置文件发送给配置管理服务，以使配置管理服务根据各目标服务的操作标识、固定配置文件和可选配置文件生成第一目标配置清单文件；

接收配置管理服务发送的第一目标配置清单文件。

可选地，部署模块具体用于：

基于各固定配置文件、各可选配置文件、以及第一目标配置清单文件，通过第一预设调用命令调用预设管理工具对OpenStack的各目标服务进行部署或更新。

可选地，部署模块具体还用于：

通过第一预设调用命令，调用预设管理工具，以使预设管理工具按以下操作对各目标服务进行遍历：

根据目标服务标识，确定目标服务在OpenStack中是否运行；

响应于目标服务的服务状态为启用状态，且目标服务在OpenStack中运行，根据目标服务标识对应的固定配置文件和可选配置文件，对目标服务进行更新；

响应于目标服务的服务状态为启用状态，且目标服务在OpenStack中未运行，根据目标服务标识对应的固定配置文件和可选配置文件，对目标服务进行部署。

可选地，第二生成模块还用于：

响应于部署类型为非指定类型，采用配置管理服务，根据各目标服务标识，生成OpenStack的第二目标配置清单文件；第二目标配置清单文件包括多个预设OpenStack服务标识，以及各预设OpenStack服务的服务状态；服务状态为启用状态或禁用状态；

部署模块具体还用于：

基于各固定配置文件、各可选配置文件、以及第二目标配置清单文件，通过第二预设调用命令调用预设管理工具对OpenStack的各目标服务进行部署或更新。

可选地，部署模块具体还用于：

通过第二预设调用命令，调用预设管理工具，以使预设管理工具按以下操作对各预设OpenStack服务进行遍历：

根据预设OpenStack服务标识，确定预设OpenStack服务在OpenStack中是否运行；

响应于预设OpenStack服务的服务状态为启用状态，且预设OpenStack服务在OpenStack中运行，根据预设OpenStack服务标识对应的固定配置文件和可选配置文件，对预设OpenStack服务进行更新；

响应于预设OpenStack服务的服务状态为启用状态，且预设OpenStack服务在OpenStack中未运行，根据预设OpenStack服务标识对应的固定配置文件和可选配置文件，对预设OpenStack服务进行部署；

响应于预设OpenStack服务的服务状态为禁用状态，且预设OpenStack服务在OpenStack中运行，停止运行并删除预设OpenStack服务。

本实施例提供的OpenStack服务部署装置可以执行上述任意一个实施例提供的OpenStack服务部署方法，具体的实现方式与原理类似，此处不再赘述。

实施例四

图5为本申请实施例四提供的电子设备的结构示意图。如图5所示，本实施例提供的电子设备50包括：存储器51、处理器52和收发器53。

存储器51、处理器52和收发器53电路互连。

存储器51存储计算机执行指令。

收发器53用于收发数据。

处理器52执行存储器51存储的计算机执行指令，实现如上述任意一个实施例提供的OpenStack服务部署方法，具体的实现方式与原理类似，此处不再赘述。

存储器、处理器和收发器之间可以通过总线实现电路互连。总线可以是工业标准体系结构(Industry Standard Architecture，简称为ISA)总线、外部设备互连(Peripheral Component Interconnect，简称为PCI)总线或扩展工业标准体系结构(Extended Industry Standard Architecture，简称为EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

本实施例中，存储器可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘等。

本实施例中，电子设备可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述OpenStack服务部署方法。

本申请的实施例还提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，计算机执行指令被处理器执行时用于实现如上述任意一个实施例提供的OpenStack服务部署方法，具体的实现方式与原理类似，此处不再赘述。示例性地，计算机可读存储介质可以为只读存储器、随机存取存储器、磁带、软盘和光数据存储设备等。

本申请的实施例还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时用于实现上述任意一个实施例提供的OpenStack服务部署方法，具体的实现方式与原理类似，此处不再赘述。

应该理解，上述的方法实施例仅是示意性的，本申请的方法还可通过其它的方式实现。例如，上述实施例中模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。例如，多个模块可以结合，或者可以集成到另一个系统，或一些特征可以忽略或不执行。

另外，若无特别说明，在本申请各个实施例中的各功能模块可以集成在一个模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一起。上述集成的模块既可以采用硬件的形式实现，也可以采用软件程序模块的形式实现。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于可选实施例，所涉及的动作和模块并不一定是本申请所必须的。

进一步需要说明的是，虽然流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求书指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。