今天我在这里和大家一起讨论一些关于使用DevOps生产软件的基础知识，以及如何使用Red Hat的Openshift管道和JFrog artifactory来修复开发管道中的漏洞。
让我们开始吧。
我想从描述现代软件开发周期开始，我们今天如何生产软件。
主要有三个阶段。
第一步是采购。
这是我们作为开发人员花费大部分时间的地方，我们搜索并利用可重用组件。
所以我们可以避免从头开始写所有东西。
这可以是框架、工具集，可以是开源社区中所有可用的东西。
我们可以在不同的注册中心、NPM、Docker hub、Maven Central等中找到它们。
然后我们再利用它们。
但这些代码不是我们自己写的。
所以它带来了一些问题，比如，我们如何在版本、元数据方面正确地管理它们，使用了什么，我们如何知道它是好的，等等。
显然，还有第三方组件的治理和遵从性。
我们的组织允许我们使用什么?
这些软件包中是否存在潜在的漏洞?
这是目前网络攻击组织最喜欢的载体之一。
接下来是发展。
几十年前，这就是我们循环图的全部，那时人们大部分(如果不是全部)代码都是从头开始编写的。
但是，我们编写的代码越来越少。
我们最近写的大部分内容都是独立组件之间的集成，Tyler Jewel喜欢将其称为缝合操作。
我们仍然知道如何编写代码，如何构建代码，以及如何测试代码。
它仍然是软件生产的核心。
但是我们编写的代码数量正在减少。
第三步正变得越来越重要，那就是分销。
当您听到持续交付和持续部署这两个术语时，您可能会想到这一点。
但这并不是唯一的分销目标。
你和其他团队一起发布你写的东西，可下载的软件，然后，当然，对开发来说，边缘和物联网发布是相对陌生的。
这是大局。
让我们看看这与DevOps有什么关系。
首先，让我们通过我的婚姻建立一些关于DevOps的概念。
多年来，我和妻子结婚后发现，为了两个人和谐地生活在一起，合作和沟通是必须存在的。
DevOps也是如此。
开发人员和运营人员一直存在分歧，因为他们在指责谁、赞扬谁或谁能得到最大份额的预算上存在分歧。
DevOps就是要消除那些消极的态度，并部署工具，这使得两个团队能够以相对较少的冲突一起工作，有助于确保
协作和沟通，这对于一个高效运作的团队来说是非常重要的。
实际上，DevOps不是一种工具，而是一种文化。
DevOps流程运行的最佳指标很容易衡量。
它应该把开发人员和运维人员结合在一起，这样他们就可以一起工作，以尽可能快的速度完成软件开发生命周期，并在最后达到最高质量。
无论你是DevOps实践的新手还是已经实施了多年的老手，你都可能听说过CI\CD、持续集成和持续交付。
它是DevOps运动中最突出的实践之一，通过将自动化引入应用程序开发的各个阶段，着重于频繁地向客户交付应用程序。
在实践中，CI\CD在应用程序的整个生命周期中引入了持续的自动化和持续的监控，从集成和测试阶段到交付和部署。
总之，这些相互关联的实践通常被称为CI\CD管道，并由开发和运维团队以敏捷的方式通过DevOps或站点可靠性工程或SRE方法一起工作来支持。
现在来看几个定义。
持续集成是开发人员的自动化过程。
成功的CI意味着定期构建应用程序的新代码更改。
测试并合并到共享存储库。
这是一种解决方案，可以同时开发应用程序的太多分支，这些分支之间总是会发生冲突。
持续交付指的是将变更自动发布到阶段和预生产环境中，然后通过运营团队或发布经理的批准将变更部署到生产环境中。
它解决了开发人员和业务团队之间的低可见性和沟通问题，自动化了减慢应用程序交付的手动步骤。
持续交付的目的是确保部署新代码所花费的工作最少。
持续部署，这是另一种可能的CD，类似于持续交付。
但是，更改会自动部署到生产环境中，无需人工干预。
这听起来很棒，但是您可能仍然会看到在这些阶段中插入了许多工具。
因此，让我们看看Openshift和JFrog是如何最小化这些问题的。
首先，让我们谈谈Openshift。
Openshift是Kubernetes，但它具有每个成长中的企业都需要的安全性、稳定性和支持。
它是许多人在应用程序开发和应用程序构建中使用的工具。
我们在Openshift上所做的，特别是在最新版本的Openshift 4上，我们构建了这个庞大的操作符框架。
操作员框架有效地将工程知识封装在易于部署、可靠和可重复的最终产品中。
运营商允许我们做的是确保我们与JFrog等合作伙伴以及其他流程和开源项目高度集成。
这样你就可以开始在Openshift内完成CI CD流程。
Openshift可能是基础层，是您在应用程序开发过程中要利用的容器技术。
但是我们已经用这个运算符框架做了我们所能做的一切，以确保我们与你可能使用的其他工具高度集成。
让我们从三个高能级的开始。
当然，还有很多，JFrog就是其中之一，我们将对其进行回顾
再过几分钟。
但是让我们从Openshift构建开始，我们谈论的是一种Kubernetes本地方式，以确保您在Openshift上构建容器映像，然后这些映像可以在任何Kubernetes发行版中移植。
所以它保证了你可以有这种可移植性，你可以扩展你的构建策略到其他Kubernetes构建，或者在你前进的过程中你自己的定制构建。
它还支持多种构建策略。
下一个是Openshift管道，它基于开源项目Tekton, Tekton，有个K。
这是一个Kubernetes本地CI\CD管道，我们已经集成到产品中，这样你就可以通过这个管道来推动你的开发，并确保你已经准备好使用Openshift了。
最后是Openshift GitOps，这是最近发布的，我们用GitOps所做的是给你一个声明性的方式，以确保你可以持续地构建和交付你所拥有的功能。
因此，它与Openshift管道等其他特性紧密集成，使您能够将Git作为惟一的真实来源进行构建，并通过管道以更快的方式将最终产品投入生产。
现在，更详细地了解Openshift管道。
它被包装成一个带有openshift的运算符。
所以你可以打开openshift的操作中心，免费下载并开始使用。
它是一种声明性的CI\CD方法，构建在前面提到的为Kubernetes构建的开源项目Tekton之上。
它是一个云原生管道，利用了Kubernetes的执行、运营模型和概念，并允许你按需扩展，因为你有多个管道在运行，每个管道都单独隔离在容器中。
这极大地提高了可重复性。
而且它还为您提供了一些保证，确保您正在构建的内容不会受到其他构建的影响。
我相信你们都熟悉测试中的“It works on my machine”问题。
这有助于确保您不会遇到“它在我的构建服务器上工作”，因为对可用和配置的软件和工具的假设。
它还内置了Kubernetes R-Back和其他模型的安全性，确保您能够跨管道和工作负载持续工作。
它还为您提供了在Kubernetes上工作的灵活性，并在您构建开发管道时支持您的确切需求。
现在，让我们把所有内容放在一起，讨论从软件到产品的整个过程。
所以一切都从开发者开始。
第一步是采购。
采购是在互联网上寻找开发人员想要使用的依赖项，然后基本上声明它们以及开发人员使用的任何构建工具或依赖项管理器。
然后它被声明为一个依赖，例如，一个go源文件，或者你可以在Docker文件中添加它们作为一个from指令。
一旦他们尝试在本地构建，发生的第一件事就是这些依赖关系试图被解决。
组织可以设置自己的私有存储库管理器或注册表管理器，从中获取所有源代码。
在JFrog Artifactory的情况下，它将知道如何获得远程注册表，存储库或依赖关系的来源，并将它们引入并缓存它们，当它们被使用JFrog Xray验证为安全合规时，它通过使用信息源(如JFrog的)，内部漏洞和许可证数据库扫描和分析进入JFrog Artifactory的所有内容，但也包括来自互联网的数据库，包括专有数据库，如VulnDB。
一旦开发团队编写了所有依赖项和围绕它的所有集成粘合剂，就可以在源代码控制中进行检查了。
提交是下一步。
这就是CI服务器发挥作用的地方。
在我今天使用的例子中，我们将使用Openshift管道，管道将运行与开发人员在本地运行的完全相同的构建，我们将使用管道的一个附加组件，那就是JFrog COI。
当我们需要集成CI服务器时，COI可以提供帮助，目前CI服务器还没有与JFrog进行开箱即用的本地集成。
下一步是解析来自JFrog artifactory的所有依赖项，它们都将被成功解析，因为它们已经被artifactory缓存了。
然后在构建成功之后，CI服务器将在这里部署它所构建的内容，这包括模块，还包括关于如何创建工件的所有元数据。
这就是JFrog ci发挥作用的地方，它将首先收集有关构建的所有信息，使用了哪些依赖项，哪些环境变量是活动的，产生了哪些工件，等等，并收集所有这些信息，将这些信息与工件一起部署到工件中作为元数据，当我们做出关于推广的决定时，我们可以依赖这些元数据。
这就是晋升过程开始的地方。
提升过程是获取工件，测试它们，并最终将它们通过注册表或存储库从一个回购转移到另一个。
这是通过测试完成的，然后贡献越来越多的元数据，然后根据元数据决定是否应该推广新的构建。
在一天结束的时候，我们的真正目标是让我们的代码投入生产。
不同的用例有不同的分布。
例如，JFrog分布到JFrog边缘，这是较小边缘设备的分布目标。
或者就像在今天的例子中一样，我们将把容器运行时部署到生产集群中，在我们的例子中，容器运行时位于Openshift上。
这是你的大局。
在前面的幻灯片中，我提到了JFrog扫描漏洞的能力。
今天，红帽的客户正在升级有关在客户漏洞扫描工具中发现的红帽容器和包的漏洞风险差异的问题。
例如，一个客户用REL 7的基本映像构建了一个容器，他们注意到REL 7的运行状况指数为。
然后他们使用x射线扫描他们的图像，扫描工具表明图像有例如，严重或高度漏洞。
恐慌接踵而至，红帽公司的支持者又得到了一张罚单。
帮助解决这些挑战。我们的安全部门已经创建了一个漏洞扫描认证，并确保我们的合作伙伴扫描工具正在使用红帽安全OVALV2数据源，正确识别RPM安装的文件，确定哪个产品安装了RPM，以确定正确的严重性、状态和修复，因为CDE可以以不同的方式影响不同的产品。hth华体会最新官方网站
最后显示红帽数据在他们的UI和扫描报告，包括红帽的4点规模的影响，以及红帽安全url。
我们已经在这方面与JFrog合作，他们现在是我们第一批获得漏洞扫描认证的合作伙伴之一。
由于时间关系，我们需要缩短我们通常的演示，所以你今天不会看到任何现场直播。
但如果你想看到一些现场，请联系JFrog并要求一个演示。
我们来谈谈我们的例子项目要做什么。
我们会创建一个NPM应用程序，我们会做NPM，安装并从artifactory获取所有资源，然后发布，我们会打包部署。
接下来，我们将进行Docker构建并推送到注册表，在本例中是在artifactory上。
然后有了构建信息，我们会用X射线扫描它，然后最终在Openshift上部署它。
这就是管道本身的样子。
您可以看到，与任何正确的构建管道一样，它是分阶段构建的，这一点我们刚刚讨论过。
我们有一个git克隆，然后我们配置JFrog COI，这是RT-config，然后配置NPM从Artifactory获得依赖。
这是我们可以保证它们被扫描并且没有已知漏洞的地方。
接下来是NPM install，然后是NPM publish，它将发布的图像放到Artifactory中。
最后，我们有构建发布，在这里我们也将构建元数据发布到Artifactory。
我们之前提到过JFrog COI，所有与您的包相关的东西都通过JFrog COI进行管理。
它可以与任何工具一起使用，不仅仅是与Openshift管道，它管理JFrog Artifactory, JFrog X射线和其他JFrog工具。
它有很多作用。但是今天在我们的例子中，它要做的是包装构建工具，允许我们通过JFrog COI发出NPM命令。
这就是我们如何保证JFrog COI知道我们构建中发生的一切，它将收集所有必要的信息，哪些工件被上传，下载，哪些依赖关系被使用，然后最后，它将把它们推送到Artifactory。
这个工具的大部分用法就是这样。
您为CI\CD配置了自动化脚本，然后您就可以洞察到正在发生的事情以及那些作为服务运行的封闭盒子，它有效地成为您自己的私人间谍，为您收集有价值的信息，然后将这些信息与工件一起部署在一个方便的包中。
让我们看看演练环境是什么样的。
在本例中，我们的集群部署在GCP上。
我们还通过运营商部署了Openshift管道。
我们还部署了一个artifactory安装，它也是使用artifactory操作符安装的。
当我们应用管道时，我们将构建NPM应用程序，构建Docker映像，然后将该Docker映像部署到相同的集群中。
它会显示为一个部署舱。
然后，当我们通过路由公开部署时，我们可以看到应用程序正在运行。
所以在我们的演练中，这里是我们的人工装置通过这些豆荚运行。
同样，这是通过操作员集线器部署的。
一旦安装了它，就会得到一个高可用性安装。
所以我们有了NGINX前面的初级和次级。
让我们看看在Openshift集群上运行的artifactory安装。
我们已经为这个例子设置了一些回购。
有一些NPM回购，一些本地回购，一些远程回购，其中artifactory充当NPMJS的代理，还有本地和远程Docker注册表。
现在我们的回购，在GitHub上是公开的。
所以，请随意跳转到github.com/JFrogTraining/red-hat-openshift-tekton去亲眼看看。
让我们看一下管道YAML。
这是Openshift管道定义。
它的设置方式是你有几个可重用的任务，你
可以将这些任务放到你的管道YAML文件中，这些任务是我们将用于CI\CD管道的有效不同步骤。
我们有一个git克隆步骤，它克隆前面提到的repo，这是一个任务。
然后，下一个任务是通过Docker镜像配置JFrog COI。
然后我们配置NPM。
然后是NPM install，它会从artifactory中删除所有依赖项。
然后是NPM发布，它将获取依赖项并打包应用程序，然后将它们发布到artifactory中的NPM存储库中。
我们将在步骤完成后发布一些构建信息。
然后我们进行构建和部署来部署应用程序。
这本质上是使用构建来处理实际的Docker映像构建和推送。
然后我们在下面这里有实际的管道定义我们引用的地方
所有我们布置的任务。
为了部署管道，我们只需使用带有OCapply-pipeline的open shift命令行。
YAML-n，然后是名称空间。
你可以把OC看作Openshift版的“鸡笼拥抱”。
部署完成后，如果单击Openshift控制台的管道区域，就会看到管道。
如果我们点击tasks，你会看到组成管道的单个任务。
您可以点击进入每一个，以获得更多的信息。
如果我们点击进入我们的管道，它会向我们展示管道的每个步骤的漂亮的可视化表示。
Git克隆，rtq配置，JFrog COI, NPM配置，安装，发布，然后构建和发布，将镜像推送到Artifactory，然后部署。
为了执行它，我们需要运行命令OCapply-fpipeline-run.YAML-n[命名空间]。
因此，让我们看看这里运行YAML文件的管道。
这将创建一个管道运行资源。
让我们看看代码是什么样的。
如您所见，这非常简单。
我们使用的框架是声明的步骤放在一起，基本上只是分配一些值。
一旦我们运行我们的应用程序，它启动管道。
一旦管道启动，我们就可以监控它的进展。
这包括查看每个步骤的日志的能力，这无疑有助于调试。
一旦我们使用NPM publish发布应用程序，它就会被推送到artifactory。
如果我们返回到artifactory，我们可以检查构建，并获得应用程序中所有内容的一些非常细粒度的细节。
一旦管道的其余部分完成，我们的应用程序现在就可以在Openshift中部署了，我们要做的就是公开一个路由。
我们来总结一下。
我们希望这有助于可视化构建DevOps管道的意义。
这是一种不同的思考方式，它不仅仅是文化，而是我们可以实施的实际实践。
我希望您能够了解如何同时使用JFrog和Openshift来帮助完成并自动化这个过程，使其尽可能无缝。
非常感谢大家抽出时间收看今天的节目。
你可以在讲义中找到回购的链接。
如果您想现场演示JFrog和Red Hat可以做什么，请与我们联系，我们将设置一些东西。
我谨代表红帽公司全体员工祝你们好运。保持安全，不要忘记，不断创新。
谢谢你！
