演示-跳你的代码从Github到Azure与JFrog平台

蔚蓝的一天。

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

我爱我的小狗。正如你在图片中看到的，我有两只非常漂亮的狗狗，我喜欢玩一些棋盘游戏。所以如果你以后想找我，或者只是想讨论Kubernetes、DevOps或其他任何事情，我很有空，我很乐意讨论。这是我的领英邮箱和推特。Shiri，再次感谢你的加入。我真的，真的很感激。

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

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

你会成功的。

我会到达那里的。

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

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

我们这里的第一件事当然是我们的vc，我们的源代码控制。不好意思，是我们的源代码。我们有Artifactory作为我们的主要存储库管理器。我们将讨论一下为什么要使用Artifactory，以及Artifactory到底是什么。我们有x光。这有助于我们保护并确保我们没有任何在我们组织内部不允许的开源许可证。我们有JFrog Distribution和Connect用于部署，并能够将其部署到不同的版本、服务器，甚至一些物联网设备。最重要的是，我们有任务控制中心。这有助于我们监视和配置我们的服务。我们有用于CI/CD的JFrog管道。 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服务器，它还支持通用存储库，这是一个非常非常酷的特性。所以如果你没有看到一个logo，你已经在使用作为前端开发人员-

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

不过，如果您发现了一些在这里看不到的东西，并且您真的想要集成，那么您总是可以使用您的通用存储库。通用存储库将为您提供创建您想要的任何存储库的能力，以及您想要获取依赖项的任何URL，然后您就可以在Artifactory内的一个地方拥有所有东西。

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

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

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

还有积分。因此，我们正在为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射线实际上是一种保护我们免受人工工厂安全问题的工具。对于Xray，我们也有用户插件。例如，对于VS代码，我可以下载插件。举个简单的例子。当开发人员看到已经修复的版本时，他可能会使用不包含安全漏洞的新版本，我们将移动任何东西-

这样就容易多了。对吧?

是的。

所以我们将在开发阶段向开发人员展示，嘿，伙计，你正在使用一个已知漏洞的版本。你依赖于这个和那个包。请把它换掉。在你开发的时候就这么做要容易得多，而不是在它已经是DevOps的包的时候，而且肯定比在已经处于生产状态的时候做要好得多。

不，那太疯狂了。

是的。

没有人愿意那样做。

所以正确的。

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

及早发现。

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

所以正确的。

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

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

是的，当然。我们有自己的机制，我们也有CVSS分数，它让我知道CVSS分数是多少，它有多关键。我们也会在演示中展示。

但是基本的概述是这样的。首先，这里有我们的数据库，Xray数据库每隔几个小时就会更新一次我们的团队每次都会收集越来越多的数据。然后我们要去寻找所有的藏物，实际上是我们这里的每一个包。我们叫它。让我们提取它。对吧?我们将从每一层中提取它，例如，从docker映像中，我们将扫描它。所以当我们扫描它的时候，我们有策略和监视。我们想做什么，到哪里去找。对吧?

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

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

当然，一切都是自动的。我们有自动动作。我们不需要一次又一次地这样做。我们只配置了一次，所有的配置都在我们的平台中。这里我们还可以阻止下载等等。到目前为止有什么问题吗?

不，那太酷了。

好了,好了。

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

哇。

是的。提供他们令人惊叹的软件，无论他们做什么，都能把它们放在我们的云上。它的美妙之处在于，你再一次看到这里有不同的许可等级，不同的产品，他们都在说，现在就得到它。这意味着这是一个transACT解决方案。

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

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

试一试，看看它是如何工作的。

是的,没错。这很简单。你只需点击它，你就有了一切。我喜欢这个解决方案。看看这个。你有很多选择，而且远远不止这些。你刚截取了一张屏幕截图，但我记得我们有不止12个选项。这非常简单。去试试吧。我们希望你们会喜欢它，并在这节课上检查它。

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

是的。

对吧?每一个-

很简单。

…你们每个人可能每周、每月或每个季度都要面对，无论何时你们推出了一个新版本。假设你有你的代码，你在GitHub中有你的容器。然后将新版本推到容器映像的主文件中。现在你想要构建它，并将其部署到Kubernetes课堂生产中。因此，我们将展示如何利用GitHub操作，这本质上是微软的CI/CD工具。因此，您可以通过JFrog CLI, JFrog命令行，将新版本的代码推入存储库，构建Docker映像并将其推入Artifactory。并且还将展示如何如此多的酷参数从GitHub映射到JFrog平台到Artifactory与实际的图像。对吧?

是的。

我们来看看它是如何工作的。然后，当图像已经推送到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上运行它，看看它是如何运行和返回的。

祈祷。

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

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

是的。但是稍等一下。在此之前，让我们进入存储库，因此无论何时他们将运行研讨会，他们将看到他们在这里有什么。

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

是的。

是的，我认为这是最酷的事情之一。所以就像我们说的，我认为，这是关于将开发人员，开发ops人员的经验带到他已经具备的水平。所以无论如何要扫描藏物所在的地方。同样的，GitHub工作流，本质上是CI/CD管道，被存储。正如您在创建新工作流的那一刻所看到的，在为您创建的新文件夹中，它与您的代码一起存在。因此，在您的代码中，我们还保存YAML，它告诉您当新版本被推送或提交到主分支时，这段代码发生了什么。它只是把CI带到代码所在的地方。

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

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

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

我们只是不想运行它，因为它会花一些时间。[crosstalk 00:22:41]让我们进行视图运行。

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

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

是的。让我们以大脑为例。这就是你刚才描述的构造块

正如你们之前看到的，Batel在这个问题上讲得很快，但其中一些并不适用于我们，没关系。稍后我们会向你们展示这个运行得很好，但是你们可以很快看到它失败的地方。对吧?

正确的。

因为你看到每一步都很顺利，然后你看到一个绿色的小圆圈。当它不能工作的时候，你就能看到哪里发生了冲突，哪里崩溃了，然后缓解它。

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

我们工作了一整天才把它弄好。但这里我们将重新运行它，当它在后台运行时，让我们看看实际的代码及其功能。

好吧。让我们从这里可爱的YAML回到工作流。

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

正确的。

这里我们决定，这里你将使用GitHub上所有我们都知道的基本事件，比如推送，提交，池。你也可以说，我想让它推送到一个特定的分支。

正确的。

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

让我们进入GitHub市场。你可以看到这里有很多不同的动作。所以无论什么时候我需要配置一些东西，首先，我可以搜索它。

也许是有人干的。

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

回收对环境有好处。

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

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

太棒了。

为了使用它，但通常像你这样的软件供应商会提供一个动作，这是如何做到这一点的官方方法，这个动作是我们实际使用并嵌入到代码中的。这里我们称之为，对吧?如你所见，我们确实使用了这个，那意味着，使用意味着我们实际上调用了这个特定的动作。这一切都是为了能够使用JFrog CLI。所以它是JFrog命令行，直接从我们的管道执行。从我们的GitHub工作流作为一个动作。这是因为我们现在想问，我们要连接的Artifactories是什么?我们希望能够使用实际的CLI命令。稍后你会看到，我们可以使用一些。你看这个，jfrog。rt。巴特尔告诉我这基本上代表JFrog

Artifactory。

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

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

告诉我们如何连接到你的手工工厂，巴特尔。

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

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

是的。

你只需要复制。

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

URL是整个平台的，对你来说，你拥有所有服务的所有许可。我们可以看到，它不仅适用于Artifactory，也适用于Xray，适用于发行，适用于一切。对吧?

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

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

你是对的。

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

完全正确。JFrog CLI使用这个令牌，导出关于Artifactory服务器的不同信息，等等。我可以运行jfrogcexport和这里的服务器ID。这是我的代币。

哇。

是的，我们做到了。

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

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

不。

你有那么多疯狂的故事。

是的。但是，巴特尔，你知道怎么做正确的事。

哦，谢谢。

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

什么,是的。

在你的代码里?

是的。我们首先要用到的是GitHub Secrets。对吧?我们有一个很好的机制来保守我们的秘密，以确保我们的安全，没有人能看到我们的特殊标志或我们的秘密。那样的话——

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

是的。

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

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

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

是的。

超级。

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

当缩进正确时。

是的。

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

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

因为它一直在断裂，然后在第102行，我又一次不小心撞到了空格。

但是看看它。太酷了。

当它工作的时候，它很漂亮。我同意。

现在起作用了。太棒了。

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

对，默认是到根目录。

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

如此尴尬。

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

对于虚拟存储库，完全正确。

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

你是对的。正确的。

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

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

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

我们也可以使用Docker推送，但如果我们要使用Docker推送，我们将无法收集环境变量。你们还记得我给你们看过我们收集的所有信息吗，这些信息很重要，我们可以很容易地追踪到。我们想要确保我们将来有这些信息。因此我们使用jf rt Docker push。我们将使用JFrog CLI来实现这一点。

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

是的,没错。更重要的是，每当我们使用JFrog CLI时，我们都会检查校验和基础机制。如果我们已经在Artifactory里面有这个神器

如果一点都没变-

是的,没错。

我们不想换掉它，只会占用更多空间。

完全正确。空间、时间和一切。它会快得多，因为我们已经在Artifactory内部安装了它。

超级酷。所以我肯定会用你们的答案。

嘿,酷。

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

是的,没错。

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

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

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

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

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

是的,当然。我很喜欢。

是啊，太酷了。最后一个显然是实际的部署。这就是它的美妙之处。你可以看到，我真正喜欢的是我们在这里说我们将从，我们在这里给出的是到Artifactory图像域的链接。不只是针对Artifactory实例，还是针对虚拟Artifactory。对吧?

正确的。

然后是真正的AKS。因此，我们引用的是我们构建和发布的这个非常特定的映像，我们希望现在将它部署到AKS集群。我们给出了部署YAML来指定技术细节[串音00:37:24]和吊舱规格。但我们在这里实际上是在说，回到我们三步前建立的图像。对吧?

是的。

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

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

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

正确的。

我们在构建主机之前已经看到了这一点。它是由GitHub提供给你的，我认为你对它有新的可见性。难以置信的

这真的非常非常酷，以防你需要做后面的事情。看看这个。我们这里有一个绿色建筑。

哇。

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

我太兴奋了。哇。

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

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

是的。

所以请耐心等待。但通常从那时起，我们也有一些缓存机制，所以它变得越来越快。但是你也可以检查它。好像第一次就行不通似的。

这从来都行不通。

别指望它会这样。有一次，我们发现问题出在连接Artifactory上，因为我们没有使用正确的凭据。

正确的。

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

完全正确。

超级酷。

这非常非常酷。

现在我很想看看这次在Artifactory中收集了什么以及你能看到什么。

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

哇。

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

还是巴特尔(Ratnish 00:40:17)。

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

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

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

这是非常重要的，它给你的严重性。因为如你所见，这里有174条违规，而这只是一小段代码。说实话吧。

是啊，没那么大。

我只是想说，你把它排在了第一位。因为我假设临界值是10或20，这更容易解，也说得通。你知道，被174击垮了。

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

巴特尔马上就去修理，但先告诉他们问题所在。

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

这里说，就像一个[瑞士00:41:40]特定版本，这个库有…它甚至不关心什么，但它说到1.1.23，就像一个[瑞士00:41:49]特定的小版本。我们知道存在这样的问题，对吧?

是的。

所以显然我们需要改变它。要么更新它，要么实际上回滚到旧版本，但将其更改为其他版本。但现在我们要看看哪个版本是有效的。

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

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

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

一分钟我就会引用Musl。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，因为我们爱Docker。我们的工作坊是在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方向00:47:09上运行的构建号。我们可以看到SHA。我们有很多信息，这些信息非常非常重要。当我在技术支持部门工作时，我见过很多这样的情况:一台机器上工作得很好，而另一台机器上却有问题。因此，每一天，每一次，无论何时，当你在构建你的软件时，有时会有一些东西会失败。肯定的。

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

你是对的。

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

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

难以置信的哇。

是啊，太棒了。

所以我认为，回到YAML，我们可以知道我们发布了，我们构建并将容器映像推送到Artifactory，然后我们将其部署到企业。因此，让我们检查Azure上的集群，看看它是否正常运行。

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

所以好吗?

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

一切看起来都很好。是的，我相信作为一部分，顺便说一句，Kubernetes部署行动，有一个ping到他们的健康。

是的。

[IN S 00:49:18]和端点，以确保服务启动并运行。但让我们看看一切看起来都很好。现在我们在门户网站上，你有一个仪表板，上面有你所有的……这将是你最常用的Azure服务。我们将进入Kubernetes，我们可以在这里看到JFrogAKS，这恰好是我们正在使用的集群。再说一次，这是你们可以自己在课堂上做的事情。这很简单，但这里我们已经预置了。但本质上，当你使用托管的Kubernetes服务时，你就得到了完全托管、完全补丁的Kubernetes环境。

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

太酷了。

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

好的,很酷。

班长。

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

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

哦，太酷了。所以无论何时我们想要连接，我们只需点击这里，从网站上获取凭据。对吧?并掌握这些信息。

是的，你可以写，但是就像我们的命令行，你的命令行一样，如果你有Mac，你也可以在笔记本电脑上写。

这太酷了。然后我们来谈谈监控。我喜欢这些图表。

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

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

完全正确。我们可以看到这里的节点数，现在显示为2，但当我配置时，它是1到5。因此，对于[odda标量00:53:10]，本质上，当CPU或[amnumorulitization 00:53:15]超过某个阈值时，它会为我们旋转一个新节点。这毕竟是一个视频管理集群。这是有好处的。

这是惊人的。太神奇了。

所以我很开心。因此，仅仅使用YAML，我们就能够获取代码，并基本上在每一次推送中……所以我们重新运行CI/CD，管道。

正确的。

我们手动触发了工作流。但每次向主服务器推送新版本时，会发生什么呢，会有新代码我们可能会在服务中改变一些东西。对吧?

正确的。

在服役中。

完全正确。

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

是的，我们花了，我想，40条空闲线路。是这样的吗?超级简单。[相声00:54:21]自动地。这是惊人的。

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

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

是的。你们也去看看吧。这里有一个链接，这是Batel在实际的研讨会上非常努力的工作。你可以使用JFrog提供的免费授权，还有Azure的免费订阅。对吧?

是的。

试着测试一下。

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

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

我们确信。对不起。

我们喜欢自己做这件事。

我们很喜欢。

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

是的。今天非常感谢你。

谢谢你！我很享受，巴特尔。谢谢你！

我知道。非常非常感谢你，希莉。祝你有愉快的一天。

再见。

再见。