CN116723186A - 镜像文件上传方法、系统及相关设备 - Google Patents

Abstract

本申请公开了镜像文件上传方法、系统及相关设备，该方法包括：使用目标浏览器控件拉取目标镜像文件，并通过目标浏览器将目标镜像文件传送给目标寄存区；启用镜像管理工具，以将目标寄存区内的目标镜像文件推送到镜像仓库。本申请可使用目标浏览器控件拉取目标镜像文件，并将目标镜像文件传送给目标寄存区，避免如传统般需提前安装好客户端应用程序，加大使用成本。镜像管理工具不包含docker工具的好处有，可避免如传统般为使用客户端应用程序上传镜像，同时要安装相应的应用守护进程dockerd。可见，本申请最终能便捷低耗地将镜像文件上传到镜像仓库，节省文件传输时长，提高用户体验。

Description

镜像文件上传方法、系统及相关设备

技术领域

本申请实施例涉及互联网技术领域，尤其涉及镜像文件上传方法、系统及相关设备。

背景技术

所谓的镜像文件和rar或ZIP压缩包类似，常以.iso为后缀，它将特定的一系列文件按照一定格式制作成单一的文件，以便用户下载和安装使用，例如一个操作系统、游戏等的文件；它最重要的特点是，可以被特定软件识别并可直接将所包含的内容刻录到光盘上，可用于创建容器等，简言之，镜像文件(或简称为镜像)就是光盘的“提取物”，在镜像文件中可以包含系统文件、引导文件、分区表信息等。

目前，镜像文件需通过客户端应用如某APP上传，这要求用户事先要安装好客户端应用程序，如此操作对用户而言不够友好，需耗费时间、运行资源等使用成本。针对于此，有必要提供有效的解决方案。

发明内容

本申请实施例提供了镜像文件上传方法、系统及相关设备，用于通过浏览器上传镜像文件，提高用户体验。

本申请实施例第一方面提供一种镜像文件上传方法，包括：

使用目标浏览器控件拉取目标镜像文件，并通过所述目标浏览器将所述目标镜像文件传送给目标寄存区；

启用镜像管理工具，以将所述目标寄存区内的所述目标镜像文件推送到镜像仓库；其中，所述镜像管理工具不包含容器引擎docker工具。

本申请第一方面所述的方法在具体实施时可采用本申请第二方面所述的内容实现。

本申请实施例第二方面提供一种镜像文件上传系统，包括：

传输单元，用于使用目标浏览器控件拉取目标镜像文件，并通过所述目标浏览器将所述目标镜像文件传送给目标寄存区；

处理单元，用于启用镜像管理工具，以将所述目标寄存区内的所述目标镜像文件推送到镜像仓库；其中，所述镜像管理工具不包含容器引擎docker工具。

本申请实施例第三方面提供一种电子设备，包括：

中央处理器，存储器以及输入输出接口；

所述存储器为短暂存储存储器或持久存储存储器；

所述中央处理器配置为与所述存储器通信，并执行所述存储器中的指令操作以执行本申请实施例第一方面或第一方面的任一具体实现方式所描述的方法。

本申请实施例第四方面提供一种计算机可读存储介质，包括指令，当所述指令在计算机上运行时，使得计算机执行如本申请实施例第一方面或第一方面的任一具体实现方式所描述的方法。

本申请实施例第五方面提供一种包含指令或计算机程序的计算机程序产品，当所述计算机程序产品在计算机上运行时，使得计算机执行如本申请实施例第一方面或第一方面的任一具体实现方式所描述的方法。

从以上技术方案可以看出，本申请实施例至少具有以下优点：

本申请实施例可使用目标浏览器控件拉取目标镜像文件，并通过目标浏览器将目标镜像文件传送给目标寄存区，避免如传统般需提前安装好客户端应用程序，加大使用成本。其中，镜像管理工具不包含docker工具的好处有，可避免如传统般为使用客户端应用程序上传镜像，同时要安装相应的应用守护进程dockerd。可见，本申请实施例最终能便捷低耗地将镜像文件上传到镜像仓库，节省文件传输时长，提高用户体验。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

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

图1为本申请实施例的一个系统架构示意图；

图2为本申请实施例方法的一个流程示意图；

图3为本申请实施例方法的另一流程示意图；

图4为本申请实施例目标浏览器的一个界面示意图；

图5为本申请实施例方法的另一流程示意图；

图6为本申请实施例方法的另一流程示意图；

图7为本申请实施例方法的另一流程示意图；

图8为本申请实施例镜像文件上传系统的一个结构示意图；

图9为本申请实施例电子设备的一个结构示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书及附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

在以下的描述中，涉及到“一个具体实施方式”或“一个具体示例”等类似表达，其描述了所有可能实施例的子集，但是可以理解，“一个具体实施方式”或“一个具体示例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。在以下的描述中，涉及到的术语多个是指至少两个。本申请所说的某数值达到阈值(如果存在)，在一些具体示例中，可包括前者大于阈值后者的情况。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

为便于理解和说明，在对本申请做进一步的详细说明之前，将对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

kubernetes：一个生产级别的容器编排系统或容器集群管理系统，用来对容器化应用进行自动化部署、扩缩和管理。

docker：一个开源的容器引擎，常用于使用Linux内核功能(如命名空间和控制组)在操作系统之上创建容器。

对象存储：是用于大规模存储非结构化数据的数据存储架构。

skopeo：一个开源的容器镜像及仓库的管理工具，用于操作、检查、签署和传输容器、镜像及镜像存储仓库。

容器镜像(可称为镜像)：docker的整个生命周期有三部分组成：镜像(image)+容器(container)+仓库(repository)。镜像概念类似虚拟机的镜像，是一个只读的模板，一个独立的文件系统，包括运行容器所需的数据，可以用来创建多个容器。

服务器纳管：指将服务器管理和维护的过程。

root用户：是系统中唯一的超级管理员，它具有等同于操作系统的权限。

Dockerd：是docker架构中一个常驻在后台的系统进程，全称为docker daemon，dockerd实际调用的还是集装箱containerd系统的api接口(rpc方式实现)；通俗的讲，Dockerd是用于管理容器的守护进程。

Tus协议：是一个基于HTTP的文件断点续传开放协议，顾名思义，断点续传的意思是，不管是用户自行中断传输过程，还是由于网络等原因的意外中断，都可以从中断的地方继续上传信息，而不用重新开始。

本申请实施例提供的方法，可应用于如图1所示的应用环境中，其中，终端102(可称为客户端或用户端)通过网络与服务器101(可称为服务端)进行通信，数据存储系统100可以存储服务器101需要处理的数据，如目标镜像文件。数据存储系统100可以集成在服务器101上，也可以放在云上或其他网络服务器上。用户(如开发员或运维员)可以在终端102的目标浏览器界面输入目标镜像文件地址，以明确要上传的镜像文件是哪个；该目标镜像文件可通过目标浏览器将目标镜像文件传送给服务器101，从而由服务器101最终推送到镜像仓库，实现镜像文件的便捷上传；此外，服务器101可将上传进度或推送结果返回给终端102，以便用户知悉镜像上传过程或启用重试机制。

上述终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备，便携式可穿戴设备可为智能手表、智能手环、头戴设备等。服务器101可以用独立的服务器或者是多个服务器组成的服务器集群来实现。需要说明的是，本申请实施例提供的方法可如上述由终端设备和服务器共同实现，也可以全部在服务器侧实现，或还可以全部在终端设备侧实现，具体可根据实际应用场景确定，此处不做限制。

下面将对本申请的方法做进一步的详细说明。

请参阅图2，本申请第一方面提供一种镜像文件上传方法的一个具体实施例，该实施例包括如下操作步骤：

21、使用目标浏览器控件拉取目标镜像文件。

因容器镜像文件(或称为镜像)的存储空间大等原因，现有的镜像文件上传方案一般是，后台人员(如开发或测试员)依赖客户端或执行命令行上传，如依赖指示加载容器镜像到dockerd的“dockerload”命令，及指示推送容器镜像到镜像仓库的“dockerpush”命令，但如此命令会让dockerd的CPU和内存消耗突增；此外，在正式发布或与其他厂商合作时，如此传输镜像需使用压缩包的方式，这无疑会给使用者带来压缩解压等方面的使用成本。相比于CS(Client-Server，客户端—服务端)架构，使用浏览器的BS(Browser-Server，浏览器—服务器)架构，对于用户来说，不需要在终端安装客户端应用程序APP，使用更为简单。因此，为减少用户的使用成本，可通过浏览器上传镜像文件，如使用目标浏览器控件拉取目标镜像文件。

22、通过目标浏览器将目标镜像文件传送给目标寄存区。

因镜像传输中间需要先保存在目标寄存区，才能最终上传到镜像仓库，故可将目标镜像文件传送给目标寄存区，以适应系统的运行和兼容性。

考虑到并发能力的问题，本申请实施例的方法可适用于kubernetes系统平台。这是因为，传统的服务端一般是单节点或者主备架构的服务器，而采用kubernetes集群可以纳管上千个服务器，且可提供基于CPU、内存等资源调度策略进行选择，可以选择资源使用更为均衡的服务节点，从而增强系统并发能力。

23、启用镜像管理工具，以将目标寄存区内的目标镜像文件推送到镜像仓库。

现有上传镜像的方案中，会使用传统的docker工具，但是docker的性能消耗大，并且需安装有守护进程dockerd，而该进程必须由root用户启动，安全风险较大。因此有必要寻求有效的解决方案，例如，可启用镜像管理工具，以将目标寄存区内的目标镜像文件推送到镜像仓库；其中，镜像管理工具不包含容器引擎docker工具，如可以是skopeo、镜像构建kaniko或容器管理器podman等工具。

综上，本申请实施例可使用目标浏览器控件拉取目标镜像文件，并通过目标浏览器将目标镜像文件传送给目标寄存区，避免如传统般需提前安装好客户端应用程序，加大使用成本。其中，镜像管理工具不包含docker工具的好处有，可避免如传统般为使用客户端应用程序上传镜像，同时要安装相应的应用守护进程dockerd。可见，本申请实施例最终能便捷低耗地将镜像文件上传到镜像仓库，节省文件传输时长，提高用户体验。

在上述示例说明的基础上，下面将提供一些具体的可能实施示例，实际应用中，这些示例之间的实施内容可根据相应的功能原理和应用逻辑由需地结合实施。

请参阅图3至图7，本申请提供一种镜像文件上传方法的另一具体实施例，该实施例包括如下操作步骤：

30、确定多个目标服务端。

为保障文件传输过程的稳定性，减少耗时长等问题的频发率，可以依据负载均衡策略和目标镜像文件大小，从服务端列表中选定多个共同收发目标镜像文件的目标服务端，目标服务端用于通过目标浏览器传送目标镜像文件。换言之，如图6所示，可根据负载均衡策略选择处理请求(如分片上传镜像文件的请求)的服务端。其中，目标服务端为受认证与授权的可信赖服务端，各目标服务端可各自有用于做身份认证的标识号，如虚拟ip号(VIP，virtual-IP)；示例性的，可以对目标服务端实施限流策略，以防流量过大等问题中断服务端进程，保障服务端可靠运行。

31、使用目标浏览器控件拉取目标镜像文件。

在一些具体示例中，步骤31的具体操作过程可包括：获得输入到目标浏览器界面的目标镜像文件地址，并通过目标浏览器控件根据目标镜像文件地址拉取目标镜像文件。

如图4所示，目标浏览器UI界面可提供“上传镜像”的文件选择框，该文件选择框能关联查找镜像文件信息如文件地址，用户可通过该文件选择框选定目标镜像文件，并触发作为目标浏览器控件的“确定”控件拉取到目标镜像文件。

32、通过目标浏览器将目标镜像文件传送给目标寄存区。

在一些具体示例中，目标寄存区包含对象存储区和/或本地临时目录，相应的，步骤32的具体操作过程可包括：向目标寄存区发送断点续传tus协议和分片请求，以使目标寄存区同意目标浏览器按tus协议分片上传目标镜像文件；将上传的目标镜像文件保存到对象存储区或本地临时目录。

如图5和图6所示，用户可通过目标浏览器上传目标镜像文件，其中可由目标浏览器向目标寄存区发送断点续传tus协议和分片请求，以使目标浏览器可按tus协议分片式地上传目标镜像文件，从而避免因网络故障或文件过大等问题增加传输时长，影响用户体验。之后，目标服务端可启动管理组件，将上传的目标镜像文件保存到对象存储区或本地临时目录。从高可用性或高可靠度方面考虑，优选的，将上传的目标镜像文件保存到本地临时目录，更方便文件做保存和传送。其中，可根据实际情况将目标镜像文件分成多个片段式的小文件，这些小文件可以相应的标记上文件索引号，使得后续可按索引号顺序和tus协议续传各个小文件到目标寄存区。

33、启用镜像管理工具，以将目标寄存区内的目标镜像文件推送到镜像仓库。

在一些具体示例中，步骤33的具体操作过程可包括：监测目标镜像文件传送到目标寄存区过程的上传进度，并在上传进度达到预设进度后启动推送任务，推送任务的创建过程包含调度镜像管理工具；执行推送任务，以使用镜像管理工具将目标镜像文件由目标寄存区推送到镜像仓库。

例如，目标服务端监测到上述上传进度达到100％等预设进度时，即监测到目标镜像文件至少部分成功上传到目标寄存区后，可启动推送任务Job。当然，预设进度也可以不是100％，如可以是95％等进度时便启动job，如此可以将先上传到目标寄存区的镜像片段(如整段镜像中前95％那部分的文件)推送给镜像仓库，后上传到的片段之后再推送给镜像仓库，以节省等待时长。具体的，推送任务Job中可使用镜像管理工具，将对象存储区或本地临时目录内的镜像文件推送到镜像仓库中。其中，推送任务Job具体可由kubernetes系统的调度策略进行调度，该Job还可以部署为异步任务。

在一些具体示例中，上述推送任务(Job)的创建过程可包括：配置推送任务对应的资源信息，所述资源包含中央处理器CPU计算资源和/或内存(memory)资源。

例如，推送任务Job的配置具体可以是配置资源信息，该资源信息可包含对CPU计算资源和/或内存(memory)资源的限制(limits)。其中，运行容器Pod期间，可能内存(memory)使用量会增加，资源限制(Limits)表示最多能使用多少内存即资源限额(硬限制)；相对的，资源需求(Requests)，即运行Pod的节点必须满足运行Pod的最基本需求才能运行Pod，如容器Pod运行至少需要2G内存、1核CPU(软限制)。

另一方面，在一些具体示例中，上述推送任务(Job)的创建过程可包括：对推送任务进行置备状态和执行状态的状态设置，其中，处于置备状态的推送任务用于明确镜像仓库是否为已认证仓库，处于执行状态的推送任务用于将目标镜像文件推送到已认证仓库。

例如，可以将推送任务job的任务状态设置为置备(provisioning)状态、执行(active)状态。置备(provisioning)可称为服务开通，是指设置IT基础架构的过程，也可以指管理数据和资源访问权限并使之可供用户和系统使用的步骤，属于部署过程中的步骤。如图7所示，处于置备(provisioning)状态的推送任务job本质上已具备推送镜像的功能，但需要待目标服务端确定了预接收目标镜像文件的镜像仓库为已认证仓库(已获得权威证书的仓库)后，才能由置备(provisioning)状态调为执行(active)状态，从而真正地执行任务即推送镜像文件到已认证仓库；此处的状态变更具体可由镜像管理工具skopeo实施。简言之，推送任务job中skopeo工具只需要下达调整任务状态的命令(调为执行状态)，即可完成推送镜像的工作，而该命令能被下达的前提是，确认预接收目标镜像文件的镜像仓库是已获得权威证书的可信赖仓库。实际应用中，job的资源信息配置和状态设置这两过程的先后执行顺序可以不限，也可以同时执行，具体可由实际情况而定。

上述创建推送镜像的job的优势有：能和管理组件解耦，减少管理组件的压力；可利用kubernetes集群的能力，实现更好的调度和扩展；对job的CPU和内存进行限制，可避免推送镜像时增大cpu和内存的消耗，浪费运行资源。

34、启用重试机制，以求将目标镜像文件成功推送到镜像仓库。

若步骤33反馈的结果是推送失败，则可利用kubernetes重试机制进行步骤重试；具体的，返回执行步骤31，以求将目标镜像文件成功推送到镜像仓库，增大容器镜像的成功上传率。

综上，本申请实施例能减轻用户对镜像上传的使用成本和学习成本，还可利用kubernetes等分布式平台提高系统的并发性能；同时，能不依赖于传统docker工具及其守护进程dockerd，有效降低cpu和内存的消耗，方便后续创建容器、部署应用及业务上线，提高用户体验。

上述步骤31至33与步骤21至23的操作内容类似，具体不再赘述。步骤30与步骤31之间的先后执行顺序可以不限，也可以同时执行，具体可视实际情况而定。相比于图2的示例说明，上述追加出的步骤30和步骤34在具体实施时不一定必须执行，追加出的这两项步骤之间可以结合实施或单独实施，具体可视实际场景而定。

请参阅图8，本申请第二方面提供一种镜像文件上传系统的一个具体示例，该系统包括：

传输单元801，用于使用目标浏览器控件拉取目标镜像文件，并通过目标浏览器将目标镜像文件传送给目标寄存区；

处理单元802，用于启用镜像管理工具，以将目标寄存区内的目标镜像文件推送到镜像仓库；其中，镜像管理工具不包含容器引擎docker工具。

可选地，目标寄存区包含对象存储区和/或本地临时目录；传输单元801具体用于：

向目标寄存区发送断点续传tus协议和分片请求，以使目标寄存区同意目标浏览器按tus协议分片上传目标镜像文件；

将上传的目标镜像文件保存到对象存储区或本地临时目录。

可选地，处理单元802具体用于：

监测目标镜像文件传送到目标寄存区过程的上传进度，并在上传进度达到预设进度后启动推送任务，推送任务的创建过程包含调度镜像管理工具；

执行推送任务，以使用镜像管理工具将目标镜像文件由目标寄存区推送到镜像仓库。

可选地，处理单元802具体用于：

配置推送任务对应的资源信息，资源包含中央处理器CPU计算资源和/或内存资源。

可选地，处理单元802具体用于：

对推送任务进行置备状态和执行状态的状态设置，其中，处于置备状态的推送任务用于明确镜像仓库是否为已认证仓库，处于执行状态的推送任务用于将目标镜像文件推送到已认证仓库。

可选地，传输单元801具体用于：

获得输入到目标浏览器界面的目标镜像文件地址，并通过目标浏览器控件根据目标镜像文件地址拉取目标镜像文件。

可选地，处理单元802还用于：

依据负载均衡策略和目标镜像文件大小，从服务端列表中选定多个共同收发目标镜像文件的目标服务端，所述目标服务端用于通过所述目标浏览器传送所述目标镜像文件。

可选地，处理单元802还用于：

若推送失败，返回执行使用目标浏览器控件拉取目标镜像文件的步骤，以求将目标镜像文件成功推送到镜像仓库。

本申请实施例中，镜像文件上传系统各单元所执行的操作，与前述第一方面或第一方面的任一具体方法实施例所描述的操作类似，具体此处不再赘述。当然，本申请第一方面各操作的具体实现过程也可参见第二方面的相关描述实现。

请参阅图9，本申请实施例的电子设备900可以包括一个或一个以上中央处理器CPU(CPU，centralprocessingunits)901和存储器905，该存储器905中存储有一个或一个以上的应用程序或数据。

其中，存储器905可以是易失性存储或持久存储。存储在存储器905的程序可以包括一个或一个以上模块，每个模块可以包括对电子设备中的一系列指令操作。更进一步地，中央处理器901可以设置为与存储器905通信，在电子设备900上执行存储器905中的一系列指令操作。

电子设备900还可以包括一个或一个以上电源902，一个或一个以上有线或无线网络接口903，一个或一个以上输入输出接口904，和/或，一个或一个以上操作系统，例如WindowsServerTM，MacOSXTM，UnixTM，LinuxTM，FreeBSDTM等。

该中央处理器901可以执行前述第一方面或第一方面的任一具体方法实施例所执行的操作，具体不再赘述。

本申请提供的一种计算机可读存储介质，包括指令，当所述指令在计算机上运行时，使得计算机执行如上述第一方面或第一方面的任一具体实现方式所描述的方法。

本申请提供的一种包含指令或计算机程序的计算机程序产品，当所述计算机程序产品在计算机上运行时，使得计算机执行如上述第一方面或第一方面的任一具体实现方式所描述的方法。

可以理解的是，在本申请的各种实施例中，各步骤的序号大小并不意味着执行顺序的先后，各步骤的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统(若存在)、装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统或装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品(计算机程序产品)存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，业务服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，read-onlymemory)、随机存取存储器(RAM，randomaccess memory)、磁碟或者光盘等各种可以存储程序代码的介质。

Claims (10)

1.一种镜像文件上传方法，其特征在于，包括：

使用目标浏览器控件拉取目标镜像文件，并通过所述目标浏览器将所述目标镜像文件传送给目标寄存区；

启用镜像管理工具，以将所述目标寄存区内的所述目标镜像文件推送到镜像仓库；其中，所述镜像管理工具不包含容器引擎docker工具。

2.根据权利要求1所述的镜像文件上传方法，其特征在于，所述目标寄存区包含对象存储区和/或本地临时目录；所述通过所述目标浏览器将所述目标镜像文件传送给目标寄存区，包括：

向所述目标寄存区发送断点续传tus协议和分片请求，以使所述目标寄存区同意所述目标浏览器按所述tus协议分片上传所述目标镜像文件；

将上传的所述目标镜像文件保存到所述对象存储区或所述本地临时目录。

3.根据权利要求1所述的镜像文件上传方法，其特征在于，所述启用镜像管理工具，以将所述目标寄存区内的所述目标镜像文件推送到镜像仓库，包括：

监测所述目标镜像文件传送到所述目标寄存区过程的上传进度，并在所述上传进度达到预设进度后启动推送任务，所述推送任务的创建过程包含调度所述镜像管理工具；

执行所述推送任务，以使用所述镜像管理工具将所述目标镜像文件由所述目标寄存区推送到镜像仓库。

4.根据权利要求3所述的镜像文件上传方法，其特征在于，所述推送任务的创建过程包括：

配置所述推送任务对应的资源信息，所述资源包含中央处理器CPU计算资源和/或内存资源。

5.根据权利要求3所述的镜像文件上传方法，其特征在于，所述推送任务的创建过程包括：

对所述推送任务进行置备状态和执行状态的状态设置，其中，处于所述置备状态的所述推送任务用于明确所述镜像仓库是否为已认证仓库，处于所述执行状态的所述推送任务用于将所述目标镜像文件推送到所述已认证仓库。

6.根据权利要求1所述的镜像文件上传方法，其特征在于，通过所述目标浏览器将所述目标镜像文件传送给目标寄存区之前，所述方法还包括：

依据负载均衡策略和所述目标镜像文件大小，从服务端列表中选定多个共同收发所述目标镜像文件的目标服务端，所述目标服务端用于通过所述目标浏览器传送所述目标镜像文件。

7.根据权利要求1所述的镜像文件上传方法，其特征在于，启用镜像管理工具，以将所述目标寄存区内的所述目标镜像文件推送到镜像仓库之后，所述方法还包括：

若推送失败，返回执行所述使用目标浏览器控件拉取目标镜像文件的步骤，以求将所述目标镜像文件成功推送到镜像仓库。

8.一种镜像文件上传系统，其特征在于，包括：

传输单元，用于使用目标浏览器控件拉取目标镜像文件，并通过所述目标浏览器将所述目标镜像文件传送给目标寄存区；

处理单元，用于启用镜像管理工具，以将所述目标寄存区内的所述目标镜像文件推送到镜像仓库；其中，所述镜像管理工具不包含容器引擎docker工具。

9.一种电子设备，其特征在于，包括：

中央处理器，存储器以及输入输出接口；

所述存储器为短暂存储存储器或持久存储存储器；

所述中央处理器配置为与所述存储器通信，并执行所述存储器中的指令操作以执行权利要求1至7中任意一项所述的方法。

10.一种计算机可读存储介质，其特征在于，包括指令，当所述指令在计算机上运行时，使得计算机执行如权利要求1至7中任意一项所述的方法。