建站
咨詢
售后
建站咨詢
新聞中心
HyperBDR是一款基于云原生理念的遷移和容災(zāi)產(chǎn)品，核心的業(yè)務(wù)場(chǎng)景是將源端以塊級(jí)別差量方式同步至云原生存儲(chǔ)中，目前已經(jīng)實(shí)現(xiàn)對(duì)塊存儲(chǔ)和對(duì)象存儲(chǔ)支持，最后再利用Boot-in-Cloud專利技術(shù)將業(yè)務(wù)系統(tǒng)一鍵式恢復(fù)至可用狀態(tài)，真正做到了對(duì)云原生編排能力的充分利用，滿足遷移和災(zāi)備等業(yè)務(wù)場(chǎng)景的不同需求。
創(chuàng)新互聯(lián)公司服務(wù)項(xiàng)目包括上虞網(wǎng)站建設(shè)、上虞網(wǎng)站制作、上虞網(wǎng)頁(yè)制作以及上虞網(wǎng)絡(luò)營(yíng)銷(xiāo)策劃等。多年來(lái)，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，上虞網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到上虞省份的部分城市，未來(lái)相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！
HyperBDR目前已經(jīng)支持的源端操作系統(tǒng)大版本就將近10個(gè)(
Windows/CentOS/Redhat/Ubuntu/SUSE/國(guó)產(chǎn)化操作系統(tǒng))，小版本更是超過(guò)幾百個(gè)，而在目標(biāo)目標(biāo)云平臺(tái)也陸續(xù)支持了將近40個(gè)(公有云、專有云、私有云、超融合、虛擬化等)，并且數(shù)量還在增加。假設(shè)我們將源端的操作系統(tǒng)到全部云平臺(tái)進(jìn)行一次覆蓋性測(cè)試，組合的測(cè)試用例可能超過(guò)10000個(gè)。
這么大規(guī)模的情況下想做到測(cè)試覆蓋，單純依靠人力顯然不現(xiàn)實(shí)，必須引入自動(dòng)化測(cè)試手段對(duì)核心業(yè)務(wù)場(chǎng)景進(jìn)行測(cè)試，這樣不僅可以滿足自動(dòng)化測(cè)試的需要，也可以在日常開(kāi)發(fā)過(guò)程中及時(shí)讓開(kāi)發(fā)人員在新開(kāi)發(fā)功能中對(duì)核心流程的影響，進(jìn)一步提升產(chǎn)品的穩(wěn)定性和可靠性。
痛點(diǎn)分析
我們先來(lái)看一下手工測(cè)試情況下，HyperBDR產(chǎn)品測(cè)試的幾個(gè)痛點(diǎn)：
痛點(diǎn)一、測(cè)試用例多，人力資源不足
在上述源端和目標(biāo)端的規(guī)模情況下，即使做一些基本冒煙，一次完整的測(cè)試的場(chǎng)景用例也依然有一百多種。例如：
- ? 源端(19種)：CentOS(6/7/8)、Redhat(6/7/8)、SUSE(11/12)、Ubuntu(14.04/16.04/18.04/20.04)、Windows(2003/2008/2012/2016/2019)、Oracle Linux、國(guó)產(chǎn)化操作系統(tǒng)
- ? 目標(biāo)端(9種)：OpenStack、AWS、阿里云、騰訊云、華為云、移動(dòng)云、ZStack、超融合產(chǎn)品、超融合產(chǎn)品
如此計(jì)算下來(lái)，一次測(cè)試的場(chǎng)景是171種?？赡苡械耐瑢W(xué)會(huì)說(shuō)，這些用例也不是很多呀，跑一次也用不了多久，所以接下來(lái)讓我們看一下HyperBDR在測(cè)試過(guò)程中第二個(gè)痛點(diǎn)：測(cè)試周期問(wèn)題。
痛點(diǎn)二、測(cè)試周期長(zhǎng)
不同于業(yè)務(wù)測(cè)試，HyperBDR單一場(chǎng)景的測(cè)試是非常耗時(shí)的，我們先忽略前期資源準(zhǔn)備時(shí)間和各種配置時(shí)間，單純就數(shù)據(jù)同步和啟動(dòng)過(guò)程進(jìn)行一下分析：
- ? 數(shù)據(jù)同步：簡(jiǎn)單來(lái)說(shuō)數(shù)據(jù)同步的過(guò)程就是將源端操作系統(tǒng)內(nèi)的有效數(shù)據(jù)(不是分配容量)，以塊級(jí)別方式讀出，寫(xiě)入到目標(biāo)的云原生存儲(chǔ)中。其中，第一次為全量，后續(xù)為永久增量。以Windows為例，假設(shè)有效數(shù)據(jù)為500G，如果按照千兆局域網(wǎng)帶寬80%利用率計(jì)算，傳輸速度大概在800 Mbps，大約為80 MB/s，耗時(shí)約為1小時(shí)8分鐘。
- ? 主機(jī)啟動(dòng)：根據(jù)不同的云原生存儲(chǔ)類型，啟動(dòng)時(shí)間有很大的差異性，例如華為云的塊存儲(chǔ)，由于快照機(jī)制以及可以支持交換系統(tǒng)盤(pán)，所以啟動(dòng)時(shí)間與容量基本沒(méi)有關(guān)系，基本可以控制在5分鐘之內(nèi)。但是對(duì)于國(guó)內(nèi)的大多數(shù)云平臺(tái)來(lái)說(shuō)，并沒(méi)有這樣的能力，像阿里云在有快照生成卷時(shí)，底層限速為40 MB/s，這樣一下子就拉長(zhǎng)了恢復(fù)實(shí)踐。我們以對(duì)象存儲(chǔ)為例，假設(shè)我們從內(nèi)網(wǎng)(Internal網(wǎng)絡(luò))將對(duì)象存儲(chǔ)數(shù)據(jù)恢復(fù)至塊存儲(chǔ)，一個(gè)500G有效數(shù)據(jù)磁盤(pán)的恢復(fù)時(shí)間大約在40分鐘左右。
所以我們?cè)谔幚韱我恢鳈C(jī)的一次測(cè)試，耗時(shí)至少在2個(gè)小時(shí)之內(nèi)。按照上面假設(shè)的場(chǎng)景，一天測(cè)試下來(lái)，可能連一朵云的完整測(cè)試都無(wú)法完成?？赡苓@里又有同學(xué)說(shuō)了，你為什么不并發(fā)呀？這又引出了我們第三個(gè)痛點(diǎn)問(wèn)題：成本。
痛點(diǎn)三、測(cè)試成本
之所以無(wú)法完全采用并發(fā)的原因，是受限于網(wǎng)絡(luò)帶寬因素。在內(nèi)部研發(fā)環(huán)境中，我們的外網(wǎng)帶寬只有40Mbps，在上述測(cè)試場(chǎng)景中，500G的數(shù)據(jù)在帶寬充分利用的前提下，全量數(shù)據(jù)傳輸?shù)臅r(shí)間在35小時(shí)左右。這無(wú)疑進(jìn)一步擴(kuò)大了一次測(cè)試的周期。
另外一點(diǎn)，源端這么多環(huán)境，如果再加上不同場(chǎng)景，需要占用的源端的計(jì)算和存儲(chǔ)資源是海量的。隨著產(chǎn)品不停地迭代，資源占用會(huì)越來(lái)越多。所以為了解決這一問(wèn)題，我們決定采用部分公有云環(huán)境，來(lái)解決本地資源不足的問(wèn)題。根據(jù)資源使用的特點(diǎn)，主要采用按量計(jì)費(fèi)方式，實(shí)現(xiàn)成本最優(yōu)。在實(shí)際測(cè)試過(guò)程中，主要產(chǎn)生的云資源包括：計(jì)算、塊存儲(chǔ)、對(duì)象存儲(chǔ)、網(wǎng)絡(luò)等。在自動(dòng)化測(cè)試中，盡可能縮短資源周期，避免浪費(fèi)，及時(shí)清理資源。另外，還需要對(duì)資源賬單情況進(jìn)行監(jiān)控，避免資源殘留。
需求分析
基本原則：不要重復(fù)制造輪子
進(jìn)行自動(dòng)化測(cè)試開(kāi)發(fā)工作，并沒(méi)有增加新的開(kāi)發(fā)人員。開(kāi)發(fā)工作主要由研發(fā)團(tuán)隊(duì)負(fù)責(zé)，測(cè)試團(tuán)隊(duì)作為使用方。但是由于開(kāi)發(fā)團(tuán)隊(duì)有自身產(chǎn)品研發(fā)任務(wù)，所以為了避免對(duì)產(chǎn)品研發(fā)造成影響，制定的第一個(gè)原則就是不要重復(fù)制造輪子，盡可能復(fù)用現(xiàn)有技術(shù)積累和第三方組件，靈活的實(shí)現(xiàn)自動(dòng)化測(cè)試的目標(biāo)。
需求一、源端自動(dòng)化創(chuàng)建與銷(xiāo)毀
首先要解決的就是源端資源的靈活創(chuàng)建，而這方面最簡(jiǎn)單的就是利用Terraform，結(jié)合不同的模板實(shí)現(xiàn)源端資源創(chuàng)建和銷(xiāo)毀能力。這樣，我們至少擁有了阿里云、華為云、AWS、OpenStack、VMware五大云作為源端的能力。
第二個(gè)要解決的是代理方式自動(dòng)化注冊(cè)問(wèn)題。源端主機(jī)需要進(jìn)行Agent安裝和注冊(cè)后，才能被HyperBDR識(shí)別進(jìn)行后續(xù)流程。根據(jù)操作系統(tǒng)不同，又分為L(zhǎng)inux和Windows系統(tǒng)。Linux系統(tǒng)中，可以使用SSH登錄系統(tǒng)后執(zhí)行安裝，而Windows則是利用WinRM方式進(jìn)行Agent安裝。
第三，可擴(kuò)展性滿足更多場(chǎng)景化需求。雖然Terraform本身提供了remote執(zhí)行方式，但是為了后續(xù)的可擴(kuò)展性，可以結(jié)合Ansible實(shí)現(xiàn)相關(guān)功能。未來(lái)的測(cè)試場(chǎng)景可能還包含對(duì)源端各種應(yīng)用數(shù)據(jù)完整性的測(cè)試，此時(shí)在準(zhǔn)備源端時(shí)還需要額外的準(zhǔn)備應(yīng)用和數(shù)據(jù)，使用Terraform結(jié)合Ansible，可以實(shí)現(xiàn)最大的靈活性。
需求二、測(cè)試場(chǎng)景與測(cè)試工具解耦，滿足擴(kuò)展性需求
簡(jiǎn)單來(lái)說(shuō)，自動(dòng)化測(cè)試程度越高，開(kāi)發(fā)成本越高，后期維護(hù)的成本會(huì)更高。因此在規(guī)劃自動(dòng)化測(cè)試時(shí)，要降低測(cè)試場(chǎng)景和測(cè)試工具之間的耦合性。這樣才能最大程度滿足測(cè)試場(chǎng)景的可擴(kuò)展性。換言之，測(cè)試場(chǎng)景是由測(cè)試工具進(jìn)行靈活組合實(shí)現(xiàn)的，而二者之間的差距是通過(guò)各種配置文件進(jìn)行融會(huì)貫通。
具體到HyperBDR的自動(dòng)化測(cè)試規(guī)劃中，我們將場(chǎng)景定義為：
- ? 為了驗(yàn)證主線流程的穩(wěn)定性，我們?cè)O(shè)計(jì)了這樣的場(chǎng)景：阿里云的一臺(tái)CentOS 7操作系統(tǒng)主機(jī)，容災(zāi)到阿里云對(duì)象存儲(chǔ)中，利用該數(shù)據(jù)，主機(jī)可以正常啟動(dòng)，系統(tǒng)啟動(dòng)后，可以正常ping通IP地址，可以正常SSH到系統(tǒng)內(nèi)部，寫(xiě)入一個(gè)文件
- ? 為了驗(yàn)證華為云驅(qū)動(dòng)的穩(wěn)定性，我們?cè)O(shè)計(jì)的場(chǎng)景如下：將阿里云的N臺(tái)主機(jī)(包含各個(gè)版本的操作系統(tǒng))，容災(zāi)到華為云的對(duì)象存儲(chǔ)或塊存儲(chǔ)中，再將主機(jī)在華為云進(jìn)行啟動(dòng)，啟動(dòng)后，利用ping通IP地址，可以正常登錄系統(tǒng)，寫(xiě)入一個(gè)文件
- ? 為了驗(yàn)證增量數(shù)據(jù)，我們?cè)O(shè)計(jì)的場(chǎng)景如下：將阿里云的N臺(tái)主機(jī)安裝數(shù)據(jù)庫(kù)，并且構(gòu)建一定量數(shù)據(jù)進(jìn)行記錄，容災(zāi)到華為云對(duì)象存儲(chǔ)中，再將主機(jī)在華為云進(jìn)行啟動(dòng)，啟動(dòng)后，除了常規(guī)驗(yàn)證外，還要對(duì)數(shù)據(jù)庫(kù)是否可以訪問(wèn)以及數(shù)據(jù)記錄條數(shù)進(jìn)行比對(duì)
而測(cè)試工具提供的能力上，我們進(jìn)行了這樣的定義：
- ? 源端創(chuàng)建/刪除資源：完全由Terraform實(shí)現(xiàn)，但是為了后續(xù)程序更好的銜接，在產(chǎn)生主機(jī)后，自動(dòng)產(chǎn)生一個(gè)conf文件，作為后續(xù)命令的輸入，而主機(jī)內(nèi)不同的應(yīng)用則通過(guò)編寫(xiě)Ansible模板實(shí)現(xiàn)
- ? 目標(biāo)平臺(tái)配置/數(shù)據(jù)同步/啟動(dòng)主機(jī)/清理資源：這幾部分主要通過(guò)調(diào)用HyperBDR SDK實(shí)現(xiàn)，而具體的配置則在配置文件中進(jìn)行修改，如果是不同場(chǎng)景時(shí)，只需要不同的配置文件即可實(shí)現(xiàn)
以上全部的步驟，均是可以單獨(dú)執(zhí)行的，而每一步完成后，寫(xiě)入統(tǒng)一的CSV文件，這樣步驟在連接時(shí)可以通過(guò)該文件形成統(tǒng)一性。后續(xù)可以將該CSV文件直接推送到數(shù)據(jù)可視化工具中，形成趨勢(shì)展現(xiàn)的效果。
需求三、實(shí)現(xiàn)場(chǎng)景自動(dòng)化，測(cè)試失敗及時(shí)通知
在實(shí)際應(yīng)用中，幾乎從研發(fā)到交付的整個(gè)過(guò)程中都需要使用該工具。比如研發(fā)同學(xué)在提交代碼前，至少需要對(duì)基本流程進(jìn)行一次測(cè)試；交付同事在搭建一些演示環(huán)境時(shí)，也可以利用該腳本提高效率；而測(cè)試同事更是對(duì)這個(gè)工具有強(qiáng)烈的需求。
那么真正的不同場(chǎng)景自動(dòng)化工作，則是由Jenkins任務(wù)完成串聯(lián)，并且在測(cè)試失敗后，可以及時(shí)通知大家，盡快進(jìn)行修改。例如：每個(gè)小時(shí)，做一次小的冒煙測(cè)試，確保主線流程是否穩(wěn)定；每天凌晨，做一次基本冒煙，確保已經(jīng)支持云平臺(tái)的穩(wěn)定性；每周做一次大冒煙，確保主要的操作系統(tǒng)版本的穩(wěn)定性。這樣不僅節(jié)約了人力資源，也能第一時(shí)間發(fā)現(xiàn)版本中的不穩(wěn)定因素。
實(shí)現(xiàn)方式
整體架構(gòu)
根據(jù)上面的需求，完整的工具包含兩部分：
- Terraform：主要包含了源端創(chuàng)建使用的模板以及ansible playbooks，Terraform在每次執(zhí)行后，會(huì)自動(dòng)產(chǎn)生源端主機(jī)列表，用于AutoTest工具的命令行輸入?yún)?shù)
- AutoTest工具：使用Python語(yǔ)言開(kāi)發(fā)，主要通過(guò)對(duì)HyperBDR SDK調(diào)用控制HyperBDR實(shí)現(xiàn)自動(dòng)化流程調(diào)度，各個(gè)階段都是通過(guò)獨(dú)立命令行進(jìn)行控制，所有的可變部分在配置文件進(jìn)行修改
- AutoTest配置文件包含以下三部分配置：
- 基本配置：HyperBDR SDK鑒權(quán)信息，以及平臺(tái)整體配置
- 目標(biāo)云平臺(tái)配置：目標(biāo)云平臺(tái)鑒權(quán)信息，配置參數(shù)等，根據(jù)不同的存儲(chǔ)類型分為塊存儲(chǔ)和對(duì)象存儲(chǔ)
- 容災(zāi)/遷移配置：用于定義主機(jī)在目標(biāo)端的啟動(dòng)參數(shù)
Terraform創(chuàng)建資源并遠(yuǎn)程執(zhí)行指令
Terraform的使用方面，有很多教程，這里不再贅述。這里主要說(shuō)明一些Terraform使用的一些細(xì)節(jié)功能，滿足Terraform于AutoTest之間的腳本串聯(lián)。
內(nèi)置方法remote-exec
Terraform創(chuàng)建資源后，會(huì)自動(dòng)安裝Agent注冊(cè)到HyperBDR中，為了減少遠(yuǎn)程主機(jī)操作復(fù)雜度，這里將Agent上傳至新創(chuàng)建的主機(jī)，再進(jìn)行安裝實(shí)現(xiàn)自動(dòng)注冊(cè)。
Terraform本身通過(guò)provisioner提供遠(yuǎn)程連接、上傳并執(zhí)行的方式，基本結(jié)構(gòu)如下：
resource "null_resource" "ins_centos7_run_remote_command" {
# 定義了SSH連接方式，可以通過(guò)密碼或者密鑰方式
connection {
timeout = "5m"
type = "ssh"
user = "root"
password = "${random_password.password.result}"
host = "${openstack_compute_instance_v2.ins_centos7.network[0].fixed_ip_v4}"
}
# 將本地文件上傳至遠(yuǎn)程資源的某個(gè)目錄中
provisioner "file" {
source = "../downloads/linux_agent.sh"
destination = "/tmp/script.sh"
}
# 通過(guò)remote-exec遠(yuǎn)程執(zhí)行腳本
provisioner "remote-exec" {
inline = [
"chmod +x /tmp/script.sh",
"sudo bash /tmp/script.sh",
]
}
depends_on = [openstack_compute_instance_v2.ins_centos7]
}
如果是Windows，則連接方式為winrm方式，這里要注意的一點(diǎn)是，啟動(dòng)的資源必須已經(jīng)開(kāi)啟了WinRM，否則無(wú)法使用該方式進(jìn)行連接。一種開(kāi)啟WinRM方式是利用user-data方式。這里看一下具體的示例
resource "null_resource" "run_windows_remote_command" {
# 注意此處的類型為winrm
connection {
timeout = "5m"
type = "winrm"
user = "Administrator"
password = "${random_password.password.result}"
host = "${openstack_compute_instance_v2.ins_windows.network[0].fixed_ip_v4}"
https = true
insecure = true
}
# 如果給定的是一個(gè)目錄，則會(huì)上傳整個(gè)目錄，但是要注意Windows目錄的斜線方向，盤(pán)符需要轉(zhuǎn)移C:\\
provisioner "file" {
source = "../downloads/Windows_server_64bit_beta"
destination = "C:\\Windows_server_64bit_beta"
}
# 遠(yuǎn)程執(zhí)行方式與Linux相同
provisioner "remote-exec" {
inline = [
"C:\\Windows_server_64bit_beta\\install-cli.bat",
"net start DiskSyncAgent",
]
}
depends_on = [openstack_compute_instance_v2.ins_windows]
}
與Ansible結(jié)合
直接利用Terraform的遠(yuǎn)程執(zhí)行方式很簡(jiǎn)便，但是對(duì)于更多的復(fù)雜場(chǎng)景在支持上，并不夠靈活，所以我們引入Ansible來(lái)加強(qiáng)我們對(duì)資源的控制。與remote-exec相對(duì)應(yīng)的指令是local-exec，即通過(guò)執(zhí)行本地的Ansible指令實(shí)現(xiàn)對(duì)遠(yuǎn)程資源的控制。目錄結(jié)構(gòu)如下：
.
├── main.tf
├── playbooks
│ └── apache-install.yml
我們將Ansible Playbooks存放在單獨(dú)的目錄中，Terraform中實(shí)現(xiàn)方式如下：
resource "null_resource" "run_ansible" {
connection {
timeout = "5m"
type = "ssh"
user = "root"
password = "${random_password.password.result}"
host = "${huaweicloud_vpc_eip.myeip.address}"
}
# 這里調(diào)用了local-exec本地執(zhí)行Ansible命令
provisioner "local-exec" {
command = "ANSIBLE_HOST_KEY_CHECKING=False ansible-playbook -u root -i '${huaweicloud_vpc_eip.myeip.address},' --extra-vars 'ansible_ssh_pass=${random_password.password.result}' --ssh-common-args '-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null' playbooks/apache-install.yml"
}
depends_on = [huaweicloud_compute_eip_associate.associated]
}
輸出
為了串接Terraform和AutoTest，我們需要Terraform每次執(zhí)行后，輸出一個(gè)主機(jī)列表，包含了一些基本信息，當(dāng)然這也可以作為Ansible Inventory文件使用。利用local_file resource，直接將我們想要寫(xiě)入的內(nèi)容定向輸出到文件中。具體實(shí)現(xiàn)如下：
resource "local_file" "inventory" {
filename = "./sources.conf"
content = <<-EOF
[${openstack_compute_instance_v2.ins_centos7.network[0].fixed_ip_v4}]
username = centos
password = ${nonsensitive(random_password.password.result)}
ipv4 = ${openstack_compute_instance_v2.ins_centos7.network[0].fixed_ip_v4}
mac = ${openstack_compute_instance_v2.ins_centos7.network[0].mac}
private_key = "${abspath(path.module)}/../keys/openstack_linux.pem"
os = CentOS7
EOF
}
Terraform本地緩存
由于眾所周知的原因，Terraform在執(zhí)行init命令的時(shí)候，會(huì)訪問(wèn)github，這就造成安裝過(guò)程中有一定的失敗概率，為了減少失敗的風(fēng)險(xiǎn)，需要采用本地緩存的方式，避免訪問(wèn)網(wǎng)絡(luò)造成的風(fēng)險(xiǎn)。先來(lái)看一下目錄結(jié)構(gòu)：
.
├── install.sh
├── plugins-cache
│ └── registry.terraform.io
│ ├── hashicorp
│ │ ├── local
│ │ ├── null
│ │ ├── random
│ │ ├── template
│ │ └── tls
│ ├── huaweicloud
│ │ └── huaweicloud
│ └── terraform-provider-openstack
│ └── openstack
├── README.md
├── terraform_1.3.7_linux_amd64.zip
└── update_plugins_cache.sh
install.sh用于將下載好的terraform二進(jìn)制包進(jìn)行解壓縮安裝，同時(shí)會(huì)將plugins-cache拷貝至$HOME/.terraform.d目錄，最后生成.terraformrc文件。
plugin_cache_dir = "$HOME/.terraform.d/plugins-cache"
在實(shí)際執(zhí)行時(shí)，通過(guò)指定參數(shù)實(shí)現(xiàn)從本地執(zhí)行安裝，這種方式網(wǎng)上大部分文檔都沒(méi)有提及到：
terraform init -ignore-remote-version
在構(gòu)建plugins-cache時(shí)，我們主要使用terraform providers mirror命令，例如：
terrform providers mirror /path/to/your/plugins-cache
為此我們?cè)陧?xiàng)目中增加了一個(gè)腳本，來(lái)自動(dòng)化更新我們的緩存：
#!/bin/bash
#
# This script is used to install Terraform from local
#
set -e
CURRENT_PATH=$(cd `dirname $0`; pwd)
TERRAFORM_CLI="$HOME/bin/terraform"
PLUGINS_CACHE_PATH="${CURRENT_PATH}/plugins-cache"
SRC_ROOT_PATH="${CURRENT_PATH}/.."
# NOTE(Ray): Find all terraform directories and cache providers
for dir in $(find $SRC_ROOT_PATH -type d); do
for file in "$dir"/*tf; do
if [ -f "$file" ]; then
echo "Run terraform cache in $dir..."
$TERRAFORM_CLI providers mirror $PLUGINS_CACHE_PATH
break
fi
done
done
Taskflow串聯(lián)執(zhí)行流程，實(shí)現(xiàn)擴(kuò)展性
在AutoTest工具開(kāi)發(fā)過(guò)程中，我們主要復(fù)用了OpenStack部分Python模塊簡(jiǎn)化開(kāi)發(fā)，主要使用的模塊為stevedore和taskflow，另外為了簡(jiǎn)化CSV文件操作，使用了pandas庫(kù)來(lái)進(jìn)行操作。
利用驅(qū)動(dòng)方式擴(kuò)展命令行
在setup.cfg中，我們定義了下面的驅(qū)動(dòng)，每一個(gè)指令對(duì)應(yīng)一個(gè)Taskflow的執(zhí)行流程。
tasks =
cloud_config_oss = autotest.tasks.cloud_config:CloudConfigOss
cloud_config_block = autotest.tasks.cloud_config:CloudConfigBlock
cloud_config_clean = autotest.tasks.cloud_config:CloudConfigClean
data_sync_oss = autotest.tasks.data_sync:DataSyncOss
data_sync_block = autotest.tasks.data_sync:DataSyncBlock
host_boot = autotest.tasks.host_boot:HostBoot
host_clean = autotest.tasks.host_clean:HostClean
report = autotest.tasks.report:Report
在代碼加載時(shí)，通過(guò)輸入而不同參數(shù)，動(dòng)態(tài)加載相應(yīng)的流水線：
def run_tasks(args, hosts_conf, hyperbdr_conf):
"""Load each tasks as a driver"""
# We use a csv as a data table
data_table = DataTable(hosts_conf, args.work_path)
data_table.init()
status_file = StatusFile(args.work_path)
status_file.init()
driver_name = args.which.replace("-", "_")
logging.info("Loading task driver for %s..." % driver_name)
# 根據(jù)不同的命令行名稱，加載相關(guān)的驅(qū)動(dòng)
driver_manager = driver.DriverManager(
namespace="tasks",
name=driver_name,
invoke_on_load=False)
task_driver = driver_manager.driver(hyperbdr_conf, data_table, status_file)
task_driver.run()
利用Taskflow串接流程
Taskflow是OpenStack中非常優(yōu)秀的庫(kù)，對(duì)Task執(zhí)行過(guò)程進(jìn)行了抽象后，方便上層上時(shí)序業(yè)務(wù)場(chǎng)景使用。所以在應(yīng)用中為了簡(jiǎn)化開(kāi)發(fā)過(guò)程，在Taskflow之上做了適當(dāng)?shù)某橄?，將?zhí)行過(guò)程和執(zhí)行內(nèi)容進(jìn)行分離，即基類中進(jìn)行執(zhí)行，而子類中只需要定義相關(guān)具體的任務(wù)即可。
基類代碼示例如下：
import taskflow.engines
from taskflow.patterns import linear_flow as lf
class BaseTask(object):
# 此處有代碼省略
def run(self, tasks=[], *args, **kwargs):
# 子類只需要在繼承類中定義好自己的tasks即可
if not tasks:
raise NotImplementedError("run() method "
"is not implemented")
# .......
flow_name = self.__class__.__name__
flow_api = lf.Flow(flow_name)
for task in tasks:
flow_api.add(task)
try:
taskflow.engines.run(flow_api,
engine_conf={"engine": "serial"},
store={
# 參數(shù)傳遞
})
except Exception as e:
raise e
finally:
# 任務(wù)失敗后的處理，比如記錄數(shù)據(jù)
一個(gè)具體的子類實(shí)現(xiàn)如下：
from taskflow import task
from autotest.tasks.base import BaseTask
class CloudConfigOss(BaseTask):
def run(self, *args, **kwargs):
steps = [
AddCloudAccount(),
WaitCloudAccount(),
AddOss(),
]
super().run(steps)
class AddCloudAccount(task.Task):
# TODO
class WaitCloudAccount(task.Task):
# TODO
class AddOss(task.Task):
# TODO
通過(guò)上述抽象，可以很快速的利用HyperBDR SDK實(shí)現(xiàn)各種應(yīng)用場(chǎng)景，最大程度滿足后續(xù)可擴(kuò)展性的需求。
Jenkins串聯(lián)自動(dòng)化測(cè)試流程
工具實(shí)現(xiàn)后，不僅可以滿足手工分步執(zhí)行的需要，也可以利用Jenkins串接流程，滿足場(chǎng)景自動(dòng)化測(cè)試的需求。
場(chǎng)景自動(dòng)化
我們?cè)趃it中新建一個(gè)項(xiàng)目，名稱為autotest-cases，用于自動(dòng)化場(chǎng)景測(cè)試。示例結(jié)構(gòu)如下：
.
├── Jenkinsfile
├── openstack_oss_qa_tiny_smoke
│ ├── hyperbdr.conf
│ └── terraform_templates
我們以場(chǎng)景名稱命名目錄，每一個(gè)目錄下均有單獨(dú)一套的terraform模板和hyperbdr配置文件。這樣定義Jenkins任務(wù)時(shí)，就可以把測(cè)試場(chǎng)景作為一個(gè)目錄，靈活的進(jìn)行加載。
其中Jenkinsifle的基本結(jié)構(gòu)為：
pipeline {
// 省略部分代碼
parameters {
string(
name: 'TEST_CASE',
defaultValue: 'openstack_oss_qa_tiny_smoke',
description: '測(cè)試任務(wù)執(zhí)行的目錄，對(duì)應(yīng)autotest-cases的目錄'
)
string(
name: 'HYPERBDR_URL',
defaultValue: 'https://xxxx',
description: 'HyperBDR地址，需要配合鑒權(quán)信息使用'
)
// 省略部分代碼
}
stages {
stage('Clone Repository') {
// 省略部分代碼
} // end stage
stage('更新HyperBDR環(huán)境') {
// 省略部分代碼
} // end stage
stage('下載Agent代理') {
// 省略部分代碼
} // end stage
// 鑒權(quán)信息固定寫(xiě)在Terraform tfvars文件時(shí)，使用時(shí)通過(guò)Jenkins中的Credentials進(jìn)行替換
stage('創(chuàng)建源端') {
steps {
// 對(duì)每個(gè)目錄下auth文件進(jìn)行替換后，source聲明環(huán)境變量
withCredentials([usernamePassword(credentialsId: "${CLOUD_CREDENTIALS_ID}", usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) {
sh """
sed -i "s/JENKINS_CLOUD_USERNAME/${USERNAME}/g" "${terraformVars}"
sed -i "s/JENKINS_CLOUD_PASSWORD/${PASSWORD}/g" "${terraformVars}"
"""
}
dir("${terraformTemplatePath}") {
sh """
${terraformPath} init -ignore-remote-version -plugin-dir ~/.terraform.d/plugins-cache
${terraformPath} apply -auto-approve -var-file="${terraformVars}"
"""
}
} // end steps
} // end stage
stage('目標(biāo)平臺(tái)配置') {
// 省略部分代碼
} // end stage
stage('數(shù)據(jù)同步') {
// 省略部分代碼
} // end stage
stage('啟動(dòng)主機(jī)') {
// 省略部分代碼
} // end stage
stage('清理資源') {
// 省略部分代碼
} // end stage
stage('清理環(huán)境') {
steps {
dir("${terraformTemplatePath}") {
sh """
${terraformPath} destroy -auto-approve -var-file="${terraformVars}"
"""
}
} // end steps
} // end stage
stage('發(fā)送報(bào)告') {
// 將Markdown格式報(bào)告發(fā)送至釘釘，包含執(zhí)行結(jié)果和執(zhí)行時(shí)間
} // end stage
} // end stages
} // end pipeline
通過(guò)對(duì)每一階段的定義，能夠清晰的了解每一階段執(zhí)行的結(jié)果以及失敗的原因，最終將結(jié)果發(fā)送至釘釘中，及時(shí)了解當(dāng)前代碼的穩(wěn)定性。
異常處理
在整個(gè)自動(dòng)化測(cè)試流程中，如果在中間任何一個(gè)步驟失敗，都需要對(duì)資源進(jìn)行及時(shí)清理，避免對(duì)下一次測(cè)試的影響。所以定義一個(gè)全局的失敗，進(jìn)行強(qiáng)制資源清理。
post {
failure {
// TODO(Ray): 目前暫未加入清理目標(biāo)端資源的邏輯
// 全局異常處理，保證源端和目標(biāo)端不殘留資源
dir("${terraformTemplatePath}") {
sh """
${terraformPath} destroy -auto-approve -var-file="${terraformVars}"
"""
}
} // end failure
} // end post
總結(jié)
目前，在HyperBDR的日常開(kāi)發(fā)中，我們還在不斷完善自動(dòng)化測(cè)試的場(chǎng)景，但是經(jīng)過(guò)這一輪的實(shí)現(xiàn)，讓我對(duì)自動(dòng)化測(cè)試有了全新的認(rèn)知。
自動(dòng)化測(cè)試能否實(shí)現(xiàn)全面覆蓋呢？至少在HyperBDR中不行，因?yàn)镠yperBDR的源端和目標(biāo)端造成了測(cè)試場(chǎng)景的不可預(yù)期性，很難完全通過(guò)自動(dòng)化腳本來(lái)模擬出復(fù)雜場(chǎng)景，特別是異常場(chǎng)景。例如：對(duì)源端主機(jī)內(nèi)部的破壞性測(cè)試，對(duì)數(shù)據(jù)傳輸鏈路的一些攻擊場(chǎng)景，需要配合監(jiān)控才能發(fā)現(xiàn)是否滿足預(yù)期。這些場(chǎng)景，利用自動(dòng)化測(cè)試模擬開(kāi)發(fā)代價(jià)太大，而且可能發(fā)生的場(chǎng)景還在不斷變化，根本無(wú)法滿足版本快速迭代的需求。當(dāng)然你如果有一個(gè)幾百人的研發(fā)團(tuán)隊(duì)，專門(mén)做這件事情，那另當(dāng)別論，不過(guò)這樣的投入產(chǎn)出比是否合理，值得探討。
自動(dòng)化測(cè)試中，哪些該”自動(dòng)“，哪些該”手動(dòng)“？在實(shí)現(xiàn)自動(dòng)化測(cè)試過(guò)程中，不要盲目的追求”自動(dòng)“。自動(dòng)程度越高，開(kāi)發(fā)成本越高，靈活性大打折扣，導(dǎo)致可利用的場(chǎng)景較少，這反而與預(yù)期相違背。以HyperBDR場(chǎng)景為例，倒不如將每個(gè)流程進(jìn)行切分，實(shí)現(xiàn)局部自動(dòng)化，實(shí)現(xiàn)多個(gè)工具形成工具集，再用流程串聯(lián)方式構(gòu)建場(chǎng)景化。
后續(xù)的計(jì)劃有哪些？隨著產(chǎn)品不停的迭代，自動(dòng)化測(cè)試還將不斷的擴(kuò)展，除了支持代理方式，還會(huì)增加對(duì)無(wú)代理方式、塊存儲(chǔ)方式自動(dòng)化的支持，但是這些的開(kāi)發(fā)模式全部以上述框架為前提。上述測(cè)試主要還是針對(duì)接口的測(cè)試，對(duì)于前端的測(cè)試還將引入Selenium實(shí)現(xiàn)，實(shí)現(xiàn)的范圍仍然以主線流程為主。最后，逐步豐富數(shù)據(jù)測(cè)試場(chǎng)景，增加對(duì)數(shù)據(jù)完整性的測(cè)試。
隨著DevOps理念逐步改變傳統(tǒng)研發(fā)流程，自動(dòng)化測(cè)試作為其中的一環(huán)也是必不可少的，也是未來(lái)開(kāi)發(fā)人員必備的技能之一。但是自動(dòng)化測(cè)試不同于產(chǎn)品研發(fā)，要學(xué)會(huì)”斷“的思想，理解測(cè)試的需求和場(chǎng)景，才能做出適配性最好的自動(dòng)化測(cè)試工具。
分享文章：創(chuàng)新互聯(lián)災(zāi)備產(chǎn)品HyperBDR自動(dòng)化測(cè)試實(shí)踐
網(wǎng)頁(yè)鏈接：http://m.fisionsoft.com.cn/article/cdgphje.html
