前端全栈之路 - 玩转 Docker (制品库) 本文为稀土掘金技术社区首发签约文章，14天内禁止转载，14天后未获授权禁止转载，侵权必究！ 前言在之前的章节中，我们一起学习了Docker的基础使用以及如何去构建一个生产的Docker Image。 但是Docker Image构建完毕之后一般都是在本地存储，而实际上我们发布的时候，通常需要在另外一台部署服务器上使用，如果是分布式部署的话，那么可能就不止一两台服务器这么简单。 所以本章将介绍制品库的相关知识以及使用，同时从本章开始对于前端同学来说学习难度也会逐步变高但与前端的相关性也开始逐步减弱了。 什么是制品库顾名思义，制品库是用来统一管理不同格式的软件制品的仓库（制品是指由源码编译打包生成的二进制文件，但也有特殊情况需要源码运行。所以无论是否已经完成编译，广义上只要可以直接在服务器或者在某些场景能够直接运行或使用，它都可以归纳于制品）。 与常规的代码或者软件管理仓库不同的是，制品库除了基本的存储能力之外，还提供了版本控制、访问控制、安全扫描、依赖分析等重要功能，由此可见在Devops链路中制品库是不可或缺的关键一环。 可能对于不熟悉Devops的同学，制品库这个名词比较陌生，但实际中大家都已经在不断的使用了，作为前端同学肯定都使用过NPM包来管理通用的功能与工具库，当业务规模到了一定的时候，通常需要针对业务来做一些更多的封装，此时抽取为通用的NPM包无疑是一种非常好的方式。但是携带了业务属性的NPM包又不能发布到公共的NPM仓库，需要搭建一个内网或者私有的NPM源，那么这个私有源可以称之为一个制品库了。 如何选取制品库通常情况下，除非团队规模非常的小，或者对业务基本没有任何共用的可能性，否则搭建一套属于自己的团队私有制品库都是非常有必要的。 在市面上有非常多的制品库方案可供选择，接下来提供以下几种制品库类型以供参考，大家可以自行对比取舍。 NexusNexus 3.x之前的版本都用于管理Mavn项目，而在3.x版本之后增加了对Docker、NPM的支持，所以后面所有的介绍都是基于3.x之后的版本。 Nexus可以配置3种类型的仓库，分别是proxy、hosted以及group： proxy：与英文直译相同，此类型制品库一般只能下载，而不能推送，同时他与CNPM等私有源一样，起到的是代理同步的功能，当拉取proxy仓库类型的镜像时会先将代理公共仓库的镜像（可以配置任意代理地址）同步到 Nexus 后，再同步到拉取服务器本地，后期同类型版本就不再从公共仓库拉取而是直接访问部署的 Nexus 服务，所以当有一些镜像特别大或者外部源不稳定的时候建议可以使用这种模式； hosted：与proxy不同的是，此类型的仓库都属于私有类型，用存储团队内部私有镜像或者其他的制品，这也是我们日常打交道最多的模块； group：此类型可以将以上两种类型的多个制品库组合起来，对用户暴露统一的地址，这样用户就不需要配置多个仓库地址，组合后只要访问group类型制品库，就可以访问组合的所有仓库。 Nexus Repository Manager仓库管理分为专业版和oss版，其中oss版是免费的，只提供了对制品常规的存储功能，而专业版提供了安全扫描、高可用以及用户权限等高级功能，所以专业版肯定也是收费的。 大部分情况下，oss版本已经足够日常大部分的需求，除非对高可用有特殊需求的团队才有专业版的需求，不用太在意收费版本的问题。 HarborHarbor是存储和分发Docker镜像的企业级Registry服务器，也支持Helm仓库，由VMware开源，所以是不收费哒，但是由于Harbor是多个开源项目整合而成的一个私有仓库解决方案，所以安装以及维护上成本要高于Nexus。 Harbor的主要特点有下面几点： 基于角色的访问控制：通过"项目"进行组织管理，一个用户可以对多个镜像仓库在同一命名空间里有不同的权限； 镜像复制：镜像可以在多个Registry实例中复制（同步）。尤其适合于负载均衡，高可用，混合云和多云的场景； 图形化界面：用户可以通过浏览器来检索当前Docker镜像仓库、管理项目和命名空间； 整合了两个开源的安全组件，一个是Notary，另一个是Clair，其中Clair是容器安全扫描工具，它通过各大厂商提供的CVE漏洞库来获取最新漏洞信息，并扫描用户上传的容器是否存在已知的漏洞信息，这个对于Devops是至关重要的步骤，防止我们的生产环境有所隐患。 上述几个优势使得Harbor常与k8s结合使用，同时Harbor也提供了Open API的功能, 基于此能力运维开发也可以针对Devops的流程定制更加个性化的需求，所以深受运维开发的喜爱，出场频率也是非常之高。 RegistryDocker Registry是一个轻量级、无状态、高度可扩展的制品库管理程序，也是Docker官方推荐的私有库管理服务，虽然有官方打广告，但还是掩盖不住功能单薄，无法作为真实企业级服务的基建。 抉择大多数中小研发团队会选择Nexus，毕竟满足的制品库类型非常多，可以满足大部分技术与业务场景，而且对于前端来说连带着NPM包管理也整合了，还是一个非常通用性的解决方案。 如果有足够的运维能力、有准备自己实现Devops并且发布体系基于k8s的话，也可以尝试使用Harbor来管理制品。 从学习、搭建以及使用成本上来说，Docker Registry都是最低的，但同时它能提供的功能也是最少的，如果团队对制品的管理需求并非很复杂很高或者没有专门的运维协助管理的情况下可以尝试使用。 综合下来，如果我是运维的话，我会首推Nexus，毕竟我也是一个不想折腾的人，有一个通用性的解决方案可以节约很多心力。另外与Jenkins一样，Nexus也是Java体系的，出现问题的话，本身需要对服务端知识体系了解更多的后端同学可以给予一些帮助（但愿吧）。 当然除了上述三种之外还有其他的制品库方案，本文只是列举了这三种罢了，具体还是需要结合与自身的业务情况来选择最合适的。 安装制品库对于前端来说，Nexus与Harbor的安装过程都非常繁琐，虽然Nexus提供了Docker版本的安装，Harbor也提供基于dockers compose的安装，但是两者后续的配置以及遇到一些问题解决起来都有一定的成本。 所以安装示例就选择最简单的Docker Registry来演示了。 第一步：运行以下命令下载registry镜像： dockerpullregistry:2 #下载docker容器 第二步：下载完毕后，运行下述命令启动项目 dockerrun-d-v/opt/registry:/var/lib/registry-p5000:5000--namemyregistryregistry:2 #启动容器依赖 浏览器输入http://192.168.160.88:5000/v2/链接，得到如下结果即可代表正常启动。 image.png第三步：运行构建命令docker build -f ./Dockerfile -t 192.168.160.88:5000/devops:0.0.1 .，示例是之前的Devops的例子，大家可以使用前两章的Vue镜像的例子。 image.png第四步：输入上传命令 $dockerpush192.168.160.88:5000/devops:0.0.1 顺利的话会出现如下上传界面： image.png上传完毕之后，在浏览器重新打开http://192.168.160.88:5000/v2/_catalog，一般正常的操作之后可以看到如下界面，此时代表devops镜像已经正常上传了： image.png如上是docker registry的简单使用，它也支持认证、https安全传输等特性，更多的功能可以从官方文档中获取，本章就不再过多阐述了。 从上述可以看出Registry的安装过程比前两种简单太多，但同时能提供的功能也就非常有限，只能做到对于镜像的常规管理，如果作为一个Demo的项目或者小团队内网使用的话可以使用，但为了后期的功能拓展，还是建议使用上述两种。 FAQNexus 3.x使用Docker安装会不断重启？如果之前已经玩过devops的话，遇到这个情况应该会自然想到使用Docker模式安装 GitLab 的情况，都是由于项目启动内存不到导致，启动内存不错报错导致反复启动或者链接超时等情况。 如果是低级的服务器例如2g内存的话，建议更换更高配的服务器，如果本地电脑连接的话，建议调整Docker的内存使用上限。 自建的制品库使用了Https协议后拉取或推送镜像异常？这个问题主要是自建的仓库服务没有正经的CA证书，如果有正经的CA证书也就不存在这个问题。当出现了In the case of HTTPS, if you have access to the registry's CA certificate这种问题提示的话，可以通过添加docker/daemon.json文件的以下属性来解决： { "insecure-registries":["yourIp:5000"] } 如果使用的是Docker Desktop，那么在可视化窗口的设置里面修改配置项后会自动重启，其他安装方式修改完配置项后需要手动重启Docker。 image.png不过从成本角度考虑，内网服务其实不需要认证的CA证书也行，或者配置一个免费的CA证书即可（免费的CA证书通常需要一年更换一次，要求不高可以使用）。 写在最后在后续学习dockers compose后，还是会专门介绍Harbor的安装与使用，所以大家不需要太担心缺失部分学习的模块，毕竟在目前的工程化体系中，从兼容性、学习成本以及通用性上，k8s还是非常有竞争力可以尝试使用的，而Harbor与k8s从配合上还是非常契合的。 所以整个专栏的学习链路我会尽量保证不会有任何缺失的环节，希望专栏完成之前，技术的迭代速度可以稍微缓缓，年纪大了学起来也累了。 后续大家可以持续关注【前端全栈之路】专栏，会持续更新前端视角能够接触到的全链路非前端的知识体系。当然在全栈体系中，肯定会有些技术深度不够的情况，如果有遇到讲解不够清楚或者个人理解有偏差的情况，大家可以留言指正，及时修改避免误导有需要的读者。 阅读原文