本篇文章给大家谈谈如何在容器流水线中运行多个node版本，同时本文还将给你拓展4道数学题，求解极狐GitLabCI流水线｜第2&3题：父子流水线+多项目流水线、Devops流水线中的手动测试、DevS
本篇文章给大家谈谈如何在容器流水线中运行多个 node 版本，同时本文还将给你拓展4道数学题，求解极狐GitLab CI 流水线｜第2&3题：父子流水线 + 多项目流水线、Devops 流水线中的手动测试、DevSecOps: CI/CD流水线中增加安全、JMeter - 如何在多个测试环境中运行多个线程组等相关知识，希望对各位有所帮助，不要忘了收藏本站喔。
本文目录一览：- 如何在容器流水线中运行多个 node 版本
- 4道数学题，求解极狐GitLab CI 流水线｜第2&3题：父子流水线 + 多项目流水线
- Devops 流水线中的手动测试
- DevSecOps: CI/CD流水线中增加安全
- JMeter - 如何在多个测试环境中运行多个线程组
如何在容器流水线中运行多个 node 版本
使用单个 Dockerfile 在 CI 中运行多个 node 版本，Docker 在持续集成方面迈出了一大步。需要在 CI 主机中设置一百个工具或启动整个虚拟机的日子已经一去不复返了。现在，您只需安装 Docker，就可以开始使用了大部分程序。
针对不同的 node.js 版本测试项目。如何在 Jenkins 实现这一目标的。
假设您有一个可以运行 docker 的 Jenkins。类似于这样：
项目的结构是这样的
该项目使用 npm 来管理其依赖项，并具有一个 lock 文件以确保每次我们运行时 npm install 都安装完全相同的版本。我们的代码位于包含测试文件的 src 文件夹下。package.json 的 test 任务是检查项目。
如果要针对一个特定的 node 版本检查该项目，则可以使用以下命令构建映像 Dockerfile：
并设置我们的 Jenkins 作业以运行以下脚本：
Dockerfile 的详细信息或运行方式并不重要。可以根据需要调整图像。您可以挂载卷以为其设置缓存 node_modules 或避免复制代码。请注意，官方 node 镜像已经设置了 NODE_VERSION 环境变量，因此我们实际上并不需要第 3 行。
多 Node 版本
每个项目都应定义需要检查的节点版本。我们需要调整，Dockerfile 以接受可修改将要使用的基本映像的构建 ARG。该 ARG 指令定义了一个变量，用户可以在构建时 docker build 使用带有 --build-arg <varname>=<value> 标志的命令将其传递给构建器。
最后，我们修改脚本以迭代定义的节点版本，传递 NODE_VERSION ARG 来构建映像并运行它。
就是这样：在 CI 中针对一个单一的多个节点版本运行作业 Dockerfile。
设置 Jenkins 使用 Docker 容器运行 CI 作业非常容易。这为配置作业和运行作业的环境提供了极大的灵活性。利用和一些脚本中的 ARG+ FROM 语法 Dockerfile，您可以减轻在 Jenkins 中针对不同节点版本运行相同作业的痛苦。同样，该方法可以应用于您选择的任何其他语言或技术。
本文纯属个人翻译，如有侵权立即删除。更多精彩请关注我们！
更多精彩请关注 DevOps 云学堂
添加微信小助手 devopsvip 回复 "加群"，自动加入群聊
点亮 
，告诉大家你也在看
本文分享自微信公众号 - DevOps 云学堂（idevopsvip）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与 “OSC 源创计划”，欢迎正在阅读的你也加入，一起分享。
4道数学题，求解极狐GitLab CI 流水线｜第2&3题：父子流水线 + 多项目流水线
本文来自：
武让 极狐(GitLab) 高级解决方案架构师
极狐GitLab CI 依靠其一体化、轻量化、声明式、开箱即用的特性，在开发者群体中的使用率越来越高，在国内企业中仅次于 Jenkins ，排在第二位。
极狐GitLab 流水线有 4 种不同类型，分别是：
有向无环图流水线
父子流水线
多项目流水线
合并列车
但仅靠这些流水线类型名称和官方描述，我们很难理解其意义和用途。因此，作者结合众多用户反馈和自身实践，简明扼要 “重新定义” 了这些流水线类型，并通过 3 篇连载文章为您解答，帮助您掌握极狐GitLab 流水线。
第 1 篇分享了有向无环图流水线 。
本文是第 2 篇——父子流水线 + 多项目流水线 ，enjoy～
父子流水线 Parent-Child Pipelines
1. 官方定义
Parent-Child Pipelines 即父子流水线，它和 Multi-Project Pipelines 多项目流水线都属于下游流水线。所谓下游流水线：
由另一个流水线触发的任何极狐GitLab CI/CD 流水线。它可以是：
- 一个父子流水线，是与第一个流水线在同一个项目（代码库）中触发的下游流水线；
- 多项目流水线，是在与第一个流水线不同的项目（代码库）中触发的下游流水线。
父子流水线，官方定义和介绍如下：
父流水线是在同一项目（代码库）中触发下游流水线的流水线，下游流水线称为子流水线。
- 子流水线仍然根据阶段顺序执行他们的每个工作，但可以自由地继续他们的阶段，而无需等待父流水线中不相关的工作完成；
- 该配置被拆分为更小的子流水线配置。每个子流水线只包含更容易理解的相关步骤，减少了理解整体配置的认知负担；
- 导入在子流水线级别完成，减少了冲突的可能性。
这个解释比 DAG 流水线要容易理解一些，但是我们依然可以换一种比较接地气的方式进行重新描述。
2. 重新定义
父子流水线解决一个判断题+选择题。
主要功能：
- （按条件触发并）执行同一个项目（代码库）中不同的流水线脚本。
3. 问题解答
接着第 1 篇 有向无环图流水线 中的问题 1 继续，还是那个跨平台项目。
问题 2
假如现在 iOS 平台应用有一些 Bug，开发人员仅对 iOS 部分代码进行了修改，然后希望编译打包 iOS 平台应用并发布上线。但不希望再次打包 PC 和 Android 平台，浪费时间和资源，怎么办？假如是个通用问题，在 3 个平台上都出现了，那么修改通用部分代码后还需要同时打包 3 个平台的应用，又该怎么办？这个跨平台项目文件目录如下：
- common
- code_files...
- .gitlab-ci.yaml #全部平台构建打包脚本
- android
- code_files...
- .gitlab-ci.yaml #Android平台构建打包脚本
- ios
- code_files...
- .gitlab-ci.yaml #iOS平台构建打包脚本
- pc
- code_files...
- .gitlab-ci.yaml #pc平台构建打包脚本
为了解决这个问题，就需要使用到父子流水线，主要会使用到 rules:is:changes 和 trigger 关键字，用来实现按条件触发，然后执行不同流水线脚本，比如：
stages:
- build
- triggers
android_trigger:
stage: triggers
# 当android目录下的文件发生变化时触发
rules:
- if:
changes:
- android/*
# 触发执行android/.gitlab-ci.yml脚本
trigger:
include: android/.gitlab-ci.yml
strategy: depend
ios_trigger:
stage: triggers
# 当ios目录下的文件发生变化时触发
rules:
- if:
changes:
- ios/*
# 触发执行ios/.gitlab-ci.yml脚本
trigger:
include: ios/.gitlab-ci.yml
strategy: depend
pc_trigger:
stage: triggers
# 当pc目录下的文件发生变化时触发
rules:
- if:
changes:
- pc/*
# 触发执行pc/.gitlab-ci.yml脚本
trigger:
include: pc/.gitlab-ci.yml
strategy: depend
common_build:
stage: build
script:
- echo "common build"
# 当common目录下的文件发生变化时触发，执行默认的根目录.gitlab-ci.yml脚本
rules:
- changes:
- common/*
当修改 iOS 目录文件后，只触发了 ios/.gitlab-ci.yml 脚本的执行。
当修改 common 目录文件或直接手动执行流水线后，触发执行根目录的 .gitlab-ci.yml 脚本，也就是触发所有构建。
当然这个判断题不是必要的，可以在一个正常的 Job 中直接做选择题，比如：
microservice_a:
trigger:
include: path/to/microservice_a.yml
也可以修改判断题的条件，比如使用极狐GitLab 的变量来进行条件控制：
pc_trigger:
stage: triggers
# 当PLATFORM变量的值为PC时触发
rules:
- if: $PLATFORM == "PC"
# 触发执行pc/.gitlab-ci.yml脚本
trigger:
include: pc/.gitlab-ci.yml
strategy: depend这样就实现了按照条件触发不同的流水线脚本，这也就是说为什么父子流水线是解决一个判断题 + 选择题，以及它是如何（按条件触发并）执行同一个项目中不同的流水线脚本的。
4. 总结父子流水线使用场景
1.按条件灵活触发并执行一个项目中不同的流水线脚本：比如在一个项目中，将一个复杂的流水线脚本拆分成多个简单的流水线脚本，通过 tigger 关键字组合，实现解耦和降低复杂度。或类似上文中提到的按条件单独执行 Monorepo 中部分模块的构建、测试、打包。
2.父子流水线 + DAG 流水线：可以将父子流水线与 DAG 流水线结合使用，比如 pc/.gitlab-ci.yml 中依然使用 DAG 流水线使得 test_pc 依赖 build_pc 和 build_pc_dll。
多项目流水线 Multi-Project Pipelines
1. 官方定义
Multi-Project Pipelines 多项目流水线，它和父子流水线都属于下游流水线，官方定义和介绍如下：
可以跨多个项目（代码库）设置极狐GitLab CI/CD，以便一个项目（代码库）中的流水线可以触发另一个项目（代码库）中的流水线。您可以在一个地方可视化整个流水线，包括所有跨项目的相互依赖关系。
熟悉了父子流水线后，再看多项目流水线就比较简单了。它们都是触发下游不同的流水线，只是面向的对象不同，父子流水线面向的是同一个项目（代码库），而多项目流水线是面向不同的项目（代码库），这也决定了它们使用的场景不同。
2. 重新定义
继续用通俗的语言来解释：
多项目流水线解决的是排列组合题。
主要功能：
- 编排并执行不同的项目（代码库）中的流水线脚本。
回顾上文中的 DAG 流水线和父子流水线，使用的场景大多都是在 Monorepo 模式下，对一个项目内的流水线或者 Job 进行编排。而现在架构设计领域的主流思想还是模块化和微服务，所以不少企业或开发人员还是习惯对项目进行拆分，用多个代码库进行管理。在这样的模式下，DAG 和父子流水线使用的机会就相对较少了，而多项目流水线就派上了用场。举例如下：
3. 问题解答
问题 3
假设有个 Web 项目，在极狐GitLab 中建立了一个群组 MyProject 来管理这个项目。前端代码放在代码库 MyProject/Frontend 中，后台代码放在代码库 MyProject/Server 中。测试团队对前端代码编写的UI自动化测试脚本放在代码库 MyProject/Frontend-UI-Testing 中，对后台代码编写的 API 自动化测试脚本放在代码库 MyProject/Server-API-Testing 中。要求部署时先部署后台代码，再部署前端代码，并同步进行后台的 API 测试，最后再进行前端的 UI 测试。
使用多项目流水线来解决这个问题，依然要使用 trigger 关键字。由于该问题中，后台代码的流水线是整个业务链条的起点，所以先看代码库 MyProject/Server 的流水线：
stages:
- build
- test
- deploy
- downstream
# 编译构建
build-job:
stage: build
script:
- echo "Compiling code..."
- echo "Compile complete."
# 单元测试
unit-test-job:
stage: test
script:
- echo "Running unit tests... This will take about 60 seconds."
- sleep 6
- echo "Code coverage is 90%"
# 格式校验
lint-test-job:
stage: test
script:
- echo "Linting code... This will take about 10 seconds."
- sleep 1
- echo "No lint issues found."
# 部署任务
deploy-job:
stage: deploy
script:
- echo "Deploying application..."
- echo "Application successfully deployed."
# API测试
api-test-job:
stage: downstream
# 触发下游流水线
trigger:
project: MyProject/Server-API-Testing
strategy: depend
# 部署前端
deploy-frontend-job:
stage: downstream
# 触发下游流水线
trigger:
project: MyProject/Frontend
strategy: depend当前端项目部署成功后需要执行前端的 UI 测试，所以代码库 MyProject/Frontend 的流水线如下：
stages:
- build
- test
- deploy
- downstream
# 省略build、test、deploy脚本
# UI测试
ui-test-job:
stage: downstream
# 触发下游流水线
trigger:
project: MyProject/Frontend-UI-Testing
strategy: depend
流水线运行效果如下，也就是官方定义中所说的 “您可以在一个地方可视化整个流水线，包括所有跨项目的相互依赖关系”，但这个功能是属于极狐GitLab 专业版及以上版本，免费版无法看到这个效果。
正因为多项目流水线能够编排多个项目（代码库）流水线，所以说它解决的是一个排列组合题。
4. 总结多项目流水线使用场景
按顺序触发并执行不同项目的流水线脚本：比如部署后运行自动化测试，或按照一定的顺序部署不同的模块、服务等。
极狐GitLab 4 种流水线之 “父子流水线 & 多项目流水线” 暂且搁笔，希望以上内容对您有帮助！接下来我们的连载内容是：
- 合并列车
欢迎关注极狐GitLab，及时 “追番” 不迷路！
Devops 流水线中的手动测试
管道阻塞数天当然是一种反模式。这是减轻它的一种方法 -
- 独立的持续集成 (CI) 和持续部署 (CD) 管道。
- 有一个单独的流程来为环境路由正确的工件（免责声明：我偏向于我们提供的工件 - https://relizahub.com，因为我正在研究它；视频如何实施批准 - https://www.youtube.com/watch?v=PzdZjMby6Is )
- 基本上，会发生什么 - 您运行 CI 管道，它创建一个部署工件。然后您有一些批准（手动和/或自动），这些批准专门记录在此工件上。然后你有一个单独的部署管道，它选择正确的工件并进行部署。这样，所有管道都可以快速运行，而您不必处理长时间卡住的管道。
CI 和 CD 是使团队能够提高生产力的工程实践。 而这些应该是分步实施的——先实施CI，再实施CD。因此，随着您在 DevOps 流程中的成熟，构建管道。
例如，利用 Jenkins 管道首先编排 CI 管道，其中以下是自动化的-
- 应用程序构建，
- 单元测试，
- 代码覆盖率，
此阶段的输出是部署在 Nexus 等二进制存储库中的二进制文件。
成功实施 CI 后的下一步是 CD - 将工件从一个环境自动部署到另一个环境的过程。考虑我们需要在 QA 中部署工件（二进制文件）进行测试。您可以通过将工件从 DEV 移动到 QA 系统来扩展 CI 管道以执行 CD。然后停在这里，因为只有在手动测试记录被批准时才会移动到下一个环境。这意味着将手动触发进入下一个环境。因此，在计划构建 CD 管道时，请列出应该自动化的基本步骤，然后逐步推进。
一旦您准备好自动化测试和工具，您就可以完成 CD 管道并自动从 DEV-QA-NONPROD 转移到工件。
DevSecOps: CI/CD流水线中增加安全
阅读本文需要7分钟 文末有惊喜 哈哈
DevOps的兴起改变了软件开发的前景。但是，尽管大多数参与软件构建过程的团队已经在利用这些方法，但是软件安全性仍然落后。
在本文中，我们将介绍DevSecOps，这是一种针对敏捷团队的安全性新方法。我们将讨论在实施时可能会遇到的一些挑战，提供一个简单的起点的示例，并举例说明可以在旅途中提供帮助的工具。
1.问题：安全性的瀑布模型
通常，漏洞检查是在开发过程结束时执行的。它们会产生大量文档，并可能迫使大部分代码被重写。这种方法还会在团队之间造成摩擦：当开发人员试图快速发布并交付价值时，瀑布式安全措施最终会拖慢该过程。测试大部分是手动的，可能需要很长时间才能完成。大多数时候，开发人员首先没有必要的工具来避免出现问题。
2.DevOps的好处
在查看DevOps时，我们可以看到针对大多数这些问题的解决方案。在其出现之前，开发人员曾经将运营团队视为障碍，从而减慢了发布速度并停止了创新。操作人员认为开发人员不在乎环境的成本，安全性或可靠性。
通过使用自动化并专注于协作，DevOps范例极大地改变了这种看法。现在，运营成为推动者：它不仅可以预防问题，而且还可以积极提供价值，从而加快开发速度。
单元测试和集成测试在每个构建中都执行，并且仅在提交后构建未中断的情况下，代码才发送到主分支。此外，DevOps将发布转换为正常和频繁发生的事件。结合测试自动化，这可以缩短反馈周期：整体上，使用DevOps的组织已变得更快。
在某些情况下，这些原则被推到了极致。该代码以完全自动化的方式编写，测试并发送到生产环境。在这里，瀑布式安全措施不仅效果不佳，甚至不可能。
3.转移管道中的安全性
如前所述，漏洞检查通常在开发过程结束时执行，这可能会导致后期且昂贵的调整被推迟到产品积压，延迟功能，甚至推迟产品发布。通常，这种情况会影响业务目标，降低团队满意度并在团队之间产生冲突（Dev与InfoSec）。
幸运的是，DevOps实践已经存在了一段时间，它致力于最大化软件开发价值流的性能，引入了一些关键概念，这些概念对于使Security成为开发管道中嵌入的另一个主题极为有价值，这就是术语DevSecOps。
尽管实现持续集成和持续交付（CI / CD）概念的自动化管道为传统的安全方法（开发团队发展得太快）提出了新的挑战，但它也为愿意接受它的团队提供了机会。DevSecOps的本质是在整个管道中嵌入安全性流程，并将DevOps原理和理念应用于与安全性相关的计划。使用这种方法，安全性分析可以在软件开发生命周期的早期进行（左移），从而限制了其发现的影响。
4.但是……我们到底可以投入什么呢？
实际上，这取决于特定解决方案或产品的要求和约束，因为InfoSec团队每天都会使用许多工具和策略来完成他们的工作。列举其中一些：静态应用程序安全性测试（SAST）；动态应用程序安全测试（DAST），交互式应用程序安全测试（IAST）；和软件组成分析工具。每个组件都处理一组特定的安全风险，并且可以按照DevOps原则构成敏捷开发生命周期。
在管道中同时使用SAST和DAST可以涵盖代码库和运行时漏洞，并且虽然OWASP Find Sec Bug之类的SAST解决方案可以在较早阶段使用，甚至可以集成到开发人员的IDE中，但Arachni或ZAP等DAST工具可以在构建步骤中自动部署。
可以在管道中插入其他安全技术：
使用OWASP Dependency-Check或Retire.js之类的软件组成分析工具检查导入的库将检测开发人员使用的开源库上的许可风险和已知漏洞；
通过使用例如Inspec，Nmap或基于云的工具来分析和强化基础结构；
使用git-secret或类似的解决方案公开检查秘密；
针对与SQLMap，SSLyze等有关的特定问题。
此外，诸如OWASP Glue或Gauntlt之类的包装器可以提供一个通用的界面来自动化许多开源工具，包括已经提到的大多数解决方案。
尽管上面所有示例工具都是开放源代码产品，但也存在商业解决方案，并且通常需要付费才能提供附加功能和更完整的报告，但仍然能够插入CI / CD管道。一个例子就是BlackDuck软件，它是一种软件组成分析解决方案，它不仅能够验证依赖项的漏洞和许可信息，还可以提供补救指南。
但是，将整个安全工具链部署到任何现有管道中都可能会面临挑战，因为可能会有大量的推后推，并且必须注意不要扭曲项目的日常活动。当然，最好一次集中精力在一个方面，避免造成干扰，并逐步推广。在每次迭代中，在集成更简单的安全工具和实践时获得的反馈和经验将成为解决更复杂的解决方案的实现并确保计划得到适当处理的宝贵资产。
确保管道中每个新增加的步骤都能够带来价值并被所有相关团队和更高利益相关者正确接受是至关重要的。请记住，每次检测到漏洞都会中断构建，这也会给开发人员带来麻烦和沮丧，他们期望快速的管道构建时间以及一组工具和流程定义可以帮助InfoSec快速解决安全问题并进行跟踪。
因此，为了顺利使用DevSecOps，最好采用一种简约的方法，对测试进行微调，并针对代码库中特定的高风险部分。快速的构建过程对于开发管道至关重要，应保持在控制之下，因此仅应添加必要的新步骤。为了处理繁重的工作，请创建新的策略以启用较慢的测试，这些测试可以在夜间执行，也可以通过并行，无阻塞的构建执行。
够用了，让我们举例说明如何通过融入DevSecOps实践的开源技术来实现真实的安全验证方案。
5.练习DevSecOps：起点
开始时，检查机密（即密码，API密钥和其他凭据）是否被公开是最简单的安全验证之一。除了目标简单之外，它还解决了代码开发中的真正安全问题。
为了展示这一点，我们将描述如何使用诸如Jenkins和git-secrets之类的开源工具来验证git存储库中敏感信息的存在，这些信息可以很容易地实现为DevSecOps CI / CD管道自动化。
第一步包括在Linux上安装git-secrets，这是通过Makefile执行的（更多信息可以在此处找到）。完成后，我们很清楚地添加了代码库中不应该存在的模式列表，然后扫描项目存储库。
下面的示例显示了安装过程以及AWS IAM密钥的常见验证模式，其中包括“ git secrets-register-aws”命令。
使用此解决方案时，“扫描”命令将查找保存到存储库中的机密，“扫描历史”将提供更深的外观，并包括由新提交修改的代码。如果找不到任何匹配的模式（如下所示），工具执行将返回“ 0”，否则将返回“ 1”。
这简化了与Jenkins之类的工具的集成，并允许返回值充当停止构建过程的标志。本文中提到的其他工具的工作方式类似，有助于与CI管道集成。
在下图中，显示了Jenkins和git-secret的组合。
如我们所见，git-secrets还会打印存储库中找到的密钥以及这些密钥的位置。除了使用此信息解决问题外，它还可用于检查密钥是否仍处于活动状态，上次使用时间以及其他相关数据。
当找到密钥本身上的模式匹配密钥时，将通过变量名称检测秘密。虽然将阻止名为“ aws_secret_key”的变量，但不会阻止名为“ secret”的变量。还值得注意的是，如果该解决方案直接挂接到每个开发人员的本地存储库，则即使在推送此代码之前，它也会阻止违反规则的提交。
6.渗透整个管道
当然，仅对构建步骤进行检查不足以创建安全的管道。在部署阶段，我们需要跟踪将什么代码发送到生产环境，谁在代码上签字，并确保该代码不会被篡改。
我们还应该关心生产环境。检测常见的攻击类型和加强基础架构的重要性与以往一样重要，AWS等云平台已经提供了用于此目的的工具（AWS Config，Cloud Trail，Inspector GuardDuty…），但仍然存在开源解决方案。与InStatsD和Kibana之类的工具结合使用时，Chef Inspec和ModSecurity可以提供巨大的价值。
此外，还存在特定于体系结构的问题。即使所有安全测试都表明系统提供了高度的安全性，我们也不能保证进程是否会暴露威胁。例如，销售点系统上的弱认证可能会导致社会工程攻击。解决此类问题需要在设计阶段彻底考虑安全性。
7.与审计师打交道
在自动化安全测试堆栈时，我们可能会遇到的一个问题是审核员的退缩。
对于他们来说这是一个新领域，首先，他们可能会对这种方法的可行性或有效性持怀疑态度。将它们包括在旅途中，解释自动化可以为流程带来的优势非常重要。演示如何减轻风险，并讨论自动化管道的更高可靠性。可能值得创建一个文档，列出与您的应用程序相关的风险，并说明将这些风险最小化的步骤。
8.结论
DevSecOps是一个复杂的主题，可能导致团队内部以及与审核员之间的摩擦。因此，应将其部署分解为较小的部分，使我们充分关注每一步，一次完成。尽管如此，我们还必须记住，检测漏洞只是工作的一半，而赋予开发人员权力可以帮助他们快速解决检测到的问题。
自动化和DevOps原理的应用将帮助安全团队在敏捷环境中保持正常运转。这是一种新的安全方法，专门针对它的工具才刚刚开始被广泛采用。
在本文中，我们列出了一些可用的工具，以及一个简单的示例来开始使用该概念。
《推荐 DevOps流水线最佳实践》
腾讯课堂-泽阳
课程价格
课程上新价格：128元
有效期：2020年1月9日-2020年1月16日，过期恢复原价：168元。
长按扫描下方二维码了解课程详情
或者点击这里了解详情
