突破虚拟存储库的极限

我们最近的Developer and DevOps Trends 2015调查显示，任何使用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管理员还可以更改目标存储库、修改包含和排除模式以执行安全策略，或者更新基础存储库上的权限以实现访问限制。所有这些对开发者来说都是隐藏的，他们只需要推拉图像，而不用担心所有这些细节。

它是如何工作的?

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

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