跨站点扩展DevOps的最佳实践

你好。早上好，晚上好，下午好，来自世界各地的各位。我叫肖恩·普拉特，是JFrog公司友好的市场经理。在我们开始今天的演讲之前，我想先回顾一下一些日常事务。这个会议将被记录下来，并提供给你们，通常在我们今天结束后的一到两个工作日内。如果您有问题，请将它们放入聊天功能。它应该在屏幕的底部或左侧。我们会请人来回答你的问题，拉凯什会在这节课结束时现场采访一些问题。提醒一下，你们今天在这里参加的网络研讨会是关于在不同站点上扩展DevOps，提出的挑战，以及如何解决它们。今天加入我们的是Rakesh Krishna，他是一位经验丰富的DevOps专业人士，也是JFrog的解决方案工程师。 So without any further ado, I’m going to go ahead and hand it over to Rakesh so he can get us started. Rakesh, take it away.

非常感谢Sean的精彩介绍，欢迎大家。早上好，晚上好，无论你在哪里。今天的主题是跨站点扩展DevOps的最佳实践。就像Sean提到的，我叫Rakesh，是JFrog解决方案工程组的一员。让我们开始吧。简单介绍一下JFrog公司本身。所以JFrog提供了一个DevOps平台，这是真正的端到端。端到端，因为我们可以帮助您解决一大堆需求或用例，从您的工件构建开始，一直到您的工件实际部署时的部署端。除此之外，我们还关注持续的安全性，因为我们相信安全不应该是事后才考虑的事情，而应该以自动化的方式成为常规CI/CD工作流程的一部分。所以我们确实做到了。

此外，整个JFrog平台的规模是无限的，这意味着没有限制，也没有存储库的数量，用户的数量，你可以存储的数据量的任何限制。我们可以继续储存，而且比例很好。这正是我们的许多企业客户喜欢和使用JFrog的原因。我们也有混合和多云的存在，这意味着您可以在您自己的数据中心或您自己的云提供商地区发布我们的任何JFrog产品。hth华体会最新官方网站或者你也可以采用我们在三家流行的云服务提供商中的任何一家提供的SaaS服务。这正是我们支持混合云和多云的方式。我们是通用的，这意味着我们支持30多种不同的包装类型。因此，目前正在使用的所有流行的包类型都得到了JFrog的开箱即用支持。

我们还集成了基本上任何特定的CI工具，市场上任何流行的CI工具，这就是为什么我们可以普遍地集成任何CI工具，你可以在你的常规CI/CD工作流中使用。下面是JFrog提供的DevOps平台的简要介绍。正如你所看到的，我们的平台上有很多产品。hth华体会最新官方网站让我们一个一个地来看。让我们从Artifactory开始，它是整个JFrog平台的基石。您可能知道，Artifactory是可以用来存储和管理所有工件的产品。当我说所有的工件时，我指的是您在公司内部开发的工件，以及您通常从外部引入的第三方依赖项，这些依赖项是在进行构建时进行依赖项解析时提取的。

所以这两种类型的工件都可以很好地存储在Artifactory实例中。1秒。是的，除此之外，我们还支持超过30种不同的包类型，所有流行的包类型，比如npm, Docker, Java, Python, Newgate，等等，Artifactory都支持开箱即用。因此，无论您的团队使用什么不同的包类型，或者您的开发人员在您的公司内部使用什么不同的包类型，您都可以让他们使用Artifactory来满足他们所有的工件管理需求。我们的下一个产品是Xray，这是我们的安全产品，它可以帮助你以一种自动化的方式引入安全，基本上通过启用一些安全和许可兼容的实践。Xray确实与Artifactory合作或互补，因为Artifactory是一种产品，你可以用来存储你的工件，同时你也可以使用Xray来确保你在这里存储的东西也满足所有的安全性和许可基准，你可以在你的公司。

所有这些都是自动完成的，不需要任何人工干预。这是关于x射线的简单介绍。下一个是JFrog Distribution。顾名思义，分发是关于分发您在Artifactory实例中已经拥有的工件，以便它们接近您的运行时环境或生产工作负载可能所在的位置。所以你的运行时环境在哪里并不重要，它可以在你自己的数据中心，也可以在你的公共云上，甚至可以在你的物联网设备上，所以Distribution这个产品可以帮助你让你的工件非常非常接近这些目的地，这样你就可以有你的部署工具，从Artifactory下载适当的工件，然后在它们的目的地上部署它们。我们还有JFrog Connect，这实际上是我们去年刚刚完成的收购的一部分。

这是一个真正的项目，我们可以帮助您为物联网设备配置空中或OTA更新。因此，这基本上可以帮助您管理所有物联网设备，配置OTA更新，以及监控所有这些不同的物联网设备。接下来我们有管道，这是我们的CI/CD编排工具，它可以帮助您编排从版本控制系统一直到部署方面的所有任务集。最后但并非最不重要的是，我们还有任务控制，它为您提供了一个单一窗格的玻璃视图，您可以在多个位置进行所有不同的部署，而洞察是一个为您提供一些指标的人，根据这些指标，您可以收集一些关于JFrog平台所有不同部署的见解。这是对JFrog整个平台的简要介绍。

现在让我们把注意力转移到Jfrog Artifactory本身的主要产品上，因为这就是本次网络研讨会的其余内容。这是Artifactory提供的一系列好处。就像我说的，它基本上是一个通用的二进制存储库管理器，这意味着它为您的二进制文件或工件提供存储库，以便您可以继续将所有这些二进制文件存储在一个位置。而且它在本质上也是通用的，这意味着它支持近30种不同的包装类型。所以就像我之前提到的，所有流行的包类型，如npm, Docker, Java, Python, Go, Ruby，所有这些都得到了很好的支持，它不仅为你提供了本地开发的工件，而且还提供了通常在公共注册表中可用的远程依赖项。这些东西可以缓存在您的私有Artifactory实例上，这正是普适性方法发挥作用的方式。

这就是为什么以及如何Artifactory可以帮助您引入一些集中化和标准化，这就是它如何作为一个单一的真相来源或记录系统，用于您公司内部不同团队之间可能发生的所有不同开发活动。由于它支持30种不同的包类型，当你与Artifactory交互时，所有特定于包的本地注释，如npm特定注释或Docker特定注释，都可以通过使用你的npm客户端或Docker客户端很好地使用。这就是你如何为你的构建引入一些自动化构建自动化必然意味着你使你的构建更快，对吧?这就是自动化给你带来的好处。

就像我之前说的，不管你使用什么CI工具，它可以是Jenkins, GitHub Actions, GitLab CI，或者其他什么，我们肯定可以将任何这些CI工具与Artifactory集成，这样你就可以自动化你的构建，这样你的构建就可以通过提取依赖项以自动化的方式进行。一旦构建完成，所有这些构建的所有输出都可以推回Artifactory。这给我们带来了下一个好处，那就是自动化肯定会让你的构建更快，Artifactory也会让你的构建更可靠，因为你可以在你的私有Artifactory实例中缓存所有必要的依赖。因此，即使公共注册表关闭或由于某种原因仍然无法访问，您的工件或依赖项仍然是非常可用的，因此您的构建可以毫无问题地继续进行。它还提供了对各种类型元数据的支持。

只要您上传一些新的内容，例如时间戳、上传的用户等等，Artifactory就会自动生成一些元数据，用户还可以提供他们自己的自定义元数据，我们称之为用户提供的元数据。所有这些元数据对于搜索、排序、过滤等用例都非常方便，例如，这将使您能够在下游执行任何自定义工作流。下一个好处是，就像我说的，你可以使用Artifactory和Xray来确保安全和许可控制，通过启用或定义一些策略，所有这些事情都会自动发生，只要有东西发布或缓存到Artifactory实例中。最后但并非最不重要的是，Artifactory还支持多站点需求以及灾难恢复需求，这实际上是今天网络研讨会的主题，所以我们将在后面讨论这个问题。

这是Artifactory提供的所有不同好处的快速列表。说到这里，我们确实看到用户使用一些通用的存储解决方案，如S3存储桶或共享网络驱动器，甚至是谷歌驱动器来实现工件存储目的。现在这很好，但只是这些东西不能提供Artifactory提供的好处，因为就像我说的，这些是通用的存储解决方案，不是专门为工件本身的需求而设计的，因为您基本上会失去为构建引入自动化的机会，因为这些通用存储解决方案不讲任何这些包类型的本地语言。所有特定于数据包的网络命令对于任何这些通用存储解决方案都是无效的，因为您不能引入任何构建自动化。

因此，当没有自动化的时候，很明显你会让你的构建变得更慢，而且也缺乏可靠性，因为这些存储解决方案没有缓存所有必需的依赖关系的概念，而Artifactory做到了。这就是为什么无论何时运行构建，这些构建基本上都会去上游存储库，比如公共注册库。然后从那里下载工件以解析依赖项。如果由于某种原因无法访问，那么您的构建基本上就会失败，或者需要更长的时间才能完成。这正是Artifactory所提供的好处，因为它可以支持预先缓存所有必需的依赖项，这样您的构建就不必在每次运行构建时都要访问公共注册中心。这就是Artifactory提供的一些好处。

说了这么多，让我们来看看今天的情况。首先，每个人的分布都在增加。当我说每个人时，我指的是团队、团队成员、开发人员、经理等等。它们都是分布的。我说的分布，是指地理上分布在不同的地方。这可能有几个原因。首先，有些公司确实在多个地方设有办事处。他们在多个地方都有团队。如今，团队成员越来越偏远，因为人们搬到了偏远的地方，尤其是在2020年开始的新冠肺炎期间。所以这种现象仍然存在，因为所有的团队成员越来越分散。 And along with that, there’s also the other side of things that is the runtime environments, the production workloads, servers, all these things are again very much distributed as well.

这主要是因为现在的公司正在为越来越全球化的用户群或客户群服务，而且由于业务需求，他们基本上必须在云提供商上跨多个地点、跨多个地区进行部署。这正是生产工作负载、服务器和硬件跨越多个位置的方式。以上就是关于当今环境的简单介绍。现在，鉴于我们有了所有这些东西，所有这些团队成员都被分发了，这也把我们带到了两个不同的场景，这就定义了今天网络研讨会的问题陈述。让我们一个一个地考虑这些情况。让我们以一个场景为例，该公司的开发团队分布在多个地点。

假设团队1在美国，团队2在欧洲地区。我们还说,有跨团队依赖这两个开发团队之间,正在开发的意义,让我们说什么是团队需要1团队2,反之亦然,这也意味着,只要团队2需要的东西是由团队1,这是在美国,因为这些工件是在美国开发的可就没有在美国和欧盟地区的本地团队2在哪里,他们基本上必须接触到美国团队正在使用的注册表，这意味着他们必须跨越大陆，跨越大西洋，基本上通过网络下载所有这些必要的工件，这本身就带来了一些挑战。

首先，这可能会影响性能因为潜在的网络延迟问题可能会出现因为位置之间的距离可能会导致构建需要更长的时间才能完成，或者如果网络真的坏了，或者如果它不那么可靠，基本上构建会失败因为没有向下的网络访问。这是情形一。场景二是灾难恢复需求。灾难恢复的定义是指需要对被管理的数据有某种冗余。在本例中，由于我们谈论的是工件存储和工件管理，工件管理的灾难恢复意味着我们基本上需要为所有被存储的工件以及所有这些工件的元数据提供冗余。因此，这种冗余以及我们将在主实例由于任何原因宕机时带来一些业务准备，因此切换或故障转移可以在影响很小的情况下发生。

这是我向你们展示的两种不同的情况。所以在早期，我们只看到团队和生产工作负载越来越多地分布在多个位置。此外，我们刚刚看了两个不同的场景，其中有两个不同的团队在不同的位置，有跨团队的依赖关系，还有一个灾难恢复单元。因此，鉴于这两种情况，您如何保持所有这些DevOps实践或工作流或交付彼此同步?你如何确保DevOps的交付始终是同步的，这显然是你脑子里的一个问题。这就是我想向你们介绍Artifactory支持的复制概念的地方。您可能知道，根据定义，复制意味着将工件或任何数据从一个位置复制到另一个位置。

由于我们在这里专门讨论工件，因此在本例中，复制意味着将工件从位于位置1的实例1复制到位于不同位置的另一个实例。现在让我们以一个公司为例，该公司在两个不同的地点有两个不同的团队。因此，JFrog如何支持这样的公司是通过要求位于不同位置的每个团队在每个位置都有一个自己的Artifactory实例，例如实例1位于位置1，实例2位于位置2，以便位置1的团队1可以与实例1交互。类似地，位置2中的团队2可以与实例2交互，Artifactory提供的复制功能将负责将所有必要的工件从一个位置复制到另一个位置。现在，正如您在幻灯片上看到的，Artifactory支持两种不同类型的复制。顺便说一下，这两种类型一直都存在。

我们称之为传统类型的复制，这两种类型是推式复制和拉式复制。我们从1开始。推送复制，顾名思义，是源所做的事情，即源推送将工件从源复制到目标。因此，在这种类型的复制中，需要在源端配置复制。一旦配置完成，只要有一个触发器，触发器意味着只要有一个由用户预先设置的计划，或者只要有一个触发复制的事件，这里的事件可能意味着一个简单的新工件的上传。

所以每当触发发生时,源基本上把复制元数据以及实际工件本身从源到目标,一旦完成了工件复制到目标,团队在2号位置,可以与目标交互实例并获得所有必要的工件从实例而不是一路跨多个位置或一路在距离位置访问另一个实例,这可能会再次带来一些潜在的延迟问题。类似地，还有另一种类型称为拉类型。这种复制的最终目标也与推类型的最终目标完全相似，即将工件从一个位置复制到另一个位置。只是运作方式不同而已。

所以在pull类型中，复制配置是在目标站点上完成的。所以每当有一个触发源,触发器,再一次,意味着一个时间表已经设立的用户或一个活动发生的像一个新的工件上传操作,例如,所以每当这个触发发生在源,源基本上通知目标的新事件,然后目标将基本上达到回源和把所有的新更新,其中包括工件以及元数据从源。这就是工件复制如何确保新的工件在目标上也是可用的。

一旦完成了这一点，很明显，就像我前面说的，位于位置2的团队2可以很好地与目标实例交互，这样他们就不必跨越各个大陆，例如，访问由位于遥远位置的不同团队开发的特定工件。这就是应用程序的全部内容，这些是我们多年来一直使用的传统类型。说了这么多，我们现在有了一个全新的功能，称为联合存储库，这基本上是另一种类型的存储库。现在，这个存储库联合概念是最近才引入的，我想是去年的某个时候，它使事情变得更加简单和方便，特别是在涉及双向复制时。

正如您在本例中所看到的，有三个不同的位置，并且在三个不同的位置有三个不同的Artifactory实例。一个在旧金山，顺便说一下，你可以看到它是在一个数据中心里自己托管的。还有两个例子，一个在伦敦，一个在印度的班加罗尔。它们都托管在AWS区域、欧盟西部和孟买代理上。正如您所看到的，有一个名为npm-local的单一存储库在所有三个位置中都被使用。一旦在所有这三个回购之间建立了联合，所发生的事情是，每当在旧金山实例中上传新的东西时，相同的工件及其元数据将立即复制到其他两个位置。

类似地，无论什么时候新的东西被上传到伦敦实例，以类似的方式，相同的工件和它的元数据将被复制到旧金山和班加罗尔实例，这正是这三个实例相对于这三个存储库总是彼此同步的方式，因此如果有一个团队在美国，这个团队可以很好地与这个旧金山实例交互，从一个离他们很近的位置获得所有最新的工件。类似地，印度的团队可以很好地与班加罗尔实例进行交互，并从那里获得所有准备好的工件，而不是穿越整个地球再次访问旧金山实例，因为这两个位置之间的距离，可能会出现一些延迟问题，这正是性能大幅提高的原因，构建更加可靠和快速地进行。

顺便说一下，这种方式的可扩展性非常好，这就是为什么我们的大多数企业客户都在使用它，因为他们中的大多数人都在多个国家、多个地点拥有团队或办公室。这正是存储库联合概念帮助所有此类团队实现所有此类用例的方式。类似地，同样的事情也可以用于灾难恢复需求，其中您可以将此作为您的主实例。假设这是DR或故障转移实例。因此，一旦建立了联合，这里正在进行的所有活动或所有上传都将自动复制到另一个实例，因此所有工件都是随时可用的，因为复制带来了冗余。

当或如果主实例由于某种原因宕机，您可以立即将所有工作负载或所有使用转移到完全位于不同位置的故障转移实例，这就是它仍然处于运行状态的原因，可以说，它可以继续以非常非常小的业务影响继续构建。因此，这就是Repository Federation概念如何帮助您跨多个位置复制工件。这是另一张幻灯片，它更详细地讨论了相同的联邦存储库。就像我之前解释的那样，它基本上是Artifactory上的另一种回购类型，它将帮助Artifactory的不同实例始终保持同步。这也使得多站点双向复制成为可能，就像我在幻灯片中展示的那样。我们在三个不同的地点发现了三个不同的病例。所以这是多点的，而且是双向的。就像我说的，在旧金山发生的任何事情都会自动转移到其他两个城市，反之亦然。

而且使用起来非常简单方便。我之所以这么说，是因为使用传统的推式和拉式复制，这种双向复制也是非常可能的。只是你基本上在每个地方都要处理不止一次的回购。因此，随着不断引入越来越多的位置，基本上会在每个位置添加越来越多的存储库，这显然会变得很麻烦，这就是为什么联合存储库将帮助您以一种更容易和方便的格式实现相同的目标，因为基本上每个位置只需要处理一个存储库。

这是我列出的一些好处。因此，企业绝对可以跨多个地点协作开发软件。就像我说的，这就是JFrog平台如何使用联邦回购来帮助你在多个地方扩展你的团队。这就是如何在不同位置之间频繁上传二进制文件的同步。因此，假设您的团队1不断向特定二进制文件推送新的更新，比如说，通过推送新版本。因此，所有这些新版本或新更新可以很好地在不同地点同步，以便所有最新的更新或任何二进制文件的最新版本将立即在其他有Artifactory联盟的地方可用。这就是你如何在全球范围内扩展你的开发和你的开发团队。这是一个非常活跃的趋势，我们现在有很多客户。

不用说，他们都非常喜欢使用联邦回购，因为这帮助他们非常非常容易地达到这个最终状态。这正是我们如何将存储库联合的相同概念用于您的DR或灾难恢复需求。就像我在前一张幻灯片中说的，你基本上可以让实例一作为你的主实例，让实例二作为你的DR实例。Federation将负责使工件在多个位置之间成为冗余，以便在主实例由于某种原因发生故障时可以切换到故障转移实例。这是关于存储库联合的简单介绍。现在，Repository Federation肯定会为工件数据或工件元数据带来冗余。另一个问题是不同的安全实体呢?当我说到安全实体时，我指的是不同的用户、用户组、为每个用户或用户组配置的权限、API密钥、访问令牌等等。他们怎么了?

我之所以这么认为，是因为从平台管理员的角度来看，当管理员为特定实例上的用户或用户组设置权限时，所有这些权限仅在该实例上有效。因此，如果同一家公司在多个位置有多个实例，那么所有这些权限在所有其他实例中都将无效。它仍然仅对该实例有效。这是情形一。场景二是从最终用户的角度或者从开发人员的角度来看，假设开发人员正在使用特定的API键与特定的实例交互。现在，再一次类似于权限，由特定实例给予特定用户的API密钥仅对最初给予API密钥的特定实例有效。现在，如果同一个用户尝试或想要访问另一个实例，他或她拥有的API键就无效了，因为API键是特定于实例的。

这意味着当特定用户想要与实例2交互时，用户基本上需要另一组API密钥，例如，由第二个实例给出。因此，随着使用随着不同实例的增加，规模也随着需要从最终用户的角度管理的不同API密钥的增加而增加。因此，为了帮助解决所有这些挑战或痛点，我们有了一个叫做访问联盟的东西，顾名思义，它将访问信息联合起来。当我说访问信息时，我指的是安全实体，如用户、组、权限、令牌、API密钥，等等。因此，使用Access Federation，管理员基本上可以在单个实例上配置权限，然后他们基本上可以在属于同一联邦的所有其他实例之间联合相同的权限集。

类似地，从开发人员的角度来看，同一组API键可以有效地用于属于同一联邦的任何其他实例，这样当他们想要处理位于不同位置的多个Artifactory实例时，就不必处理多个API键。这就是Access Federation的作用，基本上就是让安全实体在多个站点之间保持同步。它还支持从单一位置管理安全实体，而不必在多个位置一次又一次地重新配置。因此，这就是Repository Federation如何帮助联合工件以及工件的元数据。Access Federation将帮助您将访问信息主要与安全实体进行联合。因此，这正是我们帮助您在多个站点扩展DevOps的方式。今天的网络研讨会到此结束。非常感谢。我很乐意回答你们的任何问题。

太棒了。谢谢，Rakesh，你带我们了解了组织如何更好地扩大规模，而不会在整个开发组织中出现问题、挫折和对生产力和效率的不利影响。我们有几个问题，我想你们最好回答一下。提醒大家，你们也可以提出任何问题。我们的工作人员会在线回答这些问题，还有任何我们没有回答的问题，我们会在网络研讨会结束后与您联系。Rakesh，有一个问题是如果一个组织使用复制，他们应该如何在推式方法和拉式方法之间做出选择?

问得好，肖恩。所以，推和拉基本上会帮助他们达到相同的最终状态，也就是把工件从一个地方带到另一个地方。不同之处在于推送类型，当有单个源和多个目标时，例如，由于正在进行的推送复制是由源管理的，如果有多个目标，显然源是负责所有繁重工作的人，因此工件不仅可以推送到一个目标，而且可以推送到已经建立的多个目标。而在拉复制的情况下，拉复制是目标自己做的事情。因此，从源的角度来看，源基本上可以将大量这样的单独复制责任委托或卸载给每个目标，这样它就不必自己完成所有繁重的工作。

太好了。太棒了。谢谢你。还有一个后续问题。您在演示中提到Artifactory支持30多种不同的包类型。对于所有这些包类型和所有这些不同的包存储库，复制是否可用?

是的,当然。我们在Artifactory上支持的所有30种类型都肯定具有复制，因此无论何时它们在不同站点上有多个实例，都可以轻松地设置复制。复制可以在存储库级别设置，而不是在实例级别设置，这意味着假设一个特定实例有数百个存储库。例如，一个用户或一组用户很可能选择仅为10个存储库设置复制，以便只有这10个存储库将被复制到另一个实例。

太棒了。太好了。所以在你分享的内容上有很多细粒度的控制。Rakesh，另一个问题是你认为JFrog的客户现在如何使用这种复制?

客户如何使用复制?是的，这是一个非常流行的功能或特点，正在使用中，肖恩。就像我说的，在演讲的早期，我们确实有很多企业客户。事实上，大多数财富500强公司都是我们的客户，几乎每个公司都在使用我们的复制功能，因为几乎每个公司都有团队，分布在多个地点，多个国家，多个地点。因此，一些公司通常一开始只是在一个位置上有一个实例，但随着规模的扩大，随着团队的扩大，他们立即感到需要在不同的站点上有更多的实例。这就是当他们利用复制的时候，这样团队就不需要跨越地球来访问在遥远的位置上的东西。

明白了。

DR需求也是如此，因为DR对于大多数企业级公司来说是一个非常非常重要的因素。他们需要有一个适当的容灾计划，作为他们DevOps工具集的一部分，Artifactory的容灾选项基本上是在一个遥远的位置或另一个位置有另一个Artifactory实例。因此，如果主实例宕机或由于某种原因仍然不可访问，他们仍然会在故障转移实例上的某个安全位置上有所有可用的工件。

太好了，谢谢。最后一个问题，由于我们的时间已经接近了，而且我们的目标是将这段时间保持在30分钟左右，使用联邦回购与传统复制相比有什么优势?您曾提到，您可以使用传统复制实现相同的目标，但联邦回购使其更容易一些。你能详细说明一下吗?

当然,当然。这是个好问题，肖恩。传统的复制方法，也就是推和拉，默认情况下，你需要单向复制，也就是说，如果你在源和目标之间建立了一个复制，一个推类型的应用程序，源始终是源，目标始终是目标。在双向复制的情况下，需要做的是建立第二个复制，其中目标成为源源成为目标。因此，基本上在每个位置处理两个不同的存储库。

总共有四个，两个在源端，两个在目标端。因此，联合回购带来的区别是，所有联合存储库复制默认情况下都是双向的，这意味着一旦跨不同的存储库，跨不同的位置建立了联合，它默认是双向的，这意味着您不必在每个位置处理多个存储库。如果你在这里有一个，在实例2中有一个，这是双向的意思是这里发生的任何更新都会被带到另一个位置，反之亦然。所以它基本上让事情变得更简单和方便。

太好了。这很有道理。更少的工作，更少的维护对于管理实例的人，诸如此类。

绝对的。

太好了。太棒了。酷。好了，我们就到此结束本次网络研讨会。拉凯什，非常感谢你简明扼要地告诉我们这些。我要感谢今天到场的每一位。如果你有任何问题，你可以在聊天的最后一分钟提出，或者你可以随时在JFrog上联系我们。我们非常乐意与您讨论您的DevOps需求，以及我们如何帮助您使之更顺利。再次感谢大家，我们期待下次再见。

谢谢大家。见到你。