挑战虚拟存储库的极限

我们最近的2015年开发者和DevOps趋势调查显示，使用Docker的人也会使用额外的技术．我告诉你一个小秘密。这在一般情况下是正确的，而不仅仅是与Docker相关。绝大多数开发人员同时使用几种不同的技术。因此，大多数人(如果不是全部的话)都接触过不同的打包技术，并理解它们需要解决依赖关系并部署工件。现在，对于每一项技术，它都以不同的方式实现。例如，在Maven和Gradle中，您可以为部署和解析配置不同的端点。相反，一些较新的工具(如Npm)有一个内置的假设，即您正在使用它们的中央存储库，因此它们假设您使用相同的URL进行解析和部署。

现在，Artifactory的典型场景是您解析来自本地和远程存储库的依赖项(包括每种打包技术对应的“官方公共”存储库)，并将您自己的工件上传到本地存储库。但我们问自己，我们如何才能提供更好的用户体验?为什么我们必须向所有开发人员公开这些信息，并让他们使用不同的存储库来配置他们的构建工具以进行解决和部署?好吧，那些日子已经过去了。Artifactory现在通过允许您将工件部署到虚拟存储库来隐藏所有这些细节。

还记得虚拟存储库吗?

对于任何包类型，Artifactory允许您定义虚拟存储库，这些虚拟存储库聚集了多个相同类型的本地和远程存储库。例如，假设您的系统中定义了以下Docker存储库:

• docker-local
  一个本地Docker存储库，您的开发团队将在其中部署他们开发的Docker映像。
• docker-hub-remote
  代理Docker Hub的远程存储库。
• docker-virtual
  聚合的虚拟Docker存储库docker-local而且docker-hub-remote．

任何熟悉Artifactory的人都知道可以从任何本地或远程存储库通过虚拟存储库解析Docker映像．这就是虚拟存储库的作用。它们隐藏了解析依赖项的详细信息，使管理员无法根据需要自由地添加或删除底层存储库。到目前为止，还没有什么新消息。

有什么新鲜事吗?

现在，您还可以将包部署到虚拟存储库。这意味着开发人员只需要知道解决和部署工件的一个URL，因此他们只需要一个URL来配置他们的构建工具。这是一种便利。当您考虑到您的虚拟Docker存储库现在已经完全成熟时码头工人注册表，下一个便利级别是必须为Docker配置反向代理时。在这里，只需要一个URL就可以让本地DevOps人员的工作更轻松。

但还有更多。在幕后，Artifactory管理员还可以更改目标存储库，修改包含和排除模式以实施安全策略，或者更新底层存储库的权限以实现访问限制。所有这些对开发人员来说都是隐藏的，他们只需要推送和拉出图像，而不用担心所有这些细节。

它是如何工作的?

在你的虚拟存储库配置，只需指定虚拟存储库聚合的一个本地存储库作为部署目标。就是这样。

现在，您的虚拟存储库不仅可以从可能解析依赖关系的位置进行管理，还可以管理部署工件的位置。您的开发团队需要知道的就是这个虚拟存储库。所有其他细节都隐藏起来了。