用例——前500万是最难的:思科是如何从0个工件发展到500万个工件的

讨论转录:

好的。大家好。谢谢你来听我的演讲，看看我们是如何在一年内从一百万件增加到五百万件，仅仅依靠五个工程师。

但在我们开始之前，我想简单介绍一下我们是什么，我们做什么，以及我们在思科的发展动态。

我属于全球建筑与技术服务组织。这个也开着吗?我这里有一个。大家都能听到我说话吗?所以就像我刚才说的，我们属于思科的GATS全球架构和技术服务部门，我们所做的是为工程师和工程师提供服务，比如工具服务——这并不意味着我们不是工程师——但思科的工程部门是一个团队，负责开发思科推向市场的真正产品。hth华体会最新官方网站

我的名字是Prathibha Ayyappan，我已经在思科工作了，这是我的第5年了，这是我的第4年了，我最初是一个Java全栈开发人员，所以我们仍然在做这个，但我也专注于CI/CD工具。我们的团队叫做Build Management Services，我们为工程师提供CI/CD工具和服务，所以我们有Jenkins, Artifactory, SonarQube, Bamboo, Coverity这是我们现在做的五个，然后我们会不断增加。

就像我说的，我们的目标受众是整个工程界。我不知道这是不是件好事，但思科的一个优点是没有简单化的方法，没有走一条特定路线的硬性规定。每个团队都有做任何他们想做的事情的灵活性。因此，我们与想要与我们合作的团队合作，然后一旦我们有了成功的故事，我们就回到那些不想与我们合作的团队，让他们加入我们。

这些截图是上周的。这是我们的人工制品大师这边所以我们有八百二十万件左右的人工制品。我们在主端有1200个本地存储库。我们这些数字不是很清楚，但这里的图表显示，在一个时间框架内，我们收到了近1000万个请求，大约在4月6日，我们收到了1000万个请求。只是总下载和上传到我们的人工服务器。

我们有近330个下载请求和30个或5820万个上传请求。这就是我们操作的Artifactory实例的规模。而这些数字，至少，至少这个调查是针对圣何塞站点的，它甚至不是原始数据。这些也是来自圣何塞的。这只是Artifactory的一个例子，这就是我们的安装和服务有多大。

所以今天我要讲的是如何做到这一点或者说我们是如何走到这一步的。因为我们刚接触这个产品，而且这个产品也相当新。所以如果你想,如果你想运行Artifactory作为服务——我知道我一直说一些你的观众,你想做类似的方式在你的公司,所以很高兴有熟悉的面孔,如果你的目标是零停机,不中断服务,因为当开发人员开发和他们想上传和下载,依赖,他们甚至不想把工件,你知道,十秒钟,十,你知道,即使是一分钟的停机时间。所以如果你的目标是为你的客户达成那种服务水平协议。如果你想拥有全球影响力。我知道EMC，彭博社，这里的很多公司他们在全球都有业务所以如果你有开发人员在美国以外的地方工作，如果你想为他们建立网站如果你只是想创新，做一些新的事情。而不是像一个典型的IT团队那样，人们去创建案例，然后你有一个支持团队，一级，二级，三级，最后它来找你，然后你可能应该看看我们正在努力做什么。

让我们回顾一下历史。我们做了什么?我们从哪里开始?所以这就是Nexus的例子，有人用光了纯粹的善良。他是一名开发人员，他只是为几个组织维护它。它有将近500g的数据他受够了维护它所以他想找人来接手我们开始了我们的CI/CD团队。所以我们觉得现在是开始接手的好时机。但是我们不想做那些在那之前已经完成的事情，所以我们对市场上所有的工具进行了筛选，然后Artifactory出现了，所以我们在Artifactory和Nexus之间进行了筛选，我们选择了Artifactory，原因很明显，Artifactory支持更多的工件类型，而不仅仅是Maven和Gradle的构建。所以当我们在2014年开始的时候，它确实得到了Yum的支持，这对我们来说很重要，因为你们都知道，思科是一家做嵌入式开发的公司，rpm是创建的主要产品，所以Yum的支持和Artifactory对我们来说很重要。所以我们走了人工路线。

我们先做什么。这就是我们的建筑第一扇门。我们的团队来自RDP，北卡罗来纳州的罗利-达勒姆地区我们在那里有一个工程数据中心所以我们安装了一个独立的人工工厂。因此，如果您看到我们有一个与应用程序服务器通信的Apache代理，那么CEL 6.2就是我们的操作系统。它是红帽Linux的一种风格，在它上面有一些思科的能力。所以Tomcat有文件，2tb的文件，如果你看到它只有2tb，但这就是我们开始的方式，也许这很好，因为500gb, 2tb是巨大的。然后我们连接到一个Oracle，当时它是[…]所以不是12C。这就是它看起来的样子，一切都很好，至少我们认为是这样的，然后我们意识到我们的大多数工程团队都在圣何塞工作。RDP，他们仍然认为性能不是很好如果他们试图从RDP上传和下载我们最初迁移的Maven。Cisco。com实例不是圣何塞的所以他们马上就知道性能滞后。

这就是我们的架构第二题。幸好Artifactory有完整的复制支持，所以你可以做一个应用级的复制，我们做了同样的事情，我们在圣何塞建立了一个站点。我们把圣何塞作为我们的中心所有的用户都开始去圣何塞我们开始用我们的TP作为我们的VR实例。

所以我知道这很落后，但我们首先建立了我们的VR实例，这就是一切的开始。但这是我们的第二点，我们意识到，如果圣何塞宕机，我们必须手动将我们的更改代理故障转移到RDP服务器，而这不是自动化的。然后我们在思科内部找到了一个团队他们提供一种叫做全球站点选择器的产品作为一种服务这是思科自己开发的产品但基本上它做的是它做DNS，地理定位和故障转移配置所以如果你配置GSS在故障转移模式下工作它会立即知道如果网站宕机，它会自动故障转移到另一边。

我们这样做了，然后我们就得到了一个真正的解。我们有一个主站点，我们有一个DR站点，我们有运行良好的GSS，我们在故障转移模式下进行了测试，它运行良好。

这就是我们的建筑作品，我们对此非常满意。但后来我们意识到思科是一家全球性公司，来自班加罗尔、以色列、格林公园和世界其他地方的人都觉得我们的服务不太好。只有美国客户感到满意。

所以我们必须这样做。基本上我们建立了两个新站点，还是Artifactory，我们有一个代理，它有一个应用服务器，它有一个Oracle后端。所有这些都是一样的，但是我们再次使用GSS，全局站点选择器，来进行地质负载平衡，所以如果有人试图使用来自世界其他地方的Artifactory实例，他们将不会被定向到主站点。我们还需要稍微转换一下url。所以我们的主站有了一个新的URL，我们的全球站点有了另一个URL，所以我们使用了两个URL。这是我们的第四步。这是最新的。我们仍然只有这四个主要网站，我们希望在未来增加，但这些是我们的主要。

但是去年我们不得不两次故障转移到RDP，因为Oracle的升级，一旦文件经历了中断或类似的事情，然后因为我们那时人们使用它很多，我们花了几个小时从RDP复制回圣何塞。这并不容易，我的意思是，我们是一家网络公司，但是，你知道，有很多事情只有网络才能做。数据中心只有这么多带宽，所以如果你要复制十万件文物，这将需要一些时间。如果你今天早上去听了任务控制中心的演讲，我想[…]几乎提到过，把所有的东西复制回来可能需要几周的时间。所以，这对我们来说并不总是理想的，因为我们只有一个节点，如果发生了什么事情，我们就必须总是故障转移到RDP，然后在全国范围内复制。

这就是我们的建筑现在的样子。我们在圣何塞有两座大楼，它们在不同的地方，所以它们在技术上属于同一个数据中心，但它们仍然是不同的建筑，它们属于不同的网络机架，所以总的来说，我们的系统管理员非常理解，如果是计划中的停机时间，他们不会一次把所有东西都关掉。我们所做的就是利用这一特性，然后利用Artifactory HA，为Artifactory设置了另外两个节点，它们位于不同的建筑中。我们还有两个HA代理站点，服务器位于不同的建筑中，它们使用ACE负载平衡器进行负载平衡，基本上是在故障转移模式下工作，所以重点是我们不想有一个单点故障。只是说。因此，如果我们的HA代理服务器关闭负载平衡器，ACE负载平衡器将自动故障转移到其他HA代理。如果我们的一个节点坏了，我们仍然没事，因为我们还有另外两个节点还在工作。我们在两个NAS之间安装了一个快照计，就像[…]，如果你从2太字节看到，我们现在是50太字节。但现在就是这样。因此，如果一个文件出现故障，我们可以与存储团队一起打破快照表，我们仍然可以将数据推送到另一个文件。

我们现在唯一的单点故障是我们的数据库。我们正在与数据库管理员合作，你知道，给我们更多。它是一个类似USC P2的类，它有HA，所以如果数据库所在的BM本身出现故障，它们会自动移动它。但如果他们做任何数据库，这些升级都是补丁，那么我们就有一个单点故障，我们必须失败到RDP。

确定。是的。[…]复制和Artifactory是从圣何塞到RDP，这只是一个文件备份，甚至不是备份，它就像一个硬备用，因为如果我们必须，如果这个文件坏了，我们可以打破快照计，我们不必让整个网站瘫痪。

[…]是的，我接下来要讲这个。

[…]是的，我接下来要讲这个。

好吧。看起来不错。这就是我们现在的情况。

就像我说的，在班加罗尔有一种类型，在格林公园和圣何塞也有一种类型，你可以看到所有的交通，比如从拉丁美洲到圣何塞。从东海岸到圣何塞的所有东西都去了，因为虽然RPT站点是真实的，但这是我们的DR站点，没有人真的去那个站点，这就是重定向的工作方式。如果格林公园瘫痪了我们所有的流量都会转到圣何塞如果圣何塞瘫痪了我们所有的流量都会转到RDP。

好吧。那么，回到你的问题:我们如何设置读透缓存、复制和所有有趣的东西?

所以我们现在可以读整个主设置作为我们的抽象但基本上我们所做的是每一个写从格林公园或班加罗尔，我们的任何全球站点，他们会被直接复制到本地存储库和主。他们真的不关心它是圣何塞还是RDP主因为他们可以完全抽象它。我们要做的就是建立读透缓存。如果您知道Artifactory图标的外观这些是本地存储库，这些是远程存储库，虚拟存储库聚合了本地和远程存储库。基本上，我们所做的是严重依赖远程和虚拟存储库的支持。

因此，我们创建远程存储库，从虚拟组中提取数据，这是主服务器的虚拟存储库，这样我们就不必在所有地方复制所有东西，我们只需将所有内容写入所有站点并将所有内容复制到主服务器，但不必进行远程操作。相反。如果有人想要一个应用于主版本的工件，而这个本地站点上没有，他们可以使用这里的虚拟回购，它基本上会从主版本获得它，然后缓存在本地。

因此，我们必须经常暴露一些问题，因为当我们开始支持部署到虚拟机时，我们的用户总是必须直接部署到本地存储库，但总是必须从虚拟存储库中获取，因为他们真的不知道自己要去哪一边。这是一件事，但这更像是一个用户培训的事情，我们慢慢地解决。我们还在绕过去。但是，如果Artifactory不支持远程和虚拟存储库，那么我们更大的主要问题——更大的问题——将局限于主站点。Yum和Debian就是很好的例子。Docker和[…]就是例子，但我不能再引用它们了，因为它们Artifactory没有为[…]和Docker引入虚拟和远程存储库的支持。但是临时逻辑基本上是基于存储库类型的，所以我们必须确保我们知道团队需要什么样的存储库，我们的供应逻辑完全取决于他们想要什么样的存储库。

我们还有其他挑战。我们的团队不像我在演讲开始时暗示的那样，我们的团队很小，我们做开发，我们基本上建立一些东西，但我们不是支持团队。因此，如果我们的支持团队遇到关于为什么工件不能，您知道，为什么我不能取回这个工件的问题，那么他们需要知道供应逻辑。他们没有权利去创建存储库。

他们没有效率。所以你知道一个开发人员试图运行他的构建或者Jenkins试图运行一个构建但是失败了我们的开发人员不能等两天来基本理解我们的全局设置。

因此，培训、缺乏知识，所有这些都是每个部门面临的挑战，我们也面临同样的挑战。以及实际的手动配置过程。假设我实际上必须在四个站点创建存储库:San Jose, RDP, Green Park和Bangalore。并正确设置复制，设置[…]。例如，如果我只是选中一个框，它会删除所有从主站，因为使用delete[…]。在这种情况下，人为失误的可能性很大，而且需要很长时间。我们实际上做了这个练习，如果我们必须创建Maven存储库，它将花费我们45次点击。如果我们必须创建Debian或Yum存储库，这些只是我们设置复制和设置用户，权限目标，组的主要方式，它只需要25次点击。这是考虑到没有人为失误。如果有人为错误，你必须重做整个事情，记住。

所以这只是生产力的损失，我们的客户也不高兴。在所有。我们试着让它自动化，这就是我接下来要讲的。关于我们如何改变我们的配置时间，哦，顺便说一下，如果我们使用Docker，那么我们也有额外的部分来做Apache配置，所以如果你知道Docker配置是如何工作的，每个节点都有自己的主板。除非你有自己的子域来做不同的Docker存储库，我们可以做到这一点，因为每次你必须创建自己的子域，你必须得到你的请求[…]。这比仅仅给它们提供不同的Apache端口要耗费更多的时间。所以，这是额外的工作量。所以我们也手工做了这个练习。我们的Docker配置过程耗时90分钟。提供一个Docker存储库需要一个半小时。

PyPI, NPM, Yum和Maven也做了同样的事情，虽然没有花90分钟，但却花了将近一个小时来设置所有的东西。不好玩。所以我们所做的就是建立一个[…]，基本上，让一切都自动化。这是我们的伪任务控制中心。这是在任务控制中心出现之前。所以我们想要做的是我们想要自动化供应编排。我们构建这个应用的方式它完全是基于插件的所以你可以。目前假设Jenkins Artifactory SonarQube如果我们在未来添加Bamboo支持那么我们就可以把它插入系统。您在这里看到的是我们的Artifactory存在，这是我们的伪[…]版本，这是我们在DMZ中的Artifactory实例，所以我们可以，我们可以通过使用一个应用程序自动提供所有这些实例。

这就是我接下来要演示的。有什么问题吗?

好吧。这些只是一些截图。但基本上我们所做的是，我们都是Java开发人员，所以我们坚持使用Java。我们坚持使用Spring框架。我们有一个AngularJS前端。我们大量使用REST api，然后我们有一个服务层，它基本上负责清理、验证和供应。我说过，所有这些API客户端都是可插拔的。因此，如果我试图调用Artifactory实例，那么我将使用Artifactory客户端。

我们也有一个Oracle数据库与它一起工作，这样我们就把我们的帐户管理数据库作为我们的事实来源。所以我们确切地知道是谁提出了请求，谁想要仓库。当你在一个庞大的组织中工作时，这是很有意义的，因为你想要跟踪哪个业务部门正在尝试与你一起工作，并且只是为了让所有这些都到位，你没有办法拖回Artifactory。我们还想知道哪些团队正在使用我们的所有服务:Jenkins、Artifactory和SonarQube。这对我们也很有帮助。

所以账户管理，我可以自己登录，它有LDAP集成。就像我说的，我们有客户和团队，所以我们为他们创建记录，进入数据库，这样我们就知道谁在尝试使用我们的服务。然后我们有了服务层，我将详细讨论，因为这样更有意义。

还有访问管理，因为我是管理员，我可以看到所有这些，管理功能。但如果你只是一个用户，你不会看到所有这些，你会看到的是与你的账户绑定的服务。因此，如果你是属于物联网的客户，比如思科目前正在尝试的最先进的东西，即IODR，那么你只会看到属于你的服务。你能做的，我们能做的基本上是Artifactory中的管理员让你成为账户管理中的管理员，而不需要实际解释Artifactory是如何工作的，Artifactory是如何配置的，你可以为你的团队自动配置你的存储库。我们在后台有自助api。

如果你是一个用户，你想做一个Artifactory服务，你只需要输入一个名字，我使用swampup，你可以填写需要访问的用户，你可以输入，我们会给你一个默认的雇主ID。这主要是针对那些需要像普通用户一样运行Jenkins构建的帐户，或者你不想暴露你的真实[…]凭据。我们可以给出一个通用ID，这很简洁。这是在数据库中跟踪的，所以我们可以为你检索它，或者如果你忘了，你可以去更改它。

你可以这样做，你可以把你的主机添加到repose。你可以创建rest，你可以看到我们支持不同的类型，你可以看到它是Maven，如果是Yum，你可以看到你是否想自动计算元数据，你可以告诉你的元数据需要多大的深度。你可以以后再改。如果你不希望你的元数据是3。你也可以创建Docker存储库，它会自动提供Apache。我们还有这个简洁的文档告诉你你的url应该是什么，你需要如何获取依赖项，你的BON文件里有什么这也是依赖的它取决于你要提供什么样的存储库。

然后你就可以进入虚拟组改变你的虚拟组的配置。因此，如果您希望在虚拟组中聚合另外两个托管仓库，您可以这样做。这就是我在这里所做的。如果你关心这个，你也可以拉入一些远程存储库。然后你只需点击ok并提交，然后等待几分钟。但是我们有一个很好的记录系统。我们也有审计追踪。每次有人试图更新存储库，或者任何—整个服务器—您都将确切地知道更改了什么以及谁更改了它。这对跟踪很有用。一旦我们保存，你也可以修改我们的服务器，就像我说的，如果你愿意，你可以添加需要访问存储库的新用户，你完全可以这样做。

那么我们学到了什么?我们节省了很多时间。我们节省了近1800个小时，你知道，不做手动配置，不进入[…]站点，不犯人为错误。账户管理只需要两分钟，而不是90分钟。这对我们来说是很大的生产力提升时间就是金钱所以我们为思科赚了一些钱，至少我们是这么认为的。

这也是我们的使用率增长——用户增长——所以你知道，从接近100个用户到4500个账户管理用户，这表明，你知道，我们做得对，他们喜欢使用它。他们不需要对Artifactory做任何事情，他们不需要了解Artifactory，他们可以得到自己的存储库。

所以未来——在我谈论未来之前——我只是想先说一下，这一切之所以成为可能，只是因为Artifactory有很棒的REST api。我们在内部所做的就是使用REST api。

但是Artifactory现在有了任务控制，所以我们要调查，制作原型，然后整合。我知道我们不能完全摆脱账户管理，因为我们仍然想要跟踪客户和团队以及所有这些东西，所以我们要做的是删除API客户端部分，这样我们就不会与Artifactory集成。相反，我们将与任务控制中心整合，然后我们将有所有的逻辑来进行供应，任务控制中心将创建今天早上向我们展示的组，所以我们将有一个主组，然后，当然，他们有DR，然后我们会正确地配置全球站点，然后我们可以有一些东西，有存储库供应，以及如何配置存储库，然后可能只是从帐户管理中与任务控制集成。这就是目前的计划。

问题吗?