一种应用部署方法及设备与流程

本申请涉及计算机领域，尤其涉及一种应用部署方法及设备。

背景技术：

云计算作为一种新的计算服务提供方式，能让企业通过网络以按需、易扩展的方式获得服务，免除软件购买、运维和维护的困扰和费用，降低企业管理成本，现在的商业应用正在逐渐向云计算转移。云计算的一个重要特点是易扩展，即计算能力的弹性伸缩，当业务需要更多的计算能力的时候，系统能分配更多的计算资源给用户。在具体的提供方式上一般操作是：以集群方式把服务器分配给用户，当业务需求的计算资源大于当前的计算能力时，系统会向集群中添加更多的服务器以作补充，同样，当业务量减少时，系统会减少集群中服务器的数量。

随着网络技术的应用，应用部署作为运维开发的重要环节也得到了深入发展，应用部署的质量直接影响了应用程序的功能和用户体验。传统的应用部署方式大都是运维人员手工操作完成，即使使用自动化部署方式实现的部署方案，也在易用性、集群化、可伸缩等方面存在诸多不足，很难满足当前云计算环境的应用部署需求。图1示出了现有技术中应用部署方案的示意图，其进行应用部署的过程如下：应用部署设备110读取本地的配置文件，根据本地的配置文件依次与应用集群中的各个应用服务器建立连接，协商通信机制；应用部署设备110上传安装配置包到应用服务器1，并在应用服务器1进行应用部署；应用部署设备110按照上一步骤的方式依次在其余的应用服务器2～N上进行应用部署；全部完成后，应用部署设备110处理结果，并反馈给用户；如果应用集群中需要增加应用服务器，必须由用户修改应用部署设备的配置文件或者获取预先设置的配置文件，重复前述步骤重新进行应用部署。

由此可知，现有的应用部署方案中其网络架构是相对固定的，如果要向应用集群中动态添加一台应用服务器，则应用的部署、升级都要相应修 改部署方案，因此应用部署方式不够灵活，无法进行弹性部署。

技术实现要素：

本申请的目的是提供一种应用部署方法及设备，以解决现有技术中应用部署方式不够灵活，无法进行弹性部署的问题。

为实现上述目的，本申请提供了一种应用部署方法，该方法包括：

获取线上配置信息，其中所述线上配置信息包含根据应用的当前需求确定的待部署的应用服务器；

若所述线上配置信息与本地配置信息不同，且所述线上配置信息中有新增的应用服务器，则对所述新增的应用服务器进行应用部署，并根据所述线上配置信息更新所述本地配置信息，其中所述本地配置信息包含当前已进行应用部署的应用服务器。

进一步地，获取线上配置信息之后，还包括：

若所述线上配置信息与本地配置信息不同，且所述线上配置信息中无新增的应用服务器，则根据所述线上配置信息更新所述本地配置信息。

进一步地，获取线上配置信息，包括：

向弹性伸缩服务平台发送查询请求，并接收所述弹性伸缩服务平台根据所述查询请求发送的线上配置信息，其中所述弹性伸缩平台根据应用的需求确定当前待部署的应用服务器；或

接收弹性伸缩服务平台发送的包含所述线上配置信息的推送消息。

进一步地，对新增的应用服务器进行应用部署，包括：

将所述应用的安装配置包发送至与该应用的类型对应类型的应用服务器，并根据所述安装配置包对所述应用服务器进行应用部署。

进一步地，对新增的应用服务器进行应用部署，包括：

将所述应用的安装配置包发送至多个新增的应用服务器，并根据所述安装配置包同时对所述应用服务器进行应用部署。

进一步地，对新增的应用服务器进行应用部署，包括：

若所述应用可并发执行，则同时将所述应用的安装配置包发送至与该应用的类型对应类型的多个应用服务器，并根据所述安装配置包同时对所 述应用服务器进行应用部署；

若所述应用不可并发执行，则依次将所述应用的安装配置包发送至与该应用的类型对应类型的多个应用服务器，并根据所述安装配置包依次对所述应用服务器进行应用部署。

进一步地，根据所述安装配置包同时对所述应用服务器进行应用部署，包括：

创建针对每个应用服务器的子进程，控制所述子进程分别根据所述安装配置包对所述应用服务器进行应用部署；

获取所述子进程发送的每个应用服务器的应用部署结果。

进一步地，对新增的应用服务器进行应用部署，包括：

获取所述应用服务器的登录用户名和登录密码，根据所述登录用户名和登录密码登录所述应用服务器；

指示所述应用服务器安装所述应用的安装配置包。

进一步地，所述应用服务器的登录用户名根据以下优先级顺序的其中一种方式获取：

由命令行的输入信息获取所述应用服务器的登录用户名；

由预设文件中获取所述应用服务器的登录用户名；

获取本地设备的用户名作为所述应用服务器的登录用户名。

进一步地，所述应用服务器的登录密码根据以下优先级顺序的其中一种方式获取：

由命令行的输入信息获取所述应用服务器的登录密码；

由预设文件中获取所述应用服务器的登录密码；

由本地设备的缓存获取所述应用服务器的登录密码；

获取用户由本地设备输入的密码作为所述应用服务器的登录密码。

基于本申请的另一方面，还提供了一种应用部署设备，该设备包括：

配置获取装置，用于获取线上配置信息，其中所述线上配置信息包含根据应用的当前需求确定的待部署的应用服务器；

部署装置，用于若所述线上配置信息与本地配置信息不同，且所述线上配置信息中有新增的应用服务器，则对所述新增的应用服务器进行应用 部署，并根据所述线上配置信息更新所述本地配置信息，其中所述本地配置信息包含当前已进行应用部署的应用服务器。

进一步地，所述部署装置，还用于若所述线上配置信息与本地配置信息不同，且所述线上配置信息中无新增的应用服务器，则根据所述线上配置信息更新所述本地配置信息。

进一步地，所述配置获取装置，用于向弹性伸缩服务平台发送查询请求，并接收所述弹性伸缩服务平台根据所述查询请求发送的线上配置信息，其中所述弹性伸缩平台根据应用的需求确定当前待部署的应用服务器；或

接收弹性伸缩服务平台发送的包含所述线上配置信息的推送消息。

进一步地，所述部署装置在对所述新增的应用服务器进行应用部署时，用于将所述应用的安装配置包发送至与该应用的类型对应类型的应用服务器，并根据所述安装配置包对所述应用服务器进行应用部署。

进一步地，所述部署装置在对所述新增的应用服务器进行应用部署时，用于将所述应用的安装配置包发送至多个新增的应用服务器，并根据所述安装配置包同时对所述应用服务器进行应用部署。

进一步地，所述部署装置在对所述新增的应用服务器进行应用部署时，用于若所述应用可并发执行，则同时将所述应用的安装配置包发送至与该应用的类型对应类型的多个应用服务器，并根据所述安装配置包同时对所述应用服务器进行应用部署；以及若所述应用不可并发执行，则依次将所述应用的安装配置包发送至与该应用的类型对应类型的多个应用服务器，并根据所述安装配置包依次对所述应用服务器进行应用部署。

进一步地，所述部署装置在根据所述安装配置包同时对所述应用服务器进行应用部署时，用于创建针对每个应用服务器的子进程，控制所述子进程分别根据所述安装配置包对所述应用服务器进行应用部署；以及获取所述子进程发送的每个应用服务器的应用部署结果。

进一步地，所述部署装置在对所述新增的应用服务器进行应用部署时，用于获取所述应用服务器的登录用户名和登录密码，根据所述登录用户名和登录密码登录所述应用服务器；

指示所述应用服务器安装所述应用的安装配置包。

进一步地，所述应用服务器的登录用户名根据以下优先级顺序的其中一种方式获取：

由命令行的输入信息获取所述应用服务器的登录用户名；

由预设文件中获取所述应用服务器的登录用户名；

获取本地设备的用户名作为所述应用服务器的登录用户名。

进一步地，所述应用服务器的登录密码根据以下优先级顺序的其中一种方式获取：

由命令行的输入信息获取所述应用服务器的登录密码；

由预设文件中获取所述应用服务器的登录密码；

由本地设备的缓存获取所述应用服务器的登录密码；

获取用户由本地设备输入的密码作为所述应用服务器的登录密码。

与现有技术相比，本申请的技术方案在完成初始部署之后，能够动态获取根据应用的当前需求确定的待部署的应用服务器的线上配置信息，通过与本地配置信息比较，在发现有新增的应用服务器需要进行应用部署后，对这些新增的应用服务器进行应用部署，从而实现应用的弹性部署，提高部署方案的灵活性，同时通过线上配置信息更新原有的本地配置信息，对当前已进行应用部署的应用服务器进行记录，保证后续应用部署的准确性。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1为现有技术中应用部署方案的原理示意图；

图2为本申请实施例提供的一种应用部署方法的流程图；

图3为本申请实施例中进行应用部署时所涉及的相关设备的典型实现方式图；

图4为本申请实施例中应用部署设备进行应用部署时的处理流程图；

图5(a)为采用顺序执行的方式进行应用部署的原理示意图；

图5(b)为采用并发部署的方式进行应用部署的原理示意图；

图6为本申请实施例中将根据应用服务器类型进行应用部署的方式与并发部署的方式结合的处理流程图；

图7为本申请实施例中采用多线程的方式进行并发的应用部署的处理流程图；

图8(a)为本申请实施例中获取登录用户名的处理流程图；

图8(b)为本申请实施例中获取登录密码的处理流程图；

图9为本申请实施例提供的一种应用部署设备的结构示意图；

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

下面结合附图对本申请作进一步详细描述。

在本申请一个典型的配置中，终端、服务网络的设备和可信方均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

图2示出了本申请实施例提供的一种应用部署方法，该方法包括以下 步骤：

步骤S201，获取线上配置信息，其中所述线上配置信息包含根据应用的当前需求确定的待部署的应用服务器；

步骤S202，若所述线上配置信息与本地配置信息不同，且所述线上配置信息中有新增的应用服务器，则对所述新增的应用服务器进行应用部署，并根据所述线上配置信息更新所述本地配置信息，其中所述本地配置信息包含当前已进行应用部署的应用服务器。

该方法尤其适用于已经完成应用的初始部署，在后续运维过程中进行动态弹性调整的场景。若需要对应用进行初始部署，可以采用传统的方式，由用户提供需要进行应用部署的应用服务器的信息以及对应的安装配置包，并由此完成对应用服务器的初始部署。对于初始部署时已进行应用部署的应用服务器，可以保存为本地配置信息。

在完成初始部署之后，能够动态获取根据应用的当前需求确定的待部署的应用服务器的线上配置信息，通过与本地配置信息比较，在发现有新增的应用服务器需要进行应用部署后，对这些新增的应用服务器进行应用部署，从而实现应用的弹性部署，提高部署方案的灵活性，同时通过线上配置信息更新原有的本地配置信息，对当前已进行应用部署的应用服务器进行记录，保证后续应用部署的准确性。

在此，本领域技术人员应当理解，上述应用部署方法的执行主体可以包括但不限于用户设备、网络设备或用户设备与网络设备通过网络相集成所构成的设备。所述用户设备包括但不限于个人计算机、触控终端等实现；所述网络设备包括但不限于如网络主机、单个网络服务器、多个网络服务器集或基于云计算的计算机集合等实现。在此，云由基于云计算(Cloud Computing)的大量主机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个虚拟计算机。

图3示出了一种采用上述应用部署方法时所涉及的相关设备的典型实现方式，包括应用部署设备310、包含多个应用服务器的应用集群320、弹性伸缩服务平台330以及用户本地工作设备340。其中，应用部署设备310用于执行上述应用部署方法，对应用服务器进行应用部署；所述应用 服务器用于在应用部署完成后，运行相关应用。用户本地工作设备340为用户与应用部署设备310进行交互的设备，用于用户提供安装配置包、初始部署时的相关信息等。弹性伸缩服务平台330能够调整云资源池中的计算资源，根据应用的当前需求将云资源池中的服务器分配给该应用使用，因此能够确定待部署的应用服务器，从而获取线上配置信息，并将获取的线上配置信息提供给应用部署设备310以进行弹性部署。在实际应用中，弹性伸缩服务平台330的具体实现可以由服务提供商决定，例如阿里云平台提供的ESS(Elastic Scaling Service，弹性伸缩服务)。

优选地，获取线上配置信息，具体包括：向弹性伸缩服务平台发送查询请求，并接收所述弹性伸缩服务平台根据所述查询请求发送的线上配置信息，其中所述弹性伸缩平台根据应用的需求确定当前待部署的应用服务器；或接收弹性伸缩服务平台发送的包含所述线上配置信息的推送消息。以本申请实施例中提供的方案为例，如果应用部署设备使用了推送服务，则可以接收弹性伸缩服务平台发送推送消息，该推送消息中包含了线上配置信息，通过解析推送消息，可以获取线上配置信息进行应用部署；若应用部署设备未使用推送服务，那么可以定时(例如每隔两秒)向弹性伸缩服务平台发送一次查询请求，进行线上配置信息的查询，通过弹性伸缩服务平台反馈，获取线上配置信息。根据不同的应用场景，可以采用不同的方式获取线上配置信息，以提高本方案的通用性。

以某一视频播放的应用为例，若当前部署有该应用的应用服务器为5台，该5台应用服务器的相关信息会保存在本地配置信息中，包括应用服务器的IP、应用服务器的数量等。每当有热门节目播放时，由于观看者较多服务器的负载会显著增加，容易造成服务器宕机，影响用户观看体验。因此需要在其它新的应用服务器上部署该应用以分担当前应用服务器的负载，例如一共需要7台应用服务器才可以满足当前的负载要求，此时会获取包含该7台应用服务器相关信息的线上配置信息。通过与本地配置信息比较，会对新增加的2台应用服务器进行应用部署，以满足应用的当前要求，同时将本地配置信息中的内容更新为所述7台应用服务器的相关内容。

此外，在前述场景中还可能存在以下情形，当热门节目播放完后，观看者的数量可能随之减少，此时仍然使用7台应用服务器会造成计算资源的浪费。因此可以根据此时应用的需求，减少应用服务器的数量，提高计算资源的利用率。对于前述远程应用配置方法，在获取线上配置信息之后，若所述线上配置信息与本地配置信息不同，且所述线上配置信息中无新增的应用服务器，则根据所述线上配置信息更新所述本地配置信息。当所述线上配置信息与本地配置信息不同，且所述线上配置信息中无新增的应用服务器，即表示根据应用的当前需求确定的待部署的应用服务器的数量相较于当前已进行应用部署的应用服务器的数量是减少的，对于应用部署设备，仅需要根据所述线上配置信息更新所述本地配置信息即可。

在实际应用中，某一应用部署设备进行应用部署的具体处理步骤如图4所示，包括以下步骤：

步骤S401，获取应用的初始配置信息以及对应的安装配置包install.tgz，并由此完成对应用服务器的初始部署。对于初始部署时已进行应用部署的应用服务器的相关信息，可以保存为本地配置信息的文件topo.conf。

步骤S402，确定是否使用推送服务，若使用了推送服务，则执行步骤S403；若未使用推送服务器，则执行步骤404。

步骤S403，接收弹性伸缩服务平台推送消息，并由推送消息中获取线上配置信息，然后执行步骤S405。

步骤S404，向弹性伸缩服务平台发送查询请求，并根据反馈获取线上配置信息，然后执行步骤S405。

步骤S405，将所述线上配置信息与本地配置信息进行比较，若两者相同，则等待设定时间后，返回执行步骤S402；若两者不同，则执行步骤S406。

步骤S406，判断所述线上配置信息中是否有新增的应用服务器，若是，则执行步骤S407；若否，则执行步骤S408。

步骤S407，使用安装配置包install.tgz对所述新增的应用服务器进行应用部署，然后执行步骤S408。

步骤S408，根据所述线上配置信息更新保存所述本地配置信息的文件topo.conf，然后返回执行步骤S402。

作为本申请实施例的一种优选的实施方式，对新增的应用服务器进行应用部署，具体包括：将所述应用的安装配置包发送至与该应用的类型对应类型的应用服务器，并根据所述安装配置包对所述应用服务器进行应用部署。通过对应用服务器定义不同的类型，来划分不同的服务器集群，这样即可以在不同的服务器集群部署不同的应用，将同一类应用整合至相应类型的应用服务器，便于服务器集群的管理。在本实施例中，使用roledefs和roles分别对应用服务器的集群以及应用服务器进行定义。具体格式为：

通过上述方式定义了两个应用服务器的集群：集群1“apphosts”，包含三个应用服务器host1、host2、host3，在属于“apphosts”集群的应用服务器执行任务1(task1)，具体任务是安装app应用(run('/root/install_app.sh))；集群2“apphosts”，包含两个应用服务器host3、host4，在属于“webhosts”集群的应用服务器执行任务2(task2)，具体任务是安装web应用(run('/root/install_web.sh'))。通过对应用服务器进行集群化管理，可以同时在不同类型的应用服务器上部署不同类型应用，这种实现方式更加符合云计算的复杂应用场景。

在实际应用中，若需要一次对数量较大的应用服务器进行应用部署时，如果采用顺序执行的部署方式，将非常消耗时间资源。例如，图1所示的方法中应用部署设备上传安装配置包到应用服务器1，并在应用服务器1进行应用部署，然后应用部署设备按照上一步骤的方式依次在其余的 应用服务器2～N上进行应用部署，此时对N个应用服务器进行应用部署所使用的时间为T×N，其中T为对一个服务器进行应用部署所需要的时间。由于应用服务器之间的应用部署过程是相互独立的，因此对所有应用服务器进行并发的应用部署不会对整个应用部署过程带来负面影响，并且理论上一个应用在N个应用服务器进行并发部署所需要的部署时间仅为T，与顺序执行的部署方式相比，其能够节约(N-1)/N的时间，这将大大提高应用部署的效率。具体地，对新增的应用服务器进行应用部署，具体包括：将所述应用的安装配置包发送至多个新增的应用服务器，并根据所述安装配置包同时对所述应用服务器进行应用部署。

图5(a)和图5(b)分别为前述顺序执行的部署方式以及并发部署方式的原理示意图。在图5(a)中，以两个应用分别对三个应用服务器进行应用部署的两个部署任务为例，应用1的部署任务task1会依次在host1、host2和host3中部署应用1，完成之后在执行应用2的部署任务task2，该task2会依次在在host1、host2和host3中部署应用2，假设应用1和应用2在每个应用服务器上完成部署的时间相同，均为T，则此种方式的总部署时间需要6T。而在5(b)所示的并发执行的场景下，应用1的部署任务task1会同时在host1、host2和host3中部署应用1，待task1完成后，应用2的部署任务task2会同时在host1、host2和host3中部署应用2，因此此种方式的总部署时间为2T，部署效率明显提高。

作为一种更优选的实施方式，可以将前述根据应用服务器类型进行应用部署的方式与并发部署的方式结合，其逻辑处理流程如图6所示。在实际应用中，可以通过配置信息中的roles变量来确定是否设置了对应的类型，如果存在roles变量，则可以根据roles变量来确定对应类型的应用服务器，然后根据应用的配置信息中的parallel变量来确定该应用的部署是否可以并发进行。若所述roles变量为'apphosts'，且所述应用可并发执行(即parallel变量使能)，则同时将所述应用的安装配置包发送至与该应用的类型对应类型的多个应用服务器，并根据所述安装配置包同时对所述应用服务器进行应用部署，即同时将所述应用的安装配置包发送至与host1、host2和host3，并根据所述安装配置包同时对host1、host2和host3进行 应用部署。若所述应用不可并发执行(即parallel变量不使能)，则依次将所述应用的安装配置包发送至与该应用的类型对应类型的多个应用服务器，并根据所述安装配置包依次对所述应用服务器进行应用部署，即将所述应用的安装配置包发送至与host1，并根据所述安装配置包对host1进行应用部署之后，再将安装配置包发送至与host2并对host2进行应用部署，最后将装配置包发送至与host3并对host3进行应用部署。

对于不存在roles变量的情形，即表示该应用需要在未定义类型的应用服务器上进行部署，本实施例中，hosts变量定义的应用服务器即表示该种应用服务器。因此，若不存在roles变量，且所述应用可并发执行，则在同时将所述应用的安装配置包发送至与多个hosts变量定义的应用服务器中，并根据所述安装配置包依次对所述应用服务器进行应用部署。若不存在roles变量，且所述应用不可并发执行，则依次将所述应用的安装配置包发送至与多个hosts变量定义的应用服务器，并根据所述安装配置包依次对所述应用服务器进行应用部署。

此外，考虑到多线程安全问题，在对多个应用服务器进行并发部署时，可以采用多进程的方式。根据所述安装配置包同时对所述应用服务器进行应用部署，具体包括：创建针对每个应用服务器的子进程，控制所述子进程分别根据所述安装配置包对所述应用服务器进行应用部署；获取所述子进程发送的每个应用服务器的应用部署结果。仍以在“apphosts”集群的三个应用服务器并发部署应用为例，其处理流程如图7所示，若在进行应用部署时，若应用部署设备中的主进程确定所述应用可并发执行，则获取线上配置信息中新增的应用服务器的信息并完成安装配置包的准备；然后针对每个应用服务器创建一个对应的子进程，例如针对“apphosts”集群的三个应用服务器host1、host2和host3则分别创建子进程1、子进程2和子进程3，每个子进程专门负责对应应用服务器的应用部署、管控等工作，不同的子进程之间相互不影响。创建完子进程后，主进程指示子进程1、子进程2和子进程3分别在host1、host2和host3进行应用部署，各个子进程在完成应用部署后，会将应用部署结果发送到主进程。主进程收集完所有子进程的应用部署结果时，对结果进行汇总后发送给用户本地工作 设备，以完成向用户的信息反馈。

在实际应用中，对新增的应用服务器进行应用部署，具体包括：获取所述应用服务器的登录用户名和登录密码，根据所述登录用户名和登录密码登录所述应用服务器；指示所述应用服务器安装所述应用的安装配置包。在对应用服务器进行应用部署时，可以通过登录用户名和登录密码来登录到对应的应用服务器来取得在该应用服务器安装相关应用的安装配置包的权限，由此可以保证网络环境的安全性。对于集群规模较大的场景，其内包含的应用服务器数量较大，因此在部署过程中会有非常多的登录用户名和登录密码的输入需求，为了降低用户管理应用服务器的登录用户名和登录密码的难度，在本申请实施例中所述应用服务器的登录用户名根据以下优先级顺序的其中一种方式获取，具体可参考图8(a)：

1、由命令行的输入信息获取所述应用服务器的登录用户名。由命令行输入的用户名为优先级最高的获取方式，当检测到用户由命令行输入登录用户名时，则直接由命令行提取登录用户名，并使用该登录用户名尝试登录应用服务器。

2、由预设文件中获取所述应用服务器的登录用户名。此种方式的优先级低于由命令行的输入信息获取所述应用服务器的登录用户名，其中所述预设文件可以是安装配置包中的配置描述文件，也可以是用户在初始配置过程中向应用部署设备上传的初始配置信息中的内容。所述应用服务器的登录用户名一般可以由预设文件中的相关变量保存，例如本实施例中，通过预设文件中的两个变量保存登录用户名，分别为user变量和hosts变量，其中hosts变量分别对不同的应用服务器定义不同的登录用户名，其形式可以是应用服务器的标识(例如IP地址)与应用服务器的登录用户名的对应关系表的形式，当存在hosts变量时，获取应用服务器的登录用户名，同时确定该应用服务器当前是否存在，此时从hosts变量中提取应用服务器的登录用户名。而user变量则统一定义了一个登录用户名，当不存在hosts变量时或者hosts变量中的应用服务器当前不在线时，才由user变量中提取登录用户名，因此user变量的优先级低于hosts变量。

3、获取本地设备的用户名作为所述应用服务器的登录用户名。没有 从命令行获取到登录用户名、并且不存在hosts变量以及user变量时，才会默认获取本地设备的用户名作为所述应用服务器的登录用户名。其中，所述本地设备可以是用户与应用部署设备进行交互的设备，例如在图3的典型实现方式中，本地设备即为用户本地工作设备340。

当应用部署设备通过前述任意一种方式获取到登录用户名之后，会继续获取登录密码。其中，所述应用服务器的登录密码根据以下优先级顺序的其中一种方式获取，具体可参考图8(b)：

1、由命令行的输入信息获取所述应用服务器的登录密码。由命令行输入的密码为优先级最高的获取方式，当检测到用户由命令行输入登录密码时，则直接由命令行提取登录密码，并配合之前获取到的登录用户名尝试登录应用服务器。

2、由预设文件中获取所述应用服务器的登录密码。此种方式的优先级低于由命令行的输入信息获取所述应用服务器的登录密码，所述应用服务器的登录密码同样可以由预设文件中的相关变量保存，例如本实施例中，通过预设文件中的两个变量保存登录密码，分别为passwords变量和password变量，其中passwords变量分别对不同的应用服务器定义不同的登录密码，其形式可以是应用服务器的标识(例如IP地址)与应用服务器的登录密码的对应关系表的形式，当存在passwords变量时，获取应用服务器的登录密码，同时确定该应用服务器当前是否存在，此时从passwords变量中提取应用服务器的登录密码。而password变量则统一定义了一个登录密码，当不存在passwords变量时或者passwords变量中的应用服务器当前不在线时，才由password变量中提取登录密码，因此password变量的优先级低于passwords变量。

3、由本地设备的缓存获取所述应用服务器的登录密码。与获取登录用户名时类似，当没有从命令行获取到登录密码、并且不存在passwords变量以及password变量时，才会由本地设备的缓存中获取密码作为所述应用服务器的登录密码。

4、获取用户由本地设备输入的密码作为所述应用服务器的登录密码。当本地设备的缓存中也未保存任何密码时，作为优先级最低的方式，会需 要用户由本地设备输入密码。

本实施例中登录用户名、登录密码都以命令行的输入作为最高的优先级，这符合用户的使用习惯。此外，一般用户都会将常用的登录用户名和登录密码记录在预设文件里，只有在少量的特殊情况下才会通过本地设备进行手动输入。因此通过此种方式获取登录用户名和密码的方式最大限度的满足用户的使用需求，为应用部署的高效进行提供了便捷。

图9示出了本申请实施例提供的一种应用部署设备，该设备包括配置获取装置910和部署装置920。具体地，所述配置获取装置910用于获取线上配置信息，其中所述线上配置信息包含根据应用的当前需求确定的待部署的应用服务器；所述部署装置920用于若所述线上配置信息与本地配置信息不同，且所述线上配置信息中有新增的应用服务器，则对所述新增的应用服务器进行应用部署，并根据所述线上配置信息更新所述本地配置信息，其中所述本地配置信息包含当前已进行应用部署的应用服务器。

该设备尤其适用于已经完成应用的初始部署，在后续运维过程中进行动态弹性调整的场景。若需要对应用进行初始部署，可以采用传统的方式，配置获取装置910获取用户提供的需要进行应用部署的应用服务器的信息以及对应的安装配置包，并由部署装置920完成对所述应用服务器的初始部署。对于初始部署时已进行应用部署的应用服务器，可以保存为本地配置信息。

在完成初始部署之后，配置获取装置910能够动态获取根据应用的当前需求确定的待部署的应用服务器的线上配置信息，通过与本地配置信息比较，在发现有新增的应用服务器需要进行应用部署后，由部署装置920对这些新增的应用服务器进行应用部署，从而实现应用的弹性部署，提高部署方案的灵活性，同时通过线上配置信息更新原有的本地配置信息，对当前已进行应用部署的应用服务器进行记录，保证后续应用部署的准确性。

在此，本领域技术人员应当理解，上述应用部署设备可以包括但不限于用户设备、网络设备或用户设备与网络设备通过网络相集成所构成的设备。所述用户设备包括但不限于个人计算机、触控终端等实现；所述网络 设备包括但不限于如网络主机、单个网络服务器、多个网络服务器集或基于云计算的计算机集合等实现。在此，云由基于云计算(Cloud Computing)的大量主机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个虚拟计算机。

图3示出了一种采用上述应用部署设备进行应用部署时所涉及的相关设备的典型实现方式，包括应用部署设备310、包含多个应用服务器的应用集群320、弹性伸缩服务平台330以及用户本地工作设备340。其中，应用部署设备310用于根据配置信息对应用服务器进行应用部署；所述应用服务器用于在应用部署完成后，运行相关应用。用户本地工作设备340为用户与应用部署设备310进行交互的设备，用于用户提供安装配置包、初始部署时的相关信息等。弹性伸缩服务平台330能够根据应用的当前需求确定待部署的应用服务器，从而获取线上配置信息，并将获取的线上配置信息提供给应用部署设备310以进行弹性部署。在实际应用中，弹性伸缩服务平台330的具体实现可以由服务提供商决定，例如阿里云平台提供的ESS(Elastic Scaling Service，弹性伸缩服务)。

优选地，所述配置获取装置910，具体用于向弹性伸缩服务平台发送查询请求，并接收所述弹性伸缩服务平台根据所述查询请求发送的线上配置信息，其中所述弹性伸缩平台根据应用的需求确定当前待部署的应用服务器；或接收弹性伸缩服务平台发送的包含所述线上配置信息的推送消息。以本申请实施例中提供的方案为例，如果应用部署设备使用了推送服务，则可以接收弹性伸缩服务平台发送推送消息，该推送消息中包含了线上配置信息，通过解析推送消息，可以获取线上配置信息进行应用部署；若应用部署设备未使用推送服务，那么可以定时(例如每隔两秒)向弹性伸缩服务平台发送一次查询请求，进行线上配置信息的查询，通过弹性伸缩服务平台反馈，获取线上配置信息。根据不同的应用场景，可以采用不同的方式获取线上配置信息，以提高本方案的通用性。

以某一视频播放的应用为例，若当前部署有该应用的应用服务器为5台，该5台应用服务器的相关信息会保存在本地配置信息中，包括应用服务器的IP、应用服务器的数量等。每当有热门节目播放时，由于观看者较 多服务器的负载会显著增加，容易造成服务器宕机，影响用户观看体验。因此需要在其它新的应用服务器上部署该应用以分担当前应用服务器的负载，例如一共需要7台应用服务器才可以满足当前的负载要求，此时会获取包含该7台应用服务器相关信息的线上配置信息。通过与本地配置信息比较，会对新增加的2台应用服务器进行应用部署，以满足应用的当前要求，同时将本地配置信息中的内容更新为所述7台应用服务器的相关内容。

此外，在前述场景中还可能存在以下情形，当热门节目播放完后，观看者的数量可能随之减少，此时仍然使用7台应用服务器会造成计算资源的浪费。因此可以根据此时应用的需求，减少应用服务器的数量，提高计算资源的利用率。对于前述远程应用配置设备，在配置获取装置910获取线上配置信息之后，部署装置920还用于若所述线上配置信息与本地配置信息不同，且所述线上配置信息中无新增的应用服务器，则根据所述线上配置信息更新所述本地配置信息。当所述线上配置信息与本地配置信息不同，且所述线上配置信息中无新增的应用服务器，即表示根据应用的当前需求确定的待部署的应用服务器的数量相较于当前已进行应用部署的应用服务器的数量是减少的，对于应用部署设备，仅需要根据所述线上配置信息更新所述本地配置信息即可。

在实际应用中，某一应用部署设备进行应用部署的具体处理步骤如图4所示，包括以下步骤：

步骤S401，配置获取装置获取应用的初始配置信息以及对应的安装配置包install.tgz，并由此完成对应用服务器的初始部署。对于初始部署时已进行应用部署的应用服务器的相关信息，可以保存为本地配置信息的文件topo.conf。

步骤S402，配置获取装置确定是否使用推送服务，若使用了推送服务，则执行步骤S403；若未使用推送服务器，则执行步骤404。

步骤S403，配置获取装置接收弹性伸缩服务平台推送消息，并由推送消息中获取线上配置信息，然后执行步骤S405。

步骤S404，配置获取装置向弹性伸缩服务平台发送查询请求，并根据 反馈获取线上配置信息，然后执行步骤S405。

步骤S405，配置获取装置将所述线上配置信息与本地配置信息进行比较，若两者相同，则等待设定时间后，返回执行步骤S402；若两者不同，则执行步骤S406。

步骤S406，配置获取装置判断所述线上配置信息中是否有新增的应用服务器，若是，则执行步骤S407；若否，则执行步骤S408。

步骤S407，部署装置使用安装配置包install.tgz对所述新增的应用服务器进行应用部署，然后执行步骤S408。

步骤S408，配置获取装置根据所述线上配置信息更新保存所述本地配置信息的文件topo.conf，然后返回执行步骤S402。

作为本申请实施例的一种优选的实施方式，所述部署装置920在对所述新增的应用服务器进行应用部署时，具体用于将所述应用的安装配置包发送至与该应用的类型对应类型的应用服务器，并根据所述安装配置包对所述应用服务器进行应用部署。通过对应用服务器定义不同的类型，来划分不同的服务器集群，这样即可以在不同的服务器集群部署不同的应用，将同一类应用整合至相应类型的应用服务器，便于服务器集群的管理。在本实施例中，使用roledefs和roles分别对应用服务器的集群以及应用服务器进行定义。具体格式为：

通过上述方式定义了两个应用服务器的集群：集群1“apphosts”，包含三个应用服务器host1、host2、host3，在属于“apphosts”集群的应用服务器执行任务1(task1)，具体任务是安装app应用 (run('/root/install_app.sh))；集群2“apphosts”，包含两个应用服务器host3、host4，在属于“webhosts”集群的应用服务器执行任务2(task2)，具体任务是安装web应用(run('/root/install_web.sh'))。通过对应用服务器进行集群化管理，可以同时在不同类型的应用服务器上部署不同类型应用，这种实现方式更加符合云计算的复杂应用场景。

在实际应用中，若需要一次对数量较大的应用服务器进行应用部署时，如果采用顺序执行的部署方式，将非常消耗时间资源。例如，图1所示的方案中应用部署设备上传安装配置包到应用服务器1，并在应用服务器1进行应用部署，然后应用部署设备按照上一步骤的方式依次在其余的应用服务器2～N上进行应用部署，此时对N个应用服务器进行应用部署所使用的时间为T×N，其中T为对一个服务器进行应用部署所需要的时间。由于应用服务器之间的应用部署过程是相互独立的，因此对所有应用服务器进行并发的应用部署不会对整个应用部署过程带来负面影响，并且理论上一个应用在N个应用服务器进行并发部署所需要的部署时间仅为T，与顺序执行的部署方式相比，其能够节约(N-1)/N的时间，这将大大提高应用部署的效率。具体地，所述部署装置920在对所述新增的应用服务器进行应用部署时用于将所述应用的安装配置包发送至多个新增的应用服务器，并根据所述安装配置包同时对所述应用服务器进行应用部署。

图5(a)和图5(b)分别为前述顺序执行的部署方式以及并发部署方式的原理示意图。在图5(a)中，以两个应用分别对三个应用服务器进行应用部署的两个部署任务为例，应用1的部署任务task1会依次在host1、host2和host3中部署应用1，完成之后在执行应用2的部署任务task2，该task2会依次在在host1、host2和host3中部署应用2，假设应用1和应用2在每个应用服务器上完成部署的时间相同，均为T，则此种方式的总部署时间需要6T。而在5(b)所示的并发执行的场景下，应用1的部署任务task1会同时在host1、host2和host3中部署应用1，待task1完成后，应用2的部署任务task2会同时在host1、host2和host3中部署应用2，因此此种方式的总部署时间为2T，部署效率明显提高。

作为一种更优选的实施方式，可以将前述根据应用服务器类型进行应用部署的方式与并发部署的方式结合，其逻辑处理流程如图6所示。在实际应用中，可以通过配置信息中的roles变量来确定是否设置了对应的类型，如果存在roles变量，则可以根据roles变量来确定对应类型的应用服务器，然后根据应用的配置信息中的parallel变量来确定该应用的部署是否可以并发进行。所述部署装置920在对所述新增的应用服务器进行应用部署时，具体用于：若所述roles变量为'apphosts'，且所述应用可并发执行(即parallel变量使能)，则同时将所述应用的安装配置包发送至与该应用的类型对应类型的多个应用服务器，并根据所述安装配置包同时对所述应用服务器进行应用部署，即同时将所述应用的安装配置包发送至与host1、host2和host3，并根据所述安装配置包同时对host1、host2和host3进行应用部署；若所述应用不可并发执行(即parallel变量不使能)，则依次将所述应用的安装配置包发送至与该应用的类型对应类型的多个应用服务器，并根据所述安装配置包依次对所述应用服务器进行应用部署，即将所述应用的安装配置包发送至与host1，并根据所述安装配置包对host1进行应用部署之后，再将安装配置包发送至与host2并对host2进行应用部署，最后将装配置包发送至与host3并对host3进行应用部署。

对于不存在roles变量的情形，即表示该应用需要在未定义类型的应用服务器上进行部署，本实施例中，hosts变量定义的应用服务器即表示该种应用服务器。因此，所述部署装置920在对所述新增的应用服务器进行应用部署时，还用于若不存在roles变量，且所述应用可并发执行，则在同时将所述应用的安装配置包发送至与多个hosts变量定义的应用服务器中，并根据所述安装配置包依次对所述应用服务器进行应用部署；若不存在roles变量，且所述应用不可并发执行，则依次将所述应用的安装配置包发送至与多个hosts变量定义的应用服务器，并根据所述安装配置包依次对所述应用服务器进行应用部署。

此外，考虑到多线程安全问题，在对多个应用服务器进行并发部署时，可以采用多进程的方式。所述部署装置920在根据所述安装配置包同时对所述应用服务器进行应用部署时，具体用于创建针对每个应用服务器的子 进程，控制所述子进程分别根据所述安装配置包对所述应用服务器进行应用部署；获取所述子进程发送的每个应用服务器的应用部署结果。仍以在“apphosts”集群的三个应用服务器并发部署应用为例，其处理流程如图7所示，若在进行应用部署时，若应用部署设备中部署装置920的主进程确定所述应用可并发执行，则获取线上配置信息中新增的应用服务器的信息并完成安装配置包的准备；然后针对每个应用服务器创建一个对应的子进程，例如针对“apphosts”集群的三个应用服务器host1、host2和host3则分别创建子进程1、子进程2和子进程3，每个子进程专门负责对应应用服务器的应用部署、管控等工作，不同的子进程之间相互不影响。创建完子进程后，主进程指示子进程1、子进程2和子进程3分别在host1、host2和host3进行应用部署，各个子进程在完成应用部署后，会将应用部署结果发送到主进程。主进程收集完所有子进程的应用部署结果时，对结果进行汇总后发送给用户本地工作设备，以完成向用户的信息反馈。

在实际应用中，所述部署装置在对所述新增的应用服务器进行应用部署时，具体用于获取所述应用服务器的登录用户名和登录密码，根据所述登录用户名和登录密码登录所述应用服务器；指示所述应用服务器安装所述应用的安装配置包。在对应用服务器进行应用部署时，可以通过登录用户名和登录密码来登录到对应的应用服务器来取得在该应用服务器安装相关应用的安装配置包的权限，由此可以保证网络环境的安全性。对于集群规模较大的场景，其内包含的应用服务器数量较大，因此在部署过程中会有非常多的登录用户名和登录密码的输入需求，为了降低用户管理应用服务器的登录用户名和登录密码的难度，在本申请实施例中所述应用服务器的登录用户名根据以下优先级顺序的其中一种方式获取：

1、由命令行的输入信息获取所述应用服务器的登录用户名。由命令行输入的用户名为优先级最高的获取方式，当检测到用户由命令行输入登录用户名时，则直接由命令行提取登录用户名，并使用该登录用户名尝试登录应用服务器。

2、由预设文件中获取所述应用服务器的登录用户名。此种方式的优先级低于由命令行的输入信息获取所述应用服务器的登录用户名，其中所 述预设文件可以是安装配置包中的配置描述文件，也可以是用户在初始配置过程中向应用部署设备上传的初始配置信息中的内容。所述应用服务器的登录用户名一般可以由预设文件中的相关变量保存，例如本实施例中，通过预设文件中的两个变量保存登录用户名，分别为user变量和hosts变量，其中hosts变量分别对不同的应用服务器定义不同的登录用户名，其形式可以是应用服务器的标识(例如IP地址)与应用服务器的登录用户名的对应关系表的形式，当存在hosts变量时，获取应用服务器的登录用户名，同时确定该应用服务器当前是否存在，此时从hosts变量中提取应用服务器的登录用户名。而user变量则统一定义了一个登录用户名，当不存在hosts变量时或者hosts变量中的应用服务器当前不在线时，才由user变量中提取登录用户名，因此user变量的优先级低于hosts变量。

3、获取本地设备的用户名作为所述应用服务器的登录用户名。没有从命令行获取到登录用户名、并且不存在hosts变量以及user变量时，才会默认获取本地设备的用户名作为所述应用服务器的登录用户名。其中，所述本地设备可以是用户与应用部署设备进行交互的设备，例如在图3的典型实现方式中，本地设备即为用户本地工作设备340。

当应用部署设备通过前述任意一种方式获取到登录用户名之后，会继续获取登录密码。其中，所述应用服务器的登录密码根据以下优先级顺序的其中一种方式获取：

1、由命令行的输入信息获取所述应用服务器的登录密码。由命令行输入的密码为优先级最高的获取方式，当检测到用户由命令行输入登录密码时，则直接由命令行提取登录密码，并配合之前获取到的登录用户名尝试登录应用服务器。

2、由预设文件中获取所述应用服务器的登录密码。此种方式的优先级低于由命令行的输入信息获取所述应用服务器的登录密码，所述应用服务器的登录密码同样可以由预设文件中的相关变量保存，例如本实施例中，通过预设文件中的两个变量保存登录密码，分别为passwords变量和password变量，其中passwords变量分别对不同的应用服务器定义不同的登录密码，其形式可以是应用服务器的标识(例如IP地址)与应用服务 器的登录密码的对应关系表的形式，当存在passwords变量时，获取应用服务器的登录密码，同时确定该应用服务器当前是否存在，此时从passwords变量中提取应用服务器的登录密码。而password变量则统一定义了一个登录密码，当不存在passwords变量时或者passwords变量中的应用服务器当前不在线时，才由password变量中提取登录密码，因此password变量的优先级低于passwords变量。

3、由本地设备的缓存获取所述应用服务器的登录密码。与获取登录用户名时类似，当没有从命令行获取到登录密码、并且不存在passwords变量以及password变量时，才会由本地设备的缓存中获取密码作为所述应用服务器的登录密码。

4、获取用户由本地设备输入的密码作为所述应用服务器的登录密码。当本地设备的缓存中也未保存任何密码时，作为优先级最低的方式，会需要用户由本地设备输入密码。

本实施例中登录用户名、登录密码都以命令行的输入作为最高的优先级，这符合用户的使用习惯。此外，一般用户都会将常用的登录用户名和登录密码记录在预设文件里，只有在少量的特殊情况下才会通过本地设备进行手动输入。因此通过此种方式获取登录用户名和密码的方式最大限度的满足用户的使用需求，为应用部署的高效进行提供了便捷。

综上所述，本申请的技术方案在完成初始部署之后，能够动态获取根据应用的当前需求确定的待部署的应用服务器的线上配置信息，通过与本地配置信息比较，在发现有新增的应用服务器需要进行应用部署后，对这些新增的应用服务器进行应用部署，从而实现应用的弹性部署，提高部署方案的灵活性，同时通过线上配置信息更新原有的本地配置信息，对当前已进行应用部署的应用服务器进行记录，保证后续应用部署的准确性。

需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中，本申请的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或 软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

另外，本申请的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和/或通过广播或其他信号承载媒体中的数据流而被传输，和/或被存储在根据所述程序指令运行的计算机设备的工作存储器中。在此，根据本申请的一个实施例包括一个装置，该装置包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该装置运行基于前述根据本申请的多个实施例的方法和/或技术方案。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。