共计 3153 个字符，预计需要花费 8 分钟才能阅读完成。
一、背景
====
制品，artifact，也称为工件，是指在构建或继续集成过程中从源码创立而成的二进制包，而这些二进制包通常是通过赋予其的版本号来惟一定位和治理的。制品仓库，artifact repository，则是存储和治理这些版本化的二进制包，并对外提供检索和拜访办法的应用程序。
制品仓库通常分为地方仓库、企业仓库和本地仓库。地方仓库面向公众凋谢，存储和治理事后构建好的二进制包，通常提供软件开发的各种公共框架和通用工具库，如面向 Java 的 Maven 地方仓库，面向 Docker 镜像的 DockerHub 等。企业仓库则通常位于企业或团队外部，一是缓存并对立治理地方仓库的公共制品供外部应用，以晋升拜访效率并增强监管，二是用于存储和治理企业或团队本身创立而成的各种制品，包含最终交付的利用，或者企业或团队外部应用的公共库等。本地仓库则是构建零碎的缓存，记录构建过程中所需及创立的各种制品，并与地方仓库或企业仓库交互，实现制品在不同仓库之间的传递。
在以后的 DevOps 体系当中，企业制品仓库已成为其中的一个重要环节，除了存储和治理制品之外，还须要和继续集成、自动测试、继续部署，以及治理、审批等各种零碎进行对接和协同，实现信息的集成、共享和流转，从而实现流水线式的继续交付。此外，企业制品仓库也是企业信息安全治理中的重要节点，只有通过平安审计的制品才可能被纳入到企业制品仓库，以实现企业继续交付流水线当中的受信源。
目前世界 500 强中 93% 的企业，寰球共有 5000 家以上的企业都曾经放弃了 Sonatype 的 Nexus 而应用 JFrog 的计划。为什么会是这样？本文依据二者最新的倒退状况，从制品治理的各个角度列出二者的技术现状加以比拟，置信大家可能清晰地失去论断。
二、制品治理的概览比拟
===========
首先，本文从作为企业制品仓库所需的次要技术要求对二者做一个概览的比拟：
从中能够看出，JFrog 的产品反对的语言包类型更为丰盛，高可用、定制化扩大，以及元数据等技术计划更为齐备，而且提供了 Sonatype 工具所不具备的复制同步能力，可能更好的反对跨地区的团队协同。
咱们再从更细节一些的技术点对二者进行比拟，如下图所示：
从中能够看出，JFrog 可能反对代理更多类型的地方制品仓库，并且可能提供 Docker 镜像的分层展现。另外，在制品存储、加强查问等方面，JFrog 也提供了更多的反对。
所以，仅从概览来看，JFrog 无疑比 Sonatype 具备更为丰盛和全面的能力。
三、制品治理的计划比拟
===========
第二局部对 JFrog 和 Sonatype 的产品特点进行了概览的比拟，本节将从二者的计划特点进行更为全面的剖析。
首先来看二者的商业模式，如下图所示：
JFrog 提供了更为灵便自主的试用形式：在本地化部署的根底上，也提供了对于云端和混合云架构的反对，可能适应客户不同的基础架构需要；而且，具备大规模的可扩展性，可能帮忙客户节省成本。
再从部署形式来看，如下图：
JFrog 提供了丰盛、全面、自动化的部署形式，包含面向 Kubernetes 环境的 Helm Chart 编排，不便了产品的部署利用。
再来看可扩展性，如下图：
能够看出，JFrog 可能全面反对企业级利用的扩大需要，并保障其稳定性。
以后的开发环境更多的是团队合作形式，从而要求制品仓库也可能反对跨数据中心、跨城市，甚至跨国的协同工作。二者在团队协同方面的特点如下图所示：
很显著，JFrog 面向多团队、跨地区的协同工作提供了丰盛、全面的解决方案，而 Sonatype 只能反对单数据中心的利用模式。
在以后的 DevOps 体系当中，制品仓库须要可能与继续交付工具链中的其余零碎很好的集成与对接，而从这一角度来看，二者的技术特点如下图所示：
JFrog 全面的 API 笼罩、全功能的 CLI 工具，以及自定义的元数据等能力使得其制品仓库可能不便、全面地和客户现有的环境和工具进行集成与对接，从而不便地建设全面、统一的 DevOps 计划。此外，JFrog 还提供了性能扩大的用户插件框架，反对定制化的二次开发。在这一方面，Sonatype 只能提供无限的反对。
从最根本的制品治理的能力来看，JFrog 是惟一真正的全语言反对，如下图所示：
而从制品的存储形式来看，JFrog 提供了更为丰盛的解决方案，可能适应客户不同的业务需要，从而更大程度地节约老本。如下图所示：
最初，从制品仓库的认证平安管理体系来看，JFrog 提供了更宽泛的拜访、认证形式，以及灵便的权限体系，如下图所示：
综合下面的比拟能够看出，从作为企业制品仓库所需的各个技术层面和细节来看，JFrog 的产品和计划无疑成熟度更高，可能为企业提供更为丰盛、全面、弱小且灵便的反对，而 Sonatype 的产品和计划只能在受限的范畴内提供反对。这也正是目前 JFrog 在寰球商业制品库市场占有率第一的起因所在。
四、DevSecOps 的计划比拟
在当下软件应用的开发过程当中，自研的外部代码所占的比例逐渐地缩小，开源的框架和共用库曾经失去了宽泛的援用。然而，开源软件的大量援用也给咱们的利用带来了安全隐患。据统计，目前 14% 的 NPM 包、30% 的 Docker Hub 镜像都蕴含安全漏洞，而 Maven 包里有 59% 的已知安全漏洞还没有失去修复，而破绽的均匀修复工夫是 290 天，最重大级别破绽的均匀修复工夫也仅是 265 天。因而，提供针对外来制品的平安检测，构建制品受信源，已成为以后 DevOps 体系中对企业制品仓库的重要需要。
要想实现实现及时、精确的制品平安扫描，首先要基于精确、全面的安全漏洞数据库。JFrog 和 Sonatype 应用的安全漏洞数据库状况如下图所示：
可见，在 NVD（美国国家破绽数据库）提供的 CVE（公共破绽和裸露）的根底上，JFrog 还提供了 VulnDB 这一商业破绽数据库。而 VulnDB 提供了更大范畴的安全漏洞数据，如下图所示：
JFrog 和 Sonatype 的平安检测计划都能够与企业的 CI/CD 流水线集成。然而反对的水平还是有所不同的，如下图所示：
从上图能够看出，JFrog 的计划可能笼罩更为宽泛的 DevOps 的链条，从而将传统的 DevOps 过程扩大成为 DevSecOps，这也是业界以后的倒退方向。
JFrog 的计划可能在 DevOps 的各个阶段提供安全漏洞监控方面的反对，如下图:
而且，JFrog 的计划还可能将安全漏洞的监控扩大到研发或生产过程中。JFrog 提供的 KubeXray 可能在 Kubernetes 的运行环境中检测并解决 POD 的安全漏洞问题，如下图:
而通过与 IDE，如 IntelliJ IDEA、Eclipse、Visual Studio 等的联合，JFrog 使得开发人员在开发过程中就可能时刻关注和理解利用的平安情况，从而实现平安扫描的左移。如下图：
除了发现制品的安全漏洞之外，JFrog 还提供了针对安全漏洞的精准定位和影响范畴剖析的能力，使得安全漏洞的发现和修复更加精准和全面。如下图:
综上所述，JFrog 是目前可能惟一提供端到端 DevSecOps 反对的企业制品仓库产品，除了提供最残缺的商业破绽数据库外，JFrog 的产品和计划还惟一实现了安全漏洞的跨语言品种的深层次精准定位和影响范畴剖析。
五、总结
企业制品仓库已成为企业建设 DevOps 体系的重要环节，除了根本的制品存储与治理外，还须要可能与 DevOps 全链条实现对接与集成，并提供安全漏洞扫描与监控，建设企业可信源，从而实现残缺的 DevSecOps 解决方案。
通过本文的比照和剖析能够分明地看出，JFrog 的产品和解决方案无疑是更为全面、更为丰盛、更为灵便、更为弱小的抉择。
** 欢送观看 JFrog 杰蛙每周二在线课堂，点击报名：
https://www.bagevent.com/even…**