Часть 1: Web / Android
注意: 本文是原文的俄文翻譯 然而，所有插圖、連結、引用和術語均保留原始語言，以避免翻譯成俄語時含義失真。祝您學習愉快！
目前，DevOps 專業是 IT 產業需求量最大的專業之一。如果您打開熱門職位搜尋網站並按薪資進行篩選，您將看到與 DevOps 相關的職位位於清單頂部。然而，重要的是要明白，這主要指的是「高級」職位，這意味著候選人擁有高水準的技能、技術和工具知識。這也伴隨著與生產不間斷運作相關的高度責任。然而，我們開始忘記DevOps 是什麼。最初，它不是任何特定的人或部門。如果我們尋找這個術語的定義，我們會發現許多美麗而正確的名詞，例如方法論、實踐、文化哲學、概念群等等。
我的專業是測試自動化工程師（QA自動化工程師），但我相信它不應該只與編寫自動測試或開發測試框架架構相關。 2020年，自動化基礎設施的知識也很重要。這使您可以自行組織自動化流程，從運行測試到根據您的目標向所有利害關係人提供結果。因此，DevOps 技能是完成工作所必需的。這一切都很好，但是，不幸的是，有一個問題（劇透：本文試圖簡化這個問題）。關鍵是 DevOps 很難。這是顯而易見的，因為公司不會為容易做的事情付出很多代價……在DevOps世界中，有大量的工具、術語和實踐需要掌握。這在職業生涯初期尤其困難，取決於累積的技術經驗。
來源：
到這裡，我們大概就結束了介紹部分，重點討論本文的目的。
這篇文章是關於什麼的？
在這篇文章中，我將分享我建立測試自動化基礎架構的經驗。網路上有很多關於各種工具以及如何使用它們的資訊來源，但我想純粹在自動化的背景下查看它們。我相信許多自動化工程師都熟悉這種情況：除了你之外沒有人運行開發的測試或關心維護它們。結果，測試變得過時，你必須花時間更新它們。同樣，在職業生涯的開始，這可能是一項相當困難的任務：明智地決定哪些工具應該有助於消除給定的問題，以及如何選擇、配置和維護它們。一些測試人員向 DevOps（人類）尋求幫助，老實說，這種方法是有效的。在許多情況下，這可能是唯一的選擇，因為我們無法了解所有依賴項。但正如我們所知，DevOps 是非常忙碌的人，因為他們必須考慮整個公司的基礎設施、部署、監控、微服務和其他類似的任務，這取決於組織/團隊。通常情況下，自動化並不是優先考慮的事項。在這種情況下，我們必須從頭到尾盡一切努力。這將減少依賴性，加快工作流程，提高我們的技能，並讓我們能夠看到正在發生的事情的全局。
文章介紹了最受歡迎、最受歡迎的工具，並展示如何使用它們逐步建立自動化基礎設施。每個組別都由經過個人經驗測試的工具代表。但這並不意味著您必須使用相同的東西。工具本身並不重要，它們出現並變得過時。我們的工程任務是了解基本原理：為什麼我們需要這組工具以及我們可以在它們的幫助下解決哪些工作問題。這就是為什麼我在每個部分的末尾留下了您的組織中可能使用的類似工具的連結。
本文中沒有的內容
我再次重申，本文不是關於特定工具的，因此不會插入文件中的程式碼和特定命令的描述。但在每個部分的結尾，我都會留下詳細研究的連結。
這樣做是因為：
- 這些材料很容易在各種來源（文件、書籍、視訊課程）中找到；
- 如果我們開始深入，我們將不得不寫這篇文章的 10、20、30 部分（而計劃是 2-3）；
- 我只是不想浪費您的時間，因為您可能想使用其他工具來實現相同的目標。
實踐
我真的希望這份資料對每位讀者都有用，而不僅僅是讀過之後就忘記了。在任何學習中，實踐都是非常重要的組成部分。為此我已經準備好了。還有作業等著你，以確保你不會盲目地複製正在執行的命令列。
計畫
步驟
科技
工具
1
本地運行（準備網路/Android演示測試並在本地運行）
Node.js、Selenium、Appium
2
版本控制系統
混帳
3
貨櫃化
Docker, Selenium grid, Selenoid (Web, Android)
4
持續整合/持續交付
亞特實驗室持續集成
5
雲平台
Google雲端平台
6
編曲配置
Kubernetes
7
基礎設施即代碼 (IaC)
地形、Ansible
各部分的結構
為了使敘述清晰，每個部分按照以下大綱進行描述：
- 該技術的簡要描述，
- 自動化基礎設施的價值，
- 基礎設施現狀的說明，
- 學習鏈接，
- 類似的工具。
1.本地運行測試
技術簡述
這只是在本地運行演示測試並驗證它們是否通過的準備步驟。實作部分使用的是Node.js，但是程式語言和平台也不重要，你可以使用你公司使用的語言和平台。
Однако в качестве инструментов автоматизации я рекомендую использовать Selenium WebDriver для web-платформ и Appium для Android-платформы соответственно, так как на следующих шагах мы будем использовать 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-системы для запуска контейнеров, но важно понимать, что в таком случае появляется дополнительная прослойка. Например, Docker на Mac незаметно запускает контейнеры внутри легковесной Linux VM. Мы еще вернемся к этой теме, когда будем обсуждать запуск Android-эмуляторов внутри контейнеров, так так здесь появляется очень важной нюанс, который необходимо разобрать более подробно.
自動化基礎設施的價值
我們發現容器化和 Docker 很酷。讓我們在自動化的背景下看待這個問題，因為每種工具或技術都需要解決一個問題。讓我們概述一下 UI 測試背景下測試自動化的明顯問題：
- 安裝 Selenium 尤其是 Appium 時存在大量相依性；
- 瀏覽器、模擬器、驅動版本之間的相容性問題；
- 缺乏瀏覽器/模擬器的隔離空間，這對於平行運行尤其重要；
- 如果需要同時運行10個、50個、100個甚至1000個瀏覽器，則難以管理和維護。
但由於 Selenium 是最受歡迎的自動化工具，而 Docker 是最受歡迎的容器化工具，因此有人嘗試將它們結合起來創建一個強大的工具來解決上述問題也就不足為奇了。讓我們更詳細地考慮此類解決方案。
docker 中的硒網格
Этот инструмент является самым популярным в мире Selenium для запуска нескольких браузеров на нескольких машинах и управления ими из центрального узла. Для запуска необходимо зарегистрировать как минимум 2 части: Hub и Node(s). Hub – это центральный узел, который получает все запросы от тестов и распределяет их по соответствующим Nodes. Для каждого Node мы можем настроить конкретную конфигурацию, например, указав нужный браузер и его версию. Однако нам все еще необходимо самим позаботиться о совместимых драйверах для браузеров и установить их на нужные Nodes. По этой причине Selenium grid не используется в чистом виде, за исключением тех случаев, когда нам нужно работать с браузерами, которые нельзя установить на Linux OS. Для всех остальных случаев значительно гибким и правильным решением будет использование Docker-образов для запуска Selenium grid Hub и Nodes. Такой подход сильно упрощает управление узлами, так как мы можем выбрать нужный нам образ с уже установленными совместимыми версиями браузеров и драйверов.
儘管對穩定性的負面評論，特別是在並行運行大量節點時，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 節中，我們將討論允許您擴展的解決方案，從而顯著降低公司成本。
Selenoid for Android
После успеха Selenoid в качестве инструмента для web-автоматизации, люди хотели получить что-то подобное для Android. И это свершилось – Selenoid был выпущен с поддержкой Android. С высокоуровневой пользовательской точки зрения принцип работы аналогичен web-автоматизации. Единственное отличие заключается в том, что вместо контейнеров с браузерами Selenoid запускает контейнеры с Android-эмуляторами. На мой взгляд, на сегодняшний момент это самый мощный бесплатный инструмент для запуска Android-тестов параллельно.
Мне бы очень не хотелось говорить о негативных сторонах данного инструмента, так как он действительно мне очень нравится. Но все же тут присутствуют те же недостатки, относящиеся и к web-автоматизации, связанные с масштабированием. В дополнение к этому нужно рассказать о еще одном ограничении, которое может стать неожиданностью, если мы настраиваем инструмент впервые. Для запуска Android-образов нам необходима физическая машина или VM с nested virtualisation — поддержкой. В практическом руководстве я демонстрирую, как это активировать на Linux VM. Однако если вы являетесь macOS пользователем и хотите развернуть Selenoid локально, то для запуска Android-тестов это будет невозможно. Но вы всегда можете запустить Linux VM локально с настроенной ‘nested virtualisation’ и развернуть Selenoid внутри.
基礎設施現況圖解
В контексте этой статьи мы добавим 2 инструмента для иллюстрации инфраструктуры. Это Selenium grid для web-тестов и Selenoid для Android-тестов. В руководстве на 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 и запустим 2 виртуальные машины с Selenoid. На первой мы поднимем 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
GCP for Android
n1-標準-4 x 8：n1-標準-16
$776.72
23 天 * 12 小時 * 1.52 = 419.52 美元
23 days * 12h * 0.32 = 88.32$
Sauce Labs for Android
Real Device Cloud 8 平行測試
$1.999
正如您所看到的，成本差異巨大，特別是如果您僅在 XNUMX 小時的工作時間內執行測試。但如果您使用搶佔式機器，您可以進一步降低成本。它是什麼？
可搶佔式虛擬機器是一種可以以比普通實例低得多的價格建立和運行的實例。但是，如果其他任務需要存取這些資源，Compute Engine 可能會終止（搶佔）這些執行個體。搶佔式執行個體是多餘的 Compute Engine 容量，因此它們的可用性會隨使用情況而變化。
如果您的應用程式具有容錯能力並且可以承受可能的執行個體搶佔，那麼搶佔式執行個體可以顯著降低您的 Compute Engine 成本。例如，批次作業可以在搶佔式實例上執行。如果其中一些實例在處理過程中終止，作業會減慢但不會完全停止。搶佔式執行個體可以完成您的批次任務，而不會為您現有的執行個體帶來額外的工作負載，也不需要您為額外的普通執行個體支付全額。
И это все еще не конец! В действительности я уверен, что никто не запускает тесты по 12 часов без перерыва. И если это так, то вы можете автоматически запускать и останавливать виртуальные машины, когда они не нужны. Реальное время использования может снизиться до 6 часов в сутки. Тогда оплата в контексте нашей задачи уменьшится аж до 11$ в месяц за 8 браузеров. Разве это не прекрасно? Но с preemptible машинами мы должны быть осторожны и готовы к прерываниям и нестабильной работе, хотя эти ситуации могут быть предусмотрены и обработаны программно. Оно того стоит!
Но ни в коем случае я не говорю ‘никогда не используйте облачные тестовые фермы’. Они имеют ряд преимуществ. Прежде всего это не просто виртуальная машина, а полноценное решение для автоматизации тестирования с набором функционала из коробки: удаленный доступ, логи, скриншоты, видеозапись, различные браузеры и физические мобильные устройства. Во многих ситуациях это может быть незаменимой шикарной альтернативой. Особенно тестовые платформы полезны для IOS-автоматизации, когда публичные облака могут предложить только Linux/Windows-системы. Но разговор про IOS будет в следующих статьях. Я рекомендую всегда смотреть по ситуации и отталкиваться от задач: в каких-то дешевле и эффективнее использовать публичные облака, а в каких то тестовые платформы определено стоят потраченных денег.
基礎設施現況圖解
探索連結
類似工具：
6. 編排
技術簡述
У меня хорошие новости – мы почти достигли конца статьи! На данный момент наша инфраструктура автоматизации состоит из web и Android-тестов, которые мы запускаем через GitLab CI параллельно, используя инструменты с поддержкой Docker: Selenium grid и Selenoid. Более того, мы используем созданные через 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 在叢集內的工作與虛擬機器內的工作沒有什麼不同。故事結局。
月球:
意識到使用 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 grid, Selenoid (Web, Android)
- 並行運行測試
- 隔離環境
- 簡單、靈活的版本升級
- 動態停止未使用的資源
- 易於設置
4
持續整合/持續交付
亞特實驗室持續集成
- 測試部分管道
- 快速回饋
- 整個公司/團隊的可見性
5
雲平台
Google雲端平台
- 按需資源（我們僅在需要時付費）
- 易於管理和更新
- 所有資源的可見性與控制
6
編曲配置
Kubernetes
在 Pod 內帶有瀏覽器/模擬器的容器上下文中：
- 縮放/自動縮放
- 自癒
- 不間斷更新和回滾
7
基礎設施即代碼 (IaC)
地形、Ansible
- 與開發基礎設施類似的好處
- 程式碼版本控制的所有好處
- 易於更改和維護
- 全自動
心智圖：基礎設施的演變
第1步：本地
步驟2：VCS
步驟3：容器化
第四步：持續整合/持續交付
步驟5：雲端平台
第6步：編排
步驟7：IaC
接下來是什麼？
那麼，本文到此結束。但總而言之，我想與您達成一些協議。
從你的角度出發
正如我在一開始所說的，我希望這篇文章具有實際用途，並幫助您將所學到的知識應用到實際工作中。我再補充一下.
但即使在那之後，也不要停下來，練習，研究相關連結和書籍，了解它在你的公司是如何運作的，找到可以改進的地方並參與其中。祝你好運！
從我這邊
Из заголовка видно, что это была только первая часть. Несмотря на то, что она получилось довольно большой, здесь все еще не раскрыты важные темы. Во второй части я планирую рассмотреть инфраструктуру автоматизации в контексте IOS. Из-за ограничений Apple, связанных с запусками IOS симуляторов только на macOS системах, наш набор решений сужен. Например, мы лишены возможности использовать Docker для запуска симулятора или публичных облаков для запуска виртуальных машин. Но это не означает, что нет других альтернатив. Я постараюсь держать вас в курсе передовых решений и современных инструментов!
另外，我還沒有提到與監控相關的相當大的主題。在第 3 部分中，我將介紹最受歡迎的基礎設施監控工具以及要考慮的數據和指標。
最後。將來，我計劃發布有關建立測試基礎設施和流行工具的影片課程。目前，網路上有不少關於 DevOps 的課程和講座，但所有材料都是在開發背景下呈現的，而不是測試自動化。在這個問題上，我確實需要關於這樣的課程對於測試人員和自動化工程師社群是否有趣且有價值的回饋。先感謝您！
來源： www.habr.com
