基于Docker容器的应用程序许可方法、装置、设备和介质

技术领域

本公开一般涉及计算机技术领域，尤其涉及一种基于Docker容器的应用程序许可方法、装置、设备和介质。

背景技术

Docker容器可以基于虚拟化技术来运行应用程序(比如网站，游戏等)，由于容器虚拟的特性，使得其生命周期不可控，往往会出现退出，重建等。

然而，由于一台机器上可以运行多个容器，且客户获得一个授权，可以运行多个容器，导致用户可在未授权许可范围内进行Docker容器的滥用，无法对软件商进行可控的保护，有待解决。

发明内容

鉴于现有技术中的上述缺陷或不足，期望提供一种基于Docker容器的应用程序许可方法、装置、设备和介质，以解决因授权被复制和滥用，导致无法对软件商进行可控的保护的问题。

第一方面，本申请实施例提供了一种基于Docker容器的应用程序许可方法，包括：

识别存在处于启动状态的Docker容器；

获取所述Docker容器的镜像文件，并从所述镜像文件中获取所述Docker容器的许可文件；

根据所述许可文件，确定所述Docker容器是否被授权许可。

可选地，所述Docker容器为业务节点基于所述镜像文件启动的，所述镜像文件为所述业务节点从私有云拉取获得。

可选地，所述镜像文件中烧制有所述许可文件的安全路径，所述获取所述Docker容器的镜像文件，并从所述镜像文件中获取所述Docker容器的许可文件，包括：

读取所述镜像文件的摘要，并对所述摘要进行解密，得到所述安全路径；

按照所述安全路径，读取所述许可文件。

可选地，根据所述许可文件，确定所述Docker容器是否被授权许可，包括：

对所述许可文件进行解密，得到针对所述Docker容器的至少一个许可标签；

基于所述至少一个许可标签，确定所述Docker容器是否被授权许可。

可选地，所述许可标签包括同时运行的预设容器数量，所述基于所述至少一个许可标签，确定所述Docker容器是否被授权许可，包括：

检测物理机当前运行的所述Docker容器的实际数量；

在所述实际数量小于或等于所述预设容器数量时，确定所述Docker容器被授权许可。

可选地，所述许可标签包括所述Docker容器的授权期限，所述基于所述至少一个许可标签，确定所述Docker容器是否被授权许可，包括：

根据所述授权期限，确定所述Docker容器的过期时间；

获取物理机运行的当前时间；

在所述当前时间未达到所述过期时间时，确定所述Docker容器被授权许可。

可选地，所述方法还包括：

获取至少一个未被授权许可的所述Docker容器；

从所述镜像文件中获取强行终止规则；

按照所述强行终止规则，对所述至少一个未被授权许可的所述Docker容器进行强行终止。

第二方面，本申请实施例提供了一种基于Docker容器的应用程序许可装置，包括：

识别模块，用于识别存在处于启动状态的Docker容器；

第一获取模块，用于获取所述Docker容器的镜像文件，并从所述镜像文件中获取所述Docker容器的许可文件；

确定模块，用于根据所述许可文件，确定所述Docker容器是否被授权许可。

第三方面，本申请实施例提供了一种电子设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，该处理器执行该程序时实现如本申请实施例描述的基于Docker容器的应用程序许可方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本申请实施例描述的基于Docker容器的应用程序许可方法。

由此，通过获取处于启动状态的Docker容器的镜像文件，并根据镜像文件中的许可文件确定Docker容器是否被授权许可，有效保证了Docker容器在许可合规运行下的可控性，解决了因授权被复制和滥用，导致无法对软件商进行可控的保护的问题。

本发明附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

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

图1示出了适于用来实现本申请实施例的基于Docker容器的应用程序许可方法的流程图；

图2示出了适于用来实现本申请一个实施例的形成镜像摘要的示意图；

图3示出了适于用来实现本申请一个实施例的启动构件镜像文件流程；

图4示出了适于用来实现本申请一个实施例的许可标签的示意图；

图5示出了适于用来实现本申请一个实施例的基于Docker容器的应用程序许可系统的示意图；

图6示出了适于用来实现本申请一个实施例的生成镜像文件的流程图；

图7示出了适于用来实现本申请一个实施例的许可审计的流程图；

图8示出了适于用来实现本申请实施例的基于Docker容器的应用程序许可装置的方框示意图；

图9示出了适于用来实现本申请实施例的电子设备或服务器的计算机系统的结构示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与发明相关的部分。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

图1为本申请实施例的基于Docker容器的应用程序许可方法的流程图。

在介绍本申请实施例的基于Docker容器的应用程序授权许可方法之前，先简单介绍下Docker容器以及可以应用于本申请的SaaS(Software-as-a-Service，软件即服务)。

具体地，Docker容器是一个开源的应用容器引擎，让开发者可以以统一的方式将他们的应用和应用所依赖的环境数据打包到一个可移植的容器中，然后发布到任何安装了docker引擎的服务器上，如Linux或Windows机器。

Docker属于Linux容器的一种封装，可以提供简单易用的容器使用接口。由于软件开发商已经将应用程序与该程序所依赖的环境数据打包在一个文件里面(Docker镜像)，使得软件购买者可以直接通过运行这个文件，就能在物理机上生成一个相应的虚拟容器，即Docker容器，而封装在Docker镜像中的程序可以在这个虚拟容器里运行。Docker镜像的唯一标识由镜像的摘要来保证，Docker镜像的摘要是不可篡改的，从而来确保开发商对软件购买者的授权的稳定性。

也就是说，Docker的接口相当简单，软件开发商可以方便地创建和使用容器，把自己的应用放入容器；Docker容器还可以进行版本管理、复制、分享和修改等操作。

SaaS是指通过Internet提供软件服务的新模式，传统模式下，厂商通过许可协议将软件产品部署到企业内部多个客户终端实现交付，而SaaS模式下厂商将应用软件统一部署在自己的服务器上，客户可以根据自己实际需求，通过互联网向厂商定购所需的应用软件服务，按定购的服务多少和时间长短向厂商支付费用，并通过互联网获得厂商提供的服务。SaaS定义了一种新的交付方式，也使得软件进一步回归服务本质。

SaaS应用软件有免费、付费和增值三种模式。付费通常为“全包”费用，囊括了通常的应用软件许可证费、软件维护费以及技术支持费。如图1所示，本申请实施例的基于Docker容器的应用程序许可方法，包括以下步骤：

步骤101，识别存在处于启动状态的Docker容器。

其中，Docker容器是独立运行的一个或一组应用的载体，它是一个类似于对象的概念，Docker镜像是系统的硬盘文件，由Docker镜像能够生成很多个容器，每个Docker镜像里都设置了相关程序，Docker镜像是一层层组成的，根据Docker镜像最上面一层设置的程序确定相应的Docker容器，也就是说，Docker容器是Docker镜像运行时的实体。换言之，Docker容器是根据Docker镜像内容经过物理机的运行而得到的。

进一步地，Docker镜像文件是用于创建Docker容器的模板，它将实现业务功能的应用以及应用所依赖的环境数据全部打包到一个“软件包”里，类似于软件的安装包，软件购买者将Docker镜像文件通过云存储设备下载到物理机器中，然后通过特殊命令进行启动。

可选的，云存储设备可包括公有云和私有云。其中，公有云(Public Cloud)通常指第三方提供商位用户提供的能够使用的云，公有云一般可通过Internet使用，可能是免费或成本低廉的，公有云的核心属性是共享资源服务。私有云(Private Cloud)是将云基础设施与软硬件资源创建在防火墙内，以供机构或企业内部各部门共享数据中心内的资源。创建私有云，除了硬件资源外，一般还有云设备(Iaas，Infrastructure as a Service，基础设施即服务)软件。私有云计算同样包含云硬件、云平台、云服务三个层次。不同的是，云硬件是用户自己的个人电脑或服务器，而非云计算厂商的数据中心。云计算厂商构建数据中心的目的是为千百万用户提供公共云服务，因此需要拥有几十上百万台服务器。私有云计算，对企业来说只服务于本企业员工以及本企业的客户和供应商。因此，本申请的软件购买者优选的可从私有云中下载Docker镜像文件，有效提高了Docker镜像文件下载过程中安全性，降低了因使用公有云被软件开发商或黑客破解的风险。

其中，私有云可部署在企业数据中心的防火墙内，也可以将它们部署在一个安全的物理机托管场所，私有云的核心属性是专有资源。

可选的，为了进一步增加Docker镜像文件的安全性，软件购买者可在私有云中设置镜像仓库，镜像仓库可通过独立的密码进行进入，Docker镜像可存储在镜像仓库中，由此，可以进一步降低非软件购买者对Docker镜像获取的可能性，从而降低Docker镜像被恶意破解的风险，提高对软件开发者的可控的保护。

在一个或多个实施例中，可由软件开发商提供私有云，即，软件开发商将封装好得Docker镜像文件存储在软件开发商得私有云中，软件购买者利用软件开发商提供的私有云地址、购买的产品标识等信息从软件开发商的私有云或私有云中的镜像仓库中拉取Docker镜像文件。

进一步地，本申请实施例可以通过“Docker pull命令”实现拉取，docker pull指从私有云中拉取或者更新指定镜像，例如，拉取的镜像文件是软件购买者存在私有云的java文件的产品镜像，即为docker pull java。

也就是说，本申请实施例可以先将所要启动的Docker容器对应的镜像文件(如软件包)下载到本地，该镜像文件包含有许可文件，通过将包含有许可文件的镜像文件拉取到本地，然后利用迹象文件启动Docker容器。因此，本申请实施例在识别存在处于启动状态的Docker容器时，可以根据镜像文件的读取情况进行识别。

步骤102，获取Docker容器的镜像文件，并从镜像文件中获取Docker容器的许可文件。

其中，镜像文件中烧制有存储Docker容器许可文件的安全路径，在通过拉取获得Docker容器的镜像文件之后，可从镜像文件中获取Docker容器的许可文件，包括：读取镜像文件的摘要，并对摘要进行解密，得到安全路径；按照安全路径，读取许可文件。其中，烧制是指将需要的数据通过相应的烧制工具烧录到存储介质中，例如光盘、烧录卡、计算机可读存储介质等，在本申请中，存储介质可以为用于存储镜像文件的计算机可读存储介质。

应当理解的是，如图2和表1所示，本申请实施例在推送包含许可文件的定制镜像到私有云之前，将Dockerfile中许可文件映射到镜像系统中安全路径，其中，Dockerfile是一个用来构建镜像的文本文件，文本内容包含了构建镜像所需的指令和说明；也就是说，dockerfile是用来制作镜像的源码文件，是构建容器过程中的指令，docker能够读取dockerfile的指定进行自动构建容器，基于dockerfile制作镜像。

许可文件的命名方式可以由数字和字母组成，例如，本申请实施例可以将许可文件命名为：

a5e4c87aa1b1ad044d4566421e02f784.lic,

本申请实施例可以将该镜像文件映射到系统中安全路径，其中，该安全路径可以为一个隐藏文件夹，例如，该隐藏文件夹可以为/opt/boe/clf/.hidden，从而实现对许可文件的有效保护，有效避免许可文件被恶意复制。

表1

进一步地，如图3所示，图3为本申请实施例启动构件镜像文件流程，将许可文件构建到镜像文件中的示意图，由此，本申请实施例在获取到Docker容器的镜像文件后，即可从镜像文件中获取Docker容器的许可文件。

其中，许可文件的格式具有多种，如表2至表4所示，表2为简单的字符串格式，该字符串可以由五部分组成，每个部分包含五位，并且该五位可以为数字和字母随机组合生成；表3为多因素字符集合格式，该字符串可以由五分部组成，第一部分为一个随机数字，剩余四部分由五个随机数组成；表4为自包含综合证书格式，其可以由数字、大小写字母随机生成，本领域技术人员可以根据实际情况选择相应的许可文件格式，为避免冗余，在此不做详细赘述。

表2

表3

表4

步骤103，根据许可文件，确定Docker容器是否被授权许可。

可选地，根据许可文件，确定Docker容器是否被授权许可，包括：对许可文件进行解密，得到针对Docker容器的至少一个许可标签；基于至少一个许可标签，确定Docker容器是否被授权许可。

具体而言，本申请实施例可以从Docker容器镜像文件安全的隐藏的路径中获取加密后的许可文件，比如：

a5e4c87aa1b1ad044d4566421e02f784.lic；

由此，即可解密相关文件，获取针对Docker容器的至少一个许可标签，其中，许可标签的示意图可以如图4所示，由图4可以看出，授权容器数量为1，有效期到2020年12月31号；从而即可根据许可标签判定该Docker容器是否被授权许可，实现对授权许可的可控性。

作为一种可能实现的方式，许可标签包括同时运行的预设容器数量，基于至少一个许可标签，确定Docker容器是否被授权许可，包括：检测物理机当前运行的Docker容器的实际数量；在实际数量小于或等于预设容器数量时，确定Docker容器被授权许可。其中，物理机可以为本地的物理机，也可以为远程的物理机。

具体而言，本申请实施例可以根据合法授权实例的数量确定Docker容器的被授权许可，例如，本申请实施例可以根据镜像签名获取机器中运行的实例数量，验证是否在合法的范围内，从而确定Docker容器是否被授权许可。

作为另一种可能实现的方式，许可标签包括Docker容器的授权期限，基于至少一个许可标签，确定Docker容器是否被授权许可，包括：根据授权期限，确定Docker容器的过期时间；获取物理机运行的当前时间；在当前时间未达到过期时间时，确定Docker容器被授权许可。

应当理解的是，授权期限可以为3个月、6个月、一年等。本申请实施例可以参考Docker容器的标签信息，根据许可要求来启动授权容器1……N。如表5所示，Docker容器的标签授权信息为：授权容器数量为1，有效期到2020年12月31号。

表5

也就是说，Docker容器的过期时间为2020年12月31号，如果当前物理机运行的当前时间未达到2020年12月31号，则确定Docker容器被授权许可，如果当前物理机运行的当前时间达到2020年12月31号，则说明授权期限到期，无法继续运行该软件。

由此可知，本申请实施例还设置有许可审计模块，并且通过许可审计模块对目前物理机器上运行的业务应用的容器进行许可检查，校验，执行管控操作。主要保证物理机器上运行的容器，在合理合规的前提下运行，比如容器里的包含的许可文件是否为官方发行，有无篡改，许可文件里授权的软件是否是正版，软件是否授权过期，授权的数量是否在规定数量内等。如果不合规，将对异常的容器进行强行终止。许可审计模块可以是单独的容器或者进程，可以不断的循环启动，从而可以实时对物理机器上运行的业务应用的容器进行许可检查，校验，执行管控操作；并且，为了防止镜像被篡改，比如改名字和许可授权文件，它利用原始的镜像签名和目前所有运行的容器中镜像签名进行比对，如果正常比对上，才容许运行容器，并进行统计和计数。

此外，如果授权规则校验失败，则给相关的应用发送告警信息，警告业务用户，目前授权超限和越界，并记录告警信息到业务日志，便于业务查看，以便进行回溯，审计结果如表6所示。

表6

可选地，方法还包括：获取至少一个未被授权许可的Docker容器；从镜像文件中获取强行终止规则；按照强行终止规则，对至少一个未被授权许可的Docker容器进行强行终止。

其中，强行终止规则可以是按照时间排序，根据业务场景，强行终止最新的启动的容器；也可以强行终止最旧的启动的容器；也可以随机选取容器进行强行终止，在此不做具体限定。

具体而言，本申请实施例还可以获取一个或者多个未被授权许可的Docker容器，并且对不同的未被授权许可的Docker容器可以采取相同的强行终止规则，也可以采取不同的强行终止规则，具体地可以由相关技术人员根据实际情况记进行强行终止，为避免冗余，在此不做详细赘述。

由此，通过获取到的强行终止规则对未被授权许可的Docker容器进行强行终止，有效保证了Docker容器在许可合规运行下的可控性，解决了因授权被复制和滥用，导致无法对软件商进行可控的保护的问题。

为使得本领域技术人员进一步了解本申请实施例的基于Docker容器的应用程序授权许可方法，下面结合图5和图6进一步说明。

如图5所示，图5为本申请一个实施例的基于Docker容器的应用程序许可方法涉及的系统示意图。该系统包括客户端(Clients)、主机(Hosts)和Registries(注册表)。

具体地，Docker客户端通过命令行或者其他工具使用DockerSDK与Docker的守护进程通信。Docker的守护进程是Docker的容器运行的后台的监控台，它里面包含运行中的容器列表、运行的状态、运行的个数等容器的信息，通过它可以实时了解到目前机器上运行的容器的情况，并且通过它可以重启，强行终止制定的容器；主机(Hosts)为一个物理或者虚拟的机器用于执行Docker守护进程和容器。容器是镜像运行时候的状态，例如游戏操作的界面。它提供应用服务。守护进程是系统后台进程，它类似系统的监工程序，监控和控制容器的运行。Registry可以为代码控制中的代码仓库，一个DockerRegistry中可以包含多个仓库(Repository)；每个仓库可以包含多个标签(Tag)；每个标签对应一个镜像标签是用来给的镜像文件(虚拟软件包)设定一个标记，比如这个应用的镜像是人工智能图像处理软件，我们可以给他设定一个标记，这样用户会方便查询和下载感兴趣的镜像，标签示例：类别＝AI，产品＝图像处理，过期时间＝2021-12-31。

DockerMachine是一个简化Docker安装的命令行工具，具体地，DockerMachine是一种可以在虚拟主机上安装Docker的工具，并可以使用docker-machine命令来管理物理机；Docker Machine也可以集中管理所有的docker物理机，比如快速的给100台服务器安装上docker。其可以在本地或者远程的相应平台上安装Docker。它类似一个标准的安装和运行容器的工具，帮助用户方便在各个机器上安装Docker。

进一步地，如图6所示，图6为本申请一个实施例的生成镜像文件的流程图。

S601，准备许可文件。

S602，在Dockerfile中将许可文件映射到镜像文件中的安全路径。

S603，启动构件镜像文件流程，将许可文件构建到镜像流程。

S604，为镜像文件打标签，说明授权规则。

S605，将镜像文件送到私有云。

进一步地，如图7所示，图7为本申请一个实施例的许可审计的流程图。

S701，拉取镜像文件。

S702，启动容器1……N。

S703，开始审计。

S704，读取镜像文件的签名。

S705，从容器安全路径获得许可文件。

S706，解密许可文件，获得授权规则。

S707，判断是否在授权规则范围内，如果是，执行步骤S711，否则，执行步骤S708。

S708，许可报警。

S709，记录告警日志。

S710，强行终止多余容器。

S711，记录授权日志。

应当注意，尽管在附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。

根据本申请实施例提出的基于Docker容器的应用程序授权许可方法，通过获取处于启动状态的Docker容器的镜像文件，并根据镜像文件中的许可文件确定Docker容器是否被授权许可，有效保证了Docker容器在许可合规运行下的可控性，解决了因授权被复制和滥用，导致无法对软件商进行可控的保护的问题。

进一步参考图8，其示出了根据本申请一个实施例的基于Docker容器的应用程序许可装置10的示例性结构框图。

如图8所示，该基于Docker容器的应用程序许可装置10包括：识别模块100、第一获取模块200和确定模块300。

识别模块100用于识别存在处于启动状态的Docker容器；

第一获取模块200用于获取Docker容器的镜像文件，并从镜像文件中获取Docker容器的许可文件；

确定模块300用于根据许可文件，确定Docker容器是否被授权许可。

可选地，在一些实施例中，Docker容器为业务节点基于镜像文件启动的，镜像文件为业务节点从私有云拉取获得。

可选地，在一些实施例中，镜像文件中烧制有许可文件的安全路径，第一获取模块200具体用于：

读取镜像文件的摘要，并对摘要进行解密，得到安全路径；

按照安全路径，读取许可文件。

可选地，在一些实施例中，确定模块300具体用于：

对许可文件进行解密，得到针对Docker容器的至少一个许可标签；

基于至少一个许可标签，确定Docker容器是否被授权许可。

可选地，在一些实施例中，许可标签包括同时运行的预设容器数量，确定模块300还用于：

检测物理机当前运行的Docker容器的实际数量；

在实际数量小于或等于预设容器数量时，确定Docker容器被授权许可。

可选地，在一些实施例中，许可标签包括Docker容器的授权期限，确定模块300还用于：

根据授权期限，确定Docker容器的过期时间；

获取物理机运行的当前时间；

在当前时间未达到过期时间时，确定Docker容器被授权许可。

可选地，在一些实施例中，上述的装置10，还包括：

第二获取模块，用于获取至少一个未被授权许可的Docker容器；

第三获取模块，用于从镜像文件中获取强行终止规则；

强行终止模块，用于按照强行终止规则，对至少一个未被授权许可的Docker容器进行强行终止。

应当理解，装置10中记载的诸单元或模块与参考图1描述的方法中的各个步骤相对应。由此，上文针对方法描述的操作和特征同样适用于装置10及其中包含的单元，在此不再赘述。装置10可以预先实现在电子设备的浏览器或其他安全应用中，也可以通过下载等方式而加载到电子设备的浏览器或其安全应用中。装置10中的相应单元可以与电子设备中的单元相互配合以实现本申请实施例的方案。

在上文详细描述中提及的若干模块或者单元，这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

根据本申请实施例提出的基于Docker容器的应用程序授权许可装置，通过获取处于启动状态的Docker容器的镜像文件，并根据镜像文件中的许可文件确定Docker容器是否被授权许可，有效保证了Docker容器在许可合规运行下的可控性，解决了因授权被复制和滥用，导致无法对软件商进行可控的保护的问题。

下面参考图9，图9示出了适于用来实现本申请实施例的电子设备或服务器的计算机系统的结构示意图，

如图9所示，计算机系统900包括中央处理单元(CPU)901，其可以根据存储在只读存储器(ROM)902中的程序或者从存储部分908加载到随机访问存储器(RAM)903中的程序而执行各种适当的动作和处理。在RAM903中，还存储有系统的操作指令所需的各种程序和数据。CPU901、ROM902以及RAM903通过总线904彼此相连。输入/输出(I/O)接口905也连接至总线904。

以下部件连接至I/O接口905；包括键盘、鼠标等的输入部分906；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分907；包括硬盘等的存储部分908；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分909。通信部分909经由诸如因特网的网络执行通信处理。驱动器910也根据需要连接至I/O接口905。可拆卸介质911，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器910上，以便于从其上读出的计算机程序根据需要被安装入存储部分908。

特别地，根据本申请的实施例，上文参考流程图图1描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分909从网络上被下载和安装，和/或从可拆卸介质911被安装。在该计算机程序被中央处理单元(CPU)901执行时，执行本申请的系统中限定的上述功能。

需要说明的是，本申请所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以为的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作指令。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，前述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以不同于附图中所标注的顺序发生。例如，两个连接表示的方框实际上可以基本并行地执行，他们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作指令的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元或模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元或模块也可以设置在处理器中，例如，可以描述为：一种处理器包括上述的基于Docker容器的应用程序授权许可方法。其中，这些单元或模块的名称在某种情况下并不构成对该单元或模块本身的限定，例如，识别模块，还可以被描述为“识别存在处于启动状态的Docker容器”。

作为另一方面，本申请还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的电子设备中所包含的，也可以是单独存在，而未装配入该电子设备中的。上述计算机可读存储介质存储有一个或多个程序，当上述程序被一个或者一个以上的处理器用来执行描述于本申请的基于Docker容器的应用程序授权许可方法。

以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本申请中所涉及的公开范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离前述公开构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其他技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。