クラウドネイティブ災害復旧製品 HyperBDR の自動テスト実践

HyperBDR は、クラウド ネイティブ コンセプトに基づいた移行および災害復旧製品です。コアビジネスシナリオは、ブロックレベルの差分方式でソースエンドをクラウドネイティブストレージに同期することです。現在、ブロックストレージとオブジェクトストレージのサポートを実現しています。最後に、特許取得済みの Boot-in-Cloud テクノロジーを使用して、ワンクリックでビジネス システムを使用可能な状態に復元し、クラウド ネイティブのオーケストレーション機能を最大限に活用して、移行や災害復旧などのビジネス シナリオのさまざまなニーズに対応します。

HyperBDRは現在、ソースオペレーティングシステムの約10のメジャーバージョンをサポートしています（
対象OSはWindows/CentOS/Redhat/Ubuntu/SUSE/国産OSなど数百種類以上、マイナーバージョンも数百種類以上をサポートしており、対象クラウドプラットフォームも40種類近く（パブリッククラウド、プロプライエタリクラウド、プライベートクラウド、ハイパーコンバージェンス、仮想化など）をサポートしており、その数は今も増え続けています。ソース オペレーティング システムからすべてのクラウド プラットフォームまでカバレッジ テストを実行すると仮定すると、合計テスト ケースは 10,000 を超える可能性があります。

このような大規模な状況では、テスト範囲を達成するために人力だけに頼るのは明らかに非現実的です。コアビジネスシナリオをテストするには、自動テスト方法を導入する必要があります。これにより、自動テストのニーズを満たすだけでなく、開発者は日々の開発中に新しく開発された機能がコアプロセスに与える影響を迅速に把握できるようになり、製品の安定性と信頼性がさらに向上します。

問題点分析

まず、手動テストによる HyperBDR 製品テストの問題点を見てみましょう。

問題点1: テストケースが多すぎることと人材が不足していること

前述のソース側とターゲット側の規模では、基本的なスモーク テストをいくつか実行したとしても、完全なテストには 100 を超えるシナリオが残ります。例えば：

• • ソース（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、国産OS
• • 対象エンド（9種類）：OpenStack、AWS、Alibaba Cloud、Tencent Cloud、Huawei Cloud、Mobile Cloud、ZStack、ハイパーコンバージド製品、ハイパーコンバージド製品

このように計算すると、テストには 171 のシナリオがあります。ユースケースはそれほど多くなく、一度実行するのにそれほど時間はかからないと言う学生もいるかもしれません。そこで、テスト プロセスにおける HyperBDR の 2 番目の問題点であるテスト サイクルの問題について見てみましょう。

問題点2: テストサイクルが長い

ビジネス テストとは異なり、HyperBDR の単一シナリオのテストには非常に時間がかかります。初期のリソース準備時間とさまざまな構成時間を無視して、データの同期と起動プロセスのみを分析してみましょう。

• • データ同期: 簡単に言えば、データ同期のプロセスは、ソース オペレーティング システム内の有効なデータ (割り当てられた容量ではない) をブロック レベルで読み取り、ターゲットのクラウド ネイティブ ストレージに書き込むことです。そのうち初回は全額、次回以降は永久増額となります。 Windowsを例にとると、実効データが500Gと仮定し、ギガビットLAN帯域の使用率80%で計算すると、伝送速度は約800Mbps、約80MB/sとなり、所要時間は約1時間8分となります。
• • ホストの起動: 起動時間はクラウド ネイティブ ストレージの種類によって大きく異なります。たとえば、Huawei Cloud のブロック ストレージにはスナップショット メカニズムがあり、システム ディスクのスワップをサポートしているため、起動時間は基本的に容量とは関係なく、基本的に 5 分以内に制御できます。しかし、ほとんどの国内クラウド プラットフォームにはそのような機能がありません。たとえば、Alibaba Cloud がスナップショットからボリュームを生成する場合、基礎となる速度制限は 40 MB/秒であり、これによりリカバリプロセスが大幅に長くなります。オブジェクトストレージを例に挙げてみましょう。内部ネットワークからオブジェクト ストレージ データをブロック ストレージに復元するとします。 500G の有効なデータ ディスクの回復時間は約 40 分です。

したがって、単一のホストでテストを処理する必要があり、これには少なくとも 2 時間かかります。上記で想定したシナリオによれば、1 日のテストの後でも、1 つのクラウドの完全なテストを完了できない可能性があります。おそらく、ここにいる学生の中には、なぜ並行処理を行わないのかと尋ねる人もいるでしょう。ここで、3 番目の問題点であるコストについて考えます。

問題点3: テストコスト

同時実行性を完全に採用できない理由は、ネットワーク帯域幅の制限によるものです。当社の社内研究開発環境では、外部ネットワーク帯域幅はわずか 40Mbps です。上記のテストシナリオでは、帯域幅をフルに活用することを前提として、500G データの完全なデータ伝送時間は約 35 時間です。これにより、テスト サイクルがさらに延長されることは間違いありません。

もう 1 つのポイントは、ソース側に非常に多くの環境があり、さまざまなシナリオが追加された場合、ソース側で必要なコンピューティング リソースとストレージ リソースが膨大になるということです。製品が繰り返し改良されるにつれて、占有されるリソースはますます増えていきます。そこで、この問題を解決するために、ローカルリソースの不足の問題を解決するためにパブリッククラウド環境を導入することにしました。リソース使用の特性に基づいて、最適なコストを実現するために従量課金制をメインに採用しています。実際のテストプロセス中に生成される主なクラウド リソースには、コンピューティング、ブロック ストレージ、オブジェクト ストレージ、ネットワークなどがあります。自動テストでは、リソース サイクルを可能な限り短縮し、無駄を回避し、リソースをタイムリーにクリーンアップします。さらに、リソースの残留を回避するために、リソースの課金を監視する必要があります。

需要分析

基本原則: 車輪の再発明はしない

新たな開発者を追加することなく、自動テストの開発作業が実行されました。開発作業は主に R&D チームによって行われ、テスト チームはユーザーとして機能します。ただし、開発チームには独自の製品開発タスクがあるため、製品開発に影響を与えないようにするために、車輪の再発明ではなく、既存の技術蓄積とサードパーティのコンポーネントを可能な限り再利用して、自動テストの目標を柔軟に達成するという最初の原則が策定されました。

要件1: ソースエンドの自動作成と破棄

最初に解決すべきことは、ソース リソースの柔軟な作成です。これを行う最も簡単な方法は、Terraform を使用してさまざまなテンプレートを組み合わせて、ソース リソースを作成および破棄する機能を実装することです。このようにして、ソースエンドとして、少なくとも Alibaba Cloud、Huawei Cloud、AWS、OpenStack、VMware の 5 つの主要クラウドの機能が揃います。

解決すべき2番目の課題は、エージェントを使用した自動登録の問題です。後続のプロセスで HyperBDR によって認識されるには、ソース サーバーにエージェントをインストールして登録する必要があります。オペレーティングシステムによって、Linux と Windows システムに分かれます。 Linux では、SSH を使用してシステムにログインし、インストールを実行できます。一方、Windows では、WinRM を使用してエージェントをインストールできます。

3 番目に、スケーラビリティにより、シナリオベースのニーズをより多く満たすことができます。 Terraform 自体はリモート実行モードを提供していますが、その後のスケーラビリティのために、Ansible と組み合わせて関連機能を実装することができます。将来のテスト シナリオには、ソース側でのさまざまなアプリケーション データの整合性のテストも含まれる可能性があります。この場合、ソース側の準備時に追加のアプリケーションとデータの準備が必要になります。 Terraform と Ansible を組み合わせて使用​​すると、最大限の柔軟性を実現できます。

要件2: スケーラビリティ要件を満たすためにテストシナリオをテストツールから分離する

簡単に言えば、テストの自動化の度合いが高くなるほど、開発コストが高くなり、その後のメンテナンスのコストも高くなります。したがって、自動テストを計画する際には、テスト シナリオとテスト ツール間の結合を減らす必要があります。これは、テスト シナリオのスケーラビリティを最大化する唯一の方法です。つまり、テスト シナリオはテスト ツールの柔軟な組み合わせによって実装され、両者のギャップはさまざまな構成ファイルを通じて統合されます。

具体的には、HyperBDR の自動テスト計画では、シナリオを次のように定義します。

• • メインプロセスの安定性を検証するために、Alibaba Cloud の CentOS 7 オペレーティングシステムホストが Alibaba Cloud オブジェクトストレージに対して耐災害性を備えているというシナリオを設計しました。このデータを使用することで、ホストは正常に起動できます。システムが起動すると、IP アドレスを正常に ping でき、SSH でシステムに正常にログインしてファイルを書き込むことができます。
• • Huawei Cloud ドライバーの安定性を検証するために、次のシナリオを設計しました。Alibaba Cloud の N 台のホスト (さまざまなバージョンのオペレーティング システムを含む) が Huawei Cloud のオブジェクト ストレージまたはブロック ストレージに対して耐障害性を備え、その後、ホストが Huawei Cloud 上で起動されます。起動後、IPアドレスをpingしてシステムに通常通りログインし、ファイルを書き込むことができます。
• • 増分データを検証するために、Alibaba Cloud の N 台のホストにデータベースをインストールし、記録用に一定量のデータを構築し、それを Huawei Cloud Object Storage に復元するというシナリオを設計しました。次に、Huawei Cloud でホストを起動します。起動後は、定期的な検証に加えて、データベースにアクセスできるかどうかやデータレコードの数を比較する必要もあります。

テスト ツールによって提供される機能を次のように定義します。

• • ソース側でのリソースの作成/削除: これは Terraform によって完全に実装されています。ただし、後続のプログラムとの接続を改善するために、後続のコマンドの入力としてホストが生成された後に conf ファイルが自動的に生成されます。ホスト内のさまざまなアプリケーションは、Ansible テンプレートを記述することによって実装されます。
• • ターゲット プラットフォームの構成/データ同期/ホストの起動/リソースのクリーンアップ: これらの部分は主に HyperBDR SDK を呼び出すことによって実装され、具体的な構成は構成ファイルで変更されます。シナリオが異なる場合は、それを実装するために必要なのは異なる構成ファイルだけです。

上記のすべての手順は個別に実行でき、各手順が完了したら統合された CSV ファイルに書き込むことで、接続時にこのファイルを通じて手順を統合できるようになります。その後、CSV ファイルをデータ視覚化ツールに直接プッシュして、トレンド表示効果を作成できます。

要件3: シナリオの自動化とテスト失敗のタイムリーな通知を実現する

実際のアプリケーションでは、このツールは研究開発から納品までのほぼすべてのプロセスで必要になります。たとえば、R&D の同僚は、コードを提出する前に基本プロセスを少なくとも 1 回テストする必要があります。デリバリー担当者もスクリプトを使用して、デモ環境を構築する際の効率を向上させることができます。テスト担当者の間ではこのツールに対する強い要望があります。

さまざまなシナリオでの実際の自動化作業は、Jenkins タスクによって連続して完了し、テストが失敗した後、全員に時間内に通知され、できるだけ早く変更を加えることができます。たとえば、メイン プロセスの安定性を確認するために、1 時間ごとに小規模なスモーク テストを実行します。クラウド プラットフォームの安定性を確認するために、毎朝基本的なスモーク テストを実行します。メインのオペレーティング システム バージョンの安定性を確認するために、週に 1 回大規模なスモーク テストを実行します。これにより、人的リソースを節約できるだけでなく、バ​​ージョン内の不安定な要因をできるだけ早く発見できるようになります。

実装

全体的なアーキテクチャ

上記の要件に従って、完全なツールは次の 2 つの部分で構成されます。

• Terraform: 主に、ソース側の作成に使用されるテンプレートと Ansible プレイブックが含まれます。各実行後、Terraform は AutoTest ツールのコマンド ライン入力パラメータのソース ホストのリストを自動的に生成します。
• AutoTest ツール: Python で開発され、主に HyperBDR SDK を呼び出して HyperBDR を制御し、自動プロセス スケジューリングを実現します。各ステージは独立したコマンドラインによって制御され、すべての変数部分は構成ファイルで変更されます。
• AutoTest 構成ファイルには、次の 3 つの部分が含まれています。

• 基本構成: HyperBDR SDK 認証情報と全体的なプラットフォーム構成
• ターゲットクラウドプラットフォームの構成：ターゲットクラウドプラットフォームの認証情報、構成パラメータなど。ストレージの種類に応じてブロックストレージとオブジェクトストレージに分かれています。
• 災害復旧/移行構成: ターゲット側のホスト起動パラメータを定義するために使用されます

Terraformはリソースを作成し、リモートでコマンドを実行します

Terraform の使い方については多くのチュートリアルがあるので、ここでは詳しく説明しません。ここでは主に、Terraform と AutoTest 間のスクリプト連結を実現するために Terraform が使用するいくつかの詳細な機能について説明します。

組み込みメソッド remote-exec

Terraform はリソースを作成すると、エージェントを自動的にインストールし、HyperBDR に登録します。リモート ホスト操作の複雑さを軽減するには、新しく作成されたホストにエージェントをアップロードし、自動登録のためにインストールします。

Terraform 自体は、プロビジョナーを通じてリモート接続、アップロード、実行を提供します。基本的な構造は次のとおりです。

リソース"null_resource" "ins_centos7_run_remote_command" {
 # パスワードまたはキーで接続できるSSH接続方法を定義します
 繋がり{
 タイムアウト= "5分"
 タイプ= "ssh"
 ユーザー= "root"
 パスワード= "${ランダムパスワード.パスワード.結果}"
 ホスト= "${openstack_compute_instance_v2.ins_centos7.network[0].fixed_ip_v4}"
 }
 #ローカルファイルをリモートリソースのディレクトリにアップロードする
 プロビジョナー「ファイル」 {
 ソース= "../downloads/linux_agent.sh"
 宛先= "/tmp/script.sh"
 }
 # リモートからスクリプトを実行する- exec
 プロビジョナー「リモート実行」 {
 インライン= [
 「chmod +x /tmp/script.sh」 、
 「sudo bash /tmp/script.sh」 、
 ]
 }
 依存先= [ openstack_compute_instance_v2 .ins_centos7 ]
 }

Windowsの場合、接続方法はwinrmとなります。ここで注意すべき点は、開始されたリソースで WinRM が有効になっている必要があることです。有効になっていないと、このメソッドは接続に使用できません。 WinRM を有効にする 1 つの方法は、ユーザー データ メソッドを使用することです。具体的な例を挙げます

リソース"null_resource" "run_windows_remote_command" {
 # ここでの型は winrm であることに注意してください
 繋がり{
 タイムアウト= "5分"
 タイプ= "winrm"
 ユーザー= "管理者"
 パスワード= "${ランダムパスワード.パスワード.結果}"
 ホスト= "${openstack_compute_instance_v2.ins_windows.network[0].fixed_ip_v4}"
 https =真
 安全でない=本当
}
 # ディレクトリが指定されている場合は、ディレクトリ全体がアップロードされますが、Windows ディレクトリのスラッシュ方向に注意してください。ドライブ文字を転送する必要があります C : \\
 プロビジョナー「ファイル」 {
 ソース= "../downloads/Windows_server_64bit_beta"
 宛先= "C:\\Windows_server_64bit_beta"
 }
 # リモート実行方法はLinuxと同じ
 プロビジョナー「リモート実行」 {
 インライン= [
 「C:\\Windows_server_64bit_beta\\install-cli.bat」 、
 「net start DiskSyncAgent」 、
 ]
 }
 依存先= [ openstack_compute_instance_v2 .ins_windows ]
 }

Ansibleとの統合

Terraform のリモート実行方法を直接使用するのは簡単ですが、より複雑なシナリオをサポートするには柔軟性が足りないため、リソースの制御を強化するために Ansible を導入します。 remote-exec に対応するコマンドは local-exec で、ローカルの Ansible コマンドを実行してリモート リソースを制御します。ディレクトリ構造は次のとおりです。

 。
 ├── main.tf
 ├── プレイブック
│ └── apache -インストール.yml

Ansible Playbook は、Terraform で次のように実装された別のディレクトリに保存されます。

リソース"null_resource" "run_ansible" {
 繋がり{
 タイムアウト= "5分"
 タイプ= "ssh"
 ユーザー= "root"
 パスワード= "${ランダムパスワード.パスワード.結果}"
 ホスト= "${huaweicloud_vpc_eip.myeip.address}"
 }
 # ここで local - exec は Ansible コマンドをローカルで実行するために呼び出されます
 プロビジョナー「local-exec」 {
 コマンド= "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"
 }
 依存= [ huaweicloud_compute_eip_associate .related ]
 }

出力

Terraform と AutoTest を接続するには、実行ごとに基本的な情報を含むホスト リストを Terraform が出力する必要があります。もちろん、これは Ansible Inventory ファイルとしても使用できます。 local_file リソースを使用して、ファイルに書き込みたいコンテンツを直接出力します。具体的な実装は以下のとおりです。

リソース"local_file" "inventory" {
 ファイル名= "./sources.conf"
 コンテンツ= <<- EOF
 [ $ { openstack_compute_instance_v2 .ins_centos7 .network [ 0 ] .fixed_ip_v4 } ]
 ユーザー名= centos
 パスワード= $ {非機密( 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 }
 秘密鍵= "${abspath(path.module)}/../keys/openstack_linux.pem"
 os = CentOS7
 終了
}

Terraform ローカル キャッシュ

よく知られている理由により、Terraform は init コマンドを実行するときに GitHub にアクセスするため、インストール プロセス中に失敗する可能性が一定程度発生します。障害のリスクを軽減するためには、ネットワークへのアクセスによって生じるリスクを回避するためにローカル キャッシュを使用する必要があります。まずディレクトリ構造を見てみましょう。

 。
 ├── install.sh
 ├── プラグイン-キャッシュ
│ └── レジストリ.terraform .io
 │ ├── ハシコーポレーション
│ │ ├── ローカル
│ │ ├──ヌル
│ │ ├── ランダム
│ │ ├── テンプレート
│ │ └── tls
 │ ├── ファーウェイクラウド
│ │ └── ファーウェイクラウド
│ └── terraform -プロバイダー- openstack
 │ └── オープンスタック
├── README.md
 ├── terraform_1 .3 .7_linux_amd64 .zip
 └── update_plugins_cache .sh

install.sh は、ダウンロードした terraform バイナリ パッケージを解凍してインストールし、plugins-cache を $HOME/.terraform.d ディレクトリにコピーし、最後に .terraformrc ファイルを生成するために使用されます。

 plugin_cache_dir = "$HOME/.terraform.d/plugins-cache"

実際の実行では、ほとんどのオンライン ドキュメントには記載されていないパラメータを指定してローカルでインストールが実行されます。

 terraform init -無視-リモート-バージョン

plugins-cache を構築するときは、主に terraform provider mirror コマンドを使用します。次に例を示します。

 terrform プロバイダーは、 / path / to / your / plugins - cache をミラーリングします

この目的のために、キャッシュを自動的に更新するスクリプトをプロジェクトに追加しました。

 # !/ bin / bash
 #
 # このスクリプトはローカルからTerraformをインストールするために使用されます
#
セット- 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 ) :すべてのTerraformディレクトリとキャッシュプロバイダーを検索します
for dir in $ ( $SRC_ROOT_PATH を検索- d と入力) ;する
 "$dir"内のファイルの場合/*tf;する
 [ -f "$file" ]の場合;それから
 echo "$dir で terraform キャッシュを実行します..."
 $TERRAFORM_CLI プロバイダーは $PLUGINS_CACHE_PATH をミラーリングします
 壊す
 フィ
 終わり
終わり

タスクフローは実行プロセスをシリアル化してスケーラビリティを実現します

AutoTest ツールの開発中は、開発を簡素化するために、主に OpenStack のいくつかの Python モジュールを再利用しました。使用された主なモジュールは stevedore と taskflow でした。また、CSV ファイルの操作を簡略化するために、操作には pandas ライブラリを使用しました。

ドライバーモードを使用してコマンドラインを拡張する

setup.cfg では、次のドライバーを定義します。各命令は、タスクフローの実行プロセスに対応します。

タスク=
 cloud_config_oss =自動テスト.tasks .cloud_config : CloudConfigOss
 cloud_config_block = autotest .tasks .cloud_config : CloudConfigBlock
 cloud_config_clean =自動テスト.tasks .cloud_config : CloudConfigClean
 data_sync_oss =自動テスト.tasks .data_sync : DataSyncOss
 data_sync_block = autotest .tasks .data_sync :データ同期ブロック
 host_boot = autotest .tasks .host_boot :ホストブート
 host_clean = autotest .tasks .host_clean :ホストクリーン
 report = autotest .tasks .report :レポート

コードがロードされると、異なるパラメータを入力することで、対応するパイプラインが動的にロードされます。

 def run_tasks ( args 、 hosts_conf 、 hyperbdr_conf ) :
 「各タスクをドライバーとしてロードする」
 # データテーブルとしてcsvを使用します
 data_table = DataTable ( hosts_conf 、 args .work_path )
 データテーブル.init ( )
 status_file =ステータスファイル( args .work_path )
 ステータスファイル.init ( )
 ドライバー名= args .which .replace ( "-" , "_" )
 ログ記録.info ( "%s のタスク ドライバーをロードしています..." % driver_name )
 # 異なるコマンドライン名に従って関連するドライバーをロードします
 driver_manager =ドライバー.DriverManager (
 名前空間= "タスク" 、
 名前=ドライバー名、
 ロード時に起動= False )
 task_driver = driver_manager .driver ( hyperbdr_conf 、 data_table 、 status_file )
 タスクドライバ.run ( )

タスクフローを使用してプロセスを接続する

Taskflow は OpenStack の非常に優れたライブラリです。タスク実行プロセスを抽象化し、上位層の順次ビジネス シナリオの使用を容易にします。そのため、アプリケーションにおける開発プロセスを簡素化するために、タスクフロー上で適切な抽象化を行い、実行プロセスと実行内容を分離します。つまり、実行は基本クラスで実行され、関連する特定のタスクのみをサブクラスで定義する必要があります。

基本クラスのコード例は次のとおりです。

タスクフロー.enginesをインポートする
タスクフロー.patternsからlinear_flowをlfとしてインポートします
クラス BaseTask (オブジェクト) :
 # ここではコードを省略

 def run ( self 、タスク= [ ] 、 * args 、 ** kwargs ) :
 # サブクラスは継承したクラス内で独自のタスクを定義するだけでよい
 タスクでない場合:
 NotImplementedError を発生させます( "run() メソッド "
 「実装されていません」 ）
 # .......

 フロー名= self .__class__ .__name__
 flow_api = lf .Flow (フロ​​ー名)
 タスク内のタスクの場合:
 flow_api .add (タスク)
 試す：
 タスクフロー.エンジン.run ( flow_api 、
 engine_conf = { "エンジン" : "シリアル" } ,
 ストア= {
 # パラメータの受け渡し
} ）
 except 例外を eとして:
 eを上げる
 ついに：
 # データの記録など、タスク失敗後の処理

具体的なサブクラスの実装は次のとおりです。

タスクフローからタスクをインポート
autotest .tasks .baseからBaseTask をインポートします
クラス CloudConfigOss ( BaseTask ) :
 def run ( self 、 * args 、 ** kwargs ) :
 ステップ= [
 クラウドアカウントの追加( ) 、
 WaitCloudAccount ( ) 、
 アッドオス（ ） ,
 ]
 super ( ) .run ( )ステップ
クラス AddCloudAccount (タスク.Task ) :
 # やるべきこと
クラス WaitCloudAccount (タスク.Task ) :
 # やるべきこと
クラス AddOss (タスク.Task ) :
 # やるべきこと

上記の抽象化により、HyperBDR SDK を使用してさまざまなアプリケーション シナリオを迅速に実装し、その後のスケーラビリティ要件を最大限に満たすことができます。

Jenkins シリアル自動テストプロセス

ツールを実装すると、手動でのステップバイステップ実行のニーズを満たすだけでなく、Jenkins を使用してプロセスを接続して、シナリオ自動化テストのニーズを満たすこともできます。

シーンオートメーション

自動シナリオテスト用に、git に autotest-cases という名前の新しいプロジェクトを作成します。例の構造は次のとおりです。

 。
 ├── ジェンキンスファイル
├── openstack_oss_qa_tiny_smoke
 │ ├── hyperbdr.conf
 │ └── terraform_templates

ディレクトリにはシナリオに基づいて名前を付け、各ディレクトリには個別の Terraform テンプレートと hyperbdr 構成ファイルのセットが含まれます。このように Jenkins タスクを定義すると、テストシナリオをディレクトリとして扱い、柔軟に読み込むことができます。

Jenkinsifle の基本構造は次のとおりです。

パイプライン
//一部のコードを省略
 パラメータ{
 弦（
 名前: 'TEST_CASE' 、
 デフォルト値: 'openstack_oss_qa_tiny_smoke' 、
 説明: 'テストタスクが実行されるディレクトリ。autotest-cases のディレクトリに対応します'
 ）
 弦（
 名前: 'HYPERBDR_URL' 、
 デフォルト値: 'https://xxxx' 、
 説明: 「HyperBDR アドレス、認証情報と一緒に使用する必要があります」
 ）
 //一部のコードを省略
}
 ステージ{
 ステージ( 'リポジトリのクローン' ) {
 //一部のコードを省略
} //終了ステージ
 ステージ( 'HyperBDR 環境の更新' ) {
 //一部のコードを省略
} //終了ステージ
 ステージ( 'ダウンロードエージェント' ) {
 //一部のコードを省略
} //終了ステージ
// Terraform tfvarsファイルで認証情報が固定されている場合、Jenkinsでの使用時に認証情報に置き換えられます。
 ステージ( 'ソースを作成' ) {
 手順{
 //各ディレクトリの認証ファイルを置き換えた後、ソースは環境変数を宣言します
 withCredentials ( [ usernamePassword ( credentialsId : "${CLOUD_CREDENTIALS_ID}" 、 usernameVariable : 'USERNAME' 、 passwordVariable : 'PASSWORD' ) ] ) {
 sh "" "
 sed -i " s / JENKINS_CLOUD_USERNAME / $ {ユーザー名} / g " " $ { terraformVars } "
 sed -i " s / JENKINS_CLOUD_PASSWORD / $ {パスワード} / g " " $ { terraformVars } "
 「 」
 }
 dir ( "${terraformTemplatePath}" ) {
 sh "" "
 ${terraformPath} を init -ignore-remote-version -plugin-dir ~/.terraform.d/plugins-cache します
 ${terraformPath} を適用 -auto-approve -var-file=" $ { terraformVars } "
 「 」
 }
 } //終了手順
} //終了ステージ
 stage ( 'ターゲットプラットフォームの構成' ) {
 //一部のコードを省略
} //終了ステージ
 ステージ( 'データ同期' ) {
 //一部のコードを省略
} //終了ステージ
 ステージ( 'ホストの開始' ) {
 //一部のコードを省略
} //終了ステージ
 ステージ( 'リソースのクリーンアップ' ) {
 //一部のコードを省略
} //終了ステージ
 ステージ（ 「環境をクリーンアップする」 ） {
 手順{
 dir ( "${terraformTemplatePath}" ) {
 sh "" "
 ${terraformPath} を破棄 -auto-approve -var-file=" $ { terraformVars } "
 「 」
 }
 } //終了手順
} //終了ステージ
 ステージ( 'レポートを送信' ) {
 //実行結果と実行時間を含むMarkdown形式のレポートをDingTalkに送信します
} //終了ステージ
} //終了ステージ
} //パイプライン終了

各段階を定義することで、各段階の結果と失敗の理由を明確に理解できます。最後に、結果を DingTalk に送信して、現在のコードの安定性をタイムリーに把握できます。

例外処理

自動テストプロセス全体において、いずれかのステップが失敗した場合は、次のテストに影響が及ばないように、リソースを時間内にクリーンアップする必要があります。したがって、リソースのクリーンアップを強制するためにグローバル障害が定義されます。

役職{
 失敗
// TODO ( Ray ) :現在、ターゲットリソースをクリーンアップするロジックは追加されていません
//ソース側とターゲット側にリソースが残っていないことを確認するためのグローバル例外処理
 dir ( "${terraformTemplatePath}" ) {
 sh "" "
 ${terraformPath} を破棄 -auto-approve -var-file=" $ { terraformVars } "
 「 」
 }
 } //失敗終了
} //投稿終了

要約する

現在、HyperBDR の日常的な開発では、自動テストのシナリオを継続的に改善していますが、今回の実装を経て、自動テストに対する新たな理解が得られました。

自動テストは完全なカバレッジを達成できますか?少なくとも HyperBDR ではそうではありません。HyperBDR のソース側とターゲット側によってテスト シナリオが予測不可能になり、自動化されたスクリプトを通じて複雑なシナリオ、特に異常なシナリオを完全にシミュレートすることが困難だからです。たとえば、ソース ホストの破壊テストやデータ転送リンクに対する一部の攻撃シナリオでは、期待どおりに動作しているかどうかを確認するために監視が必要です。これらのシナリオでは、自動テスト シミュレーションを使用した開発コストが高すぎるうえ、考えられるシナリオが絶えず変化するため、迅速なバージョン反復のニーズを満たすことができません。もちろん、これに専任する数百人規模の研究開発チームがある場合は、話は別です。しかし、このような投入産出比率が合理的であるかどうかは議論する価値がある。

自動テストでは、どれを「自動化」し、どれを「手動」にすればよいのでしょうか?自動テストを実装するときは、盲目的に「自動化」を追求しないでください。自動化の度合いが高くなるほど、開発コストが高くなり、柔軟性が低下し、結果として利用可能なシナリオが少なくなり、予想に反することになります。 HyperBDR シナリオを例にとると、各プロセスを分割して部分的な自動化を実現し、複数のツールでツールセットを形成し、プロセスを直列に接続してシナリオを構築するのがよいでしょう。

今後の計画は何ですか?製品が繰り返し改良されるにつれて、自動テストは拡大し続けます。エージェント方式のサポートに加えて、エージェントレスおよびブロック ストレージ自動化のサポートも強化されます。ただし、これらの開発モデルはすべて上記のフレームワークに基づいています。上記のテストは主にインターフェーステスト用です。フロントエンドテストにも Selenium が導入されますが、実装の範囲は依然としてメインラインプロセスが中心となります。最後に、データ テスト シナリオを徐々に充実させ、データ整合性に関するテストを追加します。

DevOps の概念が従来の研究開発プロセスを徐々に変化させていく中で、自動テストは不可欠な要素となり、将来の開発者にとって必須のスキルの 1 つとなっています。ただし、自動テストは製品開発とは異なります。最も適応性の高い自動テスト ツールを作成するには、「解釈」という考え方を学び、テストのニーズとシナリオを理解する必要があります。