运维自动化基础建设|企业级工件库选择和搭建

运维自动化基础建设|企业级工件库选择和搭建

相信大家接触比较多的可能是本地YUM源的建设工作，本地YUM源建立好之后给我们带来的收益相信不用我多说，大家都是比较认可的，那么接下来的文档我们来聊聊企业里常见、常用的工件库都有哪些。文档中所列工具基本都支持Docker部署，我就不实地演示了。

搭建内部工件库(私服)能给我们带来什么

•加速CI/CD的响应，减少等待•避免关键代码泄漏（站在安全角度）•为规范化建设提供基石•统一管理依赖•工件的生命周期的管理

业内主流的工件库

头部的两个

•Sonatype Nexus[1]•标级通用制品库管理平台-杰蛙[2]

其他的

•npm专用的•sinopia•Verdaccio•cnpmjs•docker专用的•Harbor•docker Registry•composer专用的•packagist•satis•Toran Proxy•python专用的•pypiserver•R专用的•other

如何选择

杰蛙

杰蛙分社区版和商业版，社区版支持的包管理较少，如果公司项目选型是基于全Java语言的话，用杰蛙的社区版基本能覆盖需求，如果是涉及到多语言，JAVA,PHP,Nodejs等多语言的场景下，杰蛙的社区版可能就有些捉襟见肘了，话说回来，杰蛙的商业版并不是每个公司都能承担得起的。下图我贴上对比大家可以看下

PS: 如果真的能够购买商业版，企业内部一站式DevOps基本能解决一大半了，试用了下这个东西，是真的强大，尤其是组件(工件)生命周期管理这一块。

Sonatype Nexus

其实Nexus也是有社区版和商业版，与杰娃不同的是，Nexus的社区版功能也足够强大，足以满足80%以上的场景需求，各种包管理的支持也可以通过官方的或三方的插件来实现。

接下来我们来重点聊聊 Sonatype Nexus

为什么选 Sonatype Nexus， 我们碰到了什么疼点呢？

•站在OPS的角度来看，每个语言维护一个工件库，成本有点大，尤其是在Docker还没有那么普及的场景下，部署起来也是一个成本•每一个工件库都要专门写一个对应的文档，广而告之大家这个工具应该怎么使用•维护多套域名映射到不同的工件库上•RD查询包信息的时候可能需要登陆多个平台进行操作（比如同时写PHP和JAVA的RD）•并不是每个工件库都能提供完善的基于角色的账号管理体系，账号的维护也是一个不小的问题•元数据分布在各个节点，需要二次汇总•CI/CD或CMDB和各工件库的对接都要来一遍，加大工作量•还是有些场景下存在git submodule来实现依赖的管理

我们用 Sonatype Nexus 的场景

包管理这一块的实现

•mvn包管理支持•composer包管理支持 （需插件支持）•npm包管理支持•python包管理支持•go的proxy支持•yum包管理支持•自定义包上传

其他功能

•基于LDAP的认证•和CI/CD集成

个人感受

开始的时候确实如前文所讲，针对每个包管理工件进行了专用的工件库的搭建操作，由于各种原因，维护起来并不是很轻松(非单纯的维护机器或应用的可用性)，要协助答疑和排障工作，接触到Nexus之后，真的是解救了我们，单个入口实现多语言的工件库实现工作，而且和CI/CD的对接工作相对来说轻松了很多，Nexus提供API接口供用户操作。

另外一个层面就是从之前维护gitlab代码库组作为被依赖的组件改成由Nexus托管之后，工程化建设工作又向前迈了一大步。

TIPS

当前GITHUP和Gitlab也已经具备了工件库的功能，相信这块在大厂的参与下未来会更好，为企业的NoOPS赋能～

遗憾的是，Nexus页面访问确实有点慢，另外就是工件生命周期管理这块社区版并不能很好的支持，要不然人开什么企业版～

总结

工件库的建设的目的在前面也有描述，更多的是能为我们后续的CMDB的元数据规范和工程化建设提供一个良好的基石。敬请期待后文

引用链接

[1] Sonatype Nexus: https://www.sonatype.com/ [2] 行标级通用制品库管理平台-杰蛙: https://www.jfrogchina.com/