Artifactory 仓库架构和命名最佳实践（上）

Posted 2020-11-05

背景

为公司设计正确的仓库命名规范是至关重要的。为产品开发创建正确的仓库结构，在产品扩展性方面发挥着至关重要的作用。它不仅可以减少创建管理仓库的开销，还可帮助团队意识到仓库规范管理的好处，帮助组织内部各个团队清楚的了解软件交付物的命名规范。

使用 Artifactory 作为仓库管理平台，将所有不同类型的二进制文件存放在一个地方，并将企业级功能完全集成到软件开发生命周期中。

软件开发涉及到不断更新和迭代的过程。 通过参与产品开发的各个团队，以最高精度维护仓库结构成为该过程的重要任务之一。 我们面临的挑战是，没有清晰的命名约定或创建仓库结构的指导原则可以遵循。

JFrog 建议使用四部分的命名结构，其中包括：

1. Team —— 产品或团队名称作为项目的主要标识符

2. Technology —— 使用的技术，工具或包的类型。

3. Maturity —— 软件包生命周期，例如开发，测试和发布阶段。

4. Locator —— 定位，工件的物理拓扑。

此结构会生成以下推荐的仓库命名结构，该结构应在整个公司中使用：<Team> - <Technology> - <Maturity> - <Locator>。

其他准则适用于四种不同的 Artifactory 仓库类型，包括：本地，远程，虚拟和分发。 本地仓库命名约定由两部分组成。第一个是存储的文件是你们自己的，第二个是第三方的。 远程仓库是 Artifactory 拓扑的一部分，它们的命名规则应与本地仓库定义的规则保持一致，或者如果是提供给其他人使用的，建议给它们稍微不同的命名约定。虚拟仓库是对外透明的，封装了内部细节，所以不需要定位器结构字段。最后重要的一点是，分发仓库支持多种技术类型，通常以“-Dist”结尾。

为仓库设置命名约定时，需要考虑的三个主要类别是：安全，性能和可操作性。

当使用 Artifactory 作为仓库时，最好的做法是在仓库级别管理安全权限。这样公司中不同的团队将会管理不同的仓库。

性能问题因技术而异，为了确保仓库效率最高，应该执行清理策略。此外，在仓库结构中应用的可操作性应考虑效益问题以及团队结构。尽管管理员偏好较少的仓库，但有时创建单独的仓库，并具有不同的读/写/删除权限，以防止团队间的彼此干扰是最好的方式。

本文涵盖的所有这些考虑事项将使你能够在全球拓扑中管理你的 Artifactory，并为安装了企业版 Artifactory 的公司提供所需的 DevOps 支持。

使用仓库管理平台

JFrog Artifactory 是为加速开发周期而创建的通用二进制仓库管理平台。这意味着它不仅是一个仓库，而且还是一个功能强大的管理平台，有助于管理多个仓库以简化分布式软件开发流程。

在为仓库定义准则和约定时，灵活性优于严格的规则。创建弹性的规范能够为 Artifactory 管理员提供足够的空间来根据需要量身定制规则。

命名约定和仓库结构是同样重要的。选择合适的名称和用一个仓库还是多个仓库一直是棘手的问题。选择的组织结构应该与你们现在的开发，测试，部署和分发流程一致，这一点非常重要。这里所描述的命名约定和组织结构主要基于当前主流的流程，但可能并不适用于所有公司。然而，希望你可以使用这里列出的组织和命名中的注意事项来将其适应于你自己的命名约定。

创建命名约定

公司通常需要处理在多个仓库中产生的多种技术，生命周期和产品。当你有不止一个产品的时候，你需要给它起个名字。作为开发人员，在过去的几十年里，我们已经了解到一个名字可以清晰地表明你正在做什么。

JFrog 认为最佳实践应该包含以下四点：

最佳实践1：定义生成可用 URL 的仓库名称。例如，由于 Artifactory 是区分大小写的，所以建议使用小写字母。更重要的是，避免在你的环境中使用需要 URL 编码的字符，例如”_”字符。通过简化 URL，这将使你的 Artifactory 实例的最终使用者以及管理反向代理和负载均衡的管理员更容易理解和使用。

最佳实践2：所有编码人员都熟悉的：self documenting code! 尽可能确保你的仓库名称是自描述。虽然是一个描述字段，但是当仓库名称清晰时，它使事情变得更加容易。

最佳实践3：Artifactory UI 界面搜索展示的问题。你的仓库名字的描述应该放到首位。通过这样做，在应用过滤器选项之后，将根据名称组件的重要性在 Artifactory 树型浏览器中将相似的仓库放在一起。

最佳实践4：要注意一些特殊的规则。例如，有一些特殊字符（'/'，'\\'，'：'，'|'，'？'，'*'，'''，'''，'<'，'>'' ，'+'，空格）应当被禁止。名称最多可以包含64个字符，远程仓库可以包含58个字符。还有一些保留的和不推荐的名称，如'Repo'和'Trash'。附加单词'-Cache'也被认为是保留的，因为它主要用于为远程仓库自动创建缓存。

仓库命名基础结构

JFrog 推荐一个四部分命名结构，最好是按以下顺序。

1.产品或团队

产品或团队名称是项目的主要标识。你可以根据企业命名约定选择缩写。例如，一些组织喜欢使用产品缩写而不是使用整个产品名称。另一方面，有些人更喜欢使用团队名称和产品名称。主要的想法是选择一个与你的团队相关且容易理解的名字。

例如：JFrog

为命名约定选择团队/产品名称的粒度级别是开发命名约定中最困难的部分之一。这将在本文后面的仓库组织部分进一步讨论。但是，由于存在虚拟仓库，这也可以在晚些时候相当容易地更改，所以不要太担心，所以应选择易于理解和一致的东西，并查看它是否适用于你。

2.技术

技术是指工具或包装的类型。Artifactory 是一个通用的二进制仓库管理平台，其核心功能使其能够存储各种类型的包，这些包涵盖了 Maven，NuGet 和 Docker 等技术。每个仓库应该保存同一种类型的二进制文件。

继续上面的示例，例如：JFrog-Docker

在命名约定中加入工具或软件包名称的类型可帮助开发人员识别工件，使其更容易根据其类型进行浏览。在大多数情况下，这将精确反映在创建仓库时选择的软件包类型，但你可以选择更具体。例如，如果你的通用仓库存储视频，则可以选择“Video”一词作为技术类型。其他例子有：使用'Centos'而不是'Rpm'或'Rhel'，'Ubuntu'而不是'Deb'。

3．成熟度

Maturity 指的是软件包开发的成熟度，如开发，测试和发布阶段。包的Promotion 可以在 Artifactory 中以多种不同的方式完成。从较小事件的简单属性标记（例如“通过测试”）到工件已经通过的较多的质量检测，其中工件将从一个仓库移动或复制到另一个仓库。

那么，为什么我们要这样做呢？通常情况下，在传统的开发模式中，当工件改变其状态时，这可能代表了在其成熟度的不同阶段。你可能有一个“ 沙箱 ”，对于在初始提交构建的“ Dev ”或“ Snapshot ” 产生的工件正在由开发人员在他们的办公电脑上进行测试。然后工件将移动到“ Qa ”，“ Preprod ”或“ Staging ”仓库，最后转到“ Release”或“ Prod “仓库。当工件完成时，或者当它触发了保留的某些监管要求时，工件及其可能的所有依赖关系可以移动到“ Archive”。

在 DevOps 中怎么做呢？根据 DevOps 原则，工件不应该传递给新团队，而应该在整个生命周期中由同一团队拥有。从自动化的角度来看，控制状态不是关于公司内的团队，而是基于具有不同权限模型的不同环境，以确保工件不会过早部署。

继续上面的示例，例如：JFrog-Docker-Release

下图说明了一个典型的 Promotion 概念。如果满足质量要求，工件从一个 DevOps 阶段传递到另一个阶段：

4.定位

定位实质上是指你的工件的物理拓扑结构。拓扑中的每个仓库都必须是唯一的。真正本地的本地仓库，意味着它们的内容在本地进行管理/上传，应以“Local”结尾。作为其他地方管理的内容和远程仓库应以其他服务的指示符结尾。

例如，“bj” 可以用于在北京的数据中心管理的工件。为了符合要求，访问外部位置的远程仓库应以“-Remote”结尾。这通常被省略，特别是对于主要的中央仓库，假设用户熟悉“Jcenter”和“Npmjs”作为中央仓库的名称，但是这样的假设可能导致混淆。

使用以下仓库名称完成我们的示例：JFrog-Docker-Release-bj

仓库类型

Artifactory 拥有四种仓库类型：本地，远程，虚拟和分发。本地和远程仓库是真正的物理仓库，而虚拟仓库实际上是它们的集合，用于创建搜索和解决工件的受控域。分发仓库是将数据从 Artifactory 导出到 JFrog Bintray 的特例。

JFrog Bintray 是一个通用的分发平台。它是一个云平台，可让你完全控制发布，存储，升级和分发软件的方式。

本节提供了有关针对每个仓库类型如何应用上述命名结构的指导原则。

命名约定的任何部分在不相关时都可以是可选的，并且四部分命名约定的一般概念可以适用于初始约定中未涉及的其他情况。

1.本地仓库

使用前一节中描述的四部分命名结构，我们可以解决本地仓库命名约定的所有必需注意事项，包括：团队/组织（业务单位或产品），技术，成熟度和定位。正如所讨论的，顺序代表了重要性。JFrog 的建议是：<Team> - <Tech> - <Maturity> - <Locator>，但其他命名方式可能适用于某些情况。

本地仓库有两个基本的使用场景：第一个场景是当你引用与你自己的组织工件相关的工件时。在这种情况下，定位完全基于拓扑考虑。另一方面，团队和成熟度稍微复杂一些，主要取决于所需的仓库数量。团队取决于业务逻辑和权限。成熟度取决于工件的所有权/处置。如果一个 Artifactory 实例专注于部署而不是开发，那么考虑成熟度实际上比技术更重要。但是，优先符合统一的命名约定。

本地仓库的第二个使用场景是用于存储第三方工件的时候。这通常包括一种场景，无论是什么原因，你无法远程代理某第三方依赖源（无论是因为防火墙还是仅仅因为它没有 http 访问权限），或者你正在实施一个白名单。总的来说，在这两种场景下，技术类型结构定义还是一样的，但团队名称应该是指明其来源地的东西; 例如，Tomcat 或 Centos。由于通常还有这些拓扑，所以定位的方式与其他本地仓库的工作方式相同。然而，成熟度现在不是像 Release / Dev 这样的东西，而是反映了工件的信任级别。所以它可能是“Upload”或“Whitelist”。例如，“Tomcat-Mvn-Upload-Local”。如果你使用本地仓库在某个状态下对远程进行快照，则可能是日期。例如，“Centos7-Rpm-Oct2017-Local”。

2.远程仓库

远程仓库分为两类：

一些是 Artifactory 拓扑的一部分，在这种情况下，它们的命名约定应该与本地储存库和四个相关部分的命名约定一致，并且定位指示源储存库被远程访问。

一些是中央储存库。这些是你的工件正在从中依赖的外部仓库，可以通过它们的源 ID 引用，如 JCenter。对于严格的一致性，你可以考虑以下模型，<Center_Name> - <Technology> --Remote，默认的 Artifactory 命名行为使用源。通常，这有助于轻松识别工件。

3.虚拟仓库

大多数虚拟仓库不包含<Locator>，并且由<Team> - <Tech> - <Maturity>组成。在很多情况下，用户不需要知道拓扑实现细节。通常，所有消费和写入都是通过虚拟仓库完成的，而不是本地/远程仓库。这样尽可能多的实现细节可以省略，让用户使用一个众所周知的 URL。此外，尽管本地仓库的成熟度严格限于工件阶段，但对于虚拟仓库，你可能会更多地考虑受众。例如，名称中包含“-Dev”的虚拟仓库指示开发人员应该使用的虚拟仓库。最后，一个常见的使用案例是整个公司使用一个虚拟仓库，该仓库将特定技术的所有仓库（例如 Docker）聚合为解析和读取权限。

4.分发仓库

分发仓库在这个约定中有些异乎寻常，因为它们可以支持多种技术类型，并且通常没有成熟度的区别，因为你只应该分发稳定的工件。一般来说，它们应该以“-dist”作为定位符结束。分发产品的分发仓库应使用以下约定：<productname> -product- <orgname> -dist。更通用的分发仓库应该使用像<ruleset> - <orgname> -dist这样的约定为其配置的规则集的某个名称标识符。如果你的组织不具有多个 Bintray 组织，则这种组织名称可以省略，这是比较常见的。但是，必须将不同的分发仓库分发给不同的组织，并且额外的组织（例如支持开源项目）也不是前所未闻的。有些前瞻性规划不会损失任何功能，这就是为什么它包含在推荐的约定中的原因。

未完。请关注下篇：Artifactory 仓库架构和命名最佳实践（下）