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