演示-使用JFrog平台将代码从Github跳到Azure

蔚蓝的一天。

耶。好了，我们开始吧。首先，Shiri，非常感谢你今天的到来。我非常感激。让我们自我介绍一下。我叫Batel Zohar，是JFrog的一名开发者倡导者。在此之前，我是一名嵌入式工程师，然后我转到HTS团队和JFrog的支持团队。

我爱我的小狗。正如你在图片中看到的，我有两只非常漂亮的狗，我喜欢玩一些棋盘游戏。所以，如果你想稍后联系我，或者只是想讨论Kubernetes, DevOps或其他任何事情，我都很有空，我很乐意讨论。这是我的LinkedIn邮箱和Twitter。Shiri，再次感谢你参加我们的节目。我真的，真的很感激。

我的荣幸。离开家，在美丽的特拉维夫JFrog办公室里，我只是趁我有时间好好利用它。很高兴来到这里。我是Shiri Hochhauser。我是微软的ISV技术策略师，这意味着我正在与软件供应商和JFrog这样的初创公司合作，尽管JFrog是我最喜欢的公司之一，显然，我帮助他们在我们的云平台上构建解决方案，并在我们的云上施展他们的魔力。

所以只要有可能，我就喜欢拳击和旅行。你们可以通过LinkedIn或电子邮件联系我。不幸的是，我没有巴特尔那么先进，我还在通过Twitter摸索，但慢慢地，但肯定会到达那里。

你会成功的。

我要去那里。

好的，再次感谢。我们开始吧。让我们来讨论一下DevOps和持续的更新流。

所以我们的想法，当然是让一切都自动化。对吧?我猜你们已经看到这个图表了。我不会讲太多，但我们的想法是让一切都自动化。对吧?我们想要构建我们的测试，我们的发布，所有的一切都尽可能地自动化，并试图减少人类的行为，对吧?对于人类来说，我们会犯错误。有时候一遍又一遍地做同样的重复性工作真的很困难，也很累。让我们回到两小时的工作，讨论一下Jfrog平台，然后开始这个环节。所以我们的想法是从我们的VCS创建一个端到端的解决方案，从我们的资源控制到我们的部署，为您提供创建最佳版本和快速发布所需的所有工具。 We would like to release fast as much as we can.

我们首先要做的当然是我们的VCS，我们的源代码控制。我们的源代码，抱歉。我们有Artifactory作为主要的存储库管理器。我们将讨论一下为什么要使用Artifactory以及Artifactory到底是什么。我们有x射线。这有助于我们确保并确保我们没有任何不允许在我们组织内使用的开源许可证。我们有JFrog Distribution和Connect用于部署，并能够将其部署到不同的版本，服务器，甚至一些物联网设备。最重要的是，我们有任务控制中心。这有助于我们监控和配置我们的服务。我们有用于CI/CD的JFrog pipeline。 So basically, you have a full end-to-end solution from one place to another, since you created your code to deploy it to different service.

让我们从头开始。什么是Artifactory?

谁不知道Artifactory是什么?

有些人不知道这是什么，但我们开始吧。所以Artifactory是一个通用的二进制存储库管理器。我们的想法是，它是一个可以存储所有工件的地方，但它不存储代码。这不是风险投资。在这个地方，你创建了代码，创建了包，你会把它上传到Artifactory。然后你有了Artifactory中所有的特性，比如有了进一步的，完整的可追溯性。所以你可以看到你到底创造了什么，我们重建了什么。你有一个聪明的缓存机制。假设我要从远程存储库获取一些依赖项。对吧? Of course, most of the developers are using the same code all over again, and again, just changing some small components or some stuff that they need specific dependency and so on.

在这种情况下，我不想一次又一次地得到这个依赖项。对吧?我将在不同的团队或不同的存储库中使用相同的版本。所以我只需要从远程存储库下载一次。我把它放在本地的Artifactory中，一种缓存机制，我将使用这段代码。这是一种很聪明的缓存方式。

我们还有一个智能存储机制，这真的很酷。我们使用基于校验和的存储机制。想想你创建代码的方式。您创建了您的包，并且正在上传到Artifactory。另一队会用你的包，对吧?您希望为这个特定版本扩展功能或创建新特性。我可以下载。如果我要使用完全相同的版本，我不想保存两次。我只保存一次。然后我很容易地减少了存储当然，完全可复制地构建了我们的CI管道今天我们会看到。

那么为什么是Artifactory呢?所以它是通用的。它集成了27个包管理器、NCI服务器，还支持通用存储库，这是一个非常非常酷的功能。所以，如果你没有看到一个标志，你已经使用作为前端开发-

但它们都在这里，比如Maven, NPM，比如Helm。一切都在这里。

但是，如果您发现在这里看不到的东西，并且您确实想要集成，那么您总是可以使用通用存储库。通用存储库将为您提供创建您想要的任何存储库的能力，以及您想要获取依赖项的任何URL，然后您将所有内容放在Artifactory中的一个位置。

第二颗子弹是记录系统。它是所有支持的包格式的完整元数据。所以你有了所有的信息。你会在这节课上看到。例如，当我上传一个管道包时，我就会获取这个包的所有属性。我可以看到是谁在什么时候上传的，并拥有关于这个特定包的所有信息。

第三个是存储优化和基于校验和的存储。就像我们说的，每当我们上传一些东西到Artifactory时，我们都会计算SHA-1, SHA-2, MD5等等。这样它就不会保存同一件藏物两次。我们只是联系在一起，以防我们在不止一个地方需要它。

自动化。当然，我们喜欢把事情自动化。我们有Rest, API, CLI。人工查询语言是我们自己的语言来创建非常复杂的查询。从数据库中获取一些信息。例如，如果需要，可以过滤某些属性。

我们有积分。因此，我们正在为CI/CD构建与自动化工具的集成。

这是你关于DevSecOps的可爱部分。是的。我们来谈谈DevSecOps。

是的。所以我之前告诉巴特尔的是，我真的很兴奋能看到它。作为DevOps流程的一部分，嵌入安全性已经是一个广泛的运动，这是一个向左的安全范式转变。因此，我们希望自动化一切，但我们也希望将安全性作为部署到生产中的一个组成部分。所以我们不想在它已经部署之后才跟踪它。我们也不希望任何人必须做任何活动来检查或扫描他们的代码或部署中的漏洞。我们希望它只是部署过程中一个原生的、不可分割的部分。如果你能够开发一些东西并将其部署到生产环境中，并且它能够顺利进入生产环境，这意味着它也是非常安全的。它不仅是可扩展的，或者它是好的和操作的，而且它也是安全的。这就是x射线的作用。 It’s like… And Batel will show in details, but it checks for vulnerabilities where the code is already built and pushed into, right?

是的,没错。因此，x射线实际上是一种工具，可以保护我们免受我们工厂的安全问题。对于x射线，我们也有一个用户插件。例如，对于VS code，我可以下载插件。举一个简单的例子。当开发人员看到已经修复的版本时，他可能会使用不包含安全漏洞的新版本，我们将移动任何东西

这样做就容易多了。对吧?

是的。

所以我们要向开发者展示在开发阶段，嘿，伙计，你正在使用一个有已知漏洞的版本。你依赖于这个和那个包。请把它换掉。在开发时这样做要容易得多，而不是在开发后将其打包为DevOps时这样做，而且肯定比在生产中这样做要好。

不，那太疯狂了。

是的。

没有人愿意那样做。

所以正确的。

这样做太可怕了。它花了很长时间，你需要恢复版本和所有的东西。所以这可能比从头开始做要困难得多，

早点赶上。

是的,没错。并且快速释放。你还记得我们想要尽快发布。

所以正确的。

所以当我们谈到为什么我们想要使用Xray时，我们认为最强大的是它与Artifactory的原生集成。所有东西都在一个地方。我不需要搬到另一个地方。我不需要再次发送它来上传它，或者做任何其他事情。我的平台上已经有了所有的产品。hth华体会最新官方网站我可以在一个地方看到所有东西，我会在demo中展示。这是积分。我们有Artifactory，它是原生集成的、可见性和影响分析、通用安全性和遵从性等等。所以这里的一切都在一个地方，我可以很容易地扫描我的漏洞，以确保我在转移到生产环境之前保持安全，这对调试他们的东西来说是非常可怕的。

我怎么知道我应该先说什么呢?比如，你有什么优先排序的机制吗?因为很明显，如果我要看到几百个[丝绒00:00:10:39]，我不知道该先接近哪一个。

是的，当然。所以我们有我们自己的机制，我们也有一个CVSS分数，让我知道什么是CVSS的分数，多少是关键的。我们也会在演示中展示这个。

但基本的概述是这样的。首先，我们这里有我们的数据库，x射线数据库每隔几个小时就会更新，我们的团队每次都会收集越来越多的数据。然后我们实际上要搜索每一个工件，我们这里的每一个包。我们叫它。我们把它提取出来。对吧?我们从每一层提取它，例如，从我们的docker图像中，我们要扫描它。所以无论何时我们扫描它，我们都有政策和监视。我们想做什么，到哪里去找。对吧?

所以政策会定义我想做什么。我可以扫描开源许可证，以确保我没有使用组织内部不允许的特定许可证，比如GPL。所以，当你听到一些疯狂的故事，关于暴露你所有的代码或支付大量的钱，只是因为你在余额中使用了一个特定的不允许的。当然还有安全漏洞。我们要确保我们受到保护，我们不会有任何准确的东西，或者明天早上会袭击我们，我们是安全的。

所以手表会告诉我去哪里找它，这样我就可以为不同的分数创建不同的策略。假设我得到了一个非常非常高的分数。对吧?我想挡住我的建筑。我想确保构建失败。但如果我找到的不是很高，我就会找到非常低或中等的东西。在这种情况下，我真的没有保障的可能性非常低。我不想让任何事情失败。我可能想要更新安全团队或更新来自其他组织的人员，但我不想让所有东西都崩溃，只是插入构建。在某些情况下，这可能真的很难。 So I want just to add a web hook or a slack notification, or something like that.

当然，一切都会自动进行。我们有自动操作。我们不需要一次又一次地这样做。我们只需要配置一次就可以在我们的平台上配置好所有的东西。在这里，我们还可以防止下载和更多。到目前为止有问题吗?

不，那太酷了。

好了,好了。

哇。所以我想我们已经涵盖了JFrog平台上的五六个产品中的两个。hth华体会最新官方网站JFrog微软有很长的历史，但在过去的两年里，我们所做的增强基本上是为了能够在Azure上为JFrog的客户提供最好的体验。对吧?我还记得当你在市场上看的时候，只有两种产品。如果你现在去Azure市场，它本质上是我们的Upsource，那里有超过40,000个第三方供应商的解决方案。

哇。

是的。提供他们出色的软件，无论他们做什么，都能在我们的云上得到。它的美妙之处在于，再一次，你看到这里有不同的许可层，不同的产品，所有这些都在说现在就得到它。这意味着这是一个事务解决方案。

因此，当您单击此按钮时，它会立即为您部署，或者在JFrog SaaS多租户产品上，您可以获得自己的环境，或者出于某种遵从性或安全性原因，您需要将其部署在您的租户上。您也可以通过一次单击获得它，因为它部署了一个具有JFrog Solution需要运行的能力的资源组。而且付款是通过Azure订阅支付的，所有这些都是无缝的。您将被重定向到JFrog网站，点击许可键，或者购买一个新的。您也可以设置免费试用。对吧?你也可以——

是的,没错。你也有开源版本在这里，所以我们可以很容易地得到它只需点击一下。我们把所有东西都放在一个地方，而且

试一试，看看效果如何。

是的,没错。这很简单。你只要点一下，你就拥有了一切。我喜欢这个解决方案。看看这个。你有很多选择，而且远不止这些。你刚才截屏了，但我记得我们这里有不止12个选项。这非常简单。去试试吧。我们希望你会喜欢它，并在这个研讨会上查看它。

是的。这里我们将概述整个管道，整个过程，我认为这是一个非常经典的场景。

是的。

对吧?每一个-

很简单。

你们每个人可能每个星期、每个月或每个季度都要面对新版本。假设你有你的代码，你有GitHub中的容器。然后将新版本推送到容器映像的主服务器。现在您想要构建它，并将它部署到您的Kubernetes教室生产中。因此，我们将展示如何利用GitHub操作，它本质上是微软的CI/CD工具。因此，您可以将新版本的代码推送到存储库中，利用JFrog CLI和JFrog命令行，构建Docker映像并将其推送到Artifactory中。并且还将展示如何将这么多很酷的参数从GitHub映射到JFrog平台到具有实际图像的Artifactory。对吧?

是的。

我们来看看它是如何工作的。然后，当图像已经被推入人工工厂，我们将用x射线扫描它。我们要展示的是，不幸的是，我们发现了很多漏洞，但我们能够更快地缓解它。

是的,速度更快。我们有能力修复它。不用担心。我们会有办法的。

我们会帮你的。不用担心。然后将它部署到Kubernetes集群中。我们将把它显示为一个简单的简短的CUE YAML文件。

是的。

当缩进是正确的[听不清00:17:12]。我喜欢它的缩进正确。当他们没有那么多的时候，我认为这里也显示了安全向左转移。对吧?

正确的。

你也可以从两边看到。

完全正确。所以正如我们一开始所说的，我们希望推动一切向前发展，包括开发部分。对吧?向左移动，确保我们能扫描到自己。首先是我们的GitHub。我们将把凭据作为秘密，以确保它在代码中不只是纯文本。然后我们用x光来确保我们再次扫描它。所以我们想把所有东西都移到左移，基本上从头开始扫描。

一路上，我们保证你的安全。就像代码本身，当它是真正的代码时。所以我们要确保你的安全。而且当它已经被打包成藏物时，x射线会保护你的安全。显然，当它在生产时，我们仍然会跟踪它

是的，当然。

并记录下来，但我们会全程报道你的。对吧?我们要确保它从第一个代码开始就一直是安全的。

是的,没错。好吧。我想我们可以开始了，对吧?

是的,当然。让我们深入研究一下。太棒了。

所以在我们在GitHub Actions中创建构建之前，我们已经有了一个构建。我们去我们自己的建筑吧。

现在我们看到之前构建并推送的Docker镜像已经在Artifactory中了。对吧?

是的,没错。那是在我们改变之前。假设我们添加了另一个依赖项，或者只是在这里改变了一些东西。在那之前，我们已经有了一些公开的模型。我们有一些文物。我们可以看看舱单。Json在这里。我们可以看到依赖关系和我们需要的一切。我们有环境变量。它能让我非常快速地调试程序。

那些环境变量，它们从何而来?

在这种情况下，它们来自GitHub Actions和JFrog CLI。因此，JFrog CLI为我提供了非常容易地收集环境变量的能力。然后，当我需要调试东西时，比如在特定机器中发生故障或出现一些问题时，我可以轻松地从UI、CLI或REST API进行调试。我可以找到他们在这个建筑中使用的所有环境。

因此，它与CI/CD工具集成在一起，能够提取构建的细节。

是的,没错。

多酷。

是的。这就是我们使用JFrog CLI的原因。这里，如果我们要讲一点GitHub Action，我有一些我们已经用过的原生东西。此构建还运行

在这里你可以看到，如果任何事情都不起作用，巴特尔需要受到指责。

是的。

是她写的。她是GitHub的演员。

哦,不。

是她写的。是她干的。

好吧。我们把它去掉。这是另一个很酷的部分。你可以看到GitHub事件名被推送了。对吧?你记得我们想要确保我们是自动化的，所以我们想要创建一个提交，推送和测试每一个提交。在这种情况下，我们为每个推送创建[听不清00:20:18]。当然，我们可以为一个特定的分支改变它等等，但就在这个例子中，我们使用一个测试，当我们在这种情况下为每个推送创建一个构建时使用它。我们这里有一些信息。让我们试着在GitHub Actions上运行它，看看它是如何运行的。

祈祷。

哦,第一次。对不起。好吧。

你想先运行它然后我们会在它运行时讨论它。

是的。但是等一下，在此之前，我们先来看一下仓库，这样无论什么时候他们运行研讨会，他们都会看到这里有什么。

他们会看到的，还有这里。

是的。

是的，所以我认为这是最酷的事情之一。就像我们说的，我认为这是关于把开发者，DevOps的家伙，带到他已经在的地方。所以扫描藏物本来就在哪里。同样的方式，GitHub工作流，本质上是CI/CD管道，被存储。当你创建一个新的工作流时，你会看到一个新文件夹正在为你创建，它和你的代码在一起。所以在你的代码中，我们还保存了YAML，它告诉你当一个新版本被推送或提交到主分支时，这个代码发生了什么。它把CI集合到代码所在的地方。

是的。那太酷了。它在这里创建了导演。我们可以看到yaml，当然我们也可以创建不同的yaml。对吧?基本上把它分成不同的步骤。对吧?

是的。所以你通常会有一个工作流。工作流是从头到尾的完整管道。显然，它可以用一个或多个动作来构建。这些行动就像小步骤或小积木。这是有道理的。对吧?显然你可以有12个不同的操作，但你也可以采取一个动作并让它调用其他动作。因此，将您想要一起作为工作流执行的一些操作和步骤组合在一起更有意义。然后你也能够影响其他人的行为，因为他们是有意义的。 It’s like common tasks that you see being reused and being reproduced all the time.

好的,很酷。酷。就像我们之前说的，对于每一个推力，我们会

我们只是不想运行它，因为它需要一些时间。[相声00:22:41]我们来表演一下。

我很抱歉。让我们转到视图运行。

查看运行。这里我们可以看到前一个我们可以重新运行其中一个。

是的。让我们来看看大脑。这就是你刚才描述的基本元素和

正如你们之前看到的，巴特尔在这方面做得很快，但有些方法对我们不起作用，这没关系。稍后我们会给你们看这个会运行得很好，但是你们可以很快地看到它失败的地方。对吧?

正确的。

因为你看到每一步都很顺利，然后你看到一个绿色的小圆圈。然后在它不工作的地方，你就能看到它在哪里发生冲突，在哪里坠毁，并减轻它。

当然是我的耻辱。我们不想看到所有的红灯。

我们一整天都在努力让它成功。但这里我们要重新运行它，当它在后台运行时，让我们看看实际的代码和它做了什么。

好吧。让我们回到工作流程，从一个可爱的YAML开始。

所以我们从这个开始，这是一个触发器，这是有意义的，因为我们想说所有这些将在什么时候运行。

正确的。

这里我们决定这里你将使用GitHub上我们都知道的任何基本事件，它可能是push, commit, pool。你也可以说，我想把它推送到一个特定的分支。

正确的。

对吧?因为我不希望它在每次推送中都发生，只是当你推送到master或者只是当你推送到staging或者其他什么时候。我们可以配置环境变量。重要的是你可以看到[听不清00:24:14]run-host，在主机上运行。那么为您运行的构建机器是什么呢，比如云中的某个地方，这个CI/CD管道。在这些步骤中，你会看到，正如我们之前所说的，每一步都是一个动作。每个use代表一个操作，我们将向您展示其中一些操作是预先配置和预定义的。其中一些可能是我们在另一个文件中配置的动作。所以你为什么不向他们展示当我们在市场行为中搜索JFrog时会发生什么呢?太棒了。

我们到GitHub Marketplace。你可以看到这里有很多不同的动作。所以无论何时我需要配置什么，我都可以，首先，搜索它。

也许是有人干的。

也许有人创造了它。完全正确。也许以前有人这么做过。我们喜欢重用相同的代码。

回收利用有利于环境。

回收利用很好。首先，在这里你可以看到我们有不同的行动，其中一些是由社区创造的。就像你在这里看到的，一些动作有5颗星，这很酷。其中一些更像我们的官方版本。

但这也说明了很多人实际上在GitHub上使用JFrog，他们用JFrog来管理他们的工件。他们有自己的代码库和你在GitHub上的代码库他们有这样的场景。它的美妙之处在于越来越多的人使用相同的场景。他们将与社区分享这个堆栈。这就是GitHub的意义所在

太棒了。

并且使用它，但通常像您这样的软件供应商也会想要提供一种官方的操作方法来做这件事，而这个操作是我们实际使用并嵌入到代码中的。这里我们叫它，对吧?如你所见，我们确实使用了这个，这意味着，使用意味着我们实际上调用了这个特定的动作。这都是关于如何使用JFrog CLI的。所以它是JFrog命令行，直接从我们的管道执行。直接从我们的GitHub工作流中取出来作为一个动作。这是因为我们现在想说，我们要连接的Artifactories是什么?我们希望能够使用实际的CLI命令。稍后你会看到我们实际上可以使用一些。你看这个jfrog.rt。巴特尔告诉我，这是JFrog的缩写

Artifactory。

Artifactory。我们实际上可以使用CLI，但那是JFrog CLI语法。我们可以用它，因为我们有这个用途。对吧?在这里，我们可以配置CLI，即JFrog的命令行，以便从我们的管道中工作。我们显然需要告诉它你想用什么Artifactory，因为我们会告诉它，哦，Docker push，但是到哪里呢?去什么工厂?

是的，[相声00:27:19]。

告诉我们怎么连接你的神器，巴特尔。

好吧。我马上给你们看这首神奇的诗。在这里我们可以看到关于JFrog CLI的非常非常有趣的文档。因此，您可以看到，默认情况下，我们将使用最新版本的JFrog CLI。我们要做的第一件事是配置Artifactory，就像你之前说的。所以我要去我的终端。我们来确认一下。

所有的步骤都在这里，看到了吗?

是的。

你只需要复制。

完全正确。我们要复制这一步骤。这很简单。这并不难。因此，jfrog c add将为我提供配置jfrog平台的能力。这是我的默认服务器。可以看到，我将使用URL bateltest.jfrog.io。

URL是针对整个平台的，对于你来说，你拥有所有服务的许可证。所以我们可以看到，它不仅适用于Artifactory，也适用于x射线，适用于分销，适用于所有东西。对吧?

完全正确。在这里。我们默认创建URL，斜杠和服务名，这里我可以使用访问令牌。例如，如果我想为CI/CD创建一个特定的访问令牌，我可以很容易地创建它，在Artifactory中找到它，并在VL操作中重用它。当然，我也可以使用纯文本，这里我要添加我的凭据。我不想用代理或者其他你认为我不需要的东西，事情会解决的，很好。

现在我们要得到的是一个令牌，它本质上是一个访问令牌，所以我们可以连接。不是我们，而是我们的GitHub Action，我们的GitHub Workflow可以连接到Artifactory。对吧?

你是对的。

这将建立一个连接，允许它稍后使用所有这些CLI命令，并对Artifactory实例推送和执行所有这些操作。对吧?

完全正确。JFrog CLI获取这个令牌并导出它以获取关于Artifactory服务器的不同信息等等。我可以运行jfrog c export，输入服务器ID。我们可以看到这是我的令牌。

哇。

是的，我们做到了。

现在，很明显你不会做不明智的事情。只是把它放进去。

我希望如此。[相声00:29:40]你知道，这种事以前发生过。

不。

你有那么多疯狂的故事。

是的。但是，巴特尔，你知道怎么把事情做好。

哦，谢谢。

所以我确信这是最大的问题之一。对吧?这就像说，好吧，我们想把我们的代码和存储库分享给很多人，但事实是，你从来不想在代码中使用密码和令牌。但肯定的是，当我们和很多人分享我们的仓库时。我们在GitHub上有。那么你如何确保你没有任何登录凭据，哈希令牌，密码，信息

什么,是的。

在你的代码里?

是的。首先我们要用到的是GitHub Secrets。对吧?我们有一个很好的机制来保护我们的秘密，以确保我们保持安全，没有人能看到我们的特殊令牌或我们的秘密。在这种情况下——

这里我们看到我们本质上指的是。就像，当我们想引用时，我们调用secrets。这是参数名，我猜这是你之前给secret命名的方式。

是的。

让我们来看看，如果现在我能看到你之前的秘密，那是怎么回事。我们进入设置和秘密。这里我们可以看到我们之前配置的秘密的名字。现在如果我们要用一个新值来更新这个。所以他看起来很茫然。显然它不是空白的。对吧?

你把它放在那里。是的。这种方法以前奏效过。(相声00:31:08)

所以它的美妙之处在于，因为你根本不想看到别人以前藏在那里的秘密。即使您拥有对存储库的完全访问权限，您也无法访问令牌。即使您有权更改令牌，您仍然不应该有权查看现有令牌并利用该权利?

是的。

超级。

超级酷。我喜欢这张照片。所以现在我们保证了一切安全，看起来它是超级保护的。我们这里什么都有。让我们更新令牌，以确保我在正确的服务器上使用的是最新的Artifactory版本。让我们回到YAML。我告诉过你，我喜欢YAML。所以我非常喜欢它。它非常好读。看看我们在做什么。

当缩进正确时。

是的。

这种情况并不经常发生。我不得不说，我讨厌yaml。我要坦白一件事。我讨厌它。

不。不。你怎么会讨厌它呢?

因为它不断地中断，然后我看到，像在第102行，我不小心又一次击中了空格。

但是看看它。太酷了。

当它工作时，它是美丽的。我同意。

现在它起作用了。太棒了。

是的，现在是。因此，在我们连接到它之后，我们在这里，甚至不是我们连接了它，而是我们配置了我们的Artifactory将访问令牌作为环境变量。这就是我们现在想要构建和推送Docker镜像的地方。因此，我们想要构建Docker映像，然后将其推送到Artifactory instant。所以这里我们将简单地使用docker构建，我们想要构建Dockerfile文件。这就是为什么我们要修改目录，因为Dockerfile在Workshop应用下。

是的，默认是到根目录。

到根目录，对。在那之前我们得到了一个错误它没有找到我们的Dockerfile。

如此尴尬。

所以很明显，这就像找到正确的位置，然后我们也使用标签。这个Docker映像将被构建在我们想要它被定位的地方。它的名字。它将是那个的这个ID，但这一部分，它实际上代表你的Artifactory实例。对吧?这部分代表虚-

对于虚拟存储库，确实如此。

对于Artifactory中的虚拟存储库。正确吗?

你是对的。正确的。

这只是我们项目的名字我们想把ATS。正确的。因为这是我们的部署。

正确的。因为我们要用ATS。

现在，我只是想知道，但我也知道，这个命令jfrogrt已经设置好了。rt代表Artifactory，我想这是Docker push。但是为什么我们在这里只使用普通的Docker build命令来构建它呢?尽管我们仍然在依赖项和Artifactory中的所有东西的帮助下构建它。但是为什么我们不直接使用Docker的push命令呢?我们为什么要用CI ?

所以我们也可以使用Docker push，但是如果我们要使用Docker push，我们将无法收集环境变量。你们还记得我向你们展示过我们收集的所有信息吗，这些信息很重要，我们可以很容易地追踪到它们。我们想要确保我们将来有这些信息。因此我们使用jfrt Docker push。我们将使用JFrog CLI完成此操作。

好多了。所以你的Docker push就是Docker push加上速度。再加上从CI/CD中提取大量参数到Artifactory，这些参数将与发布的图像一起存在。

是的,没错。不仅如此，每当我们使用JFrog CLI时，我们都会检查校验和基本机制。如果我们已经在神器工厂里找到了这个藏物

如果它没有改变

是的,没错。

我们不想取代它，占用更多的空间。

完全正确。空间，时间和一切。它会快得多，因为我们已经在Artifactory中有了它。

超级酷。所以我一定会用你们的。

嘿,酷。

完全冷却。那么现在本质上假设所有这些都正确通过了，很快我们要去看看运行是否成功结束。但愿如此，但在Docker镜像再次被推送到Artifactory之后，还有一个镜像被部署到Kubernetes。首先，我们之前创建了一个Kubernetes集群，这是它应该有的一部分。使用Azure很容易做到诚实，你只需要完成向导。我们稍后会展示，就像我们已经预配置的那样，但是我们现在希望能够将映像部署到。这就是重点，对吧?您想要启动并运行部署，因此我们首先需要连接到Kubernetes集群，以便我们有权限推出新版本。这里也是一样的。对吧?

是的,没错。

所以我们要用另一个秘密?

完全正确。我们创建了另一个名为AZURE_CREDENTIALS的秘密，只是为了与Azure建立连接。

JFrog IKS是一个集群。这里你可以看到，我们再次使用。这也显示了。这是另一个动作，这也是一个原子步骤，它是关于设置上下文的。当您希望能够登录以获取凭证并登录到集群时，按照特定的服务原则，它具有权限。你向这个动作提供凭据，集群名称和资源组，它在后台做的就是登录。现在，我们将从这里开始运行的每个命令都将在这个凭据服务原则的上下文中运行。对吧?

这是惊人的。这非常简单。现在假设用户是

它只是让它更有条理。对吧?

是的,当然。我喜欢它。

是啊，太酷了。很明显，最后一个是实际的部署。这就是它的美妙之处。你可以看到，我真正喜欢这个的是我们在这里说我们将从本质上取图像，我们在这里给出的是到Artifactory中图像字段的实际链接。所以，不仅是Artifactory实例，还是虚拟Artifactory。对吧?

正确的。

然后是实际的AKS。我们指的是我们构建和发布的这个非常具体的映像，我们希望它现在部署到AKS集群中。我们给出了部署YAML来指定技术细节和pod规范。但是我们在这里告诉大家，回到我们三步之前建立的图像。对吧?

是的。

从Artifactory。然后去做。再说一遍，你能说出最后两个JFrog命令行是什么吗?

当然可以。所以我们又有了jfrog rt, jfrog Artifactory bce，它是构建收集环境。它收集所有的环境变量，比如如果你想看到在GitHub上运行它的主机和其他关于运行器的信息。构建发布了jfrog rt bp，这是测试版。这为您提供了构建信息，并创建了一个称为beta构建的新工件。我们有完整的json文件，包含所有相关信息，我们会看到如何调试它以及我们能从这个发布中学到什么。

它也有很多关于主机的参数。对吧?

正确的。

我们在构建宿主之前看到过。它是由GitHub提供给你的，我认为你有新的可见性。难以置信的

这真的非常非常酷，以防你需要做背部运动。看看这个。我们这里有一座绿色建筑。

哇。

让我们快速点击构建，看看这里有什么。

我太兴奋了。哇。

是啊，太神奇了。就像你之前说的，我们有所有的步骤。对吧?这很简单。你可以看到它跑得非常快。大概花了两分钟，因为我们已经有了

所以我们对你们说实话，第一次通常需要更长的时间。

是的。

所以请耐心听我们说。但通常从那时起，我们也有了一些缓存机制，所以它变得越来越快。但是你也可以查看一下。就像第一次都不成功一样。

这行不通。

别指望它会。所以有一次，我们发现问题是连接到Artifactory，因为我们没有使用正确的凭据。

正确的。

或者后来是关于连接到AKS集群。但你可以很容易、很快速地识别它。我很好奇，如果你能看到这里，你就能看出它在从实际的工作流程中收集环境变量。对吧?

完全正确。

超级酷。

这非常非常酷。

现在我很想看看这次运行中收集了什么，在Artifactory中可以看到什么。

好吧。所以我们从这里开始吧，因为它很酷。你可以看到我们也部署了建筑青蛙，所以我们可以点击它。看看我们这里有什么。所以我们被重定向到建筑。

哇。

是的。这里是发布模块。我们有最新的AKS。我们可以看到这里用到的所有图层。我们可以看到我们之前说过的环境变量。我们有所有的信息，作为这个构建的一部分。我们在这里看到了GitHub信息。

这里还是巴特尔[鼠语00:40:17]

还是巴特尔。是的。还是我。哦,不。所以。

但我也想看看是否有任何漏洞或问题。

太棒了。因此，让我们也去看看包是否有任何漏洞。你可以看到这是用x光扫描的我们有不同的版本。[相声00:40:34]是的。所以这很关键。哦，不，那太糟糕了。让我们看看为什么它如此重要。你看这里的x光严重性。

这太重要了，它给了你严重性。因为正如你所看到的，这里有174个违规，这是一段非常小的代码。说实话吧。

是啊，没那么大。

我只是想说，你把它放在首位，这太好了。因为我假设临界值是10或20，这更容易解，也更有意义。你知道的，174让我不知所措。

是的。调试所有东西真的非常非常困难。我们来试试其中的一些。让我们以肌肉为例。我们有一个固定的版本，这真的非常非常酷。思考- - - - - -

巴特尔马上就去修理工，不过先把问题告诉他们。

好吧。[相声00:41:22]让我在这里选择一个协议。这里的问题是libc，它有浮点堆栈我们有一些问题与一些数学目录和-有关

这里写着，就像一个[瑞士语00:41:40]特定的版本，这个库有…它甚至不重要，但它说，通过1.1.23，就像[瑞士语00:41:49]特定的，次要的版本。我们知道存在这个问题，对吧?

是的。

所以显然我们需要改变它。要么更新它，要么回滚到旧版本，而是将其更改为其他版本。但现在我们必须寻找它真正有效的版本。

是的。让我们看看如何调试它。用x射线很容易。所以你可以看到你眼前的一切。你有固定的版本，就像我之前说的，我知道这太快了

[相声00:42:17]所以它马上就会告诉你。

它马上就能告诉我。我不需要想太多。我只看到了固定的版本。我可以在代码中修改它。如果我添加插件，例如，对于VS代码，我将立即获得固定版本。每当我创建它并编写代码时

当我提到穆斯林的时候。Libc版本1.1.23，它会说，不，不。源自[相声00:42:40]

是的,没错。你可以从你的左侧学习并看到它。

我们还可以看到爆炸策略，这很神奇。我看到你们可以看到它的影响。如果你有几个组件引用这个库，我们会在这里看到越来越多的组件，这样我们就知道了。

完全正确。

所以我们知道要更新它。正如我们所看到的，这个是1.1.20r3，我们必须将其更改为r5才能正常。

是的,没错。可以看到，我们上传了图片?AKS图像。然后我们可以看到它在其中一层下面。这是其中之一。我们可以检查校验和，看看到底是哪一层。这里是文件，实际上是脆弱的，有1.1.20版本的问题。如果它在不同的路径上受到影响，我可以看到所有的路径并一起改变它们，所以我不需要一次又一次地做同样的工作。我只是沿着撞击路径改变它们。在12月，如果它很重要，我有参考资料，所以如果我想了解更多关于它的信息，就像你想要的，所以我可以点击参考资料，进入CVSS，或者在这种情况下打开墙，得到我需要的关于安全问题的所有信息。

超级酷。

是的。因此，不仅如此，我们还在扫描开放源码许可证，或者正如我们之前所说，如果我们使用GPL, MIT，或者只是不允许使用Apache许可证，例如。我可以很容易地把它从这里堵住。同样，我可以配置一个自动操作，以防我发现一些东西，构建失败，停止下载或任何我想阻止我的开发人员使用这个特定的包，例如。

完全正确。我认为这很神奇，因为我们经常只是想工作，我们只是想使用任何我们想要的软件包，但显然我们不想做任何违反公司政策的事情，但我们只是不想检查它。这样很容易，就像它说的，好吧，这个是被禁止的，但它指的是你。有时它甚至可以自动引用，在幕后，把你的依赖项，它指的是非授权版本到开放版本，然后把它重定向到一个依赖项，也就是授权版本。对吧?因为这就像，再说一次，我们想要提供…这与这个系统无关。这并不是要阻止开发者使用他们想要的东西。这只是为了确保公司不会暴露在……公司成长，当他们成为一个大企业时，如果他们使用开源版本，他们可能会面临诉讼和问题。所以在这种情况下，你可以将其与你所授权的内容进行交易，而开发者甚至不会知道。

是的。

很神奇的。

这非常简单。这是惊人的。我们来谈谈Docker层。我也喜欢这个功能。假设我们都上传了一个不同版本的ak。我可以看到正在运行的层。因此，每当我需要调试某些东西或它正在某处运行，但在另一台机器上出现问题时。再说一遍，这非常非常简单。如果我要更改某些内容，我可以看到确切的命令。或者如果我只是，我不知道，删除这里的副本或者改变一个环境变量。 Right? You can see here the environment variable where using NGENIX version 1.15. I can easily, see the version and debug. Another cool feature is here, the Set Me Up. And whenever you want to run it locally, for your testing-

复制主机上发生的一切，构建主机。你根本不知道发生了什么。

是的，另一个GI团队或其他人只是想复制它，甚至只是测试它。我们发布了一个新版本。我们修好了。我们认为这很神奇。但有人需要测试它，所以我们可以很容易地点击这里的副本，下载版本。关于可追溯性，我想向你们展示的最后一件事是这里的工件信息。同样，我们可以根据特定的包类型进行过滤。我们现在就住在码头吧，因为我们爱码头。我们的工作坊是在Docker中进行的这是我们的Azure工作坊。我们坐慢车吧。 So Azure workshop, where is… Can you see that? Here. Okay. So here is my ideas, right? And I have the catalog here, and here is the latest. And you can see that I have the layers, like I said before, exactly what we saw on the packages.

超级酷。

这是舱单。Json中也有属性。所以无论什么时候，你都不需要做任何事情。在这种情况下，它将自动获取信息并获得Docker标签。我们在G方向上运行的构建号。我们可以看到SHA。我们有很多信息，而且非常非常重要。当我在技术支持部门工作时，我看到过很多这样的情况:一台机器上的东西运行得很好，而另一台机器上却出现了问题。因此，每一天，每一次，无论何时，当你在构建你的软件时，有时会有一些东西失败。肯定的。

期望它。是的。但我认为它的美妙之处在于，它让你再次看到那些在云中运行的进程。然后它是匹配服务，所以你不能访问它。

你是对的。

因此，当您拥有自己的构建主机时，您可以确切地看到它是如何配置的以及它使用了什么。但通常情况下，人们真的很高兴他们得到了免费的GitHub构建机。但有时他们会说，也许它失败了因为它运行的依赖项或参数或Docker版本，不管它运行的是什么，现在他们可以看到在构建主机上运行的是什么。我认为它给了你这个组件的能力，它是被管理的。这太不可思议了。

谢谢你！是的。这里我们有了所有的信息。同样，我们可以找到x射线信息我们也有一个大的json文件，里面有他们之前看到的所有信息。从这里我们可以

难以置信的哇。

是啊，太棒了。

所以我想，回到YAML，这样我们就知道我们发布、构建和推送了容器映像到Artifactory，然后我们将它部署到企业。因此，让我们检查Azure上的集群，看看它是否健康，是否启动并运行。

好的，等一下[相声00:48:59]

所以好吗?

让我们确保它运行了。是的,没错。它被部署了，我们在这里创建的下一个部署，你可以看到名称空间。好吧。我想我们很好。

一切看起来都很好。是的，我确信，作为Kubernetes部署动作的一部分，它们的健康状况也会受到影响。

是的。

[00:49:18]和端点，以确保服务已启动并运行。我们先看看是不是一切正常。所以现在我们在门户中，你有一个仪表板，上面有你所有的…这将是你最常用的Azure服务。我们将进入Kubernetes，我们可以在这里看到JFrogAKS，它恰好是我们正在使用的集群。这是你们可以自己做的作为研讨会的一部分。这很简单，但这里我们已经预先配置好了。但从本质上讲，当你使用托管的Kubernetes服务时，你得到的是完全托管的、完全修补的Kubernetes环境。

master是高可用性master，预配置为3到5个实例。然后这里只有一个节点池，因为我想让它尽可能的小。这里有一个节点池，运行节点大小，非常小。如果我没记错的话，这是两核四内存的机器。我们有从一到三的音阶。您可以选择使用Azure CNI的网络策略。你也可以使用Kubenet。Azure CNI只是给每个pod一个你的实际IP。

那太酷了。

这很酷，但你也需要为此做好计划，因为这意味着你将使用很多很多很多很多的IP地址。所以你更有可能感到疲惫。显然，这对传感器来说要容易得多。它就像一个固定的，而不是虚拟的，而是你虚拟网络中的一个真实的IP地址。所以不是舰桥给每个舱的。所以它有优势，但这是一个需要考虑的问题。现在我们来验证一下。让我们看一下显示器。

好的,很酷。

班长。

在我看到之前先说一句，你更新了Kubernetes版本。那太酷了。

最后。是的，其中一件事就是，很明显，我们一直在跟进，很多人问我为什么我们更新得这么快。所以很明显，我们只是在遵循实际的Kubernetes版本，但我收到那些必须更新它的邮件，这非常困难。所以这是最好的，最新的版本。但我认为做这些更新会变得更容易。当你有一个好的背景时，随着时间的推移，它会变得更容易完成。我们这里也启用了AAD，这意味着你也可以登录，这是我们传递的凭证的一部分。我们并没有花时间在这上面，但是你也可以通过AD身份验证Kubernetes集群。即使作为开发者，你也可以给别人使用那个的权限，但对于一个服务原则，它可以在其他服务上有其他权限。真的很酷。

哦，那太酷了。所以当我们想要连接时，我们可以点击这里，从站点获取凭证。对吧?得到这些信息。

是的，你可以写，但是它在，像我们的CLI，你的CLI，像任何地方，如果你有Mac，你也可以在你的笔记本电脑上写。

那太酷了。然后我们来谈谈监控。我喜欢这里所有的图表。

所以我们没有破坏任何东西。这是个好消息。我们仍然可以看到CPU仍然非常低，但它正在前进。就像，好吧，它很稳定。我们也可以看到网络。所以请求仍然是来回的。所以我们的状态很好。对吧?

是的。看起来不错。[相声00:53:03]自动的，对吗?每当我们[相声00:53:03]。

完全正确。我们可以看到，节点数，现在显示为2，但当我配置时，它是1到5。所以当CPU或者CPU超过某个阈值时，它就会为我们启动一个新节点。毕竟这是一个视频管理集群。这是有好处的。

这是惊人的。太神奇了。

所以我很开心。因此，实际上，只要有了YAML，我们就能够获取代码，并基本上每次推送它……所以我们重新运行CI/CD，管道。

正确的。

我们手动触发了工作流。但每次向master推送一个新版本时，会发生什么呢，它会使用新代码我们可能只是改变了服务中的一些东西。对吧?

正确的。

在服务中。

完全正确。

Kubernetes集群中引入的服务之一。那实际上会构建它，Docker构建，把它推入Artifactory，扫描它和它的所有参数。然后，在下一步中，我们将自动返回到Artifactory，从那里获取发布的映像并将其部署到Kubernetes集群。所有这些都是

是的，我想我们花了40条免费线。类似的东西?超级简单。[相声00:54:21]自动的。这是惊人的。

事实上，它可以引用呼吸请求，就像它在Artifactory上发布的图像一样。我喜欢它。

如此简单。我喜欢它。是的。好吧。今天就到这里吧。

是的。你们也去看看吧。这里有一个链接，巴特尔在实际的研讨会上花了很多功夫。你可以使用JFrog的免费授权，也可以使用Azure的免费订阅。对吧?

是的。

然后试着测试一下。

是的。所以当你测试它的时候，你会得到完整的。你可以在本地运行它。这样你就有了所有的信息，所有的指令。你可以在这里看到我们今天讨论的内容。你会有一些先决条件和一些你想要运行的信息，我们希望你会喜欢它。我觉得是

我们相信你会喜欢的。来吧。

我们确定。对不起。

我们喜欢自己做。

我们很喜欢它。

所以，如果你遇到任何困难或遇到任何问题，我们是信任的，伙计们。我们确定你会没事的。但为了以防万一，我们来了。现在就来问我们问题，或者稍后发给我们。我们有空。

是的。非常感谢你们今天的到来。

谢谢你！我很喜欢，巴特尔。谢谢你！

我知道。非常非常感谢你，Shiri。祝你今天愉快。

再见。

再见。