DevOps管道:Red Hat OpenShift CI/CD管道与Artifactory和Xray [swampUP 2021]

早上好，下午好，晚上好，
这取决于你在哪里。
我叫Phil Lamb，是DevOps高级解决方案架构师
为红帽的全球合作伙伴和联盟集团。
我在德克萨斯州的达拉斯沃斯堡地区工作。
在担任这个职位之前，我做了15年多的专业开发人员，
我对DevOps、敏捷、自动化充满热情，
基本上，所有能让我尽可能偷懒的东西都能让我写出好的代码。
今天我在这里和大家谈谈使用DevOps制作软件的一些基础知识，
以及如何使用红帽的Openshift管道和JFrog artifactory
您也可以修复开发管道中的漏洞。
让我们开始吧。
我想从现代软件开发周期的描述开始，
我们今天是如何开发软件的。
主要有三个阶段。
第一步是采购。
这是我们作为开发者花费大部分时间的地方，
我们搜索并利用可重用的组件。所以我们可以避免从头开始编写所有内容。
这可以是框架、工具集，实际上可以通过开源社区获得的任何东西。
我们可以在不同的注册表、NPM、Docker hub、Maven Central等中找到它们。
然后我们再利用它们。
但这些代码并不是我们自己写的。
所以它带来了这样的担忧，
我们如何在版本、元数据、
用了什么，我们怎么知道它是好的，等等。
显然，存在第三方组件治理和遵从性。
我们的组织允许我们使用什么?
这些软件包中是否存在潜在的漏洞?
这是目前对组织进行网络攻击最喜欢的媒介之一。
接下来是发展。
几十年前，这就是我们的整个周期图，
回到人们从头开始编写大部分(如果不是全部的话)代码的时候。
但是我们写的代码越来越少。
我们现在写的大部分内容都是不同组件之间的集成，
泰勒·朱厄尔喜欢称之为缝合行动。
我们仍然知道如何编写代码，如何构建代码，以及如何测试代码。
它仍然是软件生产的核心。
但是我们编写的代码量正在减少。
第三步，也是越来越重要的一步，就是分销。
当您听到持续交付和持续部署这两个术语时，您可能会想到这一点。
但这并不是唯一的发行目标。
把你写的东西分发给其他团队，
可下载软件，当然，还有相对较新的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方法，建立在前面提到的开源项目Tekton之上
为Kubernetes构建的。这是一个云原生管道
它利用了Kubernetes的执行、操作模型和概念
并且允许您在运行多个管道时按需扩展
每条管道都被单独隔离在容器里。
这极大地提高了可重复性。
它还可以保证您正在构建的内容不会受到其他构建的影响。
我相信你们都熟悉测试中的“It works on my machine”问题。
这有助于确保你不会遇到“它在我的构建服务器上工作”，
因为对可用和配置的软件和工具的假设。
它还内置了Kubernetes R-Back的安全性
以及其他模型，确保您始终跨管道和工作负载工作。
它还为您提供了在Kubernetes上工作的灵活性，并支持您的确切需求
因为你正在建立一个开发管道。
现在让我们把所有的东西放在一起，谈谈整个软件之旅
一直到生产。
所以一切都从开发者开始。
第一步是采购。
采购就是浏览互联网，找到开发人员想要使用的依赖项，
然后基本上声明它们以及开发人员使用的任何构建工具或依赖管理器。
然后将其声明为依赖项，例如在go源文件或
你可以把它们作为from指令添加到Docker文件中。
一旦他们尝试在本地构建，首先发生的事情就是这些依赖关系试图被解决。
组织可以建立自己的私有存储库管理器或注册中心管理器
他们从那里获得所有信息。
在JFrog artifactory的案例中，
它将知道如何访问依赖项的远程注册中心、存储库或源
把他们带回来藏起来
当它们被JFrog x射线验证为安全且符合要求时，
扫描和分析进入JFrog人工制品的所有东西
通过使用信息源，如JFrog的内部漏洞和许可证数据库，
还有互联网上的数据库，
包括像lol dB这样的专有软件。
一旦开发团队编写了所有的依赖项和围绕它的所有集成胶，
它已经准备好在源代码控制中进行检查。
提交是下一步。这就是CI服务器发挥作用的地方。
在我今天要用的例子中，
我们将使用Openshift管道
管道将运行开发者在本地运行的完全相同的构建，
我们要使用的管道中还有一个附加功能，那就是JFrog COI。
当我们需要集成CI服务器时，COI可以提供帮助
它目前还没有与JFrog进行开箱即用的本地集成。
下一步是解析JFrog artifactory中的所有依赖项，
它们都将被成功解析，因为它们已经被artifactory缓存了。
然后在构建成功之后，
这是CI服务器将部署它构建的内容的地方，
这包括模块，还包括关于如何创建工件的所有元数据。
这就是JFrog ci发挥作用的地方，
它将首先收集有关构建的所有信息，
使用了哪些依赖项，哪些环境变量处于活动状态，
制作了哪些文物，等等，收集所有这些信息，
将带有工件的信息作为元数据部署到工件中
当我们做出关于晋升的决定时，我们可以依靠它。
这就是晋升过程的开始。
推广的过程是获取文物，
测试它们，并最终通过人工的注册中心或存储库移动它们
从一个回购到另一个回购。
这是通过测试完成的，然后贡献越来越多的元数据，
然后根据元数据做出决定，
新版本是否应该推广。
在一天结束的时候，我们的目标确实是让我们的代码进入生产环境。
不同的用例有不同的发行版。
例如，JFrog分布到JFrog边缘，
它们是小型边缘设备的分发目标。
或者在今天的例子中，
我们将部署到一个生产集群
一个容器运行时，在我们的例子中是在Openshift上。
这是你的大蓝图。
在上一张幻灯片中，我提到了JFrog扫描漏洞的能力。
今天，红帽的客户正在升级关于与
红帽容器和包的漏洞风险
在客户的漏洞扫描工具中发现。
例如，一位客户用REL 7的基本图像构建了一个容器，
他们注意到REL 7的健康指数为a。
然后他们用x射线扫描他们的图像，扫描工具表明图像有例如，
严重或高漏洞。
恐慌随之而来，红帽的支持又得到了一张罚单。
帮助解决这些挑战。我们的安全部门已经创建了一个漏洞扫描器认证
并确保我们的合作伙伴扫描工具正在使用红帽安全OVALV2数据馈送，
正确识别rpm安装的文件，
确定安装RPM的产品
以确定正确的严重性、状态和修复
因为CDE会以不同的方式影响不同的产品。hth华体会最新官方网站
最后在他们的用户界面和扫描报告中显示红帽的数据，包括红帽的4分影响量表，
以及红帽安全url。
我们已经和JFrog合作过了，他们现在是
第一个获得漏洞扫描认证的合作伙伴。
由于时间关系，我们需要简化我们通常的演示，
所以你今天不会看到任何现场直播。
但是如果你想看一些现场的东西，请联系JFrog并要求一个演示。
让我们讨论一下我们的示例项目将要做什么。
我们要创建一个NPM应用，
我们将使用NPM, install
所有的资料都来自人工工厂
然后发表，
我们将打包部署。
接下来，我们将构建Docker并将其推送到注册表，
在这种情况下是人造的。
然后有了构建信息，我们会用X射线扫描它，
然后最终将其部署在Openshift上。
这就是管道本身的样子。
你可以看到，就像任何正常的构建管道一样，
它是建立在舞台上的，我们刚刚讨论过。
我们有一个git克隆，然后我们配置JFrog COI，这是RT-config，
然后配置NPM从artifactory获取依赖项。
在这里我们可以保证它们被扫描，没有已知的漏洞等。
接下来是NPM安装，然后是NPM发布，这将发布的映像放到artifactory中。
最后，我们有构建发布，在这里我们也将构建元数据发布到工件。
我们之前提到过JFrog COI，
与您的包相关的所有内容都通过JFrog COI进行管理。
它可以与任何工具一起使用，不仅仅是与Openshift管道，
它管理JFrog artifactory, JFrog X射线和其他JFrog工具。
它有很多作用。但是在我们今天的例子中，它要做的是包装构建工具，
允许我们通过JFrog COI发布NPM命令。
这就是我们如何保证JFrog COI知道我们构建中发生的一切，
它会收集所有必要的信息，
上传、下载了哪些工件，使用了哪些依赖项
最后，它会把它们推到人工体内。
这个工具的大部分用途就是这样。
您可以为CI\CD配置自动化脚本，
然后你会深入了解正在发生的事情，以及那些作为服务运行的封闭盒子，
它实际上成了你的私人间谍，
为您收集有价值的信息
然后将这些信息与工件一起部署到一个方便的包中。
让我们看看演练环境是什么样的。
在本例中，我们的集群被部署到GCP上。
我们还通过运营商部署了Openshift管道。
我们也部署了一个人工安装，它也是使用人工操作器安装的。
当我们应用管道时，我们将构建NPM应用，
构建一个Docker镜像，然后将该Docker镜像部署到同一个集群中。
它会以一个吊舱的形式出现。
然后当我们通过路由暴露部署时，
我们可以看到应用程序正在运行。
在我们的演练中，
这是我们通过这些pod运行的人工安装。
同样，这是通过运营商集线器部署的。
安装它后，您将获得高可用性安装。
所以我们有一个主要的和两个次要的NGINX前端。
让我们看看在Openshift集群上运行的人工安装。
我们已经为这个示例设置了一些仓库。
有一些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映像构建和推送。
下面是管道的定义
在这里我们引用了我们布置的所有任务。
为了部署管道，我们只需使用open shift命令行
OCapply-pipeline。YAML-n，然后是名称空间。
您可以将OC视为Openshift的“鸡笼拥抱”。
一旦部署完成，如果您点击Openshift控制台的管道区域，
你会看到管道。
如果我们单击tasks，您将看到组成管道的各个任务。
你可以点击每一个来获得更多的信息。
如果我们点击我们的管道，它会向我们展示管道的一个很好的可视化表示，
每一个步骤。
Git clone, rtq config, JFrog COI, NPM config，
安装，发布，然后构建和发布，
将映像推送到artifactory，然后部署它。
为了执行它，我们需要运行命令OCapply-fpipeline-run.YAML-n[namespace]。
因此，让我们看一下在这里运行YAML文件的管道。
这将创建一个管道运行资源。
让我们看看代码是什么样子的。
正如你所看到的，这很简单。
我们把框架声明的步骤放在一起
基本上就是赋值。
一旦我们运行应用程序，它就会启动管道。
一旦管道启动，我们就可以监控其进度。
这包括查看每个步骤的日志的能力，这肯定有助于调试。
一旦我们使用NPM publish发布应用程序，
它被推到人工工厂。
如果我们点击回到人工工厂，
我们可以检查构建并获得一些非常细粒度的细节
关于我们应用程序中的所有内容。
一旦管道的其余部分完成，
我们的应用程序现在可以在Openshift中部署
我们要做的就是在人们面前暴露一条路线。
我们来总结一下。
我们希望这有助于可视化构建DevOps管道的意义。
这是一种不同的思考方式，
这不仅仅是一种文化，而是一种我们可以实施的实际做法。
我希望你能看到如何使用JFrog和Openshift
帮助完成并自动化这个过程，使其尽可能无缝。
非常感谢大家抽出时间观看今天的节目。
您可以在注释中找到到回购的链接。
如果你想现场演示JFrog和红帽的功能，
跟我们联系，我们会安排的。
所以我代表红帽的所有人，
祝你好运。保持安全，不要忘记，不断创新。
谢谢你！