使用JFrog DevOps部署到谷歌无服务器

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

谷歌在相当长的一段时间里有自己的旅程，你可以想象在谷歌的早期，数据中心是如何不断地重新配置的。现在，这是谷歌数据中心相对现代布局的视图。但是，对于早期的谷歌开发人员来说，他们不断地构建和部署到不断地重新配置的底层硬件上，这是相当具有破坏性的，所以我们真的需要一种方法来将数据中心更像一台计算机来进行部署，而不是组成数据中心的单个服务器。

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

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

现在我们实际上已经采用了这个核心基础设施能力，并尝试了几次将其产品化，这始于2008年，实际上比谷歌云本身的应用程序引擎还要早。App Engine诞生于高度武断的PaaS时代。这是一个高度管理的(包括电池)，某种程度上完全集成的开发应用程序环境，但它确实受到了需要一些严格约束的运行时参数的意见的影响。所以你只能在里面运行某些软件和某些软件栈。

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

然后在2019年，我们发布了我们认为是无服务器领域的一个最佳点，即无服务器容器的想法，即云运行，这是我今天将花大部分时间谈论的内容。如果要我用一张幻灯片来总结一下云运行是什么样的，那就是你有一个容器。这就是Docker通过序列化容器格式让它大受欢迎的原因，现在被称为开放容器倡议，任何OCI容器，直接在谷歌的基础设施上运行，尽可能少的干预管理。你可以把一个容器，交给谷歌。谷歌将按比例为您运行它。

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

还有容器运行时环境，这是Cloud Run本质上所关注的。我认为Cloud Run几乎是一种超级强大的对接站，您可以在运行时将容器构件插入其中，它带来了谷歌云平台的所有额外功能。今天我不会把这些都讲一遍，但为了让你们对其中一些有个概念，我将顺时针讲。

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

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

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

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

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

我们有这样的场景，我们有当前稳定运行的版本。我们称之为蓝色修订a，然后我们部署一个新的修订B，我们想开始管理一些流量和切换，假设10个请求中有一个转移到那个新修订。我们可以这样做，然后监控新的修订，观察任何类型的异常行为，任何倒退，已经通过了我们的QA过程，等等。然后我们可以继续将越来越多的流量转移到那个版本，随着时间的推移，使其完全中断。随着Cloud Run的动态扩展，每一个修订都将弹性地扩展到它所接收的流量比例。我们来看看这个演示是怎么回事。

因此，在演示中，我要做的第一件事就是向您展示如何快速而简单地将服务部署到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]响应。现在，我有了这个服务的检测，它会显示有多少请求。我将把它拉到视图中，现在可以看到，这个服务缩小到零。没有传输服务。没有容器正在运行。让我们通过运行一个load命令来改变它。我们会在10秒左右发送一些流量你会看到这里发生的是处理这些流量的容器数量当负载测试完成时，我们会立即把这些都缩减到0，你会看到所有的请求都被处理了，流量也得到了管理，非常有弹性。

现在，我想给你们看交通分流。正如我提到的，我们有蓝色和绿色部署的想法。现在，我们只有蓝色的部署。让我们假设我已经在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.

云监控图将显示容器实例的数量，以及内存和CPU的使用情况。然而，我们的监控工具内建的可视化，更适合真实世界的操作，它只关心一分钟分辨率的事情，在这种情况下，这种快速缩放不太明显。希望这能让您快速了解Cloud Run是什么以及它能做什么。

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

当涉及到更多的自定义集成工作时，我认为这两个平台都有非常丰富的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生成容器构件的可操作现金副本，并将其转移到我们的构件注册表模拟。这并不是使用谷歌的工件注册表作为主要的工件注册表。在这种情况下，真相的来源总是Artifactory，在那里您可以利用任何扫描或QA步骤或任何审计。这本质上是将该工件的缓存副本放到与Cloud Run相同的基础设施环境中。

现在，这就是使用Cloud Run作为部署JFrog生态系统中构建的构件的一种方式。然而，有一个次要的用途，我认为是值得指出的云运行，当涉及到使用这个与JFrog管道，那就是使用云运行作为一个非常简单的方式托管web钩子，可以用来构建各种自定义集成到管道。

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

因此，将Cloud Run和JFrog生态系统集成在一起的两种不同的方法，但并不是唯一的两种方法。我认为，就像我之前提到的那样，事件、web钩子和两个工具之间的强大API界面之间的丰富集成，为您提供了很大的灵活性，使您自己的集成能够最好地满足您的需求。说到这里，非常感谢大家。