CN118012453A - 软件部署方法、装置、电子设备、存储介质和程序产品 - Google Patents

Abstract

本公开提供了一种软件部署方法、装置、电子设备、存储介质和程序产品，涉及计算机技术领域。其中，软件部署方法包括：响应于获取到的待部署软件的安装包，调用升级器组件基于静态分派的条件将所述安装包提取到主机文件系统中对应的目标位置，形成软件副本；基于所述静态分派的条件和软件部署需求生成识别协议；响应于获取到的业务容器启动请求，调用容器运行时组件基于所述识别协议扫描所述软件副本的目录，得到符合所述软件部署需求的目标软件副本；生成所述目标软件副本的挂载决议，以基于所述挂载协议启动所述业务容器，完成软件部署。通过本公开的技术方案，有利于简化镜像管理，降低软件部署导致镜像管理压力。

Description

软件部署方法、装置、电子设备、存储介质和程序产品

技术领域

本公开涉及计算机技术领域，尤其涉及一种软件部署方法、一种软件部署装置、一种电子设备、一种计算机可读存储介质和一种计算机程序产品。

背景技术

随着信息化需求迅速扩张，各行各业对计算机设备及计算机软件的需求量都日益增加，软件在使用前涉及合理部署问题，软件部署方案包括镜像文件分发、容器镜像以及软件文件共享等，其中，容器镜像作为软件部署的一种方案，通过容器集群结合上游依赖实现软件部署，上游依赖指软件工程作业人员在实际开发软件的过程中，根据自己的实际需求所选取的、非业务特定的上游库，目前的软件部署方案由于通过统一的镜像进行分发，其将上游依赖与完整应用程序强绑定，如果上游的基础库由于出现漏洞等原因需要升级，需要对各种镜像进行逐一更新，更新过程复杂且效率低，进而导致对镜像管理的压力也很大。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开的目的在于提供一种软件部署方法、软件部署装置、电子设备和计算机可读存储介质，至少在一定程度上能够改善相关技术中由于软件部署导致镜像管理的压力较大的问题。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开的一个方面，提供一种软件部署方法，包括：响应于获取到的待部署软件的安装包，调用升级器组件基于静态分派的条件将所述安装包提取到主机文件系统中对应的目标位置，形成软件副本；基于所述静态分派的条件和软件部署需求生成识别协议；响应于获取到的业务容器启动请求，调用容器运行时组件基于所述识别协议扫描所述软件副本的目录，得到符合所述软件部署需求的目标软件副本；生成所述目标软件副本的挂载决议，以基于所述挂载协议启动所述业务容器，完成软件部署。

在一个实施例中，响应于获取到的待部署软件的安装包，调用升级器组件基于静态分派的条件将所述安装包提取到主机文件系统中对应的目标位置，形成软件副本，包括：响应于获取到的所述安装包，调用所述升级器组件获取所述静态分派的条件；根据所述静态分派的条件和预先协商的软件副本提取目录格式，计算所述软件副本在所述主机文件系统中的所述目标位置；将所述安装包提取到所述目标位置，形成所述软件副本。

在一个实施例中，在根据所述静态分派的条件和预先协商的软件副本提取目录格式，计算所述软件副本在所述主机文件系统中的所述目标位置之后，还包括：基于所述目标位置检测所述安装包是否在所述主机文件系统上部署过；在检测到所述安装包未部署过时，调用所述升级器组件生成所述软件副本。

在一个实施例中，还包括：在所述软件副本中对配置方案描述接口进行配置，所述配置方案描述接口用于为所述容器运行时组件提供所述软件副本的配置描述信息。

在一个实施例中，基于所述静态分派的条件和软件部署需求生成识别协议，包括：基于所述静态分派的条件确定所述软件副本的部署版本号；基于预先协商的软件副本提取目录格式对所述部署版本号以及所述静态分派的条件进行配置处理，生成所述识别协议；其中，所述识别协议用于使所述软件副本所在目录路径能够被所述容器运行时组件识别和区分。

在一个实施例中，响应于获取到的业务容器启动请求，调用容器运行时组件基于所述识别协议扫描所述软件副本的目录，得到符合所述软件部署需求的目标软件副本，包括：响应于所述启动请求，调用所述容器运行时组件加载文件系统捆绑，以创建依赖于所述软件副本的隔离文件系统环境；基于所述识别协议解析所述文件系统捆绑，以扫描所述软件副本的目录，得到符合所述软件部署需求的目标软件副本。

在一个实施例中，基于所述识别协议解析所述文件系统捆绑，以扫描所述软件副本的目录，得到符合所述软件部署需求的目标软件副本，包括：调用所述容器运行时的启动工具基于所述识别协议通过文件系统捆绑扫描所述软件副本的目录和配置方案描述接口，以确认所述业务容器的用于软件配置的配置项；基于所述用于软件配置的配置项和用户指定的部署版本号选定最佳软件副本，作为所述目标软件副本。

在一个实施例中，生成所述目标软件副本的挂载决议，包括将所述目标软件副本的副本目录映射至所述业务容器的内部目录，得到所述目标软件副本的挂载路径；调用所述容器运行时的启动工具基于所述软件部署需求进行所述业务容器的配置，得到软件配置信息；基于所述挂载路径和所述软件配置信息生成所述目标软件副本的只读挂载决议。

在一个实施例中，响应于获取到的待部署软件的安装包，调用升级器组件基于静态分派的条件将所述安装包提取到主机文件系统中对应的目标位置，形成软件副本，还包括：基于所述静态分派的条件为所述软件副本的目录命名，所述静态分派的条件包括所述软件副本的编号、版本号、依赖项、运行的操作系统和使用的计算设备中的至少一种。

根据本公开的另一个方面，提供一种软件部署装置，包括：提取模块，用于响应于获取到的待部署软件的安装包，调用升级器组件基于静态分派的条件将所述安装包提取到主机文件系统中对应的目标位置，形成软件副本；生成模块，用于基于所述静态分派的条件和软件部署需求生成识别协议；扫描模块，用于响应于获取到的业务容器启动请求，调用容器运行时组件基于所述识别协议扫描所述软件副本的目录，得到符合所述软件部署需求的目标软件副本；部署模块，用于生成所述目标软件副本的挂载决议，以基于所述挂载协议启动所述业务容器，完成软件部署。

根据本公开的再一个方面，提供一种电子设备，包括：处理器；以及存储器，用于存储处理器的可执行指令；其中，处理器配置为经由执行可执行指令来执行上述任意一项的软件部署方法。

根据本公开的又一个方面，提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述任意一项的软件部署方法。

根据本公开的又一个方面，提供一种计算机程序产品，其上存储有计算机程序，计算机程序被处理器执行时实现上述任意一项的软件部署方法。

本公开的实施例所提供的软件部署方案，基于配置两个核心组件，即升级器updater和容器运行时runtime，以主机文件系统作为交互接口，通过调用升级器组件基于形态分配行为生成软件副本，结合容器运行时组件通过对软件副本的目录的扫描结果对业务容器进行配置，以对挂载路径映射的配置，配置方案能够与被部署软件的具体需求对应，通过使用升级器组件根据静态分派的条件的规则，将安装包提取到主机文件系统中的目标位置，不同的部署行为能够对应于不同的软件副本，有利于实现上游依赖与完整应用程序之间的解耦，进一步地，通过识别协议中定义的规则，选择符合软件部署需求的目标软件副本，生成目标软件副本的挂载决议，以基于挂载协议启动业务容器，完成软件部署，在确定了目标软件副本后，根据挂载协议生成挂载决议，按照挂载决议的规定，将所需资源挂载到业务容器中，使得上游基础库的升级变得更加灵活和高效，进而有利于简化镜像管理，降低软件部署导致镜像管理压力。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出本公开实施例中一种软件部署系统结构的示意图；

图2示出本公开实施例中一种软件部署方法的流程图；

图3示出本公开实施例中另一种软件部署方法的示意图；

图4示出本公开实施例中一种软件部署方案中形成软件副本的示意图；

图5示出本公开实施例中再一种软件部署方法的流程图；

图6示出本公开实施例中一种软件部署方案的示意框图；

图7示出本公开实施例中一种软件部署系统的示意框图；

图8示出本公开实施例中一种软件部署装置的示意图；

图9示出本公开实施例中一种电子设备的示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

随着软件规模日益扩大，维护软件的成本日益提升，利用已有上游依赖进行二次开发的需求也越来越大。然而，当前的主流软件部署方案几乎都通过统一的镜像进行分发，其将上游依赖与完整应用程序一视同仁，相对机械、刻板，不能灵活地满足上游依赖进行部署、升级、独立维护的需求。假设某SaaS服务商专门提供基于C++的软件开发、运维服务解决方案，而某一天该厂商使用的某基础库爆出了漏洞需要升级，此时SaaS服务商的服务器上所部署的业务往往并不只有一个客户的一种业务，而是包括各种不同的镜像，包含不同的操作系统、软件配置，导致对各种镜像逐一更新复杂、费力又低效。

另外，容器镜像的统一性虽然能保证业务高度一致，但镜像的层结构仍然较为机械，面对上游依赖部署场景难以发挥文件系统捆绑设计中层的复用功效。当镜像需要的依赖库较多时，每次更新一个软件，都会在原有镜像的文件系统捆绑基础上增加新的层，这些层的顺序与更新行为的顺序高度相关，复用起来较为复杂；当多个软件依赖同一个配置文件，而该配置文件的内容并不完全固定时，对层结构复用造成的破坏就更加显著。

再次，如果用户需要3个彼此独立的依赖软件，每个软件有3种版本，那么对于单一基础镜像就需要至少9个层、9个不同的镜像，有些软件同一版本下不同安装配置还会产生不同行为，这些不同行为的安装都需要给镜像打上不同的tag进行区分，随着软件数、软件的部署方案差异、软件的不同版本数等的增加，建立和维护镜像所占用的资源也将显著增加，当某一软件在旧镜像中只有一种安装方式，但在新的镜像中产生了以不同方式安装的新需求时，往往会产生tag规则的改变，进一步提升维护复杂性。

另外，在容器集群部署过程中，保证容器隔离性也非常重要，目前已有的容器隔离解决方案在文件系统中软件文件的复用、不同软件共存时升级部署等工况中会出现复杂性较高等问题，而如果不执行隔离解决方案，又会导致软件内部的文件不同步等问题，因此需要降低复杂性的同时保证部署过程中的隔离性。

本申请提供的方案，能够降低软件部署中出现上述问题的概率。

图1是本申请一个示例性实施例提供的计算机系统的结构示意图。该系统包括：若干个终端120和服务器集群140。

终端120可以是手机、游戏主机、平板电脑、电子书阅读器、智能眼镜、MP4(MovingPicture Experts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器、智能家居设备、AR(Augmented Reality，增强现实)设备、VR(Virtual Reality，虚拟现实)设备等移动终端，或者，终端120也可以是个人计算机(Personal Computer，PC)，比如膝上型便携计算机和台式计算机等等。

其中，终端120中可以安装有用于提供软件部署的应用程序。-

终端120与服务器集群140之间通过通信网络相连。可选的，通信网络是有线网络或无线网络。

服务器集群140是一台服务器，或者由若干台服务器组成，或者是一个虚拟化平台，或者是一个云计算服务中心。服务器集群140用于为提供软件部署的应用程序提供后台服务。可选地，服务器集群140承担主要计算工作，终端120承担次要计算工作；或者，服务器集群140承担次要计算工作，终端120承担主要计算工作；或者，终端120和服务器集群140之间采用分布式计算架构进行协同计算。

在一些可选的实施例中，服务器集群140用于存储软件部署程序信息。

可选地，不同的终端120中安装的应用程序的客户端是相同的，或两个终端120上安装的应用程序的客户端是不同控制系统平台的同一类型应用程序的客户端。基于终端平台的不同，该应用程序的客户端的具体形态也可以不同，比如，该应用程序客户端可以是手机客户端、PC客户端或者全球广域网(World Wide Web，Web)客户端等。

本领域技术人员可以知晓，上述终端120的数量可以更多或更少。比如上述终端可以仅为一个，或者上述终端为几十个或几百个，或者更多数量。本申请实施例对终端的数量和设备类型不加以限定。

可选的，该系统还可以包括管理设备(图1未示出)，该管理设备与服务器集群140之间通过通信网络相连。可选的，通信网络是有线网络或无线网络。

可选的，上述的无线网络或有线网络使用标准通信技术和/或协议。网络通常为因特网、但也可以是任何网络，包括但不限于局域网(Local Area Network，LAN)、城域网(Metropolitan Area Network，MAN)、广域网(Wide Area Network，WAN)、移动、有线或者无线网络、专用网络或者虚拟专用网络的任何组合)。在一些实施例中，使用包括超文本标记语言(Hyper Text Mark-up Language，HTML)、可扩展标记语言(ExtensibleMarkupLanguage，XML)等的技术和/或格式来代表通过网络交换的数据。此外还可以使用诸如安全套接字层(Secure Socket Layer，SSL)、传输层安全(Transport Layer Security，TLS)、虚拟专用网络(Virtual Private Network，VPN)、网际协议安全(InternetProtocolSecurity，IPsec)等常规加密技术来加密所有或者一些链路。在另一些实施例中，还可以使用定制和/或专用数据通信技术取代或者补充上述数据通信技术。

下面，将结合附图及实施例对本示例实施方式中的软件部署方法进行更详细的说明。

如图2所示，根据本公开的一个实施例的软件部署方法，应用于服务器，包括：

步骤S202，响应于获取到的待部署软件的安装包，调用升级器组件基于静态分派的条件将安装包提取到主机文件系统中对应的目标位置，形成软件副本。

其中，将安装包输入升级器组件的输入文件，对应输出软件副本，安装包的内容根据软件部署的实际需求而定，包括但不限于软件运行的必要文件外以及提取方式的描述信息，另外，如果需要生成配置文件，也可以基于安装包生成。

升级器组件用于从远程或本地软件仓库中下载最新的安装包，并将其应用到容器内的软件环境中，从而实现容器内的软件更新操作。

安装包的文件被提取到主机文件系统中形成了具有不同静态分派的条件、并放置在不同目录的软件副本，软件副本可以是不同软件也可以是相同软件，可以有不同版本号，也可以配置相同版本号但具体的版本不同，在本公开中，软件副本需要遵循以下两点：

首先，若两个安装包存在不同静态分派的条件，包括但不限于版本号、所集成的第三方组件、所采用的协议和接口差异等，则必须形成两份不同副本，若两个安装包的行为相同，则不会产生两份副本。

其次，副本所在目录需要满足预先协商的规律，它需要能被容器运行时组件识别并区分，这种规律即识别协议，识别协议可以是简单的编号，也可以是软件副本中版本号、依赖库等各个因素的组合。

通过基于静态分派的条件生成软件副本，能够兼容不同软件、同软件不同版本、同版本不同配置的安装，包括但不限于依赖库、计算设备(例如CPU、Nvidia或AMD等的GPU等)等的差异，只需要打包不同的软件副本并修改容器运行时组件的启动工具的行为即可。

示例性地，静态分派为编译期的行为，动态分派为运行期的行为，基于静态分派形成软件副本，即在软件开发中，通过对不同的静态类型进行编译和构建，生成软件副本，软件副本静态分派的条件即划分不同的软件副本的规则，在软件升级过程中，基于动态分派将软件副本从静态分派条件映射到对应的释放目录，以提取到主机文件系统中对应的目标位置。

示例性地，静态分派的条件可以基于以下几个方面进行规则的制定：

文件类型：根据文件的类型(如可执行文件、配置文件、库文件等)，将文件分派到对应的目标位置。

文件名和路径：根据文件的名称和路径信息，将文件提取到与其对应的目标位置。例如，将名为"index.html"的文件提取到Web服务器的网站根目录下。

文件属性：根据文件的属性(如权限、所有者、时间戳等)，将文件分派到适当的目标位置。

文件依赖关系：考虑到文件之间的依赖关系，将依赖文件提取到依赖文件所需的目标位置。

通过预先配置静态分派的条件，可以确保升级过程中文件的正确提取和组织，使得软件副本在主机文件系统中能够按照预期的方式工作。

步骤S204，基于静态分派的条件和软件部署需求生成识别协议。

其中，软件部署需求指软件在部署过程中的各种要求或需求，例如所需要的资源、配置项、依赖关系等。

识别协议指容器运行时环境在接收到软件部署需求后，根据静态分派的条件生成的一种协议或约定，识别协议用于识别每个业务容器所需的目标软件副本。

步骤S206，响应于获取到的业务容器启动请求，调用容器运行时组件基于识别协议扫描软件副本的目录，得到符合软件部署需求的目标软件副本。

其中，容器运行时(Container Runtime)是符合OCI(Open ContainerInitiative)Runtime规范的实现，指负责创建和管理容器的软件组件，它提供了一组API和工具，用于创建、启动、停止和销毁容器，以及管理容器与宿主机之间的资源隔离和访问控制。

示例性地，通过容器运行时组件的扫描操作，只要能够扫描到目标软件副本，即可进行挂载，从而能够产生尽可能少的副本，不同容器中同一配置、同一版本的同一软件将挂载宿主机上的同一副本，消耗资源小，即便是具有不同文件系统结构的不同镜像，也只需要一份副本。

步骤S208，生成目标软件副本的挂载决议，以基于挂载协议启动业务容器，完成软件部署。

其中，挂载是指将外部的文件、目录或卷与容器内的路径进行关联，使得容器可以访问这些资源，挂载协议用于定义和描述如何进行挂载操作，它规定了挂载的方式、路径、权限等相关信息。

在软件部署过程中，通过启动业务容器运行目标软件副本，以实现软件的部署。

另外，基于静态分派可以生成版本不同、配置不同或不同软件的待部署的软件副本，不同软件副本之间彼此隔离，不会相互影响，在软件部署过程中，也有利于保证容器之间的隔离性，无论是单一软件升级还是整体环境升级都不需要重新打包镜像文件，当需要新软件或者修改软件配置、升级软件版本时省去了处理、分发镜像的过程(同时减少了镜像管理的操作，方便部署)，升级器组件updater完成软件的更新与安装后，容器运行时组件runtime启动的新容器即是最新配置。

在该实施例中，基于配置两个核心组件，即升级器updater和容器运行时runtime，以主机文件系统作为交互接口，通过调用升级器组件基于形态分配行为生成软件副本，结合容器运行时组件通过对软件副本的目录的扫描结果对业务容器进行配置，以对挂载路径映射的配置，配置方案能够与被部署软件的具体需求对应，通过使用升级器组件根据静态分派的条件的规则，将安装包提取到主机文件系统中的目标位置，不同的部署行为能够对应于不同的软件副本，有利于实现上游依赖与完整应用程序之间的解耦，进一步地，通过识别协议中定义的规则，选择符合软件部署需求的目标软件副本，生成目标软件副本的挂载决议，以基于挂载协议启动业务容器，完成软件部署，在确定了目标软件副本后，根据挂载协议生成挂载决议，按照挂载决议的规定，将所需资源挂载到业务容器中，使得上游基础库的升级变得更加灵活和高效，进而有利于简化镜像管理，降低软件部署导致镜像管理压力。

进一步地，容器运行时的识别协议能够随静态分派的条件进行适配调整，在新的镜像中产生了以不同方式安装的新需求时，往往会产生能够保证改变的tag规则仍能够被容器运行时识别，从而能够降低容器维护复杂性。

在一个实施例中，响应于获取到的待部署软件的安装包，调用升级器组件基于静态分派的条件将安装包提取到主机文件系统中对应的目标位置，形成软件副本，还包括：

静态分派的条件为软件副本的目录命名，静态分派的条件包括软件副本的编号、版本号、依赖项、运行的操作系统和使用的计算设备中的至少一种。

其中，软件副本的编号指每个软件副本分配一个唯一的编号，用于标识该副本。

版本号用于指示软件副本的版本，以区分不同的版本。

依赖项用于列出软件副本所依赖的其他组件或库。

运行的操作系统用于指定软件副本所需的操作系统环境。

使用的计算设备用于描述软件副本运行所需的计算设备类型或架构。

根据这些信息，可以将软件副本放置在相应的目录中，并将目录命名为包含静态分派的条件信息的形式，以便后续的识别和管理。

示例性地，静态分派的条件可以参与到软件副本的安装包的目录命名，例如，假设条件有设备类型和上游依赖库，那么同样是1.0版本，如果基于Nvidia GPU运行、依赖于CUDA的软件副本将释放到nvidia/cuda/1.0，如果基于AMD GPU运行、依赖于ROCm的软件副本将释放到amd/rocm/1.0，如果基于AMD GPU运行、依赖于Vulkan的软件副本将释放到amd/vulkan/1.0。

如图3所示，在一个实施例中，响应于获取到的待部署软件的安装包，由升级器组件基于静态分派的条件将安装包提取到主机文件系统中对应的目标位置，形成软件副本，包括：

步骤S302，响应于获取到的安装包，调用升级器组件获取静态分派的条件。

其中，升级器组件包含一个updater主体程序以及一系列附加组件和接口，其中，用于获取安装包的接口和updater主体程序均属于必要部分，获取到安装包后，updater主体程序获取安装包提供的安装信息。

步骤S304，根据静态分派的条件和预先协商的软件副本提取目录格式，计算软件副本在主机文件系统中的目标位置。

其中，静态分派的条件提供了一系列信息，用于描述和标识形成的软件副本的特征和属性。这些信息可以用于确定软件副本的提取目录格式，通过结合静态分派的条件中的信息，可以根据预先约定的目录命名规则，生成目标位置的目录名称，以执行软件副本的提取过程，形成软件副本，无论是否将updater部署在容器或虚拟机环境中，软件副本都需要能从主机文件系统上访问。

该软件副本一旦安装，一般而言不需要修改，但需要执行，所以需要有读和执行权限，不一定需要写权限。

示例性地，升级器组件updater主体程序需要先解析安装包，获取其中有关软件副本的信息，例如副本的名称、版本、依赖关系等，同时，预先约定的目录格式规定了软件副本在文件系统中应该存放的位置以及文件名的格式，updater主体程序根据这些信息来计算出软件副本应该被提取到的目标位置，并将副本从安装包中提取出来并复制到这个位置。

提取过程可能还需要进行一些其他的操作，例如创建必要的文件夹、设置文件权限、更新配置文件等，最终，updater主体程序会将所有必要的文件复制到目标位置，并执行必要的操作，以确保软件副本能够正常运行。

总之，updater主体程序可以根据安装包中的信息和预先约定的目录格式来决定软件副本在哪里提取，并执行相应的提取过程，以创建一个完整的软件副本。

步骤S306，基于静态分派的条件将安装包提取到目标位置形成软件副本。

其中，将安装包从指定位置提取出来，并按照预先约定的目标位置放置和配置，最终生成可在目标主机上运行的软件副本，这个过程通常是软件部署的一部分，用于将软件引入到目标环境中。

在该实施例中，通过约定统一的目录命名规则，可以方便地识别和管理不同的软件副本，同时，预先约定的目录格式也可以使得软件副本的提取目录更加有序和规范，便于后续的维护和更新，将软件副本放置在适当的目录中，使其与其他软件或组件解耦，便于管理和部署，根据静态分派的条件，将安装包从获取到的位置提取出来，并放置到目标位置，实现将软件副本与原始镜像分离，从而简化了镜像管理的过程。

如图4所示，基于静态分派的条件确定主机文件系统上的软件副本的提取位置，将安装包402进行文件提取生成软件副本404，安装包中的程序主体4022和配置工具4024对应生成程序主体4042和配置工具4044。

基于配置工具4044生成软件配置项406，容器运行时408基于软件配置项406进行软件配置。

在一个实施例中，在根据静态分派的条件和预先协商的软件副本提取目录格式，计算软件副本在主机文件系统中的目标位置之后，还包括：基于目标位置检测安装包是否在主机文件系统上部署过；在检测到安装包未部署过时，调用升级器组件生成软件副本。

其中，基于目标位置检测安装包是否部署的一种实现方式，包括：检查主机文件系统目标位置是否有对应的目录，如果有对应的目录，则表明该安装包已部署过，通过检测安装包是否在主机文件系统上部署过，以能够将安装包应用至多个容器。

如图5所示，基于升级器组件执行的软件副本提取过程，包括：

步骤S502，根据静态分派的条件和预先协商的软件副本提取目录格式，计算软件副本在主机文件系统中的目标位置。

步骤S504，检测目标位置是否有预先协商的软件目录，以检测安装包是否在主机文件系统上部署过，若“是”，进入步骤S506，若“否”，进入步骤S508。

步骤S506，结束进程。

步骤S508，调用升级器组件将安装包提取到预先协商的目录中。

步骤S510，更新生效该软件副本的目录。

另外，本领域的技术人员能够理解的是，如果软件副本的目录未能够直接体现出静态分派的条件，基于目标位置检测安装包是否部署可以基于另一种方式实现，包括：在目标位置或与目标位置关联的区域部署数据表结构，在数据表结构中记录静态分派的条件，基于该部署方式，如果静态分派的条件增加时，可以通过直接静默修改表结构的方式，增加相关信息，且不需要下游用户感知。

其中，数据表结构可以为数据库中的数据表、Excel表或CSV(Comma-SeparatedValues)文件等。

在该实施例中，在软件部署过程中，根据特定的规则或信息来确定软件副本的属性和行为，通过检查主机文件系统中是否已经存在该安装包的部署来判断是否已经部署过，当检测到安装包未在主机文件系统中部署过时，根据预先约定好的目录命名规则和静态分派的条件中的信息，计算生成软件副本在主机文件系统中的目标位置，可以确保安装包不会被重复部署，并且能够按照约定的方式在主机文件系统中进行正确的部署。

在一个实施例中，还包括：在软件副本中对配置方案描述接口进行配置，配置方案描述接口用于为容器运行时组件提供软件副本的配置描述信息。

在该实施例中，在软件副本中对配置方案描述接口进行配置，配置方案描述接口的目的是为容器运行时组件提供软件副本的配置描述信息，以便容器运行时组件能够根据这些配置描述信息来正确地调取软件副本，通过在软件副本中使用配置方案描述接口进行配置，可以确保软件副本在运行时具备正确的配置信息，并且配置方案描述接口的作用是为容器运行时组件提供这些配置描述信息，以便容器运行时组件能够正确地管理和运行软件副本。

在一个实施例中，基于静态分派的条件和软件部署需求生成识别协议，包括：

基于静态分派的条件确定软件副本的部署版本号。

其中，通过检查软件的静态分派的条件，确定软件副本的部署版本号。这可以是从软件的元数据、配置文件或其他相关信息中获取。

基于预先协商的软件副本提取目录格式对部署版本号以及静态分派的条件进行配置处理，生成识别协议，识别协议用于使软件副本所在目录路径能够被容器运行时组件识别和区分。

其中，静态分派本身的条件是生成不同的版本的软件副本，在软件副本的提取目录格式中，根据事先协商的规则，结合部署版本号和静态分派的条件，进行配置处理，生成识别协议，识别协议是一种标识或标签，用于使容器运行时组件能够识别和区分不同的软件副本所在的目录路径。

在该实施例中，通过基于安装信息确定部署版本号，并且根据预先协商的目录格式和静态分派的条件进行配置处理生成识别协议，可以使得容器运行时组件能够准确地识别和区分不同的软件副本所在的目录路径，从而能够保证对目标软件副本的可靠识别。

在一个实施例中，响应于获取到的业务容器启动请求，调用容器运行时组件基于识别协议扫描软件副本的目录，得到符合软件部署需求的目标软件副本，包括：

响应于启动请求，调用容器运行时组件加载文件系统捆绑，以创建依赖于软件副本的隔离文件系统环境。

其中，文件系统捆绑，即OCI(Open Container Initiative)标准中的FilesystemBundle，是容器运行时规范的一部分，用于描述容器镜像文件系统的结构以及如何将其加载到容器运行时中，Filesystem Bundle通常包含一个或多个元素，比如配置容器运行时使用的元数据和配置文件，例如启动参数和挂载点等。

另外，令被部署软件在业务容器上正确执行是整个部署方案的最终目标，业务容器的文件系统捆绑依赖于所需要的软件副本，如果需要的软件副本不存在或存在问题而不能部署，那么runtime组件将会报告错误，容器的文件系统捆绑将被销毁。

基于识别协议解析文件系统捆绑，以扫描软件副本的目录，得到符合软件部署需求的目标软件副本。

在该实施例中，当启动请求到达容器运行时组件时，容器运行时组件会被调用执行加载文件系统捆绑的操作，文件系统捆绑包含了容器所需的运行环境和软件副本，通过加载文件系统捆绑，容器运行时组件会创建一个隔离的文件系统环境。这个环境是独立于宿主操作系统的，并且能够提供容器所需的文件系统和其他资源，这样容器就可以在这个隔离的文件系统环境中运行，并且能够依赖于所需的软件副本。这种隔离的环境可以确保容器与宿主操作系统和其他容器之间的相互影响最小化，同时保证容器内部的软件副本能够正常运行。

进一步地，通过配置的识别协议，容器运行时组件可以准确地识别和区分不同的软件副本所在的目录路径，容器运行时组件会通过对文件系统的扫描，捆绑扫描符合软件部署需求的目标软件副本，这个过程可能包括查找指定的文件、检查文件的版本号或其他属性等操作，经过扫描和筛选后，容器运行时组件得到符合软件部署需求的目标软件副本，这个目标软件副本可以是一个或多个，根据具体的需求而定，该过程有助于确保软件副本能够正确地部署和运行，并且能够满足用户的需求和要求。

在一个实施例中，基于识别协议解析文件系统捆绑，以扫描软件副本的目录，得到符合软件部署需求的目标软件副本，包括：

调用容器运行时的启动工具基于识别协议通过文件系统捆绑扫描软件副本的目录和配置方案描述接口，以确认业务容器的用于软件配置的配置项。

其中，启动工具为在软件部署过程中负责启动和管理业务容器的工具，可以为prestart钩子、或其它容器创建完成前执行的钩子、或者软件发布方发布的二进制工具，或者指定脚本等。

示例性地，启动工具能够实现对不同镜像的针对性配置，并且启动工具的调用需要在挂载目标软件副本目录之前完成。

本领域的技术人员能够理解的是，由于不同镜像上软件具体部署需求的具体差异(例如有的需要部署在/usr/lib，有的在/usr/lib/x86_64-linux-gnu，用户还有可能自己指定为其他路径，例如/usr/local/lib或/opt下的目录)，启动工具都可以提供相当程度的灵活性，它从软件副本提供的配置方案描述接口中获取配置所需的若干数据，这些数据可以包含参数设定、用于生成参数设定的脚本等各种不同内容。

另外，用于软件配置的配置项可以理解为根据预定义的规则，确定静态分派的条件所需的配置项，例如文件类型、文件名、文件路径、文件属性等。

基于用于软件配置的配置项和用户指定的部署版本号选定最佳的静态分派的条件软件副本，作为目标软件副本。

其中，最佳的静态分派的条件软件副本可以理解为根据静态分派条件和用户指定的版本号，选定最佳的软件副本，即符合条件且与所需版本号匹配的目标软件副本。

在该实施例中，在部署过程中，根据文件系统捆绑扫描的结果，确认业务容器用于软件配置的配置项。这些配置项可以包括配置文件、环境变量、依赖库路径等。根据识别协议中定义的规则，将捆绑扫描的结果与输入条件进行匹配和解析，在软件部署时可以指定所需的版本号，用于选择最佳的静态分派的条件软件副本。这个版本号可以是数字、标签、哈希值等形式，根据用于软件配置的配置项和用户指定的部署版本号，从所有符合条件的软件副本中选定最佳的静态分派的条件软件副本作为目标软件副本，可以优化文件系统捆绑的复用，减少不必要的资源开销，提高部署效率。同时也能够增强层结构的复用性，降低应用程序的维护成本。

在一个实施例中，生成目标软件副本的挂载决议，包括：将目标软件副本的副本目录映射至业务容器的内部目录，得到目标软件副本的挂载路径。

其中，通过在业务容器的启动配置中指定目标软件副本的副本目录，将其映射到业务容器内部的一个目录。这个目录可以是容器内的任意路径，用于存放目标软件副本的文件和数据。

示例性地，启动工具(若有)执行结束后生成挂载决议，并将挂载决议传递给runtime主体程序，Runtime主体会把-v选项指定的挂载路径以及软件副本和钩子传递的配置方案进行综合，并执行挂载，对软件副本的挂载是只读挂载，防止业务容器意外修改软件副本造成集群内的软件大面积失效，同时这样的隔离性保证了热更新的可行性，显然地，启动工具必须在容器上需挂载的目录完成挂载前执行完成。

调用容器运行时的启动工具基于软件部署需求进行业务容器的配置，得到软件配置信息。

其中，使用容器运行时的启动工具来执行业务容器的配置操作。配置包括设置容器的环境变量、网络配置、资源限制等。

进一步地，根据软件部署需求和用户指定的参数，生成软件的配置信息。这些信息可以包括数据库连接信息、端口号、日志输出路径等。根据具体需求，可以从配置文件、命令行参数或其他来源获取这些配置信息。

基于挂载路径和软件配置信息生成目标软件副本的只读挂载决议。

其中，结合目标软件副本的挂载路径和软件配置信息，生成目标软件副本的挂载决议，挂载决议是指确定目标软件副本在业务容器中的具体挂载点和配置参数，这个过程可以根据具体需求和容器运行时的规则来进行。

在该实施例中，通过将目标软件副本的目录映射到业务容器内部，并根据软件部署需求进行容器的配置。同时，根据挂载路径和软件配置信息生成目标软件副本的只读挂载决议。这样可以确保目标软件副本在业务容器中正确挂载，并按照要求进行配置，以实现软件的正常运行和使用，为了保持升级不影响已有容器的可用性质，不同版本将产生若干副本，版本的不同包括但不限于版本号的不同等，通过只读挂载能够防止意外修改现象的产生，已有副本原则上不能覆盖，以此保证升级不影响正在运行的业务，从而能够正常执行滚动更新等零中断更新部署方式。

如图6所示，本公开的软件部署方案，包括升级器602、主机文件系统606和容器运行时606。

其中，升级器主体程序6022对安装包基于静态分派的条件进行提取，得到软件副本集合6042。

在启动业务容器608之前，通过对软件副本集合的依赖关系，加载文件系统捆绑6044，并基于启动工具6062对软件副本集合6042中配置方案描述接口的调用，获取软件副本的配置信息，并确定挂载路径。

启动工具6062基于挂载路径和目标软件副本生成挂载决议，并传递给容器运行时主体程序6064，容器运行时主体程序6064基于挂载决议配置并启动业务容器608。

如图7所示，根据本公开的另一个实施例的软件部署方案，包括：

步骤S702，响应于获取到的业务容器启动请求，调用容器运行时组件加载文件系统捆绑，以创建依赖于软件副本的隔离文件系统环境。

步骤S704，调用容器运行时的启动工具基于识别协议通过文件系统捆绑扫描软件副本的目录和配置方案描述接口，以确认业务容器的用于软件配置的配置项。

步骤S706，基于用于软件配置的配置项和用户指定的部署版本号选定最佳软件副本，作为目标软件副本。

步骤S708，将目标软件副本的副本目录映射至业务容器的内部目录，得到目标软件副本的挂载路径。

步骤S710，调用容器运行时的启动工具基于软件部署需求进行业务容器的配置，得到软件配置信息。

步骤S712，基于挂载路径和软件配置信息生成目标软件副本的只读挂载决议。

步骤S714，基于只读挂载协议启动业务容器，完成软件部署。

下面以部署推理集群，对外提供推理服务接口为例，说明软件部署方案的应用场景，以对本公开的软件部署方案进行进一步说明。

假设推理服务接口中包括不同框架实现的不同业务接口，部署对象以软件的上游依赖库的部署为重点进行说明。

其中，上游依赖库包括但不限于统一计算设备结构CUDA库等。

相关技术中，运维部门需要为不同业务接口单独打包不同镜像，若某业务想要更新软件的任何部分，无论是上游依赖还是业务应用程序本身，就需要为这一更新打包更多镜像，无论这一更新多小，对现代在线业务而言，无隔离的文件共享方案则完全不现实，那会导致需要更新时不得不停机维护。

基于本公开中的软件部署方案部署CUDA，则可以将需要的CUDA库文件(例如libcuda.so、libcudart.so等)打包放进安装包，并将一个已有CUDA镜像确定为基础镜像。

在基础镜像中，CUDA库文件均以挂载点的形式存在，基于本公开的容器运行时runtime实现，可以令prestart钩子(或其它可以在恰当时机执行的启动工具)在容器的文件系统捆绑建立后，扫描其中所有这样的CUDA文件，形成挂载决议，挂载想要的CUDA库版本，或者也可以不挂载，而是将一个软件副本整体挂载上来后，在prestart钩子中将所有这样的软链接指向软件副本内的对应文件，容器运行时组件Runtime和升级器组件updater都可以放进每个集群上专门的pod，与业务容器统一管理。

进一步地，若同时部署多个软件，例如同时部署PyTorch和TensorFlow，其基本逻辑与部署单个软件的相同，示例性地，将PyTorch和TensowFlow中各个版本的基本软件副本被释放到主机文件系统，彼此之间并不互相干涉(因此就不存在文件系统捆绑中层的添加顺序和复用逻辑问题)，部署时同时挂载到容器内即可，启动工具可以使用两个独立的prestart钩子，OCI标准明确规定所有prestart钩子都必须被执行并且必须成功，执行失败将导致整个容器创建失败，所有操作被撤回，因此分离的启动工具实现可以保证部署的正确性。

如果想要更新到新版本的CUDA库，可以使用原有的基础镜像，令升级器组件updater拉取打包好的新版本CUDA安装包并提取到另一个目录，目录名可以选用CUDA库的版本号，然后，更新容器的yaml配置文件(也可以是环境变量等，总之需要runtime能读取到)指定新的CUDA库副本为生效版本，并触发滚动更新或蓝绿部署，此时容器运行时组件runtime启动的新容器即具有新版本CUDA，由于该部署过程不影响已在运行的业务，它和传统高可用部署架构一样不会产生额外的停机维护开销，能够做到零中断热更新，这个过程中不涉及镜像的修改，因此不涉及镜像维护、创建、分发等，只要在所有集群涉及的主机上分别由updater释放软件副本即可。

需要注意的是，上述附图仅是根据本公开示例性实施例的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

所属技术领域的技术人员能够理解，本公开的各个方面可以实现为系统、方法或程序产品。因此，本公开的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

下面参照图8来描述根据本公开的这种实施方式的软件部署装置800。图8所示的软件部署装置800仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

软件部署装置800以硬件模块的形式表现。软件部署装置800的组件可以包括但不限于：提取模块802，用于响应于获取到的待部署软件的安装包调用升级器组件基于静态分派的条件将安装包提取到主机文件系统中对应的目标位置，形成软件副本；生成模块804，用于基于静态分派的条件和软件部署需求生成识别协议；扫描模块806，用于响应于获取到的业务容器启动请求，调用容器运行时组件基于所述识别协议扫描所述软件副本的目录，得到符合所述软件部署需求的目标软件副本；部署模块808，用于生成所述目标软件副本的挂载决议，以基于所述挂载协议启动所述业务容器，完成软件部署。

下面参照图9来描述根据本公开的这种实施方式的电子设备900。图9显示的电子设备900仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图9所示，电子设备900以通用计算设备的形式表现。电子设备900的组件可以包括但不限于：上述至少一个处理单元910、上述至少一个存储单元920、连接不同系统组件(包括存储单元920和处理单元910)的总线930。

其中，存储单元存储有程序代码，程序代码可以被处理单元910执行，使得处理单元910执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施方式的步骤。例如，处理单元910可以执行如图2中所示的步骤S202和步骤S208，以及本公开的软件部署方法中限定的其他步骤。

存储单元920可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)9201和/或高速缓存存储单元9202，还可以进一步包括只读存储单元(ROM)9203。

存储单元920还可以包括具有一组(至少一个)程序模块9205的程序/实用工具9204，这样的程序模块9205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线930可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备900也可以与一个或多个外部设备960(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备交互的设备通信，和/或与使得该电子设备900能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口950进行。并且，电子设备900还可以通过网络适配器950与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器950通过总线930与电子设备900的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施方式的方法。

在本公开的示例性实施例中，还提供了一种计算机可读存储介质，其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施方式中，本公开的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当程序产品在终端设备上运行时，程序代码用于使终端设备执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施方式的步骤。

根据本公开的实施方式的用于实现上述方法的程序产品，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本公开的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

此外，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本公开实施方式的方法。

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

Claims (10)

1.一种软件部署方法，其特征在于，包括：

响应于获取到的待部署软件的安装包，调用升级器组件基于静态分派的条件将所述安装包提取到主机文件系统中对应的目标位置，形成软件副本；

基于所述静态分派的条件和软件部署需求生成识别协议；

响应于获取到的业务容器启动请求，调用容器运行时组件基于所述识别协议扫描所述软件副本的目录，得到符合所述软件部署需求的目标软件副本；

生成所述目标软件副本的挂载决议，以基于所述挂载协议启动所述业务容器，完成软件部署。

2.根据权利要求1所述的软件部署方法，其特征在于，响应于获取到的待部署软件的安装包，调用升级器组件基于静态分派的条件将所述安装包提取到主机文件系统中对应的目标位置，形成软件副本，包括：

响应于获取到的所述安装包，调用所述升级器组件获取所述静态分派的条件；

根据所述静态分派的条件和预先协商的软件副本提取目录格式，计算所述软件副本在所述主机文件系统中的所述目标位置；

将所述安装包提取到所述目标位置，形成所述软件副本。

3.根据权利要求2所述的软件部署方法，其特征在于，在根据所述静态分派的条件和预先协商的软件副本提取目录格式，计算所述软件副本在所述主机文件系统中的所述目标位置之后，还包括：

基于所述目标位置检测所述安装包是否在所述主机文件系统上部署过；

在检测到所述安装包未部署过时，调用所述升级器组件生成所述软件副本。

4.根据权利要求1所述的软件部署方法，其特征在于，还包括：

在所述软件副本中对配置方案描述接口进行配置，所述配置方案描述接口用于为所述容器运行时组件提供所述软件副本的配置描述信息。

5.根据权利要求2所述的软件部署方法，其特征在于，基于所述静态分派的条件和软件部署需求生成识别协议，包括：

基于所述静态分派的条件确定所述软件副本的部署版本号；

基于预先协商的软件副本提取目录格式对所述部署版本号以及所述静态分派的条件进行配置处理，生成所述识别协议；

其中，所述识别协议用于使所述软件副本所在目录路径能够被所述容器运行时组件识别和区分。

6.根据权利要求1所述的软件部署方法，其特征在于，响应于获取到的业务容器启动请求，调用容器运行时组件基于所述识别协议扫描所述软件副本的目录，得到符合所述软件部署需求的目标软件副本，包括：

响应于所述启动请求，调用所述容器运行时组件加载文件系统捆绑，以创建依赖于所述软件副本的隔离文件系统环境；

基于所述识别协议解析所述文件系统捆绑，以扫描所述软件副本的目录，得到符合所述软件部署需求的目标软件副本。

7.根据权利要求6所述的软件部署方法，其特征在于，基于所述识别协议解析所述文件系统捆绑，以扫描所述软件副本的目录，得到符合所述软件部署需求的目标软件副本，包括：

调用所述容器运行时的启动工具基于所述识别协议通过文件系统捆绑扫描所述软件副本的目录和配置方案描述接口，以确认所述业务容器的用于软件配置的配置项；

基于所述用于软件配置的配置项和用户指定的部署版本号选定最佳软件副本，作为所述目标软件副本。

8.根据权利要求1所述的软件部署方法，其特征在于，生成所述目标软件副本的挂载决议，包括：

将所述目标软件副本的副本目录映射至所述业务容器的内部目录，得到所述目标软件副本的挂载路径；

调用所述容器运行时的启动工具基于所述软件部署需求进行所述业务容器的配置，得到软件配置信息；

基于所述挂载路径和所述软件配置信息生成所述目标软件副本的只读挂载决议。

9.根据权利要求1至8中任一项所述的软件部署方法，其特征在于，响应于获取到的待部署软件的安装包，调用升级器组件基于静态分派的条件将所述安装包提取到主机文件系统中对应的目标位置，形成软件副本，还包括：

基于所述静态分派的条件为所述软件副本的目录命名，所述静态分派的条件包括所述软件副本的编号、版本号、依赖项、运行的操作系统和使用的计算设备中的至少一种。

10.一种计算机程序产品，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1～9中任意一项所述的软件部署方法。