第 1 部分：Web/Android
注意: 本文是原文的俄文翻译 然而，所有插图、链接、引用和术语均保留原始语言，以避免翻译成俄语时含义失真。 祝您学习愉快！
目前，DevOps 专业是 IT 行业需求量最大的专业之一。 如果您打开热门职位搜索网站并按薪资进行筛选，您将看到与 DevOps 相关的职位位于列表顶部。 然而，重要的是要明白，这主要指的是“高级”职位，这意味着候选人拥有高水平的技能、技术和工具知识。 这还伴随着与生产不间断运行相关的高度责任。 然而，我们开始忘记DevOps 是什么。 最初，它不是任何特定的人或部门。 如果我们寻找这个术语的定义，我们会发现许多美丽而正确的名词，例如方法论、实践、文化哲学、概念群等等。
我的专业是测试自动化工程师（QA自动化工程师），但我相信它不应该只与编写自动测试或开发测试框架架构相关。 2020年，自动化基础设施的知识也很重要。 这使您可以自己组织自动化流程，从运行测试到根据您的目标向所有利益相关者提供结果。 因此，DevOps 技能是完成工作所必需的。 这一切都很好，但是，不幸的是，有一个问题（剧透：本文试图简化这个问题）。 关键是 DevOps 很难。 这是显而易见的，因为公司不会为容易做的事情付出很多代价……在DevOps世界中，有大量的工具、术语和实践需要掌握。 这在职业生涯初期尤其困难，取决于积累的技术经验。
来源：
到这里，我们大概就结束了介绍部分，重点讨论本文的目的。
这篇文章是关于什么的？
在这篇文章中，我将分享我构建测试自动化基础设施的经验。 互联网上有很多关于各种工具以及如何使用它们的信息来源，但我想纯粹在自动化的背景下查看它们。 我相信许多自动化工程师都熟悉这种情况：除了你之外没有人运行开发的测试或关心维护它们。 结果，测试变得过时，你必须花时间更新它们。 同样，在职业生涯的开始，这可能是一项相当困难的任务：明智地决定哪些工具应该有助于消除给定的问题，以及如何选择、配置和维护它们。 一些测试人员向 DevOps（人类）寻求帮助，老实说，这种方法是有效的。 在许多情况下，这可能是唯一的选择，因为我们无法了解所有依赖项。 但正如我们所知，DevOps 是非常忙碌的人，因为他们必须考虑整个公司的基础设施、部署、监控、微服务和其他类似的任务，具体取决于组织/团队。 通常情况下，自动化并不是优先考虑的事项。 在这种情况下，我们必须自始至终尽一切努力。 这将减少依赖性，加快工作流程，提高我们的技能，并让我们能够看到正在发生的事情的全局。
文章介绍了最流行、最受欢迎的工具，并展示了如何使用它们逐步构建自动化基础设施。 每个组都由经过个人经验测试的工具代表。 但这并不意味着您必须使用相同的东西。 工具本身并不重要，它们出现并变得过时。 我们的工程任务是了解基本原理：为什么我们需要这组工具以及我们可以在它们的帮助下解决哪些工作问题。 这就是为什么我在每个部分的末尾留下了您的组织中可能使用的类似工具的链接。
本文中没有的内容
我再次重申，本文不是关于特定工具的，因此不会插入文档中的代码和特定命令的描述。 但在每个部分的末尾，我都会留下详细研究的链接。
这样做是因为：
- 这些材料很容易在各种来源（文档、书籍、视频课程）中找到；
- 如果我们开始深入，我们将不得不写这篇文章的 10、20、30 部分（而计划是 2-3）；
- 我只是不想浪费您的时间，因为您可能想使用其他工具来实现相同的目标。
实践
我真的希望这份材料对每一位读者都有用，而不仅仅是读过之后就忘记了。 在任何学习中，实践都是非常重要的组成部分。 为此我已经准备好了。 还有作业等着你，以确保你不会盲目地复制正在执行的命令行。
计划
步
专业技术
工具
1
本地运行（准备web/android demo测试并在本地运行）
Node.js、Selenium、Appium
2
版本控制系统
混帐
3
集装箱化
Docker、Selenium 网格、Selenoid（Web、Android）
4
持续集成/持续交付
亚特实验室持续集成
5
云平台
谷歌云平台
6
编曲配置
Kubernetes
7
基础设施即代码 (IaC)
地形、Ansible
各部分的结构
为了使叙述清晰，每个部分按照以下大纲进行描述：
- 该技术的简要描述，
- 自动化基础设施的价值，
- 基础设施现状的说明，
- 学习链接，
- 类似的工具。
1.本地运行测试
技术简述
这只是在本地运行演示测试并验证它们是否通过的准备步骤。 实践部分使用的是Node.js，但是编程语言和平台也不重要，你可以使用你公司使用的语言和平台。
但是，作为自动化工具，我建议分别对 Web 平台使用 Selenium WebDriver，对 Android 平台使用 Appium，因为在接下来的步骤中，我们将使用专门为这些工具而定制的 Docker 映像。 而且，就工作要求而言，这些工具是市场上需求量最大的。
您可能已经注意到，我们只考虑 Web 和 Android 测试。 不幸的是，iOS 是一个完全不同的故事（感谢 Apple）。 我计划在接下来的部分中展示 IOS 相关的解决方案和实践。
自动化基础设施的价值
从基础设施的角度来看，本地运行没有任何价值。 您只需检查测试是否在本地浏览器和模拟器中的本地计算机上运行。 但无论如何，这是一个必要的起点。
基础设施现状图解
探索链接
类似工具
- 您喜欢与 Selenium/Appium 测试结合使用的任何编程语言；
- 任何测试；
- 任何测试运行者。
2.版本控制系统（Git）
技术简述
如果我说版本控制是开发中极其重要的一部分，无论是在团队中还是个人中，这对任何人来说都不会是一个大的启示。 根据各种来源，可以肯定地说 Git 是最受欢迎的代表。 版本控制系统提供了许多好处，例如代码共享、存储版本、恢复到以前的分支、监控项目历史记录和备份。 我们不会详细讨论每一点，因为我相信您非常熟悉它并在日常工作中使用它。 但如果突然没有，那么我建议暂停阅读这篇文章并尽快填补这个空白。
自动化基础设施的价值
在这里你可以问一个合理的问题：“他为什么要告诉我们有关 Git 的事情？ 每个人都知道这一点，并将其用于开发代码和自动测试代码。” 您是绝对正确的，但在本文中，我们讨论的是基础设施，本节充当第 7 节：“基础设施即代码 (IaC)”的预览。 对于我们来说，这意味着整个基础设施，包括测试，都是以代码的形式描述的，因此我们也可以对其应用版本控制系统，并获得与开发和自动化代码类似的好处。
我们将在步骤 7 中更详细地了解 IaC，但即使现在您也可以通过创建本地存储库来开始在本地使用 Git。 当我们向基础设施中添加远程存储库时，全局将得到扩展。
基础设施现状图解
探索链接
类似工具
3.容器化（Docker）
技术简述
为了演示容器化如何改变游戏规则，让我们回到几十年前。 当时，人们购买并使用服务器机器来运行应用程序。 但在大多数情况下，所需的启动资源是事先未知的。 结果，公司花钱购买昂贵、功能强大的服务器，但其中一些容量并未得到完全利用。
演进的下一阶段是虚拟机 (VM)，它解决了在未使用的资源上浪费金钱的问题。 该技术使得在同一服务器内独立运行应用程序成为可能，分配完全隔离的空间。 但不幸的是，任何技术都有其缺点。 运行虚拟机需要完整的操作系统，这会消耗 CPU、RAM、存储，并且根据操作系统的不同，还需要考虑许可证成本。 这些因素会影响加载速度并使便携性变得困难。
现在我们来谈谈容器化。 该技术再次解决了之前的问题，因为容器不使用完整的操作系统，从而释放了大量资源，并为可移植性提供了快速灵活的解决方案。
当然，容器化技术并不是什么新鲜事，在 70 年代末首次被引入。 当时进行了大量的研究、开发和尝试。 但 Docker 改编了这项技术，并使其易于大众使用。 如今，当我们谈论容器时，大多数情况下我们指的是Docker。 当我们谈论 Docker 容器时，我们指的是 Linux 容器。 我们可以使用 Windows 和 macOS 系统来运行容器，但重要的是要了解在这种情况下会出现一个附加层。 例如，Mac 上的 Docker 在轻量级 Linux VM 中静默运行容器。 当我们讨论在容器内运行 Android 模拟器时，我们将回到这个主题，因此这里有一个非常重要的细微差别需要更详细地讨论。
自动化基础设施的价值
我们发现容器化和 Docker 很酷。 让我们在自动化的背景下看待这个问题，因为每种工具或技术都需要解决一个问题。 让我们概述一下 UI 测试背景下测试自动化的明显问题：
- 安装 Selenium 尤其是 Appium 时存在大量依赖项；
- 浏览器、模拟器、驱动版本之间的兼容性问题；
- 缺乏浏览器/模拟器的隔离空间，这对于并行运行尤其重要；
- 如果需要同时运行10个、50个、100个甚至1000个浏览器，则难以管理和维护。
但由于 Selenium 是最流行的自动化工具，而 Docker 是最流行的容器化工具，因此有人尝试将它们结合起来创建一个强大的工具来解决上述问题也就不足为奇了。 让我们更详细地考虑此类解决方案。
docker 中的硒网格
该工具是 Selenium 世界中最受欢迎的工具，用于在多台计算机上运行多个浏览器并从中央集线器进行管理。 首先，您需要注册至少 2 个部分：集线器和节点。 Hub是一个中心节点，它接收来自测试的所有请求并将其分发到适当的节点。 对于每个节点，我们可以配置特定的配置，例如，通过指定所需的浏览器及其版本。 但是，我们仍然需要自己处理兼容的浏览器驱动程序并将它们安装在所需的节点上。 因此，Selenium 网格不会以其纯粹的形式使用，除非我们需要使用无法安装在 Linux 操作系统上的浏览器。 对于所有其他情况，一个非常灵活和正确的解决方案是使用 Docker 映像来运行 Selenium 网格集线器和节点。 这种方法极大地简化了节点管理，因为我们可以使用已安装的兼容版本的浏览器和驱动程序来选择所需的映像。
尽管对稳定性的负面评论，特别是在并行运行大量节点时，Selenium 网格仍然是并行运行 Selenium 测试的最受欢迎的工具。 值得注意的是，开源中不断出现对该工具的各种改进和修改，这些改进和修改克服了各种瓶颈。
用于网络的 Selenoid
该工具是 Selenium 领域的一项突破，因为它开箱即用，使许多自动化工程师的工作变得更加轻松。 首先，这不是 Selenium 网格的另一次修改。 相反，开发人员用 Golang 创建了全新版本的 Selenium Hub，结合适用于各种浏览器的轻量级 Docker 镜像，推动了测试自动化的发展。 此外，对于 Selenium Grid，我们必须提前确定所有所需的浏览器及其版本，这在仅使用一种浏览器时不是问题。 但当涉及多种支持的浏览器时，Selenoid 凭借其“按需浏览器”功能成为第一解决方案。 我们所需要的只是提前使用浏览器下载必要的图像并更新与Selenoid交互的配置文件。 Selenoid 收到来自测试的请求后，它将自动使用所需的浏览器启动所需的容器。 测试完成后，Selenoid 将停用容器，从而为将来的请求释放资源。 这种方法完全消除了我们在 Selenium 网格中经常遇到的众所周知的“节点退化”问题。
但遗憾的是，Selenoid 仍然不是灵丹妙药。 我们获得了“浏览器按需”功能，但“资源按需”功能仍然不可用。 要使用Selenoid，我们必须将其部署在物理硬件或虚拟机上，这意味着我们必须提前知道需要分配多少资源。 我想这对于并行运行 10 个、20 个甚至 30 个浏览器的小型项目来说不是问题。 但如果我们需要 100、500、1000 甚至更多怎么办？ 一直维护和支付这么多资源是没有意义的。 在本文的第 5 节和第 6 节中，我们将讨论允许您扩展的解决方案，从而显着降低公司成本。
适用于 Android 的硒化物
在 Selenoid 作为网络自动化工具取得成功之后，人们希望在 Android 上也能有类似的东西。 事情发生了——Selenoid 发布并支持 Android。 从高级用户的角度来看，操作原理类似于网络自动化。 唯一的区别是，Selenoid 运行的是 Android 模拟器容器，而不是浏览器容器。 在我看来，这是目前并行运行 Android 测试最强大的免费工具。
我真的不想谈论这个工具的负面方面，因为我真的很喜欢它。 但网络自动化仍然存在与扩展相关的相同缺点。 除此之外，我们还需要讨论另一个限制，如果我们是第一次设置该工具，可能会感到惊讶。 要运行 Android 映像，我们需要具有嵌套虚拟化支持的物理机或 VM。 在操作指南中，我演示了如何在 Linux VM 上启用此功能。 但是，如果您是 macOS 用户并且想要在本地部署 Selenoid，那么这将无法运行 Android 测试。 但您始终可以在本地运行配置了“嵌套虚拟化”的 Linux 虚拟机，并在内部部署 Selenoid。
基础设施现状图解
在本文中，我们将添加 2 个工具来说明基础架构。 它们是用于 Web 测试的 Selenium grid 和用于 Android 测试的 Selenoid。 在 GitHub 教程中，我还将向您展示如何使用 Selenoid 运行 Web 测试。
探索链接
类似工具
- 还有其他容器化工具，但 Docker 是最受欢迎的。 如果您想尝试其他方法，请记住，我们介绍的用于并行运行 Selenium 测试的工具不能开箱即用。
- 正如已经说过的，Selenium grid 有很多修改，例如，.
4.CI/CD
技术简述
持续集成的实践在开发中非常流行，与版本控制系统相当。 尽管如此，我还是觉得术语上存在混乱。 在本段中，我想从我的角度描述该技术的 3 个修改。 在互联网上你会发现很多不同解读的文章，如果你的观点不同，那是很正常的。 最重要的是您与同事意见一致。
因此，有 3 个术语：CI - 持续集成、CD - 持续交付和 CD - 持续部署。 （下面我将用英语使用这些术语）。 每次修改都会向您的开发流程添加几个额外的步骤。 但这个词 连续 （持续）是最重要的。 在这种情况下，我们指的是从开始到结束发生的事情，没有中断或人工干预。 让我们在这个背景下看看 CI & CD 和 CD。
- 持续集成 这是进化的第一步。 将新代码提交到服务器后，我们希望收到快速反馈，表明我们的更改没问题。 通常，CI 包括运行静态代码分析工具和单元/内部 API 测试，这使我们能够在几秒/分钟内获取有关代码的信息。
- 连续交付 是我们运行集成/UI 测试的更高级步骤。 然而，现阶段我们并没有像 CI 那样快速获得结果。 首先，这些类型的测试需要更长的时间才能完成。 其次，在启动之前，我们必须将更改部署到测试/登台环境。 此外，如果我们谈论移动开发，那么似乎需要一个额外的步骤来创建我们的应用程序的构建。
- 持续部署 假设如果在前面的阶段中通过了所有验收测试，我们会自动发布对生产的更改。 除此之外，在发布阶段之后，您可以配置各个阶段，例如对生产运行冒烟测试和收集感兴趣的指标。 只有通过自动化测试进行良好的覆盖才能实现持续部署。 如果需要任何手动干预，包括测试，那么这不再是 持续 （连续的）。 那么我们可以说我们的管道只符合持续交付的实践。
自动化基础设施的价值
在本节中，我应该澄清，当我们谈论端到端 UI 测试时，这意味着我们应该将更改和相关服务部署到测试环境。 持续集成 - 该流程不适用于此任务，我们必须注意至少实施持续交付实践。 如果我们要在生产中运行 UI 测试，那么持续部署在 UI 测试中也很有意义。
在我们查看架构变化的说明之前，我想先谈谈 GitLab CI。 与其他 CI/CD 工具不同，GitLab 提供远程存储库和许多其他附加功能。 因此，GitLab 不仅仅是 CI。 它包括源代码管理、敏捷管理、CI/CD 管道、日志记录工具和开箱即用的指标收集。 GitLab 架构由 Gitlab CI/CD 和 GitLab Runner 组成。 以下是官方网站的简短描述：
Gitlab CI/CD 是一个带有 API 的 Web 应用程序，可将其状态存储在数据库中、管理项目/构建并提供用户界面。 GitLab Runner 是一个处理构建的应用程序。 它可以单独部署，并通过 API 与 GitLab CI/CD 配合使用。 对于运行测试，您需要 Gitlab 实例和 Runner。
基础设施现状图解
探索链接
类似工具
- 还有许多其他人
5、云平台
技术简述
在本节中，我们将讨论一种称为“公共云”的流行趋势。 尽管上述虚拟化和容器化技术提供了巨大的好处，但我们仍然需要计算资源。 公司购买昂贵的服务器或租用数据中心，但在这种情况下，有必要计算（有时不切实际）我们将需要多少资源，我们是否将24/7使用它们以及用于什么目的。 例如，生产需要服务器 XNUMX/XNUMX 运行，但是我们是否需要类似的资源来在工作时间之外进行测试？ 它还取决于所执行的测试类型。 一个例子是我们计划在非工作时间运行负载/压力测试，以便第二天得到结果。 但端到端自动化测试，尤其是手动测试环境，绝对不需要 XNUMX/XNUMX 服务器可用性。 对于这种情况，最好按需获取所需的资源，使用它们，并在不再需要时停止付费。 此外，如果只需点击几下鼠标或运行几个脚本即可立即收到它们，那就太好了。 这就是公共云的用途。 我们看一下定义：
“公共云被定义为第三方提供商通过公共互联网提供的计算服务，使任何想要使用或购买它们的人都可以使用它们。 它们可能是免费的，也可能是按需出售，让客户只需按使用的 CPU 周期、存储或带宽付费。”
有一种观点认为公共云价格昂贵。 但他们的核心想法是降低公司成本。 如前所述，公共云允许您按需获取资源，并且只需按使用时间付费。 此外，有时我们忘记了员工领取薪水，而专家也是一种昂贵的资源。 必须考虑到，公共云使基础设施支持变得更加容易，这使得工程师能够专注于更重要的任务。
自动化基础设施的价值
端到端 UI 测试需要哪些具体资源？ 基本上，这些是用于运行浏览器和模拟器的虚拟机或集群（我们将在下一节中讨论 Kubernetes）。 我们想要同时运行的浏览器和模拟器越多，所需的 CPU 和内存就越多，我们为此支付的费用也就越多。 因此，测试自动化背景下的公共云允许我们按需运行大量（100、200、1000...）浏览器/模拟器，尽快获得测试结果，并停止为这种疯狂的资源密集型行为付费力量。
最流行的云提供商是 Amazon Web Services (AWS)、Microsoft Azure、Google Cloud Platform (GCP)。 操作指南提供了如何使用 GCP 的示例，但一般来说，使用什么来执行自动化任务并不重要。 它们都提供大致相同的功能。 通常，在选择提供商时，管理层会重点考虑公司的整个基础设施和业务需求，这超出了本文的范围。 对于自动化工程师来说，将云提供商的使用与专门用于测试目的的云平台（例如 Sauce Labs、BrowserStack、BitBar 等）的使用进行比较会更有趣。 那么我们也来做吧！ 在我看来，Sauce Labs 是最著名的云测试农场，这就是我使用它进行比较的原因。
GCP 与 Sauce Labs 的自动化目的对比：
假设我们需要同时运行 8 个 Web 测试和 8 个 Android 测试。 为此，我们将使用 GCP 并使用 Selenoid 运行 2 个虚拟机。 在第一个容器中，我们将使用浏览器创建 8 个容器。 第二个有 8 个带有模拟器的容器。 我们来看看价格：
要使用 Chrome 运行一个容器，我们需要 n1-标准-1 车。 对于 Android 来说，它将是 n1-标准-4 对于一个模拟器。 事实上，更灵活、更便宜的方法是为 CPU/Memory 设置特定的用户值，但目前这对于与 Sauce Labs 进行比较并不重要。
以下是使用 Sauce Labs 的费用：
我相信您已经注意到了差异，但我仍然会提供一个表格，其中包含我们任务的计算结果：
所需资源
每月
工作时间（上午 8 点至晚上 8 点）
工作时间+ 可抢占
网络版 GCP
n1-标准-1 x 8 = n1-标准-8
$194.18
23 天 * 12 小时 * 0.38 = 104.88 美元
23 天 * 12 小时 * 0.08 = 22.08 美元
网络酱汁实验室
Virtual Cloud8 并行测试
$1.559
-
-
适用于 Android 的 GCP
n1-标准-4 x 8：n1-标准-16
$776.72
23 天 * 12 小时 * 1.52 = 419.52 美元
23 天 * 12 小时 * 0.32 = 88.32 美元
Android 版酱汁实验室
Real Device Cloud 8 并行测试
$1.999
-
-
正如您所看到的，成本差异巨大，特别是如果您仅在 XNUMX 小时的工作时间内运行测试。 但如果您使用抢占式机器，您可以进一步降低成本。 它是什么？
可抢占式虚拟机是一种可以以比普通实例低得多的价格创建和运行的实例。 但是，如果其他任务需要访问这些资源，Compute Engine 可能会终止（抢占）这些实例。 抢占式实例是多余的 Compute Engine 容量，因此它们的可用性随使用情况而变化。
如果您的应用具有容错能力并且可以承受可能的实例抢占，那么抢占式实例可以显着降低您的 Compute Engine 成本。 例如，批处理作业可以在抢占式实例上运行。 如果其中一些实例在处理过程中终止，作业会减慢但不会完全停止。 抢占式实例可以完成您的批处理任务，而不会给您现有的实例带来额外的工作负载，也不需要您为额外的普通实例支付全价。
而且事情还没有结束！ 事实上，我确信没有人会不间断地进行 12 个小时的测试。 如果是这样，那么您可以在不需要时自动启动和停止虚拟机。 实际使用时间可能会减少至每天 6 小时。 然后，在我们的任务中，11 个浏览器的费用将减少到每月 8 美元。 这不是很棒吗？ 但是对于抢占式机器，我们必须小心并为中断和不稳定做好准备，尽管这些情况可以在软件中提供和处理。 这很值得！
但我绝不是说“永远不要使用云测试农场”。 它们有很多优点。 首先，这不仅仅是一个虚拟机，而是一个成熟的测试自动化解决方案，具有一组开箱即用的功能：远程访问、日志、屏幕截图、视频录制、各种浏览器和物理移动设备。 在许多情况下，这可能是一个重要的时尚选择。 当公共云只能提供 Linux/Windows 系统时，测试平台对于 IOS 自动化特别有用。 但我们会在后面的文章中讨论 iOS。 我建议始终查看情况并从任务开始：在某些情况下，使用公共云更便宜、更高效，而在其他情况下，测试平台绝对值得花这些钱。
基础设施现状图解
探索链接
类似工具：
6. 编排
技术简述
我有个好消息——我们即将完成文章的结尾！ 目前，我们的自动化基础设施由 Web 和 Android 测试组成，我们使用支持 Docker 的工具：Selenium grid 和 Selenoid 通过 GitLab CI 并行运行这些测试。 此外，我们使用通过 GCP 创建的虚拟机来托管带有浏览器和模拟器的容器。 为了降低成本，我们仅根据需要启动这些虚拟机，并在不进行测试时停止它们。 还有什么可以改善我们的基础设施吗？ 答案是肯定的！ 认识 Kubernetes (K8s)！
首先，让我们看看编排、集群和 Kubernetes 等词之间的关系。 从较高的层面来看，编排是部署和管理应用程序的系统。 对于测试自动化，此类容器化应用程序是 Selenium grid 和 Selenoid。 Docker 和 K8s 相辅相成。 第一个用于应用程序部署，第二个用于编排。 反过来，K8s 是一个集群。 集群的任务是使用虚拟机作为节点，允许您在一台服务器（集群）内安装各种功能、程序和服务。 如果任何节点发生故障，其他节点将会恢复，这确保了我们的应用程序的不间断运行。 除此之外，K8s 还具有与扩展相关的重要功能，因此我们可以根据负载和设置限制自动获取最佳资源量。
事实上，从头开始手动部署 Kubernetes 并不是一项简单的任务。 我将留下著名的操作指南“Kubernetes The Hard Way”的链接，如果您有兴趣，可以练习一下。 但幸运的是，还有替代方法和工具。 最简单的方法是在 GCP 中使用 Google Kubernetes Engine (GKE)，只需点击几下鼠标即可获得现成的集群。 我建议使用这种方法开始学习，因为它可以让您专注于学习如何使用 K8 来完成您的任务，而不是学习内部组件如何相互集成。
自动化基础设施的价值
让我们看一下 K8s 提供的一些重要功能：
- 应用部署：使用多节点集群代替虚拟机；
- 动态扩展：降低按需使用的资源成本；
- 自我修复：自动恢复 Pod（因此容器也会恢复）；
- 无需停机即可推出更新和回滚更改：更新工具、浏览器和模拟器不会中断当前用户的工作
但 K8s 仍然不是灵丹妙药。 为了了解我们正在考虑的工具（Selenium grid、Selenoid）的所有优点和局限性，我们将简要讨论 K8s 的结构。 集群包含两种类型的节点：主节点和工作节点。 主节点负责管理、部署和调度决策。 工作节点是启动应用程序的地方。 节点还包含容器运行时环境。 在我们的例子中，这是 Docker，它负责容器相关的操作。 但也有替代解决方案，例如。 重要的是要了解缩放或自我修复并不直接适用于容器。 这是通过添加/减少 pod 数量来实现的，pod 数量又包含容器（通常每个 pod 一个容器，但根据任务可能会有更多容器）。 高层层次结构由工作节点组成，其中有 Pod，容器在其中引发。
扩展功能是关键，可以应用于集群节点池中的节点和节点中的 Pod。 有两种类型的扩展适用于节点和 Pod。 第一种类型是水平扩展——通过增加节点/pod 的数量来实现扩展。 这种类型是更优选的。 因此，第二种类型是垂直的。 扩展是通过增加节点/pod 的大小而不是数量来实现的。
现在让我们在上述术语的背景下看看我们的工具。
硒网格
正如前面提到的，Selenium 网格是一个非常流行的工具，它被容器化也就不足为奇了。 因此，Selenium grid 可以部署在 K8s 中也就不足为奇了。 有关如何执行此操作的示例可以在官方 K8s 存储库中找到。 像往常一样，我在本节末尾附上链接。 此外，操作指南还展示了如何在 Terraform 中执行此操作。 还有有关如何扩展包含浏览器容器的 Pod 数量的说明。 但K8s背景下的自动缩放功能仍然不是一个完全显而易见的任务。 当我开始学习时，我没有找到任何实用的指导或建议。 在 DevOps 团队的支持下经过多次研究和实验后，我们选择了在一个 Pod 内使用必要的浏览器来提升容器的方法，该 Pod 位于一个工作节点内。 该方法允许我们通过增加节点数量来应用节点水平缩放策略。 我希望这种情况在未来会改变，我们会看到越来越多的更好方法和现成解决方案的描述，特别是在内部架构发生变化的 Selenium grid 4 发布之后。
硒化物:
Selenoid 在 K8s 中的部署是目前最令人失望的。 它们不兼容。 理论上，我们可以在 pod 内启动 Selenoid 容器，但是当 Selenoid 开始使用浏览器启动容器时，它们仍将位于同一个 pod 内。 这使得扩展变得不可能，因此，Selenoid 在集群内的工作与虚拟机内的工作没有什么不同。 故事结局。
Moon:
意识到使用 Selenoid 时存在的瓶颈，开发人员发布了一个更强大的工具，称为 Moon。 该工具最初设计用于与 Kubernetes 配合使用，因此可以而且应该使用自动缩放功能。 此外，我想说的是，目前 唯一的 Selenium 世界中的一个工具，它具有开箱即用的原生 K8s 集群支持（不再可用，请参阅下一个工具 ）。 提供这种支持的 Moon 的主要功能是：
完全无国籍。 Selenoid 在内存中存储有关当前运行的浏览器会话的信息。 如果由于某种原因它的进程崩溃了——那么所有正在运行的会话都会丢失。 相反，Moon 没有内部状态，可以跨数据中心复制。 即使一个或多个副本出现故障，浏览器会话仍保持活动状态。
所以，Moon 是一个很好的解决方案，但有一个问题：它不是免费的。 价格取决于会话的数量。 您只能免费运行 0-4 个会话，这并不是特别有用。 但是，从第五次开始，您将需要为每次支付 5 美元。 每个公司的情况可能有所不同，但在我们的例子中，使用 Moon 是没有意义的。 正如我上面所描述的，我们可以按需运行带有 Selenium Grid 的虚拟机或增加集群中的节点数量。 对于大约一个管道，我们启动了 500 个浏览器，并在测试完成后停止所有资源。 如果我们使用 Moon，无论我们运行测试的频率如何，我们每月都必须额外支付 500 x 5 = 2500 美元。 再说一遍，我并不是说不要使用 Moon。 对于您的任务来说，这可能是一个不可或缺的解决方案，例如，如果您的组织中有许多项目/团队，并且您需要为每个人提供一个巨大的公共集群。 与往常一样，我在最后留下一个链接，并建议在您的任务上下文中进行所有必要的计算。
木卫四（注意力！ 这不在原始文章中，仅包含在俄语翻译中)
正如我所说，Selenium 是一个非常流行的工具，IT 领域发展非常迅速。 当我进行翻译时，一个名为 Callisto 的新工具出现在网络上（你好 Cypress 和其他 Selenium 杀手）。 它原生与 K8s 配合使用，并允许您在跨节点分布的 Pod 中运行 Selenoid 容器。 一切都开箱即用，包括自动缩放。 太棒了，但需要测试。 我已经成功部署了这个工具并进行了多次实验。 但现在下结论还为时过早，在收到远距离的结果后，也许我会在以后的文章中进行回顾。 现在我只留下独立研究的链接。
基础设施现状图解
探索链接
类似工具
7. 基础设施即代码（IaC）
技术简述
现在我们来到最后一部分。 通常，这项技术和相关任务不是自动化工程师的责任。 这是有原因的。 首先，在许多组织中，基础设施问题由 DevOps 部门控制，开发团队并不真正关心管道的工作原理以及与之相关的所有内容需要如何得到支持。 其次，老实说，基础设施即代码（IaC）的实践仍然没有被许多公司采用。 但它确实已经成为一种流行趋势，尝试参与与之相关的流程、方法和工具非常重要。 或者至少保持最新状态。
让我们从使用这种方法的动机开始。 我们已经讨论过，要在 GitlabCI 中运行测试，我们至少需要运行 Gitlab Runner 的资源。 为了使用浏览器/模拟器运行容器，我们需要预留虚拟机或集群。 除了测试资源之外，我们还需要大量的容量来支持开发、登台、生产环境，其中还包括数据库、自动调度、网络配置、负载均衡器、用户权限等。 关键问题是支持这一切所需的努力。 我们可以通过多种方式进行更改和推出更新。 例如，在 GCP 环境中，我们可以使用浏览器中的 UI 控制台，并通过单击按钮来执行所有操作。 另一种方法是使用 API 调用与云实体交互，或使用 gcloud 命令行实用程序执行所需的操作。 但由于存在大量不同的实体和基础设施元素，手动执行所有操作变得困难甚至不可能。 而且，所有这些手动操作都是不可控的。 我们无法在执行前提交审查、使用版本控制系统并快速回滚导致事件的更改。 为了解决此类问题，工程师创建并创建了自动 bash/shell 脚本，但这些脚本并不比以前的方法好多少，因为它们不太容易以程序化的方式快速阅读、理解、维护和修改。
在本文和操作指南中，我使用了 2 个与 IaC 实践相关的工具。 它们是 Terraform 和 Ansible。 有些人认为同时使用它们是没有意义的，因为它们的功能相似并且可以互换。 但事实是，最初他们被赋予了完全不同的任务。 代表 HashiCorp 和 RedHat 的开发人员在联合演示中证实了这些工具应该相互补充的事实。 概念上的区别在于 Terraform 是一个用于管理服务器本身的配置工具。 Ansible 是一个配置管理工具，其任务是在这些服务器上安装、配置和管理软件。
这些工具的另一个关键区别特征是编码风格。 与 bash 和 Ansible 不同，Terraform 使用基于对执行结果所需最终状态的描述的声明式风格。 例如，如果我们要创建 10 个虚拟机并通过 Terraform 应用更改，那么我们将获得 10 个虚拟机。 如果我们再次运行该脚本，则不会发生任何事情，因为我们已经有 10 个虚拟机，并且 Terraform 知道这一点，因为它将基础设施的当前状态存储在状态文件中。 但 Ansible 使用程序方法，如果您要求它创建 10 个虚拟机，那么在第一次启动时我们将获得 10 个虚拟机，类似于 Terraform。 但重新启动后我们已经有 20 个虚拟机了。 这是重要的区别。 在过程风格中，我们不存储当前状态，而只是描述必须执行的一系列步骤。 当然，我们可以处理各种情况，添加一些对资源是否存在和当前状态的检查，但浪费时间和精力来控制这个逻辑是没有意义的。 此外，这还增加了犯错误的风险。
总结以上所有内容，我们可以得出结论，Terraform 和声明性表示法是更适合配置服务器的工具。 但最好将配置管理工作委托给 Ansible。 抛开这些，让我们看看自动化背景下的用例。
自动化基础设施的价值
这里需要理解的唯一重要的事情是测试自动化基础设施应被视为整个公司基础设施的一部分。 这意味着所有 IaC 实践必须在全球范围内应用于整个组织的资源。 谁对此负责取决于您的流程。 DevOps 团队在这些问题上更有经验，他们能看到正在发生的事情的全貌。 然而，QA 工程师更多地参与构建自动化的过程和管道的结构，这使他们能够更好地看到所有所需的更改和改进的机会。 最好的选择是共同努力，交流知识和想法，以实现预期的结果。
以下是在测试自动化环境中使用 Terraform 和 Ansible 以及我们之前讨论的工具的一些示例：
1. 描述使用 Terraform 的虚拟机和集群的必要特征和参数。
2. 使用 Ansible，安装测试所需的工具：docker、Selenoid、Selenium Grid 并下载所需版本的浏览器/模拟器。
3. 使用 Terraform，描述将在其中启动 GitLab Runner 的 VM 的特征。
4. 使用 Ansible 安装 GitLab Runner 和必要的附带工具，设置设置和配置。
基础设施现状图解
探索链接：
类似工具
我们来总结一下吧！
步
专业技术
工具
自动化基础设施的价值
1
本地运行
Node.js、Selenium、Appium
- 最流行的网络和移动工具
- 支持多种语言和平台（包括Node.js）
2
版本控制系统
混帐
- 与开发代码类似的好处
3
集装箱化
Docker、Selenium 网格、Selenoid（Web、Android）
- 并行运行测试
- 隔离环境
- 简单、灵活的版本升级
- 动态停止未使用的资源
- 易于设置
4
持续集成/持续交付
亚特实验室持续集成
- 测试部分管道
- Быстраяобратнаясвязь
- 整个公司/团队的可见性
5
云平台
谷歌云平台
- 按需资源（我们仅在需要时付费）
- 易于管理和更新
- 所有资源的可见性和控制
6
编曲配置
Kubernetes
在 Pod 内带有浏览器/模拟器的容器上下文中：
- 缩放/自动缩放
- 自愈
- 不间断更新和回滚
7
基础设施即代码 (IaC)
地形、Ansible
- 与开发基础设施类似的好处
- 代码版本控制的所有好处
- 易于更改和维护
- 全自动
思维导图：基础设施的演变
第1步：本地
步骤2：VCS
步骤3：容器化
第四步：持续集成/持续交付
步骤5：云平台
第6步：编排
步骤7：IaC
接下来是什么？
那么，本文到此结束。 但总而言之，我想与您达成一些协议。
从你的角度出发
正如我在一开始所说的，我希望这篇文章具有实际用途，并帮助您将所学到的知识应用到实际工作中。 我再补充一下.
但即使在那之后，也不要停下来，练习，研究相关链接和书籍，了解它在你的公司是如何运作的，找到可以改进的地方并参与其中。 祝你好运！
从我这边
从标题就可以看出这只是第一部分。 尽管事实证明它相当大，但这里仍然没有涵盖重要的主题。 在第二部分中，我计划研究 IOS 背景下的自动化基础设施。 由于 Apple 限制 iOS 模拟器只能在 macOS 系统上运行，因此我们的解决方案范围缩小了。 例如，我们无法使用Docker来运行模拟器或公共云来运行虚拟机。 但这并不意味着没有其他选择。 我将尽力让您了解最新的先进解决方案和现代工具！
另外，我还没有提到与监控相关的相当大的主题。 在第 3 部分中，我将介绍最流行的基础设施监控工具以及要考虑的数据和指标。
最后。 将来，我计划发布有关构建测试基础设施和流行工具的视频课程。 目前，互联网上有不少关于 DevOps 的课程和讲座，但所有材料都是在开发背景下呈现的，而不是测试自动化。 在这个问题上，我确实需要关于这样的课程对于测试人员和自动化工程师社区是否有趣且有价值的反馈。 先感谢您！
来源： habr.com