使用JFrog DevOps部署到Google Serverless

现在,在我进入这两种技术整合,我想很多我们看到在serverless采用空间与构建更现代的应用程序的想法,我不会,但我认为重要的是要认识到,这里的最终目标是让应用程序状态为我们的客户可以更动态、可伸缩、聪明,这意味着采用一大堆更现代的开发实践在整个软件生命周期。

谷歌在这方面已经有很长一段时间了，你可以想象在谷歌的早期，一个数据中心是如何不断被重新配置的。现在，这是一个相对现代的谷歌数据中心布局视图。但是，对于早期的谷歌开发人员来说，他们不断地构建和部署底层硬件，不断地重新配置，这是相当具有破坏性的，所以我们真的需要一种方法来想出一些东西，将数据中心真正地作为一台计算机来部署，而不是组成数据中心的单个服务器。

事实上，我们在谷歌已经使用无服务器模式很长一段时间了，我们已经认识到无服务器基础设施的好处如下。一是我们有快速的自动缩放。一切都是预先配置的，并且是多租户的。不需要获取或保护计算节点。整个系统具有很强的容错性。我们有控制平面的多区域部署。事情是自我修复的，当单个计算机或容器实例变得不健康时，它们会被自动替换。然后还有一整套的支持服务，我稍后会详细讲。

对于这个核心计算基础设施，我们带来了一个非常高能力的连接集，因此它既包括谷歌整体前端系统的全球前端系统，也包括对高级协议的特定支持，如web sockets和gRPC。

现在我们已经把这个核心基础设施的能力，并尝试了几次向公众产品化，这要追溯到2008年，比谷歌云本身的应用引擎早得多。App Engine诞生于高度固执己见的PaaS时代。这是一个高度管理的，包含电池的，完全集成的开发应用程序环境，但它确实受到了需要一些严格约束的运行时参数的意见的影响。所以你只能在里面运行特定的软件和特定的软件栈。

2017年，谷歌云基本上提出了我们对函数作为服务的想法的回应，所以这是在AWS发布Lambda之后，这实际上是一种尝试，以最简洁和最集中的形式来看待开发者合同，开发者只需要提供函数的实际方法，而不是围绕它的所有包装和材料。

然后在2019年，我们发布了我们认为在无服务器领域真正的甜蜜点，这就是无服务器容器的想法，也就是Cloud Run，这就是我今天要花大部分时间谈论的内容。如果我必须用一张幻灯片来总结你对Cloud Run的看法，那就是你用一个容器。这就是Docker通过某种序列化容器格式而广受欢迎的原因，现在被称为开放容器计划，任何OCI容器，都可以直接在Google的基础设施上运行，尽可能少地干预管理。你可以把一个容器交给谷歌。然后谷歌将为你大规模运行它。

现在，当我们谈论容器时，我们通常会用这个词的两种含义来谈论它。第一个是容器的工件。这就是要建造的东西。如果你在使用JFrog Pipelines和JFrog Artifactory，这是工件的管理，它是工件的构建和存储，这是字节，在某种存储系统中，我们谈论它，这是真正的容器映像。

还有容器运行时环境，这是Cloud Run的主要关注点。我认为Cloud Run几乎是一种超级超级的坞站，您可以在运行时将容器工件插入其中，它带来了Google云平台的所有这些额外功能。所以今天我不会一一讲，但是为了让你们对其中的一些有个大概的了解，我将在这里顺时针走一圈。

首先，您在Cloud run中运行的每个服务都被分配了一个独立的工作负载标识，因此这是您的代码运行的标识，可以特别允许访问其他Cloud api。它包括这个内置的前端。所以有一个内置的负载平衡和流量管理。我将在演示中向您展示一些流量管理，但您也可以选择引入谷歌其他负载平衡或产品集以及谷歌云负载平衡器的所有功能。

它内置了日志记录和监控功能，因此无需任何特殊配置或设置即可获得可观察性。然后，您可以通过SQL代理的形式引入其他连接，例如我们的秘密管理器云SQL，它将SQL数据库作为本地套接字公开。您可以将工件外部的环境变量作为部署运行时配置的一部分进行管理。所有这些东西都是可以在容器运行时插入容器的东西。

现在，我们看到Cloud Run被广泛用于各种工作负载。Rest api非常适合Cloud Run。这本质上主要是一个基于请求响应的运行时服务，但我们看到Cloud run在数据自动化和数据工程方面的使用越来越多。因此，能够基于web hook或其他步骤进行编排例如，当新文件被复制到存储桶时所产生的事件这是我将在讲座的最后讨论一些与JFrog平台潜在的集成和自动化。

我们确实在Cloud Run目前部署的每个地区都部署了Cloud Run，所以它是一个全球可用的服务。在Cloud Run中部署的每个服务在部署时都被限制在一个特定的区域，但是您可以将该服务部署为每个区域中服务的本质克隆，然后将它们统一到一个全局负载均衡器后面。

在演示之前，我想先讲一下内置的交通管理，因为我会演示这个交通管理。流量管理的想法是，当你在构建新版本的应用程序时，你想要做一些蓝绿部署，或者金丝雀发布部署，想法是你部署了两个版本的应用程序，以一种方式让你控制一些请求流量的转移。

我们有这样一个场景，我们有当前稳定运行的版本。我们称它为蓝色版本a，然后我们部署一个新的版本B，我们想要开始管理一些流量和切换，就说10个请求中有一个到那个新版本。我们可以这样做，然后监控新的修订，观察任何异常行为，任何通过QA过程的回归，等等。然后我们可以继续将越来越多的流量转移到那个版本，随着时间的推移，让它完全消失。随着Cloud Run的动态扩展，每个修订版都将根据其接收的流量比例进行弹性扩展。让我们来看看这是什么，作为一个演示。

demo中我要做的第一件事是向你们展示如何快速简单地将服务部署到Cloud Run中。同样，没有预先配置。这只是一个项目中启用的API。我要做的是创建一个新服务我要使用一个我预先构建的容器里面有一些定制的工具，来分享更多关于它是如何扩展的。我不打算从源代码使用任何自动部署。这将通过JFrog管道建立。我将把它部署到爱荷华州。这些设置我就不一一讲了。我们有很多。我将允许未经身份验证，因为我不会尝试将此服务置于任何自定义授权之后，并且我现在将在这里更改其中一个设置，这将强制Cloud Run扩展容器的数量。 In other words, I’m going to force Cloud Run to be sort of less efficient in the way it’s handling traffic, just so you can see how our system will scale out. And go ahead and start this up.

我们看到，服务是一个长期运行的东西，由许多修订组成。这将是第一次修订，我们已经有一个功能齐全的HTTPS URL。我们可以看到我们得到了一个基本的[json 00:11:08]响应。现在，我有这个服务的工具，它会显示有多少请求。我把这个拉到视图中，你会看到，这个服务被缩小到0。没有任何交通服务。没有容器在运行。让我们通过运行一点load命令来改变它。我们将向它发送一些流量，大约10秒左右，您将看到这里发生的情况是容器的数量上升，以处理这些流量，当负载测试完成时，我们将立即将所有这些缩减为零，您将看到所有请求都被处理，流量是有管理的，非常有弹性。

现在，我想向你们展示交通分流。正如我提到的，我们有一个蓝色和绿色部署的想法。现在，我们只有蓝色部署。假设我已经在JFrog上运行了我的管道。我造了一个新神器。我已经准备好部署了。我已经在谷歌那边准备好了，准备好了。我将通过改变环境变量来模拟这个过程。在这里我可以编辑这些。我要讲的是变量。 I’m going to change a label to green, and I’m going to uncheck this box, which says, “serve this revision immediately.” What this will do is it will deploy this changed configuration and again, it would likely in a real world, use a different container image and it’s running, but not receiving any traffic. If I go back my main URL here, it still says blue.

我可以在这里做一些事情，给这个一个修订URL这是一个修订特定的URL它不受任何流量管理的约束。如果我保存这个。稍等片刻。再说一次，前端编程是前端网络，不是前端，就控制台而言，但是流量路由的方式更新得非常快。在这里。我可以转到绿色修订的特定URL，看到它是可访问的，但不能通过我的主URL。

我接下来要做的是，再次打开可视化，我将带来一些持续的负载。所以我不只是10秒，而是5分钟。这应该能帮我们解决这个问题，你会看到我要打开，你会看到蓝色容器的数量已经启动并开始服务。一旦这里稳定了一点，我就会回去开始做一些交通管理。我们从10%开始吧。再一次，当这个编程改变进入网络，一旦完成，你会看到我们的一些流量开始转移到这个绿色版本我们也带来了一个容器，来处理这10%。

这些修订中的每一个都是根据它们所接收的流量的比例动态缩放的。你可以看到，我们已经很接近了。90/10分成。如果我把流量控制到50%。再做一个改变。同样，这些不是改变或增加修订。这只是改变了流量配置。我们会看到，现在我们接近50/50了。我认为在这一点上，通常你会运行这个一段时间确保你在日志或用户错误报告中没有看到任何相关内容。确保此服务的行为符合您的预期。在这一点上，我认为我们很好，我将继续，只是把剩下的流量切换到这个。 Here you’ll see that once this traffic switch is completed, that blue revision will scale back down to zero. Again, all very, very sort of dynamic auto-scaling in the overall system. This graph is a custom visualization. That’s why I’m using my prebuilt image.

Cloud监视图将显示容器实例的数量，以及内存和CPU使用情况。然而，我们的监控工具中内置的可视化功能，更适合现实世界的操作，它实际上只关心一分钟分辨率的事情，在这种情况下，这种快速缩放不会很明显。希望这能让你快速体验到Cloud Run是什么以及它能做什么。

现在您已经了解了Cloud Run是什么以及它可以做什么，让我们来谈谈如何将JFrog与Cloud Run集成在一起。现在，这两个本质上都是具有许多功能的平台，其中一些功能确实重叠。我想说的是，有时当您考虑两个不同的平台时，您通常会看到供应商围绕集成预先构建的假设。有时候这很方便。事实上，JFrog内置了很多自动集成到pipeline中的功能。

当涉及到更多的自定义集成工作时，我认为这两个平台都有非常丰富的web钩子支持，事件生成，以及非常丰富的api，这是非常好的，这允许你不要选择一种通用的方式来集成这两个东西，而是选择一种你可以集成不同子组件的方式，这样它将最适合你自己的工作流。

当谈到将JFrog与Cloud Run集成时，很明显，JFrog有自己的生态系统和组件，它们真正完全管理软件构建和软件生命周期的管理，通常有一个终端部署步骤，将最终构建工件输出到某种运行时环境中。在这种情况下，这将是一个云运行。

现在有了JFrog Artifactory及其对容器的支持，自然的假设是部署应该指向Cloud Run，从Artifactory和JFrog中提取容器映像。然而，这并不像人们想象的那样得到支持，或者可能像人们希望的那样，我需要深入了解Cloud Run实际处理容器快速自动缩放的方式，以解释为什么它目前是这样的。

Cloud Run支持我们所说的容器流，让我更详细地介绍一下这意味着什么。这是Cloud Run内部系统的快速和高级架构视图。我们有API和控制平面主要在左边。我们在顶部有交通管理和前端系统。我们有计算的核心池，它由这些应用程序服务器节点的数量组成。我们有调度程序和存储系统，在这里，作为一个例子，来自谷歌的容器注册表在右下角。

部署新服务时，要做的第一件事是向每个组件发送一组PubSub消息，以便在每个组件中准备Cloud Run服务。其中一个步骤是从我们自己的容器工件管理中复制到一个定制的存储解决方案中。它所做的是将容器映像的字节重新配置为可识别为块存储系统的形式，而不是一组层。

然后，当容器在其中一个计算节点上启动时，我们将使用名为gVisor的东西进行隔离。因此，gVisor允许我们运行这个多租户环境，在这个环境中，我们不仅仅依赖于OCI运行时，而是将一个客户与另一个客户隔离开来。因此，Docker作为一个隔离不同容器同时彼此运行的例子并不完全足够。gVisor所做的部分工作是，它可以提供一组称为gofer的东西，这是一种在内核级别向应用程序公开网络和磁盘IO的方法，并实际提出其他实现。

这意味着，我们能够接受任何读或写文件系统调用，通过应用程序并将它们转换为流式网络读IO请求，到这个自定义存储系统。这通常类似于持久磁盘之类的东西的工作方式，因为您有一个网络挂载的块存储系统。因为它的工作方式是一个新的容器可以非常非常快地扩展到我们的整个舰队，因为容器映像与特定实例的关联，没有比挂载指令更多的延迟。因此，您可以非常非常快地将网络存储系统挂载到容器中，并且我们不必在从其他任何地方拉下容器映像时出现任何延迟。最后，一旦它开始运行，我们就可以继续进行路由流量的其余过程，并将该URL放入前端。

那么，这对我们的集成前景意味着什么呢?这意味着，作为您管道中步骤的一部分，您将希望使用一个步骤来制作我称之为来自Artifactory的容器工件的可操作现金副本，到我们的工件注册表模拟。这并不是要使用Google的工件注册表作为主要的工件注册表。在这种情况下，真相的来源总是Artifactory，在那里你可以利用任何扫描或QA步骤，或者任何审计。这实际上是将工件的缓存副本引入到与Cloud Run相同的基础设施环境中。

现在，这是使用Cloud Run作为部署JFrog生态系统中构建的工件的一种方式。然而，我认为值得指出的是Cloud Run的第二个用途，当它与JFrog pipeline一起使用时，它可以作为一种非常简单的方式来托管web钩子，它可以用来构建各种自定义集成到管道中。

因此，管道确实支持bash步骤，并且您可以在该步骤中以非常灵活的方式完成很多工作。然而，如果你想用Python或Go编写一些非常复杂的业务逻辑，并且你希望以一种可伸缩到零的方式托管，并且在需要时由管道调用，那么JFrog pipeline和Cloud Run中集成了一个外向的web hook，这使得托管可以由这些web hook调用的自定义代码非常容易和直接。

所以，两种不同的方式将Cloud Run和JFrog生态系统整合在一起，然而，并不是唯一的两种方式。我认为，正如我之前提到的，事件之间的丰富集成，web钩子，以及跨两个工具的强大API接口，为您提供了很大的灵活性，使您自己的集成能够最好地满足您的需求。说到这里，非常感谢。