跨站点扩展DevOps的最佳实践

你好。各位来自世界各地的来宾，早上好，晚上好，下午好。我叫肖恩·普拉特，是你们友好的JFrog营销经理。在我们开始今天的展示之前，我想回顾一下一些日常用品。本次会议将被录制并提供给您，通常在我们今天结束后的一两个工作日内。如果您有问题，请将它们放入聊天功能中。它应该在屏幕的底部或左侧。我们会有人在这里为你回答这些问题，Rakesh会在这节课结束时现场回答一些问题。提醒一下，您今天在这里参加的网络研讨会是关于跨不同站点扩展DevOps，所带来的挑战以及如何解决它们。今天加入我们的是Rakesh Krishna，他是JFrog经验丰富的DevOps专业人士和解决方案工程师。 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.

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

而且，整个JFrog平台可以无限扩展，这意味着对于存储库的数量、用户的数量以及您可以存储的数据量没有任何限制。我们可以继续存储，而且扩展得很好。这就是为什么我们的许多企业客户喜欢并使用JFrog的原因。我们也有混合和多云的存在，这意味着您可以在您自己的数据中心或您自己的云提供商区域发布我们的任何JFrog产品。hth华体会最新官方网站或者你也可以基本上拥有我们在三家流行的云提供商中所提供的SaaS服务。这正是我们支持混合云和多云的方式。我们是通用的，这意味着我们支持30多种不同的软件包类型。因此，目前使用的所有流行的包类型都得到了JFrog的支持。

我们基本上也集成了任何特定的持续集成工具，市场上任何流行的持续集成工具，这就是为什么我们可以普遍地集成任何持续集成工具，你可以在你的常规持续集成/持续集成工作流程中使用。下面让我们快速了解一下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更新，以及监控所有这些不同的物联网设备。接下来是pipeline，这是我们的CI/CD编排工具，它可以帮助你编排从版本控制系统到部署端的所有任务集。最后但并非最不重要的是，我们还有任务控制，它给你一个单一的窗格，你可以在多个地点进行所有不同的部署，洞察是一个给你一些指标的窗口，你可以在JFrog平台的所有不同部署中收集一些见解。这是JFrog对整个平台的一个简短的概述。

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

这就是Artifactory能够帮助您引入一些集中化和标准化的原因和方式，也是Artifactory能够为您公司内不同团队之间进行的所有不同开发活动提供单一事实来源或记录系统的原因。由于它支持30种不同的包类型，所以当你与Artifactory交互时，所有包特定的本地注释，比如npm特定的注释或Docker特定的注释，都可以通过npm客户端或Docker客户端很好地使用。这就是你在构建过程中引入自动化的方法构建自动化必然意味着你的构建速度越来越快，明白吗?这就是自动化给你带来的好处。

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

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

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

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

说了这么多，让我们来看看今天的情况。首先，每个人的分布越来越多。当我说“每个人”时，我指的是团队、团队成员、开发人员、经理等等。它们都是分布的。当我说分布的时候，我指的是地理上分布在不同的地方。这可能有几个原因。首先，有些公司确实在多个地点设有办事处。他们在多个地方都有团队。如今，团队成员越来越偏远，因为人们搬到了偏远的地方，尤其是在2020年开始的COVID期间。所以这种现象仍然存在，因为所有的团队成员都越来越分散。 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,反之亦然,这也意味着,只要团队2需要的东西是由团队1,这是在美国,因为这些工件是在美国开发的可就没有在美国和欧盟地区的本地团队2在哪里,他们基本上必须联系美国团队正在使用的注册中心，这意味着他们必须跨越大陆，跨越大西洋，通过网络下载所有必要的人工制品，这本身就带来了一些挑战。

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

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

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

我们称之为传统类型的复制，这两种类型是推和拉。我们继续往下看。推送复制，顾名思义，是源所做的事情，即源推送将工件从源复制到目标。因此，在这种类型的复制中，需要在源端配置复制。一旦配置完成，无论何时有一个触发器，触发器意味着无论何时有一个用户预先设置的时间表，或者无论何时有一个触发复制的事件，这里的事件可能意味着一个新工件的简单上传，例如。

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

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

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

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

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

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

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

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

这里是我列出的几个好处。因此，企业完全可以跨多个地点协作开发软件。就像我说的，这正是JFrog平台使用联合仓库帮助您跨多个地点扩展团队的方式。这就是你如何让频繁上传的二进制文件在不同位置间同步的方法。假设你的Team 1不断向一个特定的二进制文件推送新的更新，比如，推送新的版本。因此，所有这些新版本或新更新可以很好地在不同位置同步，因此，所有最新的更新或任何二进制文件的最新版本将立即在其他有人工联合正在进行的位置可用。这就是你如何在全球范围内扩展你的开发和你的开发团队。这是一个非常活跃的趋势，我们现在看到了很多很多客户。

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

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

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

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

太棒了。谢谢Rakesh，你带领我们了解了组织如何在不影响生产力和效率的情况下更好地进行扩展。我们收到了一些问题，我认为你们最好回答一下。提醒大家，你们也可以提出任何问题。我们有专人在线回答这些问题，如果我们没有回答，我们肯定会在网络研讨会结束后与您联系。Rakesh，有一个问题是如果一个组织使用复制，他们应该如何选择推式还是拉式?

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

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

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

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

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

明白了。

DR需求也是一样，因为DR对于大多数企业级公司来说是一个非常非常重要的因素。他们需要有一个适当的DR计划，作为他们DevOps工具集的一部分，Artifactory的DR选项基本上是在一个遥远的位置或另一个位置拥有Artifactory的另一个实例。因此，如果主实例发生故障或由于任何原因无法访问，他们仍然可以在安全位置的故障转移实例上随时获得所有工件。

太好了，谢谢你。最后一个问题，因为时间快到了，我们的目标是30分钟左右，与传统复制相比，使用联邦回购有什么优势?您已经提到，您可以使用传统的复制来实现相同的目标，但是联合存储使它更容易一些。你能详细说明一下吗?

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

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

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

绝对的。

太好了。太棒了。酷。就这样，我们要结束这次网络研讨会了。拉凯什，非常感谢你以一种非常简洁和方便的方式带领我们完成这个过程。我要感谢今天在座的每一个人。如果你有任何问题，你可以在最后一刻在聊天中提出，或者你可以随时联系我们JFrog。我们非常乐意与您讨论您的DevOps需求，以及我们如何帮助您使其更顺利。再次感谢大家，我们期待下次再见到你们。

谢谢大家。见到你。