検索のテストインフラストラクチャの自動化

手動と自動の両方のテストタスクが常に新しいテストベンチの作成を必要とすることは秘密ではありません。

Mail.Ru Searchの自動テストをすべての必要な環境で迅速に実行するには、特定の構成で新しい仮想マシンを迅速に展開する方法を学ぶ必要がありました。

クラウド内の多数の仮想マシンがWebDriverブラウザーファームによって使用され、スケーリングされ、Search Webインターフェイスのテストが高速化されます。

さらに、仮想マシンでは、コード品質のメトリックとカバレッジの測定値を収集するツール、および当社が開発した検索テストツールを起動します。

背景

すべては、KVMハイパーバイザーがインストールされ、libvirtが制御されている単一のサーバーで開始されました。 同時に、管理者がJiraのタスクを介して毎回新しい仮想マシンを手動で作成しました。 このようなプロセスにより、テスト部門のインフラストラクチャの効率と制御性にいくつかの制限が課されました。

時間が経つにつれて、Windows仮想マシンの数が増えると、ソリューションの信頼性が低下しました。定期的に、ゲストWindowsを持つVMがハングアップしたり、ホストマシンのCPU全体を使用したり、突然更新を更新して新しいブラウザーをインストールしたりしました。 環境が制御不能になり、手動で管理し続けることが不可能になりました。 タスクを分析した後、将来の仮想化プラットフォームが満たすべき要件の以下のリストをまとめました。

1. 管理用APIとそれを実装するライブラリの可用性
2. 仮想マシンのステータス管理
3. 仮想マシンのプロファイル管理（メモリ/ CPU /ディスク）
4. 異なるユーザーのクォータの管理（1人のユーザーが他の仮想環境のパフォーマンスに影響を与える可能性がある状況を取得したくありませんでした）
5. ディスクサブシステム管理（バックアップ/スナップショット）
6. ネットワーク管理
7. 水平スケーリング機能と必要なレベルのフォールトトレランス
8. 生活コミュニティ
9. 開発の見通し

決定の選択

要件を流行語で表現するために、プライベートクラウドを整理するためのIaaSソリューションを探していました。 これまで、多くのプラットフォームがこれらの要件に対応しています。 次のオープンソースソリューションに注目しました。

• Proxmox VE www.proxmox.com/proxmox-ve
• Xen www.xenproject.org
• OpenStack www.openstack.org
• ユーカリwww.eucalyptus.com
• Opennebula opennebula.org

見通し、ベンダーロックの欠如、コミュニティアクティビティの観点からこれらのプロジェクトを評価した後、OpenStackを選択しました。



OpenStackは多数のサービスであり、それぞれが機能の重要な部分を担っています。 個別のサービスには、承認、ブロックデバイス管理、ハイパーバイザー管理、および仮想マシン作成スケジューラが含まれ、ほとんどすべてのOpenStackコンポーネントはRESTful APIを備えたサービスです。 各サービスの構成を説明することは意味がありません。インフラストラクチャに割り当てられたタスクに依存します。 私たちが使用する主要なコンポーネントについて説明します。



-ハイパーバイザー：KVMを優先しました。 理由は一般的でした-それはコアに含まれています。 将来的には、これによりカーネルの更新に関する問題を回避できます。

-ブロックデバイスのバックエンドおよび仮想マシンイメージのストレージとして、Cephを選択しました。 決定の時点で、開発者は製品の準備が整っていないと述べたため、テストを非常に真剣に受け止めましたが、パフォーマンス/信頼性に問題はなかったため、そのままにしておくことにしました。 一般に、その時点でCephを使用することはOpenStackにとって非常にエキゾチックな構成でしたが、私たちのためにSwiftクラスターを上げることは無意味な作業のように思えました。

-ネットワーク仮想化のバックエンドとして、OpenVSwitchを選択しました。 当時（Grizzliリリース）OVSは、既存のVLAN上で機能する唯一のソリューションでした。



展開段階では、いくつかの困難に直面しました：2012年の終わりに、OpenStackはCentOSにそれほどスムーズに展開されませんでした。一般に、OpenStackはかなり複雑なエンジニアリング集約型製品であったため、管理者と一緒に、展開と構成に多大な労力を費やしました。

そのようなソリューションの実装に携わっている場合、そのニュアンスをすべて把握し、必要に応じて特定のサービスの実装の詳細を調べることができる専任の人がいる方が良いでしょう。



コンポーネントの相互作用のスキームは、次のようになります。

構成管理

すべてのサブシステムの展開とストレステストの後、ゲストシステムの構成を管理する方法の問題に直面しました。 構成管理ツールは最近耳にしたことがあるので、私の意見では、各ツールを詳細に説明することは意味がありません。

ただし、次のシステムが候補リストに含まれていました。

• SaltStack saltstack.org
• Opscode Chef www.getchef.com
• Puppet puppetlabs.com

私たちの重要な選択基準の1つは、Windows XPと連携できることです。これは、統計によると、ロシア市場のデスクトップシステムの中で確実に第2位を占めているためです。 Puppetはこの基準によりすぐに削除されました-その時点では、XPは公式ドキュメントにリストされていませんでした。

SaltStackは、その約束と個人的な同情（プロジェクトはPythonで書かれています）にもかかわらず、非常に粗雑であることが判明し、多くのことを独立して実装する必要があります（新しいノードのブートストラップ、cloud-initとの統合、Web APIの可用性など）プロジェクトがそれらに進化的に到達するのを待ちます。

最終的に、選択はシェフに委ねられました。

要件、ならびに競合他社（塩）を大幅に上回る開発およびコミュニティ活動のダイナミクス。



Chefでの作業は、Habréで何度も説明した古典的なアプローチと変わりません。knifeとknife-openstackプラグインを使用して、OpenStack API、ブートストラップWindowsノード用のknife-windows、通知プロセスと作業プロセスの編成用にknife-sporkを統合しますChef（静的分析、バージョン管理、Cookie /ロール/データのChefサーバーへのアップロード）。

テスト中

それとは別に、クックブックをテストおよびデバッグする方法について説明する価値があります。 Cookieをテストせずに、リポジトリにプッシュしたり、CookieをChefにアップロードしたりしません。 これらの目的のために、 vagrant www.vagrantup.comを使用します

-仮想マシンを作成してChef Cookieを適用するプロセスを自動化できます。 ところで、vagrantはChefとだけでなく、 他のCMS salt / puppet / cfengine / ansibleと統合することもできます。

一般的なアクセスでは、私たちに必要な浮浪者の箱がありません（ライセンスポリシーの性質上、これはWindowsによく当てはまります）、または箱を最初に組み立てる必要があります。 そのような場合は、veeweeを使用します。 Veeweeは、Vagrant Boxを準備するためのツールであり、ターゲットオペレーティングシステムのVagrant Boxファイルのアセンブリを自動化します。 私たちは積極的にveeweeを使用して、Windowsボックスの準備をテストし、Windowsの無人インストールをテストします。

ユースケース

では、この束はどのように機能しますか？ 最終的なユースケースをより明確にするために説明します。 どんな「生きている」タスクからも押し出しましょう。 たとえば、テストの目的で、Amigoブラウザをいくつかのターゲットプラットフォームに展開する必要があります。Windows7 / Windows XP / Windows Vista / Windows 8とします。

1. 最初に、これらのシステム用の浮浪者ボックスを準備します（まだない場合）。
2. 次に、これらの各システムへのAmigoのインストールを記述するクックブックを作成します（knife cookbook create ...）（場合によっては手順が統一され、オペレーティングシステムへの前提条件と依存関係を追加する必要がある場合があります）。
3. 次のステップは、私たちが作成したCookieがターゲットオペレーティングシステムのそれぞれに正しく展開されているか（浮浪者）を確認することです。
4. テスト後、Cookieとその依存関係をChefサーバーにアップロードします（ナイフスポークアップロード...）。
5. ロールを作成、記述、ロードします（ファイルからナイフロール...）。
6. 最後のステップは、ターゲットOSを使用して仮想マシンを作成し、それらにロールを割り当てます（ナイフOpenStackサーバー作成...）。 別の説明図：

数分後、自由に仮想マシンを構成し、そこで追加のテスト手順（手動と自動の両方）を実行できます。

私たちが得たもの

このインフラストラクチャへの移行により、コードに知識が蓄積されました。 これで、アプリケーションプロジェクトの展開方法に関する詳細なドキュメントを作成し、この知識を運用部門に転送する必要がなくなりました。 すべてはコードで記述されています（コードとしてのインフラストラクチャのイデオロギーに従うように努めています）。 展開手順（Vagrant）を自分でデバッグし、Veeweeを使用して新しいvagrantボックスを作成できます。 コードで文書化されたインフラストラクチャへの移行により、更新、スケーリング、および環境の障害からの回復のコストを削減できました。 さらに：

1. デスクトップ製品のテストを高速化する
2. カスタムレポート/テスト監視ツールのレイアウトを自動化します（継続的な配信プラクティスを積極的に適用します）
3. テスト部門が必要とするインフラストラクチャソリューション（ネクサス/ソナーなど）のセットアップ/レイアウトを高速化します。
4. 環境を作成および構成するためのシステム管理者のアイデア解決の手作業をチェーンから除外する

このソリューションがOpenSourceコンポーネントに基づいていることは間違いない利点のリストに追加することができます（Windows仮想マシン、MSDNサブスクリプションで受け取るライセンスを除く）。



将来の計画としては、Windowsを構築するためのChefおよびveeweeテンプレートのクックブックを公開する予定です（標準テンプレートとは若干異なります）。 このトピックがコミュニティの関心を引くものである場合、OpenStack（rackspace / hpcloud）用のWindowsイメージを準備する機能に関する記事を書く予定です。