本文为稀土掘金技术社区首发签约文章，14天内禁止转载，14天后未获授权禁止转载，侵权必究！

在之前的章节中，我们一起学习了 Docker 的基础使用以及如何去构建一个生产的 Docker Image。

但是 Docker Image 构建完毕之后一般都是在本地存储，而实际上我们发布的时候，通常需要在另外一台部署服务器上使用，如果是分布式部署的话，那么可能就不止一两台服务器这么简单。

所以本章将介绍制品库的相关知识以及使用，同时从本章开始对于前端同学来说学习难度也会逐步变高但与前端的相关性也开始逐步减弱了。

顾名思义，制品库是用来统一管理不同格式的软件制品的仓库（制品是指由源码编译打包生成的二进制文件，但也有特殊情况需要源码运行。所以无论是否已经完成编译，广义上只要可以直接在服务器或者在某些场景能够直接运行或使用，它都可以归纳于制品）。

与常规的代码或者软件管理仓库不同的是，制品库除了基本的存储能力之外，还提供了版本控制、访问控制、安全扫描、依赖分析等重要功能，由此可见在 Devops 链路中制品库是不可或缺的关键一环。

可能对于不熟悉 Devops 的同学，制品库这个名词比较陌生，但实际中大家都已经在不断的使用了，作为前端同学肯定都使用过 NPM 包来管理通用的功能与工具库，当业务规模到了一定的时候，通常需要针对业务来做一些更多的封装，此时抽取为通用的 NPM 包无疑是一种非常好的方式。但是携带了业务属性的 NPM 包又不能发布到公共的 NPM 仓库，需要搭建一个内网或者私有的 NPM 源，那么这个私有源可以称之为一个制品库了。

通常情况下，除非团队规模非常的小，或者对业务基本没有任何共用的可能性，否则搭建一套属于自己的团队私有制品库都是非常有必要的。

在市面上有非常多的制品库方案可供选择，接下来提供以下几种制品库类型以供参考，大家可以自行对比取舍。

Nexus 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 版本已经足够日常大部分的需求，除非对高可用有特殊需求的团队才有专业版的需求，不用太在意收费版本的问题。

Harbor 是存储和分发 Docker 镜像的企业级 Registry 服务器，也支持 Helm 仓库，由 VMware 开源，所以是不收费哒，但是由于 Harbor 是多个开源项目整合而成的一个私有仓库解决方案，所以安装以及维护上成本要高于 Nexus。

Harbor 的主要特点有下面几点：

基于角色的访问控制：通过"项目"进行组织管理，一个用户可以对多个镜像仓库在同一命名空间里有不同的权限；

镜像复制：镜像可以在多个 Registry 实例中复制（同步）。尤其适合于负载均衡，高可用，混合云和多云的场景；

图形化界面：用户可以通过浏览器来检索当前 Docker 镜像仓库、管理项目和命名空间；

整合了两个开源的安全组件，一个是 Notary，另一个是 Clair，其中 Clair 是容器安全扫描工具，它通过各大厂商提供的 CVE 漏洞库来获取最新漏洞信息，并扫描用户上传的容器是否存在已知的漏洞信息，这个对于 Devops 是至关重要的步骤，防止我们的生产环境有所隐患。

上述几个优势使得 Harbor 常与 k8s 结合使用，同时 Harbor 也提供了 Open API 的功能, 基于此能力运维开发也可以针对 Devops 的流程定制更加个性化的需求，所以深受运维开发的喜爱，出场频率也是非常之高。

Docker Registry 是一个轻量级、无状态、高度可扩展的制品库管理程序，也是 Docker 官方推荐的私有库管理服务，虽然有官方打广告，但还是掩盖不住功能单薄，无法作为真实企业级服务的基建。

大多数中小研发团队会选择 Nexus，毕竟满足的制品库类型非常多，可以满足大部分技术与业务场景，而且对于前端来说连带着 NPM 包管理也整合了，还是一个非常通用性的解决方案。

如果有足够的运维能力、有准备自己实现 Devops 并且发布体系基于 k8s 的话，也可以尝试使用 Harbor 来管理制品。

从学习、搭建以及使用成本上来说，Docker Registry 都是最低的，但同时它能提供的功能也是最少的，如果团队对制品的管理需求并非很复杂很高或者没有专门的运维协助管理的情况下可以尝试使用。

综合下来，如果我是运维的话，我会首推 Nexus，毕竟我也是一个不想折腾的人，有一个通用性的解决方案可以节约很多心力。另外与 Jenkins 一样，Nexus 也是 Java 体系的，出现问题的话，本身需要对服务端知识体系了解更多的后端同学可以给予一些帮助（但愿吧）。

当然除了上述三种之外还有其他的制品库方案，本文只是列举了这三种罢了，具体还是需要结合与自身的业务情况来选择最合适的。

对于前端来说，Nexus 与 Harbor 的安装过程都非常繁琐，虽然 Nexus 提供了 Docker 版本的安装，Harbor 也提供基于 dockers compose 的安装，但是两者后续的配置以及遇到一些问题解决起来都有一定的成本。

所以安装示例就选择最简单的 Docker Registry 来演示了。

第一步：运行以下命令下载 registry 镜像：

第二步：下载完毕后，运行下述命令启动项目

浏览器输入 http://192.168.160.88:5000/v2/ 链接，得到如下结果即可代表正常启动。

第三步：运行构建命令 docker build -f ./Dockerfile -t 192.168.160.88:5000/devops:0.0.1 .，示例是之前的 Devops 的例子，大家可以使用前两章的 Vue 镜像的例子。

第四步：输入上传命令

顺利的话会出现如下上传界面：

上传完毕之后，在浏览器重新打开 http://192.168.160.88:5000/v2/_catalog，一般正常的操作之后可以看到如下界面，此时代表 devops 镜像已经正常上传了：

如上是 docker registry 的简单使用，它也支持认证、https 安全传输等特性，更多的功能可以从官方文档中获取，本章就不再过多阐述了。

从上述可以看出 Registry 的安装过程比前两种简单太多，但同时能提供的功能也就非常有限，只能做到对于镜像的常规管理，如果作为一个 Demo 的项目或者小团队内网使用的话可以使用，但为了后期的功能拓展，还是建议使用上述两种。

如果之前已经玩过 devops 的话，遇到这个情况应该会自然想到使用 Docker 模式安装 GitLab 的情况，都是由于项目启动内存不到导致，启动内存不错报错导致反复启动或者链接超时等情况。

如果是低级的服务器例如 2g 内存的话，建议更换更高配的服务器，如果本地电脑连接的话，建议调整 Docker 的内存使用上限。

这个问题主要是自建的仓库服务没有正经的 CA 证书，如果有正经的 CA 证书也就不存在这个问题。当出现了 In the case of HTTPS, if you have access to the registry's CA certificate 这种问题提示的话，可以通过添加 docker/daemon.json 文件的以下属性来解决：

如果使用的是 Docker Desktop，那么在可视化窗口的设置里面修改配置项后会自动重启，其他安装方式修改完配置项后需要手动重启 Docker。

不过从成本角度考虑，内网服务其实不需要认证的 CA 证书也行，或者配置一个免费的 CA 证书即可（免费的 CA 证书通常需要一年更换一次，要求不高可以使用）。

在后续学习 dockers compose 后，还是会专门介绍 Harbor 的安装与使用，所以大家不需要太担心缺失部分学习的模块，毕竟在目前的工程化体系中，从兼容性、学习成本以及通用性上，k8s 还是非常有竞争力可以尝试使用的，而 Harbor 与 k8s 从配合上还是非常契合的。

所以整个专栏的学习链路我会尽量保证不会有任何缺失的环节，希望专栏完成之前，技术的迭代速度可以稍微缓缓，年纪大了学起来也累了。

后续大家可以持续关注【前端全栈之路】专栏，会持续更新前端视角能够接触到的全链路非前端的知识体系。当然在全栈体系中，肯定会有些技术深度不够的情况，如果有遇到讲解不够清楚或者个人理解有偏差的情况，大家可以留言指正，及时修改避免误导有需要的读者。

有兴趣的同学可以加我微信号：cookieboty，一起学习前端工程化的内容，互相学习，共同进步。