虽然码头工人,kubernetes的命令集并非十分复杂,后台操作也比较快捷,但是对于大多数徘徊在容器化门口的企业和个人用户来说,仍旧是一块心病,码头工人码头工人,这是一个问题,SWR服务通过提供界面化的操作,屏蔽原生命令行,简化用户操作和技术门槛,为企业和个人用户提供极简的容器化交付平台,我们接下来会通过一系列的文章,向大家介绍SWR的这些功能特性。
今天要为大家介绍的是用户0命令行,通过WEB界面实现镜像的上传及实现原理剖析。
我们从这个最为常用并极为简单的码头工人推功能开始讲,为什么呢?由于我们在与客户交流过程中发现,大多数都未接触过容器化管理系统,甚至镜像,对后端操作不熟悉的他们,对页面操作是有一定需求的。目前主流的PaaS平台基本都支持通过页面操作构建镜像,创建集群,创建应用等等,它们都在不断地封装底层集群管理系统(如kubernetes)的接口,设计一款对于云下用户友好的前端页面,让尽可能多的后端复杂操作可以通过鼠标的几次点击完成。
我们可以将这个趋势解释为,用户的业务云化的成本(包括金钱成本和时间成本)越低,上云的倾向也就越大。如今,我们支持用户在页面上完成构建,部署等操作,如果可以实现镜像上传下载都在页面上完成,用户就可以在尝试云化的早期尽可能避开后端操作,将尽可能多的时间成本花在业务调试上,普通运维人员不需要熟悉码头工人命令,也可以从内网或者第三方镜像仓库下载镜像,上传并完成升级操作。
接下来,我们从镜像上传逻辑和镜像结构开始讲起,阐述如何去实现页面上传镜像的功能。
后端上传镜像流程分析
我们的目的是实现另一种镜像上传方式,首先要了解原生的镜像上传流程是怎样的。
上传镜像层
码头工人推时,最先被上传的是镜像层文件。如下面的busybox,每一行的短ID都表示着一个镜像层的sha256值,它有两个镜像层:
上传清单
你们是否注意到,每个镜像在上传结束之后,屏幕上都会多一行<代码> xxx:消化:xxx大小:xxx>
体现主要是负责关联镜像的元数据文件和镜像层。在所有层都上传结束后,它才被传到仓库端的,用于校验是否所有实体文件都上传完成。通过抓包或者查阅官方文档,我们可以得知,清单的结构是这样的:
