HyperBDR是一款基于云原生理念的遷移和容災(zāi)產(chǎn)品，核心的業(yè)務(wù)場(chǎng)景是將源端以塊級(jí)別差量方式同步至云原生存儲(chǔ)中，目前已經(jīng)實(shí)現(xiàn)對(duì)塊存儲(chǔ)和對(duì)象存儲(chǔ)支持，最后再利用Boot-in-Cloud專(zhuān)利技術(shù)將業(yè)務(wù)系統(tǒng)一鍵式恢復(fù)至可用狀態(tài)，真正做到了對(duì)云原生編排能力的充分利用，滿足遷移和災(zāi)備等業(yè)務(wù)場(chǎng)景的不同需求。

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è)(公有云、專(zhuān)有云、私有云、超融合、虛擬化等)，并且數(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ǔ)類(lèi)型，啟動(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ǔ)類(lèi)型分為塊存儲(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" {
  # 注意此處的類(lèi)型為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)行分離，即基類(lèi)中進(jìn)行執(zhí)行，而子類(lèi)中只需要定義相關(guān)具體的任務(wù)即可。

基類(lèi)代碼示例如下：

import taskflow.engines
from taskflow.patterns import linear_flow as lf
class BaseTask(object):
    # 此處有代碼省略
    
    def run(self, tasks=[], *args, **kwargs):
        # 子類(lèi)只需要在繼承類(lèi)中定義好自己的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è)具體的子類(lèi)實(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ì)，專(zhuān)門(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è)試工具。